Re: Support of new source packages in squeeze

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-s

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

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 tho

Re: Support of new source packages in squeeze

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

Re: Support of new source packages in squeeze

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

Re: Support of new source packages in squeeze

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

Re: Support of new source packages in squeeze

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 'di

Re: Support of new source packages in squeeze

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,

Re: Support of new source packages in squeeze

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

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

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

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

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

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

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 > Des

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

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 "paralle

Re: Support of new source packages in squeeze

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 or

Re: lrmi vs new kernels vs libx86

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 ho

Re: Support of new source packages in squeeze

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

Re: Support of new source packages in squeeze

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

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 up

Re: Support of new source packages in squeeze

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

Re: -dbg packages; are they actually useful?

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 f

Re: Support of new source packages in squeeze

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 t

Re: Support of new source packages in squeeze

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 comm

Re: Support of new source packages in squeeze

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

Re: Support of new source packages in squeeze

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 d

Re: Support of new source packages in squeeze

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).

Re: Support of new source packages in squeeze

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

Re: Support of new source packages in squeeze

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

Re: Support of new source packages in squeeze

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

Re: Support of new source packages in squeeze

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 > >> > tha

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

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

Re: Support of new source packages in squeeze

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 resoluti

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

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 l

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

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: Fortran9

inetd's status in Debian

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

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

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 s

Re: Support of new source packages in squeeze

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

Re: Support of new source packages in squeeze

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 tha

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

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 o

To the aqualung NMUer....

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

To the aqualung NMUer....

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

Re: To the aqualung NMUer....

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 y

Re: To the aqualung NMUer....

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

Re: Support of new source packages in squeeze

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

Re: To the aqualung NMUer....

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 debi

Re: To the aqualung NMUer....

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

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

-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- Versio

Re: To the aqualung NMUer....

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,

Re: To the aqualung NMUer....

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 immedi

Re: To the aqualung NMUer....

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 N

Re: Support of new source packages in squeeze

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,

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

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 ca

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

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 finduti

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

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 finduti

Grid tasks

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. Woul

Re: Support of new source packages in squeeze

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 precis

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

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 disti

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

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

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

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

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

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

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

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

Re: Accelerated video cards and non-free firmware

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

Re: inetd's status in Debian

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

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

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

Re: inetd's status in Debian

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

Re: inetd's status in Debian

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