Re: Support of new source packages in squeeze

[Raphael Hertzog]

On Sun, 08 Mar 2009, Russ Allbery wrote:
> Raphael Hertzog  writes:
> 
> > In practice, there's one exception, the debian tarball can contain
> > binary files that are installed outside of the debian dir. Those are
> > necessary listed in debian/source/include_binaries.
> 
> According to the dpkg-source man page, you mean include-binaries.

Right, indeed.

> Is there a complete specification of these new source control files?
> (Exact syntax, complete list of control files, etc.)  We'll need it to
> write Lintian checks, and dpkg-source doesn't seem to have that
> information gathered into one place.

There's nothing else than the dpkg-source man page. I've noted 
in my TODO to write a section "File formats".

debian/source/format contains only the format (a single line, no
leading/trailing spaces allowed, only the first line is read but
it's probably best to not allow anything else).

debian/source/include-binaries contains one filename per line.
Leading and trailing spaces are stripped. Lines starting with a #
(possibly prefixed by spaces) are comments and are skipped. Empty lines
are not allowed.

> Also, the dpkg-source man page implies that Format in the source section
> of debian/control is just another way of specifying the format:
> 
>--format=value
>   Try first the given format for building the source package. If
>   used multiple times, they are tried in order. It doesn’t
>   override any explicit Format field in debian/control but it does
>   override any format given in debian/source/format.
> 
> but from this thread I gather that it shouldn't be used.  What should
> Lintian do in this area?

I'm not sure. I started by using this field and over development, it
appeared to me that it was a bad choice. I recycled it as a way to
override the format in a quick and dirty way (because dpkg-buildpackage
doesn't allow to provide arbitrary arguments to dpkg-source yet).

But is this really needed or should I rather simply drop this feature ?

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#518869: ITP: shorewall6 -- Shoreline Firewall (IPv6 version), netfilter configurator

[Stefano Zacchiroli]

On Sun, Mar 08, 2009 at 08:34:23PM -0400, Roberto C. Sanchez wrote:
>   Description : Shoreline Firewall (IPv6 version), netfilter configurator

Uh? Can you please explain?

Even though I'm not following the upstream evolution I'm a user of the
shorewall package, which has IPv6 support even though disabled by
default. Why we now need a separate package now?

Thanks in advance,
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Support of new source packages in squeeze

[James Westby]

On Sun, 2009-03-08 at 17:11 +0100, Raphael Hertzog wrote:
> There's nothing to specify here, dpkg-source uses all additional tarballs
> that match the regexp (exactly like it identifies the .orig tarball
> currently).

bzr-builddeb will endeavour to provide the ".orig.tar.gz" for a format 1
package, so that you can construct a source package from a bzr branch.

This will be essentially impossible for 3.0 (quilt) packages that 
use multiple tarballs, as there is no information in the unpacked
source package that tells you which tarballs are needed. This is a
pretty serious problem in my eyes.

Have you thought about how this will work with things such as uscan?
Having some way to check for newer versions of all the tarballs that
go together to make the source package would be important.

> What does it assume and what would you need ?

I'm not sure I would actually need anything more from dpkg-dev for this
at this point. I think it's just a case of updating the code.

> In theory you can use "dpkg-source --skip-patches -x" and import
> everything except the debian dir. Those are the upstream sources, I'm not
> sure it's interesting to handle each upstream tarball separately. In fact,
> doing so could lead to conflicts since the additional tarballs might
> replace a directory that is also in the main tarball.
> 
> In practice, there's one exception, the debian tarball can contain
> binary files that are installed outside of the debian dir. Those are
> necessary listed in debian/source/include_binaries.
> 
> So maybe we should add a new option that skips the extraction of the
> debian tarball.
> 
> In any case, I don't see how -su can be of any help (given its
> definition) and the -su option is specific to the old format. If we really
> want to have a common option that works for all formats, we might
> want to create a new option "--skip-debianization" or similar.

Something will be needed for the use case I have, your proposed option
sounds sensible to me.

Thanks,

James


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[James Westby]

On Sun, 2009-03-08 at 16:07 +0100, Jan Hauke Rahm wrote:
> And how do you store that in a VCS if a second tarball includes files
> that actually overwrite files of the main orig tarball. At build time
> directories in the main orig tarball are supposed to be overwritten by
> the part tarball but if you go the same way in a VCS you lose some
> information, don't you?

I'm not sure what information would be lost, could you expand?

Thanks,

James


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[Russ Allbery]

James Westby  writes:

> bzr-builddeb will endeavour to provide the ".orig.tar.gz" for a format 1
> package, so that you can construct a source package from a bzr branch.
>
> This will be essentially impossible for 3.0 (quilt) packages that use
> multiple tarballs, as there is no information in the unpacked source
> package that tells you which tarballs are needed. This is a pretty
> serious problem in my eyes.

git-buildpackage with pristine-tar is going to have a similar problem.

For pristine-tar, the solution that comes to mind is a
debian/source/tarballs file that lists the names of all of the upstream
tarballs.  All you need there are the tarball names to know what to
generate.  Of course, it doesn't have to live there (and maybe shouldn't);
you could use a builder-specific configuration file instead.

If you're trying to recreate the tarball from a set of files, this doesn't
work as well, but that also has other problems (it doesn't give you a
reproducible tarball).  I suspect that if you're storing enough additional
metadata to know how to generate a reproducible tarball, you'll have
metadata to know how to build it.  For pristine-tar, for example, I'd put
each upstream tarball on a separate branch and merge them together, so
that pristine-tar has a branch tag to use for commit and checkout.

> Have you thought about how this will work with things such as uscan?
> Having some way to check for newer versions of all the tarballs that
> go together to make the source package would be important.

I suspect that for a lot of the check-only use cases for this, checking
only one of the tarballs will be sufficient.  (OpenAFS, for example, comes
upstream in the form of a source tarball and a documentation tarball, but
they always have the same version, so uscan can just check one of them.)
If you want to support uscan --download, though, yes, that's another
matter.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[Mikhail Gusarov]

Twas brillig at 01:09:34 09.03.2009 UTC-07 when r...@debian.org did gyre and 
gimble:

 RA> debian/source/tarballs file that lists the names of all of the
 RA> upstream tarballs.

Just as the reference: similar approach for src.rpm:

http://docs.altlinux.org/manpages/gear-rules.5.html (see the
'directives' section).

gear rules are richer, allowing also to generate patches with git-diff
(think of upstream branch and topic-foo branch).

-- 


pgpq9vSeVGfBG.pgp
Description: PGP signature

Re: Support of new source packages in squeeze

[Russ Allbery]

Mikhail Gusarov  writes:

> gear rules are richer, allowing also to generate patches with git-diff
> (think of upstream branch and topic-foo branch).

I think TopGit is the right solution to this.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[Raphael Hertzog]

On Mon, 09 Mar 2009, James Westby wrote:
> On Sun, 2009-03-08 at 17:11 +0100, Raphael Hertzog wrote:
> > There's nothing to specify here, dpkg-source uses all additional tarballs
> > that match the regexp (exactly like it identifies the .orig tarball
> > currently).
> 
> bzr-builddeb will endeavour to provide the ".orig.tar.gz" for a format 1
> package, so that you can construct a source package from a bzr branch.
> 
> This will be essentially impossible for 3.0 (quilt) packages that 
> use multiple tarballs, as there is no information in the unpacked
> source package that tells you which tarballs are needed. This is a
> pretty serious problem in my eyes.

I could create debian/source/orig-components at unpack time and maybe even
have dpkg-source -b check for their existence but I'm not yet convinced
that this problem needs to be solved at the dpkg-source level.

Furthermore, creating debian/source/orig-components is interesting
for your use case together with --skip-debianization and it's somewhat
weird to have only that file in the debian tree in that case.

What do others think ?

If bzr-builddeb wants to provide the tarballs, they must have been
injected at some point (otherwise you won't provide pristine tarballs)
and you could record the additional information at that point.

If you don't record that info and if you provide a single tarball, the
resulting package will still work, but this tarball is never
going to be pristine. That's all.

> Have you thought about how this will work with things such as uscan?
> Having some way to check for newer versions of all the tarballs that
> go together to make the source package would be important.

I have not designed solution for all tools. But I'm fully aware that uscan
will need adjustments to cope with this. It's even listed in the wiki
page. Feel free to file a bug about this so that they can think of a
solution.

(That said packages with multiple tarballs are a large minority and it's
not a big deal if uscan support is not fully aware of additional tarballs
in the beginning)

> Something will be needed for the use case I have, your proposed option
> sounds sensible to me.

Ok, will try to have that in dpkg 1.15.1.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#518869: ITP: shorewall6 -- Shoreline Firewall (IPv6 version), netfilter configurator

[Brian May]

Stefano Zacchiroli wrote:

Uh? Can you please explain?

Even though I'm not following the upstream evolution I'm a user of the
shorewall package, which has IPv6 support even though disabled by
default. Why we now need a separate package now?
  


It needs to be a separate package, because that is the way it is 
distributed upstream. ie. shorewall6, with IPv6 support is very distinct 
from shorewall, with IPv4 support.


For more information see .

Disclaimer: I am not involved in packaging this for Debian or upstream - 
just a user.


--
Brian May 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#518927: Please update dtoa.c in all packages that use it

[Alexander E. Patrakov]

Package: general
Severity: normal

Hi,

many source packages contain the "dtoa.c" file that bears the following
copyright notice:

 * The author of this software is David M. Gay.
 *
 * Copyright (c) 1991, 2000, 2001 by Lucent Technologies.

All these packages will be miscompiled by gcc-4.4, because dtoa.c
violates strict aliasing rules. See more details at
http://patrakov.blogspot.com/2009/03/dont-use-old-dtoac.html

Please do a whole-archive search for source files (you'll mostly find
copies of dtoa.c, gdtoa.c and various internal headers) that contain the
string "#define word1(x) ((U*)&x)->L[0]", and clone this bug
accordingly.

System information: irrelevant.

Diego Elio Pettenò: you received this mail because I want you to do the
same thing for Gentoo.

-- 
Alexander E. Patrakov



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]

[Andreas Rottmann]

Samuel Thibault  writes:

> Package: wnpp
> Version: N/A; reported 2009-03-08
> Severity: wishlist
>
> * Package name: parallel
>   Version : 20090218
>   Upstream Author : Ole Tange
> * URL : https://savannah.nongnu.org/projects/parallel/
> * License : GPLv3
>   Description : build and execute command lines from standard input in 
> parallel
>  For each line of input parallel will execute command with the line
>  as arguments. If no command is given the line of input is executed.
>  parallel can often be used as a substitute for xargs or cat | sh.
>
Did you know about the `-P' option of GNU xargs? IIUC, it does quite the
same thing -- what does 'parallel' offer of that functionality?

>From xargs(1):

   --max-procs=max-procs
   -P max-procs
  Run up to max-procs processes at a time; the default is 1.
  If max- procs is 0, xargs will run as many processes as
  possible at a time.  Use the -n option with -P; otherwise
  chances are that only one exec will be done.

Regards, Rotty


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]

[Samuel Thibault]

clone 518696 -1
reassign -1 findutils
retitle -1 Add "parallel" somewhere in the description of -P
thanks

Andreas Rottmann, le Mon 09 Mar 2009 11:25:11 +0100, a écrit :
> Did you know about the `-P' option of GNU xargs?

Herm, I would have found it if the manpage didn't lack keywords like
"parallel", "simultaneous", ... Reassigning.

That being said, I guess xargs lacks one parallel feature:

 -g   Group output.  Output from each jobs is grouped together and is only 
printed
  when the command is finished. STDERR first followed by STDOUT.  -g is 
the
  default. Can be reversed with -u.

A lot of applications (including md5sum) would not necessarily print
their output atomically and then you get mixed output.  Either we add
the option to findutils, or we package parallel.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[Jan Hauke Rahm]

On Mon, Mar 09, 2009 at 05:52:16PM +1000, James Westby wrote:
> On Sun, 2009-03-08 at 16:07 +0100, Jan Hauke Rahm wrote:
> > And how do you store that in a VCS if a second tarball includes files
> > that actually overwrite files of the main orig tarball. At build time
> > directories in the main orig tarball are supposed to be overwritten by
> > the part tarball but if you go the same way in a VCS you lose some
> > information, don't you?
> 
> I'm not sure what information would be lost, could you expand?

Imagine an orig tarball with a config directory and an orig part-tarball
named orig-config.tar.whatever. The second tarball would overwrite
what's in the config dir of the first one when executing dpkg-source -x.
If you just store that unpacked data in a VCS you've lost what's in the
config dir in the first tarball because it's overwritten.

Hauke


signature.asc
Description: Digital signature

Re: lrmi vs new kernels vs libx86

[Guillem Jover]

Hi!

On Sun, 2009-03-08 at 16:49:33 +0100, Evgeni Golov wrote:
> dear maintainers of packages that contain lrmi.{c,h},
> 
> today Lucas has reported #518725 - atitvout FTBFS because of missing
> *_MASK defines.
> Seeing that bug and remembering fun with lrmi myself, I thought I can
> have a look how many other packages will FTBFS.

> The following packages contain lrmi.{c,h}, and the ones with the *
> FTBFS:
> read-edid*

Some time ago I filed a bug with a patch to switch it to use libx86.
.

> svgalib*

And I ported svgalib to libx86 long time ago, so it's not using the
embedded lrmi. It also builds locally, do you have the failing logs?

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[Jan Hauke Rahm]

On Mon, Mar 09, 2009 at 01:09:34AM -0700, Russ Allbery wrote:
> If you're trying to recreate the tarball from a set of files, this doesn't
> work as well, but that also has other problems (it doesn't give you a
> reproducible tarball).  I suspect that if you're storing enough additional
> metadata to know how to generate a reproducible tarball, you'll have
> metadata to know how to build it.  For pristine-tar, for example, I'd put
> each upstream tarball on a separate branch and merge them together, so
> that pristine-tar has a branch tag to use for commit and checkout.

I might be wrong here but recreating an orig tarball from the data in a
VCS can always lead to a different tarball than the actually original
tarball when you unpacked (and commited) it via 'dpkg-source -x' just
due to the ignore regex for files. If upstream had files in his/her
tarball that got ignored by dpkg-source then those are not unpacked and
not commited and thus not repacked in a recreated orig tarball (leading
at least to different checksums). Or am I wrong with that?

Hauke


signature.asc
Description: Digital signature

Re: Support of new source packages in squeeze

[Marco d'Itri]

On Mar 09, Russ Allbery  wrote:

> I think TopGit is the right solution to this.
Is it plausible to use a branch-per-patch solution for packages
containing 30-60 patches?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#518869: ITP: shorewall6 -- Shoreline Firewall (IPv6 version), netfilter configurator

[Roberto C . Sánchez]

On Mon, Mar 09, 2009 at 08:38:23AM +0100, Stefano Zacchiroli wrote:
> On Sun, Mar 08, 2009 at 08:34:23PM -0400, Roberto C. Sanchez wrote:
> >   Description : Shoreline Firewall (IPv6 version), netfilter 
> > configurator
> 
> Uh? Can you please explain?
> 
> Even though I'm not following the upstream evolution I'm a user of the
> shorewall package, which has IPv6 support even though disabled by
> default. Why we now need a separate package now?
> 
Upstream releases now the following packages for 4.2.x:

shorewall-common
shorewall-docs
shorewall-lite
shorewall-perl
shorewall-shell
shorewall6
shorewall6-lite

shorewall6 depends upon shorewall-perl (and consequently
shorewall-common) in order to work properly.  It is a different
rules engine/compiler that handles IPv6 packet filtering.  It was
implemented separately because it is in many ways much simpler than
IPv4 packet filter (e.g., there is no NAT in IPv6 and IPsec is part
of the spec instead of requiring encapsulation).

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Support of new source packages in squeeze

[martin f krafft]

also sprach Marco d'Itri  [2009.03.09.1250 +0100]:
> > I think TopGit is the right solution to this.
> Is it plausible to use a branch-per-patch solution for packages
> containing 30-60 patches?

TopGit can certainly handle it, but it'll make a royal merging mess
of your history. The idea of TopGit is never to mess with history,
so the ancestry graph gets very complex with 5 patch branches, and
a lot more with 30-60 patches.

That said, TopGit will not lose track, and if you employ a smart
branch-naming-scheme, neither will you.

If you have any suggestions for improvements, we'd love to hear
them. Debian-related TopGit stuff probably best goes to
vcs-pkg-disc...@lists.alioth.debian.org. TopGit general stuff to
g...@vger.kernel.org with a [TopGit] subject prefix.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"the only difference between the saint and the sinner
 is that every saint has a past and every sinner has a future."
-- oscar wilde


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: -dbg packages; are they actually useful?

[Simon Richter]

Hi,

> Even Microsoft has a service for downloading symbols files for many core  
> windows components on demand (integrated with the crash dump analysis 
> tool. (I forget of the chrash dump tool is part of the pre-installed 
> debugger or it itis seperate)).

They even go a step further and ask for application vendors to submit the
.pdb files for their software, and forward crash reports.

The biggest problem I see with such a service would be matching the debug
information to the binaries on the user's system. MS use a GUID for each
loadable object AFAIK, which could probably be recreated easily -- still
leaves the problem that in order for the service to be useful, we need
quite a back archive of debug information for older versions.

   Simon


signature.asc
Description: Digital signature

Re: Support of new source packages in squeeze

[Raphael Hertzog]

On Mon, 09 Mar 2009, Jan Hauke Rahm wrote:
> On Mon, Mar 09, 2009 at 01:09:34AM -0700, Russ Allbery wrote:
> > If you're trying to recreate the tarball from a set of files, this doesn't
> > work as well, but that also has other problems (it doesn't give you a
> > reproducible tarball).  I suspect that if you're storing enough additional
> > metadata to know how to generate a reproducible tarball, you'll have
> > metadata to know how to build it.  For pristine-tar, for example, I'd put
> > each upstream tarball on a separate branch and merge them together, so
> > that pristine-tar has a branch tag to use for commit and checkout.
> 
> I might be wrong here but recreating an orig tarball from the data in a
> VCS can always lead to a different tarball than the actually original
> tarball when you unpacked (and commited) it via 'dpkg-source -x' just
> due to the ignore regex for files. If upstream had files in his/her
> tarball that got ignored by dpkg-source then those are not unpacked and
> not commited and thus not repacked in a recreated orig tarball (leading
> at least to different checksums). Or am I wrong with that?

You're wrong because dpkg-source only ignores files during build and not
during unpack. And dpkg-source -b doesn't modify .orig tarballs of course.

The -I ignore applies mainly for native packages were the tarball is
recreated each time. The -i ignore applies only to existing files whose
modifications should not be stored and has no impact on tarball creation.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[Jan Hauke Rahm]

On Mon, Mar 09, 2009 at 01:36:53PM +0100, Raphael Hertzog wrote:
> On Mon, 09 Mar 2009, Jan Hauke Rahm wrote:
> > I might be wrong here but recreating an orig tarball from the data in a
> > VCS can always lead to a different tarball than the actually original
> > tarball when you unpacked (and commited) it via 'dpkg-source -x' just
> > due to the ignore regex for files. If upstream had files in his/her
> > tarball that got ignored by dpkg-source then those are not unpacked and
> > not commited and thus not repacked in a recreated orig tarball (leading
> > at least to different checksums). Or am I wrong with that?
> 
> You're wrong because dpkg-source only ignores files during build and not
> during unpack. And dpkg-source -b doesn't modify .orig tarballs of course.

Ah, thanks for clarification!

Hauke


signature.asc
Description: Digital signature

Re: Support of new source packages in squeeze

[Goswin von Brederlow]

Jan Hauke Rahm  writes:

> On Mon, Mar 09, 2009 at 05:52:16PM +1000, James Westby wrote:
>> On Sun, 2009-03-08 at 16:07 +0100, Jan Hauke Rahm wrote:
>> > And how do you store that in a VCS if a second tarball includes files
>> > that actually overwrite files of the main orig tarball. At build time
>> > directories in the main orig tarball are supposed to be overwritten by
>> > the part tarball but if you go the same way in a VCS you lose some
>> > information, don't you?
>> 
>> I'm not sure what information would be lost, could you expand?
>
> Imagine an orig tarball with a config directory and an orig part-tarball
> named orig-config.tar.whatever. The second tarball would overwrite
> what's in the config dir of the first one when executing dpkg-source -x.
> If you just store that unpacked data in a VCS you've lost what's in the
> config dir in the first tarball because it's overwritten.
>
> Hauke

I would use branches. Each tar goes to one branch. The branches are
then merged into the master branch.

MfG
Goswin

PS: there should be some conffile in the source telling what tar.gz
goes to which branch in case the name changes between releases. Or
some logic that strips version numbers from the filesname or
something.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[Goswin von Brederlow]

m...@linux.it (Marco d'Itri) writes:

> On Mar 09, Russ Allbery  wrote:
>
>> I think TopGit is the right solution to this.
> Is it plausible to use a branch-per-patch solution for packages
> containing 30-60 patches?
>
> -- 
> ciao,
> Marco

>From the space and git point of view that is completly
doable. Branches are dirt cheap.

>From a usability point of view I find it unusable. With so many
branches you always forget to merge one or don't commit to the right
one. And changing branches will change files and if you have them open
in for example emacs it will notice the file was changed on disk and
asks you to revert it, which sucks.

But then again, if you only work on the last patch in the stack then
that isn't a problem.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[Goswin von Brederlow]

Raphael Hertzog  writes:

> On Mon, 09 Mar 2009, James Westby wrote:
>> On Sun, 2009-03-08 at 17:11 +0100, Raphael Hertzog wrote:
>> > There's nothing to specify here, dpkg-source uses all additional tarballs
>> > that match the regexp (exactly like it identifies the .orig tarball
>> > currently).
>> 
>> bzr-builddeb will endeavour to provide the ".orig.tar.gz" for a format 1
>> package, so that you can construct a source package from a bzr branch.
>> 
>> This will be essentially impossible for 3.0 (quilt) packages that 
>> use multiple tarballs, as there is no information in the unpacked
>> source package that tells you which tarballs are needed. This is a
>> pretty serious problem in my eyes.
>
> I could create debian/source/orig-components at unpack time and maybe even
> have dpkg-source -b check for their existence but I'm not yet convinced
> that this problem needs to be solved at the dpkg-source level.
>
> Furthermore, creating debian/source/orig-components is interesting
> for your use case together with --skip-debianization and it's somewhat
> weird to have only that file in the debian tree in that case.
>
> What do others think ?

I think it would be good to have this in dpkg. That way all the
different RCS build scripts can use the same file and syntax. If every
rcs-buildpackage creates their own file then migrating from e.g. svn
to git means rewriting that config.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[Goswin von Brederlow]

Jan Hauke Rahm  writes:

> On Mon, Mar 09, 2009 at 01:09:34AM -0700, Russ Allbery wrote:
>> If you're trying to recreate the tarball from a set of files, this doesn't
>> work as well, but that also has other problems (it doesn't give you a
>> reproducible tarball).  I suspect that if you're storing enough additional
>> metadata to know how to generate a reproducible tarball, you'll have
>> metadata to know how to build it.  For pristine-tar, for example, I'd put
>> each upstream tarball on a separate branch and merge them together, so
>> that pristine-tar has a branch tag to use for commit and checkout.
>
> I might be wrong here but recreating an orig tarball from the data in a
> VCS can always lead to a different tarball than the actually original
> tarball when you unpacked (and commited) it via 'dpkg-source -x' just
> due to the ignore regex for files. If upstream had files in his/her
> tarball that got ignored by dpkg-source then those are not unpacked and
> not commited and thus not repacked in a recreated orig tarball (leading
> at least to different checksums). Or am I wrong with that?
>
> Hauke

   pristine-tar - regenerate pristine tarballs
   pristine-gz - regenerate pristine gz files
   pristine-bz2 - regenerate pristine bz2 files

What they do is to store the files from the files in one branch. Then
they generate a tar/gz/bz2 from that and store the delta to the
prisine file in another branch. With both together the pristine file
can be recreated.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[martin f krafft]

also sprach Goswin von Brederlow  [2009.03.09.1443 +0100]:
> From a usability point of view I find it unusable. With so many
> branches you always forget to merge one or don't commit to the
> right one.

Uh, this is in response to TopGit, which addresses precisely this
problem: keeping track of the branches and automating their use.

It won't solve the problem about committing to the wrong branch,
which can only be solved by you. Hint: show the current branch in
your shell prompt.

> And changing branches will change files and if you have
> them open in for example emacs it will notice the file was changed
> on disk and asks you to revert it, which sucks.

Again, PEBCAK

> But then again, if you only work on the last patch in the stack
> then that isn't a problem.

TopGit maintaines a complete graph, not just a stack.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
logik ist analsadismus: gedanken werden gewaltsam
durch einen engen gang gepreßt.
-- frei nach lacan


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Support of new source packages in squeeze

[Marco d'Itri]

On Mar 09, martin f krafft  wrote:

> That said, TopGit will not lose track, and if you employ a smart
> branch-naming-scheme, neither will you.
The point is: is it simpler to use than quilt push/pop/edit or not?
If the only benefit I get is being able to automatically publish my
patches then it's not worth the effort.

> If you have any suggestions for improvements, we'd love to hear
I do not have any git experience beyond git pull.
I'd like to use it for my packages, but so far nobody has been able
to persuade me that it would be simpler to use than quilt.
Look e.g. at the ppp (38 patches with more to come, upstream now uses
git), tcp-wrappers (28 patches, dead upstream) or inn (58 patches, no
upstream) packages.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Support of new source packages in squeeze

[Jan Hauke Rahm]

On Mon, Mar 09, 2009 at 02:47:28PM +0100, Goswin von Brederlow wrote:
> Raphael Hertzog  writes:
> 
> > On Mon, 09 Mar 2009, James Westby wrote:
> >> On Sun, 2009-03-08 at 17:11 +0100, Raphael Hertzog wrote:
> >> > There's nothing to specify here, dpkg-source uses all additional tarballs
> >> > that match the regexp (exactly like it identifies the .orig tarball
> >> > currently).
> >> 
> >> bzr-builddeb will endeavour to provide the ".orig.tar.gz" for a format 1
> >> package, so that you can construct a source package from a bzr branch.
> >> 
> >> This will be essentially impossible for 3.0 (quilt) packages that 
> >> use multiple tarballs, as there is no information in the unpacked
> >> source package that tells you which tarballs are needed. This is a
> >> pretty serious problem in my eyes.
> >
> > I could create debian/source/orig-components at unpack time and maybe even
> > have dpkg-source -b check for their existence but I'm not yet convinced
> > that this problem needs to be solved at the dpkg-source level.
> >
> > Furthermore, creating debian/source/orig-components is interesting
> > for your use case together with --skip-debianization and it's somewhat
> > weird to have only that file in the debian tree in that case.
> >
> > What do others think ?
> 
> I think it would be good to have this in dpkg. That way all the
> different RCS build scripts can use the same file and syntax. If every
> rcs-buildpackage creates their own file then migrating from e.g. svn
> to git means rewriting that config.

OTOH Raphael has a point: if you don't have any debian/ in your upstream
code it doesn't really make sense to have a single
debian/source/orig-components stored there. That is adding debian
specific data (or at least data that's only needed by debian) to the
upstream data. I actually thought about storing that info in
svn-properties.

Hauke


signature.asc
Description: Digital signature

Re: emboss: FTBFS when converted to new source format 3.0 (quilt): non-unidiff patch

[Charles Plessy]

Le Mon, Jun 09, 2008 at 12:01:02AM +0200, Raphael Hertzog a écrit :
> 
> To prepare a possible switch to the new source package format "3.0
> (quilt)" [1], I converted all source packages and tried to rebuild them.
> Unfortunately, emboss failed, you can try yourself with those
> commands (and dpkg-dev >= 1.14.19 [2]) :
 
> In the case of emboss, the patch
> emboss-5.0.0/debian/patches/patch-1-9 is not in unified diff format.
> Please convert it. quilt refresh can do this for you.

Bonjour Raphaël,

Since the discussion started. I take the opportunity of asking a question with
one of my packages as example. I ask it on -devel because I wonder if it is a
cornercase or if it would concern more persons.

The software suite EMBOSS is released once per year, and any other upstream
change is done through an official monolithic patch. The Debian emboss source
package applies this upstream patch using quilt, but conversion to source
format 3.0 (quilt) does not work because the patch is not in the 'unified'
format.

http://svn.debian.org/wsvn/debian-med/trunk/packages/emboss/trunk/debian/patches/upstream.patch?op=file&rev=0&sc=0

Since despite it is not unified, this the patch is very well accepted by quilt,
do you think it would be possible to make format 3.0 (quilt) accept this format
as well ? The motivation is to stay as identical as possible to Upstream
material (the only modification I make is to add an explanatory header).

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[martin f krafft]

also sprach Marco d'Itri  [2009.03.09.1510 +0100]:
> > That said, TopGit will not lose track, and if you employ a smart
> > branch-naming-scheme, neither will you.
> The point is: is it simpler to use than quilt push/pop/edit or not?

I don't know quilt merging capabilities or the conflict resolution
features it provides, but Git continues to amaze me in those
regard. It is important though to understand how it actually works
and readjust your expectations accordingly.

http://marc.info/?l=git&m=119198136508405&w=2
http://marc.info/?l=git&m=119198488411957&w=2

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
minchinhampton (n.): the expression on a man's face when he has just
zipped up his trousers without due care and attention.
   -- douglas adams, the meaning of liff


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]

[Andreas Rottmann]

Samuel Thibault  writes:

> Andreas Rottmann, le Mon 09 Mar 2009 11:25:11 +0100, a écrit :
>> Did you know about the `-P' option of GNU xargs?
>
> Herm, I would have found it if the manpage didn't lack keywords like
> "parallel", "simultaneous", ... Reassigning.
>
> That being said, I guess xargs lacks one parallel feature:
>
>  -g   Group output.  Output from each jobs is grouped together and is 
> only printed
>   when the command is finished. STDERR first followed by STDOUT.  -g 
> is the
>   default. Can be reversed with -u.
>
> A lot of applications (including md5sum) would not necessarily print
> their output atomically and then you get mixed output.  Either we add
> the option to findutils, or we package parallel.
>
Indeed, that's a very valuable feature (if not essential) when the
commands produce output; I've attached a script that can be used to
verify that "xargs -P" does not do this, can be used like:

xargs -P 5 ./test.sh < /some/text/file

#!/bin/sh

for i in `seq 10`; do
echo -n "$i "
sleep 1
done
echo

Regards, Rotty

Bug#518984: ITP: cp2k -- Molecular/Quantum Dynamics Simulatur

[Michael Banck]

Package: wnpp
Severity: wishlist
Owner: Debichem Project 


* Package name: cp2k
  Version : CVS snapshot
  Upstream Author : 
http://developer.berlios.de/project/memberlist.php?group_id=129
* URL : http://cp2k.berlios.de/
* License : GPL
  Programming Lang: Fortran95
  Description : Molecular/Quantum Dynamics Simulatur

CP2K is a program to perform atomistic and molecular simulations of
solid state, liquid, molecular and biological systems. It provides a
general framework for different methods such as e.g. density functional
theory (DFT) using a mixed Gaussian and plane waves approach (GPW), and
classical pair and many-body potentials. 

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

inetd's status in Debian

[Pierre Habouzit]

We're in an era where inetds are less and less a central piece of a
standard Linux distribution. Inetd was used in the past because many
servers lacked a proper standalone mode, or were too memory-hungry.

Most machines nowadays have enough memory, and most daemons provide a
standalone mode (I mean who configures apache as an inetd service ?).

Looking at my own case, my sole inetd uses are for bitlebee which
nowadays provides a standalone mode, and git-daemon because I'm too lazy
to write an init script.

Just looking at the packages requiring an inet superserver, you'll see that
it's probably that nowadays users don't need a superserver at all[0].

I'm wondering if making super servers become optionnal wouldn't be a worthy
goal for squeeze.

Note: I'm not saying we should remove super servers from Debian, I'm just
  saying it's not as central as it used to be.



[0]  grep-dctrl -sSource,Package -FDepends inet-superserver gives:

Package: afbackup

Source: amanda
Package: amanda-common

Source: atftp
Package: atftpd

Package: bidentd

Package: bozohttpd

Package: dbskkd-cdb

Source: fai
Package: fai-quickstart

Package: fakepop

Source: firebird2.0
Package: firebird2.0-classic

Source: firebird2.1
Package: firebird2.1-classic

Source: linux-ftpd
Package: ftpd

Source: linux-ftpd-ssl
Package: ftpd-ssl

Package: gtalk

Package: gwhois

Source: heimdal
Package: heimdal-kdc

Source: heimdal
Package: heimdal-servers

Source: heimdal
Package: heimdal-servers-x

Source: inetutils
Package: inetutils-talkd

Source: inetutils
Package: inetutils-telnetd

Source: uw-imap
Package: ipopd

Package: isdnutils

Source: isdnutils
Package: isdnvboxserver

Source: krb5
Package: krb5-ftpd

Source: krb5
Package: krb5-rsh-server

Source: krb5
Package: krb5-telnetd

Source: ldm
Package: ldm-server

Package: leafnode

Source: ltsp
Package: ltsp-server-standalone

Package: micro-httpd

Package: midentd

Package: node

Source: cernlib
Package: pawserv

Package: pidentd

Source: proftpd-dfsg
Package: proftpd-basic

Package: qpopper

Source: qpopper
Package: qpopper-drac

Source: remctl
Package: remctl-server

Source: rsh-redone
Package: rsh-redone-server

Source: netkit-rsh
Package: rsh-server

Package: rstatd

Source: netkit-rwall
Package: rwalld

Package: sendfile

Package: skksearch

Package: sn

Source: samba
Package: swat

Source: netkit-ntalk
Package: talkd

Source: netkit-telnet
Package: telnetd

Source: netkit-telnet-ssl
Package: telnetd-ssl

Source: netkit-tftp
Package: tftpd

Package: uucp

Source: uw-imap
Package: uw-imapd

Source: wipl
Package: wipl-client-inetd

Package: xfingerd

Package: xtel

-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org


pgpW8gqPYRsQu.pgp
Description: PGP signature

Re: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]

[Chuan-kai Lin]

On Mon, Mar 09, 2009 at 11:40:51AM +0100, Samuel Thibault wrote:
> A lot of applications (including md5sum) would not necessarily print
> their output atomically and then you get mixed output.  Either we add
> the option to findutils, or we package parallel.

It appears to me that you can get the same functionality by using xargs
with an adapted version of annotate-output(1) which is a part of
devscripts.  Are there other reasons to use parallel?

-- 
Chuan-kai Lin
http://web.cecs.pdx.edu/~cklin/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[James Westby]

On Mon, 2009-03-09 at 09:24 +0100, Raphael Hertzog wrote: 
> If bzr-builddeb wants to provide the tarballs, they must have been
> injected at some point (otherwise you won't provide pristine tarballs)
> and you could record the additional information at that point.

That is almost true, except for the fact that pristine-tar is not
the only way to provide pristine tarballs.

Your suggestion will work fine where pristine-tar is used, and that
is the recommended method, but there are alternatives.

Considering how uscan and other things will work with multiple tarballs
will at least allow me to understand what is possible.

> > Have you thought about how this will work with things such as uscan?
> > Having some way to check for newer versions of all the tarballs that
> > go together to make the source package would be important.
> 
> I have not designed solution for all tools. But I'm fully aware that uscan
> will need adjustments to cope with this. It's even listed in the wiki
> page. Feel free to file a bug about this so that they can think of a
> solution.
> 
> (That said packages with multiple tarballs are a large minority and it's
> not a big deal if uscan support is not fully aware of additional tarballs
> in the beginning)

I was just wondering if you had considered what a solution might look 
like. It seems like adding a new watch file format that has multiple 
lines would work quite nicely for uscan.

> > Something will be needed for the use case I have, your proposed option
> > sounds sensible to me.
> 
> Ok, will try to have that in dpkg 1.15.1.
> 

Great, thanks,

James


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[James Westby]

On Mon, 2009-03-09 at 12:30 +0100, Jan Hauke Rahm wrote:
> Imagine an orig tarball with a config directory and an orig part-tarball
> named orig-config.tar.whatever. The second tarball would overwrite
> what's in the config dir of the first one when executing dpkg-source -x.
> If you just store that unpacked data in a VCS you've lost what's in the
> config dir in the first tarball because it's overwritten.

Yes, for SVN that is true, but I am writing a plugin for a distributed
system, so it can be made to work, just like you can access the
untouched upstream file that Debian has patched in such a system.

I haven't decided how I think it should work with multiple tarballs yet
though.

Thanks,

James


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#519003: ITP: xca -- x509 Certification Authority management tool based on QT4

[Tino Keitel]

Package: wnpp
Severity: wishlist
Owner: Tino Keitel 


* Package name: xca
  Version : 0.6.4
  Upstream Author : Name 
* URL : http://xca.sourceforge.net/
* License : BSD
  Programming Lang: C++
  Description : x509 Certification Authority management tool based on QT4

 XCA creates and manages certificate authorities and helps the user to
 create and manage keys, certificates, certificate sign requests,
 certificate revocation lists etc.
 .
 All data is saved in an encrypted, portable database, and can be exported
 in various standard formats. XCA is also available for MacOS X and
 Windows systems.
 .
 For a good workflow, certificate templates can be defined to make the
 creation of new certificates an easy task.

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



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

To the aqualung NMUer....

[Adam Cécile (Le_Vert)]

Hello,

I just received a DAK acknowledgement for aqualung 0.9~beta9.1-1.1 but 
it's not me who prepared this package.
I guess it's a NMU fixing the ffmpeg/libavcodec issue but I can't found 
any related message neither on the BTS nor on debian mailing lists 
(-devel and -release).


I would have been great if this people told me he were preparing a NMU 
because I was working on new upstream release package that ALSO fix the 
ffmpeg issue.


Anyway... If someone is responsible of this upload, please overwrite it 
by the new packages I just uploaded to debian-mentors:

http://mentors.debian.net/debian/pool/main/a/aqualung/aqualung_0.9~beta10-1.dsc

Thanks in advance,

Adam.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

To the aqualung NMUer....

[Adam Cécile (Le_Vert)]

Hello,

I just received a DAK acknowledgement for aqualung 0.9~beta9.1-1.1 but 
it's not me who prepared this package.
I guess it's a NMU fixing the ffmpeg/libavcodec issue but I can't found 
any related message neither on the BTS nor on debian mailing lists 
(-devel and -release).


I would have been great if this people told me he were preparing a NMU 
because I was working on new upstream release package that ALSO fix the 
ffmpeg issue.


Anyway... If someone is responsible of this upload, please overwrite it 
by the new packages I just uploaded to debian-mentors:

http://mentors.debian.net/debian/pool/main/a/aqualung/aqualung_0.9~beta10-1.dsc

Thanks in advance,

Adam.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: To the aqualung NMUer....

[Sune Vuorela]

On 2009-03-09, Adam Cécile (Le_Vert)  wrote:
> I would have been great if this people told me he were preparing a NMU 
> because I was working on new upstream release package that ALSO fix the 
> ffmpeg issue.

It would have been great if you write the progress in your bug report -
including that you are almost ready and just awaiting sponsorship.

And it would also be great if you would say thank you to people fixing
your packages helping transitions.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: To the aqualung NMUer....

[Adeodato Simó]

I can't possibly say how annoyed I am.

  1. Don't spam devel to contact just one person.
  2. Read devel: http://lists.debian.org/debian-devel/2009/03/msg00034.html
  3. Or you can also read d-d-a: 
http://lists.debian.org/debian-devel-announce/2009/03/msg0.html
  4. Or you can just deal with your RC bugs in a timely manner
  5. Or you can just mention in the bug report that you're working on a fix
  6. Or you can state that you don't want NMUs
  7. Or you could do as everybody else and actually thank people for
 NMUing you

Best,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
La música es de los que la quieren escuchar y de nadie más.
-- Andrés Calamaro


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[Stefano Zacchiroli]

On Mon, Mar 09, 2009 at 03:10:22PM +0100, Marco d'Itri wrote:
> > That said, TopGit will not lose track, and if you employ a smart
> > branch-naming-scheme, neither will you.
> The point is: is it simpler to use than quilt push/pop/edit or not?

No.

It is more expressive, and can give more easily access to individual
patches (e.g. for pushing them upstream) when they get entangled with
others.  I'm using it because I'm convinced that it implements the
right® packaging work-flow, as no other tool we currently have in our
toolbox.

... but it is, still, way more complex than legacy patch systems.
Also, it requires serious git-fu if you get stuck.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: To the aqualung NMUer....

[Adam Cécile (Le_Vert)]

Barry deFreese a écrit :

Adam Cécile (Le_Vert) wrote:

Hello,

I just received a DAK acknowledgement for aqualung 0.9~beta9.1-1.1 
but it's not me who prepared this package.
I guess it's a NMU fixing the ffmpeg/libavcodec issue but I can't 
found any related message neither on the BTS nor on debian mailing 
lists (-devel and -release).


I would have been great if this people told me he were preparing a 
NMU because I was working on new upstream release package that ALSO 
fix the ffmpeg issue.


Anyway... If someone is responsible of this upload, please overwrite 
it by the new packages I just uploaded to debian-mentors:
http://mentors.debian.net/debian/pool/main/a/aqualung/aqualung_0.9~beta10-1.dsc 



Thanks in advance,

Adam.


That was me.  I haven't posted the diff for the NMU yet.  I'll take a 
look at the new upstream on mentors.  Of course tagging the existing 
bug as pending or some other form of notification that you were 
working on it would have helped.


Sorry,

Barry deFreese

Hello,

Thanks for having a look to the new upstream release and sorry for not 
having updated the bug status !


Adam


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: To the aqualung NMUer....

[Barry deFreese]

Adam Cécile (Le_Vert) wrote:

Hello,

I just received a DAK acknowledgement for aqualung 0.9~beta9.1-1.1 but 
it's not me who prepared this package.
I guess it's a NMU fixing the ffmpeg/libavcodec issue but I can't 
found any related message neither on the BTS nor on debian mailing 
lists (-devel and -release).


I would have been great if this people told me he were preparing a NMU 
because I was working on new upstream release package that ALSO fix 
the ffmpeg issue.


Anyway... If someone is responsible of this upload, please overwrite 
it by the new packages I just uploaded to debian-mentors:
http://mentors.debian.net/debian/pool/main/a/aqualung/aqualung_0.9~beta10-1.dsc 



Thanks in advance,

Adam.


That was me.  I haven't posted the diff for the NMU yet.  I'll take a 
look at the new upstream on mentors.  Of course tagging the existing bug 
as pending or some other form of notification that you were working on 
it would have helped.


Sorry,

Barry deFreese


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#519003: ITP: xca -- x509 Certification Authority management tool based on QT4

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tino Keitel wrote:

> * Package name: xca
>   Description : x509 Certification Authority management tool based on
>   QT4

Is there anything significant that distinguishes this from TinyCA?

Cheers,

Marcus

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkm1h5cACgkQXjXn6TzcAQmvjwCfXYKtIRBgccuS2MAwH5Hn44kM
BkYAoJ669C/cQYFoN74PrP0yN0o8t3MZ
=bY3K
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: To the aqualung NMUer....

[Don Armstrong]

On Mon, 09 Mar 2009, Sune Vuorela wrote:
> It would have been great if you write the progress in your bug
> report - including that you are almost ready and just awaiting
> sponsorship.

This would definetly be useful, as it would help someone from wasting
time preparing the NMU in the first place, but it certainly doesn't
excuse making NMUs without notifying the maintainer beforehand.

> And it would also be great if you would say thank you to people fixing
> your packages helping transitions.

Help is certainly useful, but there's still no message to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517466 regarding the
actual patch that was used to NMU, nor any message before the NMU
regarding intent to NMU.

All of that should happen before uploading an NMU, and certainly
should have happened by now.


Don Armstrong

-- 
Where am I? THE VILLAGE. What do you want? INFORMATION. Which side are
you on? THAT WOULD BE TELLING. WE WANT INFORMATION. INFORMATION.
INFORMATION. You won't get it! BY HOOK OR BY CROOK, WE WILL. Who are
you? THE NEW NUMBER 2. Who is Number One? YOU ARE NUMBER SIX. I am not
a number! I am a free man! HAHAHAHAHAHA.
 -- Patrick McGoohan as Number 6 with Number 2 in "The Prisoner"

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: To the aqualung NMUer....

[Don Armstrong]

On Mon, 09 Mar 2009, Barry deFreese wrote:
> That was me. I haven't posted the diff for the NMU yet.

Just to underline here, you need to send the diff for the NMU to the
bug(s) that you are fixing in the NMU *before* uploading the NMU.

In the case where a 0-day NMU is valid, you can upload immediately
following this, but there should never be a period of time where the
NMU has gone through and the patch has not landed in the BTS.


Don Armstrong

-- 
Nothing is as inevitable as a mistake whose time has come.
 -- Tussman's Law

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: To the aqualung NMUer....

[Adam Cécile (Le_Vert)]

Don Armstrong a écrit :

On Mon, 09 Mar 2009, Barry deFreese wrote:
  

That was me. I haven't posted the diff for the NMU yet.



Just to underline here, you need to send the diff for the NMU to the
bug(s) that you are fixing in the NMU *before* uploading the NMU.

In the case where a 0-day NMU is valid, you can upload immediately
following this, but there should never be a period of time where the
NMU has gone through and the patch has not landed in the BTS.


Don Armstrong
  

We were both wrong and I guess we're aware of it ;)
Anyway, the issue is fixed; I just received a dak email for latest 
upstream package.


Thanks and sorry for bothering -devel !

Adam.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[martin f krafft]

also sprach Stefano Zacchiroli  [2009.03.09.2210 +0100]:
> It is more expressive, and can give more easily access to
> individual patches (e.g. for pushing them upstream) when they get
> entangled with others.  I'm using it because I'm convinced that it
> implements the right® packaging work-flow, as no other tool we
> currently have in our toolbox.

Actually, it all boils down to the distinction between who will do
the conflict resolution: you or the consumer. Manoj and I had long
debates about this on vcs-pkg-discuss.

With quilt, you are asking all consumers to do the conflict
resolution, in case a patch depends on an earlier one. 

With plain feature branches, you have to do the conflict resolution
every time you pull them together to create a package.

TopGit can do both. You can maintain a simple stack, or a queue, or
anything in between. It allows^W encourages you to lean towards the
latter, so if a patch really depends on another, then upstream will
need both anyway. Then B depends on A. If a patch does not depend on
another, then B coexists with A and can be used separately.

> ... but it is, still, way more complex than legacy patch systems.
> Also, it requires serious git-fu if you get stuck.

Yes, it's definitely too complex right now, and just like Git, it
exposes too much of the internals.

I also feel it's the right direction, but it needs work. Having
experience people feed back their input and patches (!) will help.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"there are more things in heaven and earth, horatio,
 than are dreamt of in your philosophy."
 -- hamlet


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Bug#519003: ITP: xca -- x509 Certification Authority management tool based on QT4

[Darren Salt]

I demand that Marcus Better may or may not have written...

> Tino Keitel wrote:
>> * Package name: xca
>>   Description : x509 Certification Authority management tool based on QT4

> Is there anything significant that distinguishes this from TinyCA?

Other than it not being GTK-based? I can imagine that being enough for some...

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES.

The soul would have no rainbow had the eyes no tears.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]

[Samuel Thibault]

Chuan-kai Lin, le Mon 09 Mar 2009 12:46:35 -0700, a écrit :
> On Mon, Mar 09, 2009 at 11:40:51AM +0100, Samuel Thibault wrote:
> > A lot of applications (including md5sum) would not necessarily print
> > their output atomically and then you get mixed output.  Either we add
> > the option to findutils, or we package parallel.
> 
> It appears to me that you can get the same functionality by using xargs
> with an adapted version of annotate-output(1) which is a part of
> devscripts.  Are there other reasons to use parallel?

Upstream author would say that xargs also misses

   -c   Line is a command.  The input line contains more than one
argument or the input line needs to be evaluated by the shell.
This is the default if command is not set. Can be reversed
with -f.

which makes parallel not take a command, but executes commands from
stdin.  That can however be obtained by xargs sh -c.  Another option
that xargs misses is

   -j +NAdd N to the number of CPUs.  Run this many jobs in parallel.
For compute intensive jobs -j +0 is useful as it will run
number-of-cpus jobs in parallel.

   -j -NSubtract N from the number of CPUs.  Run this many jobs in
parallel.  If the evaluated number is less than 1 then 1 will
be used.

   -j N%Multiply N% with the number of CPUs.  Run this many jobs in
parallel.  If the evaluated number is less than 1 then 1 will
be used.

in particular -j +0 is really useful.  I would personally be happy if
xargs was just able to consider e.g. -P -1 as "run as many processes as
there are processors".

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]

[Samuel Thibault]

Chuan-kai Lin, le Mon 09 Mar 2009 12:46:35 -0700, a écrit :
> On Mon, Mar 09, 2009 at 11:40:51AM +0100, Samuel Thibault wrote:
> > A lot of applications (including md5sum) would not necessarily print
> > their output atomically and then you get mixed output.  Either we add
> > the option to findutils, or we package parallel.
> 
> It appears to me that you can get the same functionality by using xargs
> with an adapted version of annotate-output(1) which is a part of
> devscripts.

I thought at first "it's not particularly convenient", then "well, so
what".  Now I'm thinking "Mmm, but people won't know they should do it
and blame xargs for being broken".  Also annotate-output is not enough
when programs e.g. output Packages entries, which not only should be
line-atomic, but also paragraph-atomic...

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Grid tasks

[Chris Walker]

I propose we (Debian-science) create two grid tasks packages:

Grid-client: This would contain the packages  a user workstation needs to
submit jobs to the grid.

Grid-server: Packages for running a grid cluster. 

The globus packages recently proposed on debian-devel are obvious
candidates. 

Would there be support for creating a grid task, and splitting it this way?

Currently the packages are in the new queue. Should I wait until they
actually reach unstable before creating the task? Are there any other
obvious candidate packages?

Chris




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Support of new source packages in squeeze

[Ben Finney]

martin f krafft  writes:

> also sprach Goswin von Brederlow  [2009.03.09.1443 +0100]:
> > From a usability point of view I find it unusable. With so many
> > branches you always forget to merge one or don't commit to the
> > right one.
> 
> Uh, this is in response to TopGit, which addresses precisely this
> problem: keeping track of the branches and automating their use.

Likewise, with Bazaar the ‘bzr-loom’ plug-in is very handy for
managing a stack of patches in a single branch and moving easily
between them.

-- 
 \  “The fact that a believer is happier than a skeptic is no more |
  `\   to the point than the fact that a drunken man is happier than a |
_o__) sober one.” —George Bernard Shaw |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#519003: ITP: xca -- x509 Certification Authority management tool based on QT4

[Tino Keitel]

On Mon, Mar 09, 2009 at 22:18:15 +0100, Marcus Better wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Tino Keitel wrote:
> 
> > * Package name: xca
> >   Description : x509 Certification Authority management tool based on
> >   QT4
> 
> Is there anything significant that distinguishes this from TinyCA?

XCA has more flexible template support, whereas TinyCA2 seems to be
limited to client, server and CA templates. Furthermore, XCA uses QT
instead of GTK.

Regards,
Tino


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]

[Cyril Brulebois]

Samuel Thibault  (09/03/2009):
> which makes parallel not take a command, but executes commands from
> stdin.  That can however be obtained by xargs sh -c.  Another option
> that xargs misses is
> 
>-j +NAdd N to the number of CPUs.  Run this many jobs in parallel.
> For compute intensive jobs -j +0 is useful as it will run
> number-of-cpus jobs in parallel.
> 
>-j -NSubtract N from the number of CPUs.  Run this many jobs in
> parallel.  If the evaluated number is less than 1 then 1 will
> be used.
> 
>-j N%Multiply N% with the number of CPUs.  Run this many jobs in
> parallel.  If the evaluated number is less than 1 then 1 will
> be used.

Particularly useful in cluster environments. :)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]

[Chuan-kai Lin]

On Mon, Mar 09, 2009 at 10:57:57PM +0100, Samuel Thibault wrote:
> I thought at first "it's not particularly convenient", then "well, so
> what".  Now I'm thinking "Mmm, but people won't know they should do it
> and blame xargs for being broken".  Also annotate-output is not enough
> when programs e.g. output Packages entries, which not only should be
> line-atomic, but also paragraph-atomic...

Below is what I had in mind when I mentioned adapting annotate-output to
a different "atomic-output" script.  This script is usefull not just
with "xargs -P", but also with "make -j" and with standard background
jobs (shell & operator), all of which produce mixed output.

Similarly, about matching the number of parallel jobs with the number of
processors/cores, we can write a script "ncpus" which returns the number
of processors/cores/hyper-threads.  You can use the ncpus script with
xargs, with make, or with my new project mdm (mdm.berlios.de)...

I consider separating these concerns (output management, processor
thread detection) into small, separate, and reusable scripts a cleaner
solution.  Of course, doing it this way requires some user education, so
a few manpage updates (for example, adding atomic-output and ncpus to
the SEE ALSO section of xargs) may be in order.

--

#! /bin/bash
# Display stdout and stderr output after program termination
# Adapted from annotate-output by Chuan-kai Lin
# Original annotate-output author info and copyright notice as follows

# this script was downloaded from:
# http://jeroen.a-eskwadraat.nl/sw/annotate 
# and is part of devscripts 2.10.46

# Executes a program annotating the output linewise with time and stream
# Version 1.2

# Copyright 2003, 2004 Jeroen van Wolffelaar 

# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA

OUT=`mktemp /tmp/atomic.XX` || exit 1
ERR=`mktemp /tmp/atomic.XX` || exit 1

echo "-- `date +%H:%M:%S` Started $@" > $ERR
echo "-- STDERR" >> $ERR
echo "-- STDOUT" >> $OUT
"$@" >> $OUT 2>> $ERR ; EXIT=$?

cat $ERR
cat $OUT
echo "-- `date +%H:%M:%S` Finished with exitcode $EXIT"
rm -f $OUT $ERR

exit $EXIT

-- 
Chuan-kai Lin
http://web.cecs.pdx.edu/~cklin/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]

[Philip Charles]

Phil's in hospital. Will reply towards end of week.



On Tuesday 10 March 2009, Chuan-kai Lin wrote:
> On Mon, Mar 09, 2009 at 10:57:57PM +0100, Samuel Thibault wrote:
> > I thought at first "it's not particularly convenient", then "well, so
> > what".  Now I'm thinking "Mmm, but people won't know they should do
> > it and blame xargs for being broken".  Also annotate-output is not
> > enough when programs e.g. output Packages entries, which not only
> > should be line-atomic, but also paragraph-atomic...
>
> Below is what I had in mind when I mentioned adapting annotate-output
> to a different "atomic-output" script.  This script is usefull not just
> with "xargs -P", but also with "make -j" and with standard background
> jobs (shell & operator), all of which produce mixed output.
>
> Similarly, about matching the number of parallel jobs with the number
> of processors/cores, we can write a script "ncpus" which returns the
> number of processors/cores/hyper-threads.  You can use the ncpus script
> with xargs, with make, or with my new project mdm (mdm.berlios.de)...
>
> I consider separating these concerns (output management, processor
> thread detection) into small, separate, and reusable scripts a cleaner
> solution.  Of course, doing it this way requires some user education,
> so a few manpage updates (for example, adding atomic-output and ncpus
> to the SEE ALSO section of xargs) may be in order.
>
> --
>
> #! /bin/bash
> # Display stdout and stderr output after program termination
> # Adapted from annotate-output by Chuan-kai Lin
> # Original annotate-output author info and copyright notice as follows
>
> # this script was downloaded from:
> # http://jeroen.a-eskwadraat.nl/sw/annotate
> # and is part of devscripts 2.10.46
>
> # Executes a program annotating the output linewise with time and
> stream # Version 1.2
>
> # Copyright 2003, 2004 Jeroen van Wolffelaar 
>
> # This program is free software; you can redistribute it and/or modify
> # it under the terms of the GNU General Public License as published by
> # the Free Software Foundation; version 2 of the License
> #
> # This program is distributed in the hope that it will be useful,
> # but WITHOUT ANY WARRANTY; without even the implied warranty of
> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> # GNU General Public License for more details.
> #
> # You should have received a copy of the GNU General Public License
> # along with this program; if not, write to the Free Software
> # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
> USA
>
> OUT=`mktemp /tmp/atomic.XX` || exit 1
> ERR=`mktemp /tmp/atomic.XX` || exit 1
>
> echo "-- `date +%H:%M:%S` Started $@" > $ERR
> echo "-- STDERR" >> $ERR
> echo "-- STDOUT" >> $OUT
> "$@" >> $OUT 2>> $ERR ; EXIT=$?
>
> cat $ERR
> cat $OUT
> echo "-- `date +%H:%M:%S` Finished with exitcode $EXIT"
> rm -f $OUT $ERR
>
> exit $EXIT
>
> --
> Chuan-kai Lin
> http://web.cecs.pdx.edu/~cklin/



-- 
  Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand
   +64 3 488 2818Fax +64 3 488 2875Mobile 027 663 4453
   phil...@copyleft.co.nz - personal.i...@copyleft.co.nz - business


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#519003: ITP: xca -- x509 Certification Authority management tool based on QT4

[Henrique de Moraes Holschuh]

On Mon, 09 Mar 2009, Tino Keitel wrote:
> On Mon, Mar 09, 2009 at 22:18:15 +0100, Marcus Better wrote:
> > > * Package name: xca
> > >   Description : x509 Certification Authority management tool based on
> > >   QT4
> > 
> > Is there anything significant that distinguishes this from TinyCA?
> 
> XCA has more flexible template support, whereas TinyCA2 seems to be
> limited to client, server and CA templates. Furthermore, XCA uses QT
> instead of GTK.

If XCA has _any_ documentation at all, it is already better than TinyCA2 in
something.

Mind you, I am assuming it does a decent job of following the x509 style
guide and gets certificate requests and CAs right.  If it doesn't, it is
actively harmful and should not be accepted at all.

Upstream looks just as dead as tinyca2, and that is a MAJOR point against
it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Accelerated video cards and non-free firmware

[Ben Hutchings]

On Wed, 2009-02-25 at 16:28 -0500, Daniel Dickinson wrote:
> Hi,
> 
> I'm looking at getting a video card, and I want to know what video card
> that has 3D acceleration to get.  Normally I'd ask on -users but as the
> subject says I want to know what video cards will still have
> acceleration when the non-free firmware is removed from the kernel,
> which is supposed to happen for squeeze.
> 
> I had heard that the ATI cards, which would normally be my first
> choice, have non-free firmware in the driver, which may be removed.  Is
> this true, and if so what accelerated cards will have have acceleration
> once non-free firmware is removed.
[...]

The firmware used for 3D acceleration in the r128 (ATI Rage 128), radeon
(ATI Radeon) and mga (Matrox G200/G400/G550) drivers is non-free and
will be moved from the linux-image packages into a new firmware-linux
package starting with Linux 2.6.29.

The free drivers for Intel and Nvidia graphics hardware should support
3D acceleration without the need for non-free firmware.  I'm not sure
that any of the free graphics drivers have great 3D performance though.

Ben.



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

Re: inetd's status in Debian

[Steve Langasek]

On Mon, Mar 09, 2009 at 08:06:16PM +0100, Pierre Habouzit wrote:
> Just looking at the packages requiring an inet superserver, you'll see that
> it's probably that nowadays users don't need a superserver at all[0].

Yes, and many users no longer have a superserver installed for that reason.

> I'm wondering if making super servers become optionnal wouldn't be a worthy
> goal for squeeze.

Why?  If it ain't broke, don't fix it.  Having a superserver installed isn't
broken.  Why should every daemon have to implement connection handling when
they can offload that to the inetd?

Demoting inetd from standard to optional seems to me like a reasonable
release goal; that doesn't require patching lots of upstream code that works
just fine the way it is already.  In fact, AFAICS it doesn't require
patching any of our packages.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#519003: ITP: xca -- x509 Certification Authority management tool based on QT4

[Tino Keitel]

On Mon, Mar 09, 2009 at 21:10:30 -0300, Henrique de Moraes Holschuh wrote:

[...]

> If XCA has _any_ documentation at all, it is already better than TinyCA2 in
> something.

It has a lot of HTML documentation. However, the GUI is easy to use, I
never needed to look into the documentation.

> Mind you, I am assuming it does a decent job of following the x509 style
> guide and gets certificate requests and CAs right.  If it doesn't, it is
> actively harmful and should not be accepted at all.

I don't know about "x509 style guide", I'll look into it.

> Upstream looks just as dead as tinyca2, and that is a MAJOR point against
> it.

Yes, the last upstream version is from 2007. But the author is working
on 0.7, the last commit in the git repisitory[1] is from March 3rd.  I
also know the author in person.

My packaging is already finished and lintian-clean, and I have a
sponsor, too.  I'm waiting for the author to include 2 small patches
and release a 0.7 version

Regards,
Tino

[1] http://git.hohnstaedt.de/xca.git


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: inetd's status in Debian

[Luk Claes]

Steve Langasek wrote:
> On Mon, Mar 09, 2009 at 08:06:16PM +0100, Pierre Habouzit wrote:

>> I'm wondering if making super servers become optionnal wouldn't be a worthy
>> goal for squeeze.
> 
> Why?  If it ain't broke, don't fix it.  Having a superserver installed isn't
> broken.  Why should every daemon have to implement connection handling when
> they can offload that to the inetd?
> 
> Demoting inetd from standard to optional seems to me like a reasonable
> release goal; that doesn't require patching lots of upstream code that works
> just fine the way it is already.  In fact, AFAICS it doesn't require
> patching any of our packages.

Right, isn't that the proposal: demote inetd and update-inetd to
optional/extra?

Btw, lots of packages are depending on update-inetd while it's
guaranteed to be available when depending on inet-superserver.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: inetd's status in Debian

[Steve Langasek]

On Tue, Mar 10, 2009 at 07:31:35AM +0100, Luk Claes wrote:
> Steve Langasek wrote:
> > On Mon, Mar 09, 2009 at 08:06:16PM +0100, Pierre Habouzit wrote:

> >> I'm wondering if making super servers become optionnal wouldn't be a worthy
> >> goal for squeeze.

> > Why?  If it ain't broke, don't fix it.  Having a superserver installed isn't
> > broken.  Why should every daemon have to implement connection handling when
> > they can offload that to the inetd?

> > Demoting inetd from standard to optional seems to me like a reasonable
> > release goal; that doesn't require patching lots of upstream code that works
> > just fine the way it is already.  In fact, AFAICS it doesn't require
> > patching any of our packages.

> Right, isn't that the proposal: demote inetd and update-inetd to
> optional/extra?

Perhaps I misunderstood, but I read this as a proposal to make /use/ of
inetd optional for the packages that currently depend on it.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org