Re: enable/disable flags in /etc/default

[Tollef Fog Heen]

]] Micah Anderson 

Hi,

| Also insserv is Priority: optional, so we can't count on that being on
| every system.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551745 is already
filed.  I have no idea why it hasn't been fixed yet, it looks like a
trivial change.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hbavznwg@qurzaw.varnish-software.com

Bug#619219: ITP: ruby-lapack -- Ruby wrapper for (C)LAPACK

[Youhei SASAKI]

Package: wnpp
Owner: Youhei SASAKI 
Severity: wishlist

* Package name: ruby-lapack
  Version : 0.4
  Upstream Author : Seiya Nishizawa and GFD-Dennou Club
* URL or Web page : 
http://www.gfd-dennou.org/arch/ruby/products/ruby-lapack/index.html
* License : Ruby's
  Description : Ruby wrapper for (C)LAPACK

Ruby-LAPACK is a Ruby wrapper for (C)LAPACK. This library is basically a
one-to-one interface to the original (C)LAPACK. 




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4frhowo.wl%uwab...@gfd-dennou.org

Re: enable/disable flags in /etc/default

[Micah Anderson]

Raphael Geissert  writes:
> That means:
> # mv /etc/rc2.d/S??apache2 /etc/rc2.d/K00apache2
> # insserv # this bit is not documented, it seems

Is using insserv directly really the right interface? Correct me if I am
wrong, but if you decided to opt-out of dependency-based initscripts,
wont insserv be useless? Also insserv is Priority: optional, so we can't
count on that being on every system.

micah


pgpsoOg6wYZn0.pgp
Description: PGP signature

Re: enable/disable flags in /etc/default

[Micah Anderson]

Tollef Fog Heen  writes:

> - install configuration using puppet/chef/cfengine/etc

Speaking of, the the changes that were made in Debian Squeeze to
update-rc.d to accommodate for dependency-based booting broke puppet’s
functionality to enable/disable services properly (#573551). Its not
clear the right way to do fix this bug at the moment, input would be
appreciated.

micah




pgpexF3LFlaNG.pgp
Description: PGP signature

Re: Need for automatic USB stick backup package

[Paul Wise]

On Mon, Mar 21, 2011 at 9:10 PM, Jeffrey Ratcliffe  wrote:

> Would such a package be useful?

I personally wouldn't use that script for a number of reasons:

It assumes that $HOME is /home/$USER

It assumes that the sysadmin hasn't already mounted something on /mnt

It mounts and backs up without any confirmation. The mount could
trigger unknown kernel vulnerabilities in filesystem code. Backing up
to random external USB devices could lead to information leakage.

vol_id doesn't seem to exist on Debian?

The progress dialog will not work when the user has gdm3 as a login manager.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTi=QLPqsnnTrpVGrCtw3=rjw9+2dc9w8t_gcq...@mail.gmail.com

Re: Library depending on -data packages

[Josh Triplett]

On Mon, Mar 21, 2011 at 05:18:00PM +0100, Luca Capello wrote:
> Given that I found this problem for the second time in the last 4
> months, I think this is worth a discussion on debian-devel@.

I agree.

> It seems that recently two library packages started to change their
> Recommends: to common data to a Depends:.  This after two bugs were
> reported by the same person, Josh Triplett (cc:ed, sorry for the spam),

I appreciate the CC.

> who asked for an explanation for the Recommends: (a reason which I find
> perfectly valid).  The two bugs are:
> 
>   
>   
> 
> When I found out about libm17n-0, I also found out that the change added
> a circular dependency and thus commented on this new bug why I think a
> library package should not depend on data packages:
> 
>   
> 
> And now, while looking again for that bug to be linked here, I found
> another occurrence of such a situation, reported almost one year ago [1]
> by Axel Beckert (cc:ed as well, again sorry for the spam):
> 
>   
> 
> [1] I remember that during one upgrade of emacs-snapshot I was surprised
> it pulled anthy-common, but then forgot about reporting it...
> 
> I see these situations as a misuse of Depends: where Recommends: would
> be perfectly fine, otherwise Recommends: are useless.  But given that it
> seems no one agrees with me, is such a behavior documented somewhere?

Some of these cases might require Depends, and some might require
Recommends.  I don't necessarily know why the libraries might need the
data packages, hence my bug reports asking for an explanation for the
Recommends.  I still don't know the answer, since the libraries changed
to use Depends rather than documenting the Recommends. :)

If a library really does *require* the corresponding data package in
order to do its job for programs that link to it, then the library
should have a Depends on the data package.  Since some of our packaging
tools apparently don't always cope well with circular dependencies, and
since the data package doesn't really serve any function on its own (so
people won't install it directly), the data package need not have a
Depends on the library.

If the library does not *require* the data to do its job for programs
that link to it, and some subset of cases can work without the data
package installed, then the library could have a Recommends on the data
package instead.  If so, that means many people (using the default
settings of the package management tools) will still get the data
package installed by default, and some people (myself included) will end
up choosing whether to install it or not.  For that matter, packages
depending on the library might potentially need to make that decision as
well, based on what subset of the library's functionality they use.  It
would help greatly if the library package documented under what
circumstances the library needs the data package, to help people decide
if they fit in the subset of cases where the library will function
without it.

The package description seems like the right place to put such
information, since users will see it in a package manager when making
installation decisions about the package.  From Debian Policy: "The
description should describe the package (the program) to a user (system
administrator) who has never met it before so that they have enough
information to decide whether they want to install it."  It seems fairly
natural to extend that to "whether they want to install it and its
dependencies/recommendations/suggests".  Many packages already do this,
noting in their description things like "install $FOO if you want
$THIS_PACKAGE to $FOOFUNC".  devscripts represents an extreme example,
noting the specific packages needed by every script it installs, but
most packages don't need to go that far.  For a simpler example, check
out autoconf, which Suggests autoconf-archive and gives a reason in its
description.

Before apt started installing Recommends by default, Recommends just
represented a stronger form of Suggests, and both only served as a vague
hint in a package manager that "you might (Suggests) or probably will
(Recommends) want this other package too".  Apt now distinguishes
Recommends and Suggests by installing Recommends by default.  However,
they still represent varying degrees of hints, and packages should still
function if people install only their Depends.

Given that Recommends have become significantly more prevalent since
this change to apt, I do think it would make sense to write down the
moderately common practice of documenting the reasons why users might or
might not want to install the Recommends/Suggests.  I don't think this
should go so far as a "must" in Policy, and in general I'd consider this
either a wishlist or at most a normal bug, depending on the
circumstances.  I think "should" seems about rig

Re: Who is (co-)maintaining lcdproc package ?

[José Luis Tallón]

Hi, all


Dominique Dumont wrote:
> In this package, lcdproc's maintainer is still Jose and Jonathan is listed as 
> uploaders.
>
> Is this still valid ? 
>
> Jose, so you want to resume maintaining lcdproc or do you want another one to 
> take over ? 
>   
As you prefer. I haven't uploaded any new versions due to a lack of
sponsors. Anybody willing to step up for sponsoring and/or
co-maintaining is welcome.
> Jonathan, as a DD, can you sponsor the new package ?
>   
He is essentially retired, as far as I can remember.
But I would really love to have Jon back :-)
> Nick, do you want to be listed as uploaded ?
>
> Depending on your answers, I'll upload a new version with an updated 
> maintainer/uploader list. (and with a correction in the bug list which is 
> missing commas)
>   
If we can possibly have a new version which fixes the problems with
armhf, I'll be all for it.
Drop me a line if I can help  (except that I can't upload it)


Thank you for you time and interest, Dominique.


Regards,

J.L.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d87d258.30...@adv-solutions.net

Re: Bug#618935: ITP: keepass2 -- password manager

[Brian May]

On 21 March 2011 21:22, Julian Taylor  wrote:
> Also keepass is very widely used, it is currently top 30 most downloaded of
> last month, top 70 all time on sourceforge.

Also keepass is in Debian stable, and it looks like it has been for a while.

As much as I like the ideas behind cpm, it unfortunately hasn't made
it to stable yet, and I am not sure how hard it would be to back port
it to stable. So I would agree, keep both for the moment.

At least cpm has made testing now, maybe there is hope... Oh, does cpm
have a website? I found
http://www.harry-b.de/dokuwiki/doku.php?id=harry:cpm, but that looks
seriously old, e.g. it refers to Sarge and Woody.
-- 
Brian May 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimf6hs4stxbyr8wxjaw2w17+o3mehuz7apvz...@mail.gmail.com

Hashcash token does not represent bits calculated [Bug]

[Aaron Toponce]

Package: hashcash
Version: 1.21-1

According to the documentation, the hashcash binary supports the '-b
bits' switch and argument for calculating a hashcash token of the size
specified. The default size is 20 bits. The '-b' switch argument
supports an exact size, say '-b 40' for minting a 40 bit token, or
incrementing/decrementing the size from default, such as '-b +10' to
create an additional 10 bits from default (20). This should create a
token of 30 bits in size. Same holds for decrementing.

Consider the following example:

$ hashcash -m foo -Z 2
hashcash token: 1:20:110321:foo::oMOAOyoyMfeKOPg7:5z7t

As per the 2nd column of the token, the default of 20 bits was used.
Let's increase to 30 bits:

$ hashcash -m foo -b 30 -Z 2
hashcash token: 1:20:110321:foo::DPuJxVpBd5hjE+WX:7CR2

The 2nd colomn shows that only 20 bits were calculated, versus the 30
that I requested. This can be verified with SHA1 showing that the first
20 bits are zero, not the first 30:

$ echo -n 1:20:110321:foo::DPuJxVpBd5hjE+WX:7CR2 | sha1sum
0239da10b8f4cf3aadd15d62b2d0c261dc82  -

The same bug exists for incrementing and decrementing the bit size. The
2nd column should convey the bit size that I requested with '-b bits'
and verifying with SHA1 should show the firt few bits as zero, as
specified. Compare with a 44 bit token found at
http://hashcash.org/stamps/:

$ echo -n 1:44:070217:foo::xSi0bPjoswUh6h1Y:TMNI7 | sha1sum
0005ae959bd508c19ba300b1088410aa  -

This is a Debian GNU/Linux unstable operating system running with:

2.6.37-1-686 #1 SMP Tue Feb 15 18:21:50 UTC 2011 i686 GNU/Linux

With C library version:

Version: 2.11.2-11

-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o


signature.asc
Description: Digital signature

Who is (co-)maintaining lcdproc package ?

[Dominique Dumont]

Hello

lcdproc package in Debian is outdated. I've prepared and uploaded in mentors 
an up-to-date package starting from the last version prepared by Nick (thanks 
Nick).

In this package, lcdproc's maintainer is still Jose and Jonathan is listed as 
uploaders.

Is this still valid ? 

Jose, so you want to resume maintaining lcdproc or do you want another one to 
take over ? 

Jonathan, as a DD, can you sponsor the new package ?

Nick, do you want to be listed as uploaded ?

Depending on your answers, I'll upload a new version with an updated 
maintainer/uploader list. (and with a correction in the bug list which is 
missing commas)

All the best

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/


signature.asc
Description: This is a digitally signed message part.

Re: Library depending on -data packages

[Jonathan Nieder]

Simon McVittie wrote:

> Or are you saying
> that things with special::auto-inst-parts should never have even a weakened
> dependency on the package of which they're an implementation detail?

Yes.  (Well, a Suggests is okay.)

> In situations where the data and the engine have a many-to-many relationship
> (the various Doom engines, each of which can play Doom, Doom II, FreeDoom or
> FreeDM), I agree that that Recommends might be too strong.

That's why I care.[1]

It seems unlikely that another game is going to start using openarena's
data without the engine but still it is nice to leave the possibility
open.

Regards,
Jonathan

[1] The package now called suckless-tools used to Recommends: dwm,
since its raison d'être was to provide basic functionality for that
window manager.  This meant:

 - for dwm users, not much.  APT's "markauto" functionality already
   ensured that dwm-tools would be uninstalled once dwm is removed.

 - for xmonad users, installing dwm-tools for dmenu would pull in an
   extra window manager.

(Side note: suckless-tools is plenty of fun on its own anyway.)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110321191822.GA4051@elie

Re: Library depending on -data packages

[Simon McVittie]

On Mon, 21 Mar 2011 at 12:10:16 -0500, Jonathan Nieder wrote:
> Simon McVittie wrote:
> > The existence of openarena-data is an implementation detail of openarena,
> > so it has this relationship:
> >
> >/--->--- Depends -->---\
> > openarena   openarena-data
> >\---<-- Recommends --<--/

(It's actually a recommendation of openarena|openarena-server, with >=
versioning, but that's probably not important here.)

> That Recommends should be an Enhances.  openarena-data continues to provide
> OpenArena game data, regardless of whether openarena is installed (unless I
> am missing something, ianal, etc etc).

openarena crashes on startup unless you have openarena-data, so, Depends
in that direction. You can't play the game as intended without the
levels/models/textures.

In my opinion, installations of openarena-data should have the OA launcher
scripts and engine, client and/or server, "in all but unusual situations" -
in principle I might want to install openarena-data just so I can look at it,
but in practice I probably want to play (or serve) the game? Or are you saying
that things with special::auto-inst-parts should never have even a weakened
dependency on the package of which they're an implementation detail?

If the Recommends was an Enhances, it'd seem rather redundant, since Enhances
is a "reverse Suggests", openarena already Depends on openarena-data and
Depends is stronger than Suggests?

In situations where the data and the engine have a many-to-many relationship
(the various Doom engines, each of which can play Doom, Doom II, FreeDoom or
FreeDM), I agree that that Recommends might be too strong.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110321172842.ga16...@reptile.pseudorandom.co.uk

Re: Library depending on -data packages

[Olaf van der Spek]

On Mon, Mar 21, 2011 at 5:42 PM, Simon McVittie  wrote:
> The data package typically just takes up space without doing anything
> useful if you install it on its own, so it should have the
> special::auto-inst-parts debtag and should usually Recommend the library or
> executable.

I don't agree. Yes, the data isn't very useful without the code, but
that doesn't mean it should depend or recommend the code.
When you want to play Quake, you don't install Quake-data (or whatever
it's called), you install the pkg containing the executable.

-- 
Olaf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTikFXRFb4-8r5krHc3nq_=vl93ameu9ibzvg+...@mail.gmail.com

Re: Library depending on -data packages

[Jonathan Nieder]

Hi,

Simon McVittie wrote:

> Which way to break the circular dependency needs to be considered 
> case-by-case;
> neither answer is universally right.

Here (with this statement of the problem) I disagree --- using Depends to
mean Enhances is _always_ wrong.

For example:

> The existence of openarena-data is an implementation detail of openarena,
> so it has this relationship:
>
>/--->--- Depends -->---\
> openarena   openarena-data
>\---<-- Recommends --<--/

That Recommends should be an Enhances.  openarena-data continues to provide
OpenArena game data, regardless of whether openarena is installed (unless I
am missing something, ianal, etc etc).

Thanks for a useful example.
Jonathan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110321170922.GA8076@elie

Re: Library depending on -data packages

[Jonathan Nieder]

(dropped cc's; hopefully that's okay.)
Hi!

Luca Capello wrote:

> I see these situations as a misuse of Depends: where Recommends: would
> be perfectly fine, otherwise Recommends: are useless.  But given that it
> seems no one agrees with me, is such a behavior documented somewhere?

Checking policy, I see:

The Recommends field should list packages that would be found
together with this one in all but unusual installations.

which I grant is not all that helpful.  The example I was introduced
to Recommends with is ancient: old X server packages used Recommends
to pull in a font server, because it was possible that your font
server might be running remotely but in all but unusual installations
you want a local one.  (Of course nowadays the X server always has a
built-in font server.)

One use of Recommends I agree with is that most latex packages use
Recommends for their documentation (which _has_ to be part of the
default installation according to the license).

So let's just consider your examples. :)

emacs depends on m17n-db

Bug#599643 is about what relationship m17n-lib has to m17n-db.  Please
correct me if I'm wrong.

 . libm17n provides an API for complex text layout
 . m17n-db provides the actual complex layout rules

So, one might conclude, for libm17n to behave as advertised, one *has*
to have m17n-db installed.  The DB is just an implementation detail
and could be provided just as well with internal tables in the library.

Wait, wait!  But emacs depends on libm17n for complex text layout and
some people are just not going to care.  What to do?

 Option A.  Split the functionality of libm17n-0 into two packages:
 (1) libm17n-0-lib, which ensures binaries linked to libm17n-0 can at
 least start up correctly and (2) libm17n-0, a dependency package
 which depends on libm17n-0-lib and m17n-db and represents the actual
 functionality.  Change emacs to "Depends: libm17n-0-lib" and
 "Suggests: libm17n-0".  Make sure the behavior when m17n-db is not
 installed is reasonable enough to function ok and to give a hint
 that the end-user about what package to ask the sysadmin to install
 to get full functionality.

 Option B.  Make emacs Suggests: and dlopen libm17n, and similarly
 make sure the fallback behavior is okay.

Neither involves a Recommends.  In either case some basic "task"
package probably ought to Recommends: m17n-db.

Many desktop apps depend on libatk1.0-data
--
Bug#599666 is about what relationship libatk has to libatk-data.  Again,
please feel free to correct me if I go wrong.

libatk1.0-data contains soname-independent files which the runtime
libraries need.  It consists mostly of locales and is a lot bigger
than the lib itself --- but that does not seem so unusual to me.
Hopefully some day we will find a better way to detail with
localization packaging to avoid wasting so much space.

emacs depends on anthy-common
-
Bug#582797 is about dependencies on libm17n implying a much heavier
dependency (anthy) whose functionality is not widely used that way.

The complication (again, as I understand it) is that to demote the
dependency to a Suggests would require finding a good fallback
behavior when it is missing.  According to that bug log, libm17n
upstream is working on it.

The plan is for the anthy input module to be in another package that
Depends: libanthy0, if I understand correctly.  That input module
could Enhances: libm17n or libm17n could Suggests it.

Hope that helps,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110321170149.GA7798@elie

Re: Library depending on -data packages

[Simon McVittie]

On Mon, 21 Mar 2011 at 17:18:00 +0100, Luca Capello wrote:
> When I found out about libm17n-0, I also found out that the change added
> a circular dependency and thus commented on this new bug why I think a
> library package should not depend on data packages

Which way to break the circular dependency needs to be considered case-by-case;
neither answer is universally right.

Sometimes the library (or executable) genuinely does need the data package -
substituting another data set in the same format wouldn't do what its users
expect. The data package typically just takes up space without doing anything
useful if you install it on its own, so it should have the
special::auto-inst-parts debtag and should usually Recommend the library or
executable.

For instance, openarena needs a corresponding version of openarena-data:
if you substitute a data-set in the same format (zipped Quake III-compatible
assets) with non-trivial modifications, it won't be network-compatible, and
might even crash if you don't make corresponding modifications to openarena.
The existence of openarena-data is an implementation detail of openarena,
so it has this relationship:

   /--->--- Depends -->---\
openarena   openarena-data
   \---<-- Recommends --<--/

Looking at libraries, it seems libgnome2-0 has this relationship with
libgnome2-common.

Sometimes the library or executable can work without the data, but works better
with it (for instance, GLib isn't localized if its -data part is missing).
It recommends the data, and the data can optionally depend on the
library or executable:

   /---<--- Depends --<---\
libglib2.0-0libglib2.0-data
   \--->-- Recommends -->--/

Sometimes the library or executable just needs *some* data in the right format:
it should typically Depend on, or even just Recommend, a virtual package
(with a preferred alternative). For instance, dictd can serve any compatible
dictionary or dictionaries of your choice.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110321164254.ga14...@reptile.pseudorandom.co.uk

Library depending on -data packages

[Luca Capello]

Hi there!

Given that I found this problem for the second time in the last 4
months, I think this is worth a discussion on debian-devel@.

It seems that recently two library packages started to change their
Recommends: to common data to a Depends:.  This after two bugs were
reported by the same person, Josh Triplett (cc:ed, sorry for the spam),
who asked for an explanation for the Recommends: (a reason which I find
perfectly valid).  The two bugs are:

  
  

When I found out about libm17n-0, I also found out that the change added
a circular dependency and thus commented on this new bug why I think a
library package should not depend on data packages:

  

And now, while looking again for that bug to be linked here, I found
another occurrence of such a situation, reported almost one year ago [1]
by Axel Beckert (cc:ed as well, again sorry for the spam):

  

[1] I remember that during one upgrade of emacs-snapshot I was surprised
it pulled anthy-common, but then forgot about reporting it...

I see these situations as a misuse of Depends: where Recommends: would
be perfectly fine, otherwise Recommends: are useless.  But given that it
seems no one agrees with me, is such a behavior documented somewhere?

Thx, bye,
Gismo / Luca


pgpZgvoEt8jSh.pgp
Description: PGP signature

Re: cdn.debian.net as a project service?

[Alexander Wirt]

Michael Vogt schrieb am Monday, den 21. March 2011:

> On Sun, Mar 20, 2011 at 01:35:23AM -0600, Raphael Geissert wrote:
> [..]
> > P.S. apt also provides a "mirror" method (just like http, ftp, etc) but I 
> > consider it to be suboptimal and a poor way to tackle the problem.
> 
> Why exactly do you feel this way? What problems do you see with it? 
> 
> I see some benefits in the mirror method like that the mirror list is
> cached locally (on apt-get update) so the mirror service is hit less
> often. Also if the central service is down apt can still use the
> cached local info. Plus it supports automatic retry if a mirror fails.
I agree here. Some kind of local override would also be nice. It would be
nice if I can run my own local mirror service, for example on my laptop I
want to use some local mirrors if I am in a specific network. Afaik there is
currently no way to dynamically choose a mirror in apt, based on a local
decision. 

Alex


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110321154856.gc11...@smithers.snow-crash.org

Re: cdn.debian.net as a project service?

[Michael Vogt]

On Sun, Mar 20, 2011 at 01:35:23AM -0600, Raphael Geissert wrote:
[..]
> P.S. apt also provides a "mirror" method (just like http, ftp, etc) but I 
> consider it to be suboptimal and a poor way to tackle the problem.

Why exactly do you feel this way? What problems do you see with it? 

I see some benefits in the mirror method like that the mirror list is
cached locally (on apt-get update) so the mirror service is hit less
often. Also if the central service is down apt can still use the
cached local info. Plus it supports automatic retry if a mirror fails.


Thanks,
 Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110321143856.GA8521@localhost

Re: problem with /etc/kernel scripts

[Ben Hutchings]

On Mon, 2011-03-21 at 06:17 +0100, Harald Dunkel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 03/20/11 18:23, Ben Hutchings wrote:
> > On Sun, 2011-03-20 at 16:49 +0100, Harald Dunkel wrote:
> >>
> >> Obviously the dkms script should not be run by the postinst script
> >> of linux-image, but of linux-headers. Shouldn't we distinguish
> >> between the hooks for linux-image and for linux-headers somehow?
> > 
> > The headers package should invoke hook scripts in
> > /etc/kernel/header_postinst.d (etc).  dkms already installs a hook
> > script there.
> > 
> 
> Sorry, I missed that.
> 
> Do you think that dkms should drop its /etc/kernel/postinst.d/dkms
> script? AFAICS this script might be called before the headers are
> installed.

It presumably should not rebuild modules unless both the image and
header packages are installed.  Depending on the order those packages
are installed, either hook may trigger this.  Also, it may be useful to
warn the user when only the image package is upgraded.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Need for automatic USB stick backup package

[Jeffrey Ratcliffe]

Inspired by a forum post[1], I've been using a bit of glue between
udev and unison[-gtk] to automatically backup USB sticks when they are
plugged in.

I've been thinking about packaging it up, on the basis that although
the glue is small, and simple to those who understand, it is not
trivial and firing up an editor as root to create the udev rules is
enough to scare off many users (I guess).

Would such a package be useful?

Regards

Jeff

[1] http://ubuntuforums.org/showthread.php?p=8584911


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTinUQujqUYR9=y5qhxk9822veqftiqus+z-59...@mail.gmail.com

Re: Trains from Debconf to Munich, Koeln, Paris, London, Cambridge

[Luca Capello]

Hi there!

On Fri, 18 Mar 2011 21:39:59 +0100, Ian Jackson wrote:
> I'm going to Debconf by train.  Having done my research, I now know
> which trains I'm going to be on.  On the way out I will be taking a
> day to look around Sarajevo by myself, which produces quite a detour.

Nothing against you, Ian, but why is this discussed on debian-devel@ and
not on debconf-discuss@ (cc:ed) or debian-events-eu@?

Thx, bye,
Gismo / Luca


pgpFXOtBh1AAr.pgp
Description: PGP signature

Re: Trains from Debconf to Munich, Koeln, Paris, London, Cambridge

[Ian Jackson]

Thomas Koch writes ("Re: Trains from Debconf to Munich, Koeln, Paris, London, 
Cambridge"):
> > Can you tell me where you got that information ?  bahn.hafas.de shows
> > two departures from Munich at 23:40, the sleepers to Budapest and
> > Zagreb (which are the same train at departure and split after
> > Salzburg).  The Budapest sleeper (EN463) terminates at 08:49 and the
> > Zagreb sleeper (D499) at 08:40.
>
> Yes, the Zagreb sleeper D499 stops at Okucani at 10:49. Just search
> directly for München-Okucani. The train from Zürich arrives at
> 12:53, so if you'd wait a little bit, a bus could be organised for
> both trains.

Ah, I see now.  Hrm, that might be a better plan than the train to
Banja Luka itself.

On the return trip, the sleeper for Munich via Zagreb departs Okucani
at 18:55, compared to leaving Banja Luka at 1549 with an hour's change
in Zagreb.

I wouldn't rely on dinner being available on board.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19847.13215.674092.194...@chiark.greenend.org.uk

Bug#619105: ITP: freegish -- 2D platform game starring a ball of tar

[Lubos Novak]

Package: wnpp
Severity: wishlist
Owner: Lubos Novak 


* Package name: freegish
  Version : 1.53
  Upstream Author : Freegish team, Cryptic Sea
* URL : https://www.github.com/megagun/gish
* License : GPL, CC-BY-SA 3.0
  Programming Lang: C
  Description : 2D platform game starring a ball of tar

Freegish is a 2D platform game, where the player maneuvers character of 
a ball
of tar. Character may become sticky, slick, heavy and can jump.

The game contains only first five levels of the single player campaign 
and few
multiplayer levels for mini games like sumo or football.

Freegish is based on open sourced code of the famous game called Gish 
with added
free art assets.

-- System Information:
Debian Release: 5.0.8
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110321102404.21741.486.report...@atlas.travelesprit.cz

Re: Bug#618935: ITP: keepass2 -- password manager

[Julian Taylor]

On Mon, Mar 21, 2011 at 10:02 AM, Thomas Koch  wrote:

> Hi,
>
> we just received cpm[1] in testing. From its description it sounds to be
> superior to keepass2. - And it does not require (evil?) C#.
> Maybe cpm could serve your need and thus Debian wouldn't need to support an
> additional package?
>
> [1] http://packages.debian.org/wheezy/cpm
>
>

cpm looks nice indeed but will cpm run on windows and macos?

keepass probably integrates better with GUI's thanks to its drag&drop and
autotyping of passwords into forms.
It has a wide array of features and is constantly getting new ones.
http://keepass.info/features.html
The documentation is excellent and it is translated into many languages.

It can export its database into many formats (xml, csv, html, arbitrary xsl
transformations, ...).
It has many plugins including one for command line scripting (although I
have not yet tested it on debian).

Upstream is very active and supportive. There are regular releases with
bugfixes and features since more than 6 years.

Also keepass is very widely used, it is currently top 30 most downloaded of
last month, top 70 all time on sourceforge.

I think all these points warrant a little duplicate functionality in the
archive.

Best Regards,
Julian Taylor

Re: Bug#618935: ITP: keepass2 -- password manager

[Jan Dittberner]

On Mon, Mar 21, 2011 at 10:02:53AM +0100, Thomas Koch wrote:
> Julian Taylor:
> > * Package name: keepass2
> >   Programming Lang: C#
> >  KeePass2 is a free/open-source password manager or safe which helps you
> >  to manage your passwords in a secure way. You can put all your
> >  passwords in one database, which is locked with one master key or a
> >  key-disk. So you only have to remember one single master password or
> >  insert the key-disk to unlock the whole database. The databases are
> >  encrypted using the algorithms AES or Twofish.
> > --
> > 
> > KeePass2 is a reimplementation of KeePass 1 based on .net. It runs very
> > well with mono and provides many more features than keepassx which is in
> > already in debian and is based on KeePass 1.
> we just received cpm[1] in testing. From its description it sounds to be 
> superior to keepass2. - And it does not require (evil?) C#.
> Maybe cpm could serve your need and thus Debian wouldn't need to support an 
> additional package?

keepassx and keepass2 are interoperable with files from their counterparts on
proprietary OSs this is especially useful with dual boot installations sharing
the password database files. There is no port of cpm to cygwin (AFAICT).


Regards
Jan

-- 
Jan Dittberner - Debian Developer
GPG-key: 4096R/558FB8DD 2009-05-10
 B2FF 1D95 CE8F 7A22 DF4C  F09B A73E 0055 558F B8DD
http://www.dittberner.info/


signature.asc
Description: Digital signature

DELAYED queue broken?

[David Paleino]

Hello people,

$ dput --delayed 5 mysql-gui-tools_5.0r14+openSUSE-2.2_i386.changes 
[..]
Uploading to ftp-master [DELAYED/5] (via ftp to ftp.eu.upload.debian.org):
Directory to upload to does not exist.

WTF? :)

I tried both with ftp.upload.d.o and ftp.eu.upload.d.o. Am I missing something?

Kindly,
David

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#619100: ITP: abacas -- Algorithm Based Automatic Contiguation of Assembled Sequences

[andreas]

Package: wnpp
Severity: wishlist
Owner: andr...@an3as.eu

* Package name: abacas
  Version : 1.3.1
  Upstream Author : Wellcome Trust Sanger Institute
* URL : http://abacas.sourceforge.net/
* License : GPL
  Programming Lang: Perl
  Description : Algorithm Based Automatic Contiguation of Assembled 
Sequences
 ABACAS is intended to rapidly contiguate (align, order, orientate),
 visualize and design primers to close gaps on shotgun assembled contigs
 based on a reference sequence.
 .
 ABACAS uses MUMmer to find alignment positions and identify syntenies
 of assembled contigs against the reference. The output is then processed
 to generate a pseudomolecule taking overlapping contigs and gaps in to
 account. ABACAS generates a comparision file that can be used to
 visualize ordered and oriented contigs in ACT. Synteny is represented by
 red bars where colour intensity decreases with lower values of percent
 identity between comparable blocks. Information on contigs such as the
 orientation, percent identity, coverage and overlap with other contigs
 can also be visualized by loading the outputted feature file on ACT.

The packaging will be done in the Debian Med team and is available in SVN at

Vcs-Svn: svn://svn.debian.org/svn/debian-med/trunk/packages/abacas/trunk/


-- System Information:
Debian Release: squeeze/sid
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (50, 'unstable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110321092521.24386.9506.report...@mail.an3as.eu

Re: Bug#618935: ITP: keepass2 -- password manager

[Thomas Koch]

Julian Taylor:
> Package: wnpp
> Severity: wishlist
> Owner: Julian Taylor 
> 
> * Package name: keepass2
>   Version : 2.15 (not yet released)
>   Upstream Author : Dominik Reichl 
> * URL : http://keepass.info/
> * License : GPL-2+
>   Programming Lang: C#
>   Description : ITP: keepass2 -- password manager
> 
>  KeePass2 is a free/open-source password manager or safe which helps you
>  to manage your passwords in a secure way. You can put all your
>  passwords in one database, which is locked with one master key or a
>  key-disk. So you only have to remember one single master password or
>  insert the key-disk to unlock the whole database. The databases are
>  encrypted using the algorithms AES or Twofish.
> --
> 
> KeePass2 is a reimplementation of KeePass 1 based on .net. It runs very
> well with mono and provides many more features than keepassx which is in
> already in debian and is based on KeePass 1.
Hi,

we just received cpm[1] in testing. From its description it sounds to be 
superior to keepass2. - And it does not require (evil?) C#.
Maybe cpm could serve your need and thus Debian wouldn't need to support an 
additional package?

[1] http://packages.debian.org/wheezy/cpm

Best regards,

Thomas Koch, http://www.koch.ro


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201103211002.53260.tho...@koch.ro

Bug#619097: ITP: libtest-pod-content-perl -- Perl module for testing POD content

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: libtest-pod-content-perl
  Version : 0.0.5
  Upstream Author : Martin Kutter 
* URL : http://search.cpan.org/dist/Test-Pod-Content/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module for testing POD content

 This is a very simple module for testing Perl's Plain Old Documentation (POD)
 format's content, not just the markup syntax. It is mainly intended for
 testing the content of generated POD - that is, the POD included in Perl
 modules generated by some mechanism.

I intend to maintain this package within the Debian Perl Group.


signature.asc
Description: Digital signature