Re: Version numbering for security uploads of native packages

[Bas Wijnen]

[Adding bug #437392 to Cc, which deals with this issue for normal NMUs,
because I'm making a suggestion about them.]

On Sat, Mar 15, 2008 at 11:52:55PM +, Adam D. Barratt wrote:
> devscripts 2.10.19 (soon to be uploaded) will modify the behaviour of
> "debchange --nmu" to version an NMU of a native package as X+nmu1 rather
> than the current X-0.1.

Good idea.  Even better, IMO, would be to use a system which is in line
with non-native packages.  How about this rule:

- An NMU will add an extra item to the version number, which starts
  counting at 1.
- When a new upstream version of a non-native package is uploaded, the
  debian revision is set to 0, and the extra item is added to that.

This means that non-native NMUs will get the same versions as they
always did, while native packages go from "1.8" to "1.8.1", for example.
For native packages, it's impossible to package a new upstream version,
because there is no upstream.

IMO this solution is slightly better than +nmu1, because it makes
versions of native and non-native packages more uniformly mangled.
However, any solution is better than no solution. :-)

> Whilst looking at this change, the question arose of what format
> security uploads of native packages should use, both in general and
> specifically when debchange's --security option is used.
> 
> Currently, debchange will produce a version number of X-0.1 in such
> cases which suffers from the problem described above. It has been
> suggested that either one of +s1 / +sec1 / +security1 or 1
> should be used to avoid the issue.
> 
> The main difficulty with the latter from the point-of-view of adding
> support to debchange is that there's no easy way of mapping a changelog
> distribution (e.g. "stable") to a release name, particularly as both
> stable and oldstable updates may have "stable" as the last distribution
> to which the package was uploaded.

So the problem is that debchange is unable to know the version should be
"stable"?  Or is the problem that versions may collide when oldstable
has a security update, and stable needs one as well?  That doesn't make
sense, because the version will have increased in unstable (by then
stable) at the time the oldstable (at that time stable) update was made.

I'm a bit confused by the problem.

However, I do see a problem with +s1 if +nmu1 is used:  +s1 sorts after
+nmu1.  This means that this versioning can no longer be used if an NMU
is needed after a security update.  In particular, suppose:
- The package version is 1.3 in all distributions.
- A security issue is found.
- 1.3+s1 is uploaded to stable and testing.
- The maintainer isn't available, and 1.3+nmu1 is uploaded to unstable.
- Some time passes, and the package is about to migrate to testing.
- Migration fails, because 1.3+nmu1 << 1.3+s1.

This problem does not occur if 1.3.1 would be used for the normal NMU
(to unstable).

> After some discussion amongst the team on IRC we decided we'd be
> happiest following either a request from the security team or a
> consensus view (or as close to a consensus as -devel ever gets :-).

I think using the rules I proposed above for normal NMUs, and +s
for security NMUs would be best.  However, I might misunderstand the
problem.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Version numbering for security uploads of native packages

[Florian Weimer]

* Adam D. Barratt:

> Currently, debchange will produce a version number of X-0.1 in such
> cases which suffers from the problem described above. It has been
> suggested that either one of +s1 / +sec1 / +security1 or 1
> should be used to avoid the issue.

For stable and oldstable, we need 1.  But the process further
down cannot be automated currently, so this doesn't help that much
anyway.  That's why I'm not inclined to put too much effert into this
discussion. 8-/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version numbering for security uploads of native packages

[Thijs Kinkhorst]

On Sunday 16 March 2008 00:52, Adam D. Barratt wrote:
> We're aware that the Developers Reference specifies that the latter
> format should be used, but it is problematic as -0.1 sorts before +b1
> and, as such, the NMU will not supersede any previous binNMUs of the
> same package version.
>
> Whilst looking at this change, the question arose of what format
> security uploads of native packages should use, both in general and
> specifically when debchange's --security option is used.

There may not be a good solution since MU's, NMU's and security uploads can 
currently be interleaved in any particular order, so it seems hard to make a 
scheme that would work reliably.

Occasionally there are problems with an upload being lower than a binNMU. 
binNMU's are problematic in this regard as they are often done without 
maintainer notification, and if you fetch the source package there's also no 
trace of them, both making it very easy to overlook. That would prompt me 
that reducing these problems may be sought in finding a better binNMU 
numbering scheme, one that sorts only just above the last sourceful upload 
but is very likely to be smaller than any time of new sourceful upload (mu, 
nmu or security) after it.

I'm not yet sure what a good number would be there, but it seems the best 
place to tackle this problem.


Thijs


pgpQgb5jnGxmz.pgp
Description: PGP signature

Re: Version numbering for security uploads of native packages

[Steve Langasek]

On Sun, Mar 16, 2008 at 11:36:20AM +0100, Thijs Kinkhorst wrote:
> On Sunday 16 March 2008 00:52, Adam D. Barratt wrote:
> > We're aware that the Developers Reference specifies that the latter
> > format should be used, but it is problematic as -0.1 sorts before +b1
> > and, as such, the NMU will not supersede any previous binNMUs of the
> > same package version.

> > Whilst looking at this change, the question arose of what format
> > security uploads of native packages should use, both in general and
> > specifically when debchange's --security option is used.

> There may not be a good solution since MU's, NMU's and security uploads can 
> currently be interleaved in any particular order, so it seems hard to make a 
> scheme that would work reliably.

> Occasionally there are problems with an upload being lower than a binNMU. 
> binNMU's are problematic in this regard as they are often done without 
> maintainer notification, and if you fetch the source package there's also no 
> trace of them, both making it very easy to overlook. That would prompt me 
> that reducing these problems may be sought in finding a better binNMU 
> numbering scheme, one that sorts only just above the last sourceful upload 
> but is very likely to be smaller than any time of new sourceful upload (mu, 
> nmu or security) after it.

The current binNMU numbering scheme was selected explicitly to allow
security uploads to sort later by numbering as
+; e.g., 1.2-5.1+etch1.

-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version numbering for security uploads of native packages

[Thijs Kinkhorst]

On Sunday 16 March 2008 11:47, Steve Langasek wrote:
> The current binNMU numbering scheme was selected explicitly to allow
> security uploads to sort later by numbering as
> +; e.g., 1.2-5.1+etch1.

Ah, I wasn't aware of that (and no-one seems to be using it currently). The 
release managers know that they can't choose a release codename which starts 
with "a"? :-)


Thijs


pgpoadyKblz2q.pgp
Description: PGP signature

Re: Version numbering for security uploads of native packages

[Bas Wijnen]

On Sun, Mar 16, 2008 at 03:47:56AM -0700, Steve Langasek wrote:
> The current binNMU numbering scheme was selected explicitly to allow
> security uploads to sort later by numbering as
> +; e.g., 1.2-5.1+etch1.

This could also lead to a problem in very rare cases: If a program has
the same version in stable and testing, and gets a security update, then
they both get a similar version.  For the example, say 1.2-5.1+sarge1 in
stable and 1.2-5.1+etch1 in testing.  Now the version in testing is
lower than that in stable, because "etch" << "sarge" (which is why I
didn't use current names, since "lenny" is, by chance, >> "etch").  If
this happens close to a release, and there is no new unstable
(non-security-versioned) upload migrating to testing, this means users
will end up with the oldstable version of the package (which may contain
dependencies on wrong library versions, for example).

This may never be a problem in reality, but it is a real bug in the
numbering scheme, AFAICS.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Version numbering for security uploads of native packages

[Raphael Hertzog]

On Sun, 16 Mar 2008, Thijs Kinkhorst wrote:
> On Sunday 16 March 2008 00:52, Adam D. Barratt wrote:
> > We're aware that the Developers Reference specifies that the latter
> > format should be used, but it is problematic as -0.1 sorts before +b1
> > and, as such, the NMU will not supersede any previous binNMUs of the
> > same package version.
> >
> > Whilst looking at this change, the question arose of what format
> > security uploads of native packages should use, both in general and
> > specifically when debchange's --security option is used.
> 
> There may not be a good solution since MU's, NMU's and security uploads can 
> currently be interleaved in any particular order, so it seems hard to make a 
> scheme that would work reliably.

It's possible, you just have to put the increment number before the
"type" of upload:
- +c0.nmu (non maintainer upload)
- +c1.sec (security upload)
- +c2.su (stable update)

Unfortunately "+0.nmu" sorts before "+b1" so I had to put "+c0.nmu" so
that binnmu sort lower. And "c" could mean "change" or "external change".

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version numbering for security uploads of native packages

[Adam D. Barratt]

On Sun, 2008-03-16 at 03:47 -0700, Steve Langasek wrote:
> The current binNMU numbering scheme was selected explicitly to allow
> security uploads to sort later by numbering as
> +; e.g., 1.2-5.1+etch1.

That makes sense, although doesn't seem to match current practice. Was
any consideration given as to where NMUs of native packages should sort?
(I realise that they're the only case that doesn't automagically dtrt
with respect to the numbering scheme).

Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#471155: ITP: gnview -- 2ch browser that uses gikonavi's setting and log data

[Hideki Yamane]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

Package name: gnview
 Version: 0.8
 Upstream Author: Mitsutoshi Kiuchi <[EMAIL PROTECTED]>
 URL: http://gnview.sourceforge.jp/
 License: GPL version2
Programming Lang: Perl
 Description: 2ch browser that uses gikonavi's setting and log data
 gnview is gtk2-perl based 2ch browser. It uses "gikonavi" 
setting 
 and logs, famous 2ch browser on Windows.
 .
 If you have gikonavi data, you can use it with gnview.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version numbering for security uploads of native packages

[Charles Plessy]

Le Sun, Mar 16, 2008 at 12:10:13PM +0100, Bas Wijnen a écrit :
> 
> This could also lead to a problem in very rare cases: If a program has
> the same version in stable and testing, and gets a security update, then
> they both get a similar version.  For the example, say 1.2-5.1+sarge1 in
> stable and 1.2-5.1+etch1 in testing.  Now the version in testing is
> lower than that in stable, because "etch" << "sarge" (which is why I
> didn't use current names, since "lenny" is, by chance, >> "etch").

Hi all,

then replacing, "sarge", "etch" and "lenny" by "debian3.1", "debian4.0"
and "debian5.0" would solve the problem permanently :)

By the way, is it necessary that the NMUs would not simply increase the
version number just as regular maintainer uplads would, given that it
can simply be detected otherwise ?

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version numbering for security uploads of native packages

[Adam D. Barratt]

On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:
> [Adding bug #437392 to Cc, which deals with this issue for normal
> NMUs, because I'm making a suggestion about them.]
> 
> On Sat, Mar 15, 2008 at 11:52:55PM +, Adam D. Barratt wrote:
> > devscripts 2.10.19 (soon to be uploaded) will modify the behaviour
> of
> > "debchange --nmu" to version an NMU of a native package as X+nmu1
> rather
> > than the current X-0.1.
> 
> Good idea.  Even better, IMO, would be to use a system which is in
> line with non-native packages.  How about this rule:
[using X.1]
> IMO this solution is slightly better than +nmu1, because it makes
> versions of native and non-native packages more uniformly mangled.
> However, any solution is better than no solution. :-)

That does seem the most logical suggestion thus far.

As .19 fixes a couple of regressions I'd like to get it uploaded soon so
may stick with +nmu for the moment (as you say, it's still better than
-0.1).

[...]
> > It has been
> > suggested that either one of +s1 / +sec1 / +security1 or 1
> > should be used to avoid the issue.
> > 
> > The main difficulty with the latter from the point-of-view of adding
> > support to debchange is that there's no easy way of mapping a changelog
> > distribution (e.g. "stable") to a release name, particularly as both
> > stable and oldstable updates may have "stable" as the last distribution
> > to which the package was uploaded.
> 
> So the problem is that debchange is unable to know the version should be
> "stable"?  Or is the problem that versions may collide when oldstable
> has a security update, and stable needs one as well?

The problem is that the security team want to use version numbers such
as "Xetch1" or "Xsarge1" and these can't reliably be deduced simply by
looking at the package.

If one takes the case of a package in etch or sarge that has not yet had
a security update, how would dch know whether to use sarge1 or etch1 in
the version number? The most recent changelog entry for both packages
would be for "stable".

Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

broken .orig.tar.gz (Re: package upload rejected - no email)

[Bernhard R. Link]

* Steve Langasek <[EMAIL PROTECTED]> [080315 21:12]:
> $ cat /srv/ftp.debian.org/queue/reject/rhinote_0.7.0-2_i386.reason 
> Rejected: md5sum and/or size mismatch on existing copy of 
> rhinote_0.7.0.orig.tar.gz.
> Rejected: can not overwrite existing copy of 'rhinote_0.7.0.orig.tar.gz' 
> already in the archive.

Looking at the file currently in unstable:
|$ tar -tvvzf ../rhinote_0.7.0.orig.tar.gz | head -n1
|drwxr-xr-x kiyuko/kiyuko 0 2006-03-24 02:15 rhinote-0.7.0.orig/

So the original file looks repackaged without any reason (and not
comment about this in the the rhinote_0.7.0-1.diff.gz).

How could this happen? This is a classic error and three people seem
to not have noticed it. The maintainer is no DD, so I won't blame him.
But is there a way to know who the sponsor of rhinote_0.7.0-1 was?
And as rhinote_0.7.0-1 says original upload, I assume some ftp-master
or ftp-assistent looked at it and missed that, too. Is there a way to
find out who is letting this crap in our archive?
(What if the .orig.tar.gz was not only repacked but actually modified,
would everyone have notices?)

Disappointed,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version numbering for security uploads of native packages

[Bas Wijnen]

On Sun, Mar 16, 2008 at 08:23:43PM +0900, Charles Plessy wrote:
> Le Sun, Mar 16, 2008 at 12:10:13PM +0100, Bas Wijnen a écrit :
> > 
> > This could also lead to a problem in very rare cases: If a program has
> > the same version in stable and testing, and gets a security update, then
> > they both get a similar version.  For the example, say 1.2-5.1+sarge1 in
> > stable and 1.2-5.1+etch1 in testing.  Now the version in testing is
> > lower than that in stable, because "etch" << "sarge" (which is why I
> > didn't use current names, since "lenny" is, by chance, >> "etch").
> 
> then replacing, "sarge", "etch" and "lenny" by "debian3.1", "debian4.0"
> and "debian5.0" would solve the problem permanently :)

I thought about this as well, but AFAIK we don't always know in advance
what the version number of testing will be (if it's going to be a minor
or major version increase).

> By the way, is it necessary that the NMUs would not simply increase the
> version number just as regular maintainer uplads would, given that it
> can simply be detected otherwise ?

NMUs should be as non-intrusive as possible.  If the maintainer wants to
use odd numbers for experimental versions, for example, an NMU shouldn't
break that convention.  That's why for non-native packages, the debian
revision is incremented in a way that doesn't touch the maintainer's
versioning scheme.  As I proposed, we could do the same for native
packages, by adding ".1" instead of "-0.1".

This does break versions which go from 1 to 1.1 to 1.2 to 2 to 2.1, etc,
but we're talking about native packages, which means we can expect
upstream not to be so crazy.  And if we can't expect that, we can
enforce it by writing it in policy. ;-)

For all practical purposes, adding ".1" really is "incrementing the
version number", it's only not with the usual step for maintainer
uploads.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: broken .orig.tar.gz (Re: package upload rejected - no email)

[Marc 'HE' Brockschmidt]

"Bernhard R. Link" <[EMAIL PROTECTED]> writes:
> * Steve Langasek <[EMAIL PROTECTED]> [080315 21:12]:
>> $ cat /srv/ftp.debian.org/queue/reject/rhinote_0.7.0-2_i386.reason 
>> Rejected: md5sum and/or size mismatch on existing copy of 
>> rhinote_0.7.0.orig.tar.gz.
>> Rejected: can not overwrite existing copy of 'rhinote_0.7.0.orig.tar.gz' 
>> already in the archive.
> Looking at the file currently in unstable:
> |$ tar -tvvzf ../rhinote_0.7.0.orig.tar.gz | head -n1
> |drwxr-xr-x kiyuko/kiyuko 0 2006-03-24 02:15 rhinote-0.7.0.orig/
>
> So the original file looks repackaged without any reason (and not
> comment about this in the the rhinote_0.7.0-1.diff.gz).
>
> How could this happen? This is a classic error and three people seem
> to not have noticed it. The maintainer is no DD, so I won't blame him.
> But is there a way to know who the sponsor of rhinote_0.7.0-1 was?

[EMAIL PROTECTED]:~$ lynx -dump 
http://packages.qa.debian.org/r/rhinote/news/20080316T114705Z.html | gpg 
--verify
gpg: Signature made Sun 16 Mar 2008 12:40:47 CET using DSA key ID 8CE11941
gpg: Good signature from "Kevin Coyner (Greenwich and Tokyo) <[EMAIL 
PROTECTED]>"
gpg: aka "Kevin Coyner <[EMAIL PROTECTED]>"
gpg: aka "Kevin Coyner <[EMAIL PROTECTED]>"
gpg: aka "Kevin Coyner (Greenwich, CT Station 2) <[EMAIL 
PROTECTED]>"

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
136: Deadline
   Programmtod durch überhastete Weiterentwicklung eines falsch
   konstruierten Entwurfsmusters. (Lutz Donnerhacke)


pgpE1LDB22sLN.pgp
Description: PGP signature

Re: broken .orig.tar.gz (Re: package upload rejected - no email)

[Kurt Roeckx]

On Sun, Mar 16, 2008 at 01:37:29PM +0100, Marc 'HE' Brockschmidt wrote:
> "Bernhard R. Link" <[EMAIL PROTECTED]> writes:
> > * Steve Langasek <[EMAIL PROTECTED]> [080315 21:12]:
> >> $ cat /srv/ftp.debian.org/queue/reject/rhinote_0.7.0-2_i386.reason 
> >> Rejected: md5sum and/or size mismatch on existing copy of 
> >> rhinote_0.7.0.orig.tar.gz.
> >> Rejected: can not overwrite existing copy of 'rhinote_0.7.0.orig.tar.gz' 
> >> already in the archive.
> > Looking at the file currently in unstable:
> > |$ tar -tvvzf ../rhinote_0.7.0.orig.tar.gz | head -n1
> > |drwxr-xr-x kiyuko/kiyuko 0 2006-03-24 02:15 rhinote-0.7.0.orig/
> >
> > So the original file looks repackaged without any reason (and not
> > comment about this in the the rhinote_0.7.0-1.diff.gz).
> >
> > How could this happen? This is a classic error and three people seem
> > to not have noticed it. The maintainer is no DD, so I won't blame him.
> > But is there a way to know who the sponsor of rhinote_0.7.0-1 was?
> 
> [EMAIL PROTECTED]:~$ lynx -dump 
> http://packages.qa.debian.org/r/rhinote/news/20080316T114705Z.html | gpg 
> --verify
> gpg: Signature made Sun 16 Mar 2008 12:40:47 CET using DSA key ID 8CE11941
> gpg: Good signature from "Kevin Coyner (Greenwich and Tokyo) <[EMAIL 
> PROTECTED]>"
> gpg: aka "Kevin Coyner <[EMAIL PROTECTED]>"
> gpg: aka "Kevin Coyner <[EMAIL PROTECTED]>"
> gpg: aka "Kevin Coyner (Greenwich, CT Station 2) <[EMAIL 
> PROTECTED]>"

I think you want the one that uploaded the .orig.tar.gz, so:
lynx -dump http://packages.qa.debian.org/r/rhinote/news/20060625T184700Z.html | 
gpg --verify
gpg: Signature made Sun 11 Jun 2006 03:11:54 PM CEST using DSA key ID B345BDD3
gpg: Good signature from "Neil McGovern <[EMAIL PROTECTED]>"
gpg: aka "Neil McGovern <[EMAIL PROTECTED]>"
gpg: aka "Neil McGovern (SPI) <[EMAIL PROTECTED]>"


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: broken .orig.tar.gz (Re: package upload rejected - no email)

[Cyril Brulebois]

On 16/03/2008, Bernhard R. Link wrote:
> But is there a way to know who the sponsor of rhinote_0.7.0-1 was?

Besides the “lynx -dump”-based solutions mentioned in this thread,
there's far easier:
| $ who-uploads rhinote # from devscripts
| Uploads for rhinote:
| 0.7.0-2 to unstable: Kevin Coyner <[EMAIL PROTECTED]>
| 0.7.0-1 to unstable: Neil McGovern <[EMAIL PROTECTED]>

You'll sometimes need to use --max-uploads=N (N defaults to 3).

Cheers,

-- 
Cyril Brulebois


pgpcMT3b3A0Wh.pgp
Description: PGP signature

Re: broken .orig.tar.gz (Re: package upload rejected - no email)

[Kevin Coyner]

On Sun, Mar 16, 2008 at 01:52:32PM +0100, Kurt Roeckx wrote..

> > > But is there a way to know who the sponsor of rhinote_0.7.0-1 was?
> > 
> > [EMAIL PROTECTED]:~$ lynx -dump 
> > http://packages.qa.debian.org/r/rhinote/news/20080316T114705Z.html | gpg 
> > --verify
> > gpg: Signature made Sun 16 Mar 2008 12:40:47 CET using DSA key ID 8CE11941
> > gpg: Good signature from "Kevin Coyner (Greenwich and Tokyo) <[EMAIL 
> > PROTECTED]>"
> > gpg: aka "Kevin Coyner <[EMAIL PROTECTED]>"
> > gpg: aka "Kevin Coyner <[EMAIL PROTECTED]>"
> > gpg: aka "Kevin Coyner (Greenwich, CT Station 2) <[EMAIL 
> > PROTECTED]>"
> 
> I think you want the one that uploaded the .orig.tar.gz, so:
> lynx -dump http://packages.qa.debian.org/r/rhinote/news/20060625T184700Z.html 
> | gpg --verify
> gpg: Signature made Sun 11 Jun 2006 03:11:54 PM CEST using DSA key ID B345BDD3
> gpg: Good signature from "Neil McGovern <[EMAIL PROTECTED]>"
> gpg: aka "Neil McGovern <[EMAIL PROTECTED]>"
> gpg: aka "Neil McGovern (SPI) <[EMAIL PROTECTED]>"

I'm going to contact upstream and ask if they would consider
releasing a new version so that this can get cleaned up.

Kevin

-- 
Kevin Coyner  GnuPG key: 1024D/8CE11941


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: broken .orig.tar.gz (Re: package upload rejected - no email)

[The Fungi]

On Sun, Mar 16, 2008 at 09:07:48AM -0400, Kevin Coyner wrote:
> I'm going to contact upstream and ask if they would consider
> releasing a new version so that this can get cleaned up.

Wouldn't prepending an epoch be less drastic? Doesn't sound like the
mistake was upstream's...
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: broken .orig.tar.gz (Re: package upload rejected - no email)

[Ansgar Burchardt]

The Fungi wrote:
> On Sun, Mar 16, 2008 at 09:07:48AM -0400, Kevin Coyner wrote:
> > I'm going to contact upstream and ask if they would consider
> > releasing a new version so that this can get cleaned up.
> 
> Wouldn't prepending an epoch be less drastic? Doesn't sound like the
> mistake was upstream's...

Isn't it enough to append something to the version number, similar to the
.ds or .dfsg if the package is intentionally repacked?  I would try avoid
prepending an epoch if possible.

Or just leave the repacked .orig for this version.  If there are no
modifications this should hurt nobody (tough I'm no DD).

Regards,
Ansgar

-- 
pgp: 0xF1F477C02BE4 CE2A E9CB 27D3 29F4  502E 53B1 6D9C F1F4 77C0



signature.asc
Description: Digital signature

Re: broken .orig.tar.gz (Re: package upload rejected - no email)

[Roberto C . Sánchez]

On Sun, Mar 16, 2008 at 02:13:32PM +, The Fungi wrote:
> On Sun, Mar 16, 2008 at 09:07:48AM -0400, Kevin Coyner wrote:
> > I'm going to contact upstream and ask if they would consider
> > releasing a new version so that this can get cleaned up.
> 
> Wouldn't prepending an epoch be less drastic? Doesn't sound like the
> mistake was upstream's...

In the Debian Perl Group, the practice has been to append +pristine to
the upstream version number.

Regards,

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


signature.asc
Description: Digital signature

Re: Version numbering for security uploads of native packages

[Russ Allbery]

"Adam D. Barratt" <[EMAIL PROTECTED]> writes:
> On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:

>> [Adding bug #437392 to Cc, which deals with this issue for normal
>> NMUs, because I'm making a suggestion about them.]
>> 
>> On Sat, Mar 15, 2008 at 11:52:55PM +, Adam D. Barratt wrote:
>> > devscripts 2.10.19 (soon to be uploaded) will modify the behaviour of
>> > "debchange --nmu" to version an NMU of a native package as X+nmu1
>> > rather than the current X-0.1.
>> 
>> Good idea.  Even better, IMO, would be to use a system which is in
>> line with non-native packages.  How about this rule:
> [using X.1]
>> IMO this solution is slightly better than +nmu1, because it makes
>> versions of native and non-native packages more uniformly mangled.
>> However, any solution is better than no solution. :-)
>
> That does seem the most logical suggestion thus far.

I dislike this approach because it makes it impossible for tools like
Lintian to recognize NMUs of native packages and perform other
NMU-specific checks (such as making sure an appropriate changelog entry is
present).  There's no way of knowing whether a native package with a
version number of 1.2.1 is an NMU or not.

I like the +nmuN approach.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version numbering for security uploads of native packages

[Adam D. Barratt]

On Sun, 2008-03-16 at 11:22 -0700, Russ Allbery wrote:
> "Adam D. Barratt" <[EMAIL PROTECTED]> writes:
> > On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:
[...]
> >> Good idea.  Even better, IMO, would be to use a system which is in
> >> line with non-native packages.  How about this rule:
> > [using X.1]
> >> IMO this solution is slightly better than +nmu1, because it makes
> >> versions of native and non-native packages more uniformly mangled.
> >> However, any solution is better than no solution. :-)
> >
> > That does seem the most logical suggestion thus far.
> 
> I dislike this approach because it makes it impossible for tools like
> Lintian to recognize NMUs of native packages and perform other
> NMU-specific checks (such as making sure an appropriate changelog entry is
> present).  There's no way of knowing whether a native package with a
> version number of 1.2.1 is an NMU or not.

Indeed. Luk already pointed out on irc that this is the (or at least a)
reason .1 wasn't suggested by DevRef.

> I like the +nmuN approach.

devscripts 2.10.19 including +nmuN was uploaded earlier this evening.

Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: broken .orig.tar.gz (Re: package upload rejected - no email)

[Steve Langasek]

On Sun, Mar 16, 2008 at 02:13:32PM +, The Fungi wrote:
> On Sun, Mar 16, 2008 at 09:07:48AM -0400, Kevin Coyner wrote:
> > I'm going to contact upstream and ask if they would consider
> > releasing a new version so that this can get cleaned up.

> Wouldn't prepending an epoch be less drastic? Doesn't sound like the
> mistake was upstream's...

Epochs are the one thing that *don't* help.  The filenames with and without
an epoch are the same, and it's precisely to avoid ambiguities about file
contents that you're not allowed to upload a different file under the same
name.

-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Raphael Hertzog]

On Sun, 03 Feb 2008, Raphael Hertzog wrote:
> On Sat, 02 Feb 2008, Charles Plessy wrote:
> > Is there sombody working on Wig&Pen? Is the format consensual enough
> > that it would be accepted in Debian?
> 
> I plan to work on it (but have not done anything yet except thinking about
> it and following discussions), the format might need some tweaks (explicit
> list of patches instead of implicit for example) but the basic principles
> are sane and I believe it will be accepted in Debian.

The wig&pen format has been implemented and much more:
http://www.ouaza.com/wp/2008/03/16/new-source-package-formats-call-for-tests/

http://lists.debian.org/debian-dpkg/2008/03/msg00155.html
http://lists.debian.org/debian-dpkg/2008/03/msg00166.html

Testers are needed so that we can merge that in time for lenny.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: broken .orig.tar.gz (Re: package upload rejected - no email)

[Steve Langasek]

On Sun, Mar 16, 2008 at 12:19:45PM +0100, Bernhard R. Link wrote:
> * Steve Langasek <[EMAIL PROTECTED]> [080315 21:12]:
> > $ cat /srv/ftp.debian.org/queue/reject/rhinote_0.7.0-2_i386.reason 
> > Rejected: md5sum and/or size mismatch on existing copy of 
> > rhinote_0.7.0.orig.tar.gz.
> > Rejected: can not overwrite existing copy of 'rhinote_0.7.0.orig.tar.gz' 
> > already in the archive.

> Looking at the file currently in unstable:
> |$ tar -tvvzf ../rhinote_0.7.0.orig.tar.gz | head -n1
> |drwxr-xr-x kiyuko/kiyuko 0 2006-03-24 02:15 rhinote-0.7.0.orig/

> So the original file looks repackaged without any reason (and not
> comment about this in the the rhinote_0.7.0-1.diff.gz).

> How could this happen? This is a classic error and three people seem
> to not have noticed it. The maintainer is no DD, so I won't blame him.
> But is there a way to know who the sponsor of rhinote_0.7.0-1 was?
> And as rhinote_0.7.0-1 says original upload, I assume some ftp-master
> or ftp-assistent looked at it and missed that, too. Is there a way to
> find out who is letting this crap in our archive?

There is no requirement that we ship pristine tarballs as downloaded from
upstream.

> (What if the .orig.tar.gz was not only repacked but actually modified,
> would everyone have notices?)

Why should that block it from inclusion in the archive?  Do you suppose
there's something magical about all upstream tarballs that makes them
non-crap and instantly trustworthy by the ftp team?

Using the pristine tarballs makes it easier to blame certain problems on
upstream, but that's all.

-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#471235: ITP: python-pysnmp4-apps -- Applications for the Python SNMP library

[Jan Lübbe]

Package: wnpp
Severity: wishlist
Owner: "Jan Lübbe" <[EMAIL PROTECTED]>


* Package name: python-pysnmp4-apps
  Version : 0.2.6a
  Upstream Author : Ilya Etingof
* URL : http://pysnmp.sourceforge.net/
* License : BSD-style
  Programming Lang: Python
  Description : Applications for the Python SNMP library

This package contains a set of SNMP applications written on top of
the PYSNMP v4 package, which is written entirely in Python and is
self-sufficient in terms that it does not rely on any third party
tool.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (300, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-x60s (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Status of dependency based boot sequencing release goal 2008-03

[Florian Weimer]

* Petter Reinholdtsen:

> Here is a small update on the release goal of converting the Debian boot
> sequening to use dynamic and dependency based ordering instead of hardcoded
> sequence numbers.
>
> The latest status information is available from
> http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot >.
>
> As of 2008-03-07, all packages with missing dependency information in
> one of their init.d scripts have been reported to BTS. More than 80%
> of the packages with init.d scripts already provide this dependency
> information, and the amount is increasing rapidly.

This reminds me of an old problem: Does the network dependency result in
initialization of the IPv6 stack?

(IPv6 networking is NOT started at boot on etch, but the module is
loaded automatically, which gets the worst of both worlds: IPv6-induced
delays and no full IPv6 support out of the box.  I wish we could avoid
thos problem for lenny.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt-get and SOCKS

[Patrick Matthäi]

xHemi schrieb:
> This might not be the correct place but here goes..
> 
> apt-get provides http_proxy and ftp_proxy support but why not SOCKS?
> I have no experience with SOCKS other than that I use it daily in conjunction
> with firefox and ssh. I think it is a feature which could be of use
> to others as well since it would enable you to use apt over ssh.
> 
> Regards
> 
> 
> !DSPAM:47c6934330731369617410!
> 
> 
> 

Hello,

is there any reason to encrypt your traffic on downloading packages?
I think this will only cause more traffic and cpu overhead on the
mirrors instead of help anything.

-- 
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi

E-Mail: [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

I am confused about configuration files

[Artur R. Czechowski]

Hello developers,
Trying to run insserv and dependency based boot sequence on my workstation
I run into a phenomenon I cannot understand.

Let's see an example: xserver-xorg package.

I have latest version from unstable:
ii  xserver-xorg   1:7.3+10   the X.Org X server

Let's see the content of the package:
[EMAIL PROTECTED]:~$ dpkg -L xserver-xorg
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/xserver-xorg
/usr/share/doc/xserver-xorg/copyright
/usr/share/doc/xserver-xorg/changelog.gz
/usr/share/doc/xserver-xorg/NEWS.Debian.gz
/usr/share/bug
/usr/share/bug/xserver-xorg
/usr/share/bug/xserver-xorg/script
/etc/init.d/xserver-xorg

Do you see the last line?
Content of /var/lib/dpkg/info/xserver-xorg.list is exactly the same.

File /etc/init.d/xserver-xorg of course exists on my filesystem:
[EMAIL PROTECTED]:~$ ls -l /etc/init.d/xserver-xorg 
-rwxr-xr-x 1 root root 805 Jun  3  2007 /etc/init.d/xserver-xorg

After I've been told and assured that /etc/init.d/xserver-xorg
has been removed from the package I downloaded the deb file and checked the
content with dpkg-deb -c. The man who told me that is damn right: file does
not exist in the package.

So, why it still exists? I read Debian Policy, section 10.7.3[1] but it does
not say what shall happen if after upgrade of the package it does not provide 
conffile anymore.

Is the only way to make sure that conffiles do not clutter filesystem to
remove them in maintainer's script on upgrade from previous version?

Regards
Artur

[1] http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3
-- 
http://www.last.fm/user/arturcz/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

IPv6 stack initialization during boot (Was: Status of dependency based boot sequencing release goal 2008-03)

[Petter Reinholdtsen]

[Florian Weimer]
> This reminds me of an old problem: Does the network dependency
> result in initialization of the IPv6 stack?

That is up to the network enabling script to decide.  :)

At the moment, the $network virtual facility is defined to mean the
scripts networking and ifupdown.  If these script are initializing the
IPv6 stack, $network represent a working IPv6 stack.

> (IPv6 networking is NOT started at boot on etch, but the module is
> loaded automatically, which gets the worst of both worlds:
> IPv6-induced delays and no full IPv6 support out of the box.  I wish
> we could avoid thos problem for lenny.)

I hope so to.  But it is as far as I can see, not related to the
dependency based boot sequencing release goal.  This goal is about the
order of the scripts, it does not specify their behaviour.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt-get and SOCKS

[Petter Reinholdtsen]

[Patrick Matthäi]
> is there any reason to encrypt your traffic on downloading packages?
> I think this will only cause more traffic and cpu overhead on the
> mirrors instead of help anything.

I took is request to ask for SOCKS support, not encrypted connections.
I know that I've used the SOCKS feature of OpenSSH some times to get
out of a network with limited accessibility, and being able to use
apt-get (or aptitude) with such network tunnel would be useful in such
setting.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: I am confused about configuration files

[Michael Biebl]

Artur R. Czechowski wrote:

> 
> Is the only way to make sure that conffiles do not clutter filesystem to
> remove them in maintainer's script on upgrade from previous version?

That's correct. The only way currently to remove obsolete conffiles is
to do it manually in the maintainer scripts [1]

If xserver-xorg doesn't correctly remove the obsolete conffile, you
should file a bug against it (unless there isn't already one).

Cheers,
Michael

[1] http://wiki.debian.org/DpkgConffileHandling
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: I am confused about configuration files

[Russ Allbery]

"Artur R. Czechowski" <[EMAIL PROTECTED]> writes:

> So, why it still exists? I read Debian Policy, section 10.7.3[1] but it
> does not say what shall happen if after upgrade of the package it does
> not provide conffile anymore.
>
> Is the only way to make sure that conffiles do not clutter filesystem to
> remove them in maintainer's script on upgrade from previous version?

I believe that's the case, although I'd like to get some confirmation
before adding something to Policy 10.7.3 about this.  See Bug#470633.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: I am confused about configuration files

[Petter Reinholdtsen]

[Russ Allbery]
>> Is the only way to make sure that conffiles do not clutter filesystem to
>> remove them in maintainer's script on upgrade from previous version?
>
> I believe that's the case, although I'd like to get some confirmation
> before adding something to Policy 10.7.3 about this.  See Bug#470633.

It is the case.  See http://wiki.debian.org/DpkgConffileHandling>
for information on this.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg with triggers support (again)

[Ben Hutchings]

On Sat, 2008-03-15 at 16:05 +0100, Vincent Bernat wrote:
> OoO Pendant le journal télévisé du  jeudi 13 mars 2008, vers 20:00, Russ
> Allbery <[EMAIL PROTECTED]> disait:
> 
> > (I *have* heard of architectures in common use where a pointer to data
> > is  a  different size  than  a pointer  to  a  function, but  function
> > pointers are very rarely passed to variadic functions.)
> 
> Which architectures are like this?

http://en.wikipedia.org/wiki/Harvard_architecture lists a number.

However, any POSIX system requires function pointers to be no larger
than data pointers so that the dlsym() function can work.

Itanium natively requires functions to be identified by a 64-bit
instruction pointer plus a 64-bit global data pointer.  The ABI defines
function pointers to point to these 128-bit data structures.

Ben.

-- 
Ben Hutchings
Life is like a sewer:
what you get out of it depends on what you put into it.


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

Re: broken .orig.tar.gz (Re: package upload rejected - no email)

[Steve Langasek]

On Sun, Mar 16, 2008 at 09:07:48AM -0400, Kevin Coyner wrote:
> > I think you want the one that uploaded the .orig.tar.gz, so:
> > lynx -dump 
> > http://packages.qa.debian.org/r/rhinote/news/20060625T184700Z.html | gpg 
> > --verify
> > gpg: Signature made Sun 11 Jun 2006 03:11:54 PM CEST using DSA key ID 
> > B345BDD3
> > gpg: Good signature from "Neil McGovern <[EMAIL PROTECTED]>"
> > gpg: aka "Neil McGovern <[EMAIL PROTECTED]>"
> > gpg: aka "Neil McGovern (SPI) <[EMAIL PROTECTED]>"

> I'm going to contact upstream and ask if they would consider
> releasing a new version so that this can get cleaned up.

Why does it need to be cleaned up?  Other than the fact that the checksums
don't match, what's wrong with the tarball in the archive?

I would be embarrassed to have upstreams releasing new upstream versions
over what should solely be an internal Debian issue.  If the current tarball
really is unacceptable, all it takes to fix up in Debian is to create a
Debian-local upstream version number - like the suggested '0.7.0+pristine.

-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version numbering for security uploads of native packages

[Joey Hess]

Bas Wijnen wrote:
> This does break versions which go from 1 to 1.1 to 1.2 to 2 to 2.1, etc,
> but we're talking about native packages, which means we can expect
> upstream not to be so crazy. 

People do this all the time, for completly sane reasons.

-- 
see shy jo


signature.asc
Description: Digital signature

What CDs and DVDs should we produce for lenny?

[Steve McIntyre]

[ Please note Reply-To: to debian-cd... ]

Hi folks,

It's time for me to ask the question again - what CDs and DVDs will we
find useful enough that we should make them for lenny? The reason I'm
asking is that we're looking at a *huge* number of discs, and it's not
clear that they'll all be useful. I've just finished building the full
set for lenny d-i beta 1 (hence why I've been so quiet the last few
days), and what we're looking at *now* is quite scary:

 2 small CDs per arch (business card, netinst)
 ~30 CDs per arch for a full CD set
 ~4 DVDs per arch for a full DVD set
 (total 353 CDs, 51 DVDs, 426 GB)

Things are only going to get bigger: we're about to add armel to the
mix, and I'm expecting that we're going to grow further yet in terms
of the number and sizes of packages before we release lenny. That
leaves us with a huge amount of data for us to build and host, and for
our mirrors to handle too. So...

 1. Is it worth making full sets of CDs at all? Can we rely on people
having a net connection or being able to use DVDs if they want
*everything*?

 2. Is it worth producing all the CDs/DVDs/whatever for all the
architectures?

 3. For some arches, should we just provide the first couple of CDs
and a full set of DVDs? This is a bit of a compromise option - if
a given machine will not boot from DVD, but can boot from CD and
get the rest of its packages from a network share then all's good.

 4. ??? - what else would be a sane option?

Suggestions/comments/complaints - please let us know what you'd
prefer.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
There's no sensation to compare with this
Suspended animation, A state of bliss


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What CDs and DVDs should we produce for lenny?

[Paul Cager]

Steve McIntyre wrote:

[ Please note Reply-To: to debian-cd... ]

Hi folks,

It's time for me to ask the question again - what CDs and DVDs will we
find useful enough that we should make them for lenny?

[...]

 1. Is it worth making full sets of CDs at all? Can we rely on people
having a net connection or being able to use DVDs if they want
*everything*?

 2. Is it worth producing all the CDs/DVDs/whatever for all the
architectures?

 3. For some arches, should we just provide the first couple of CDs
and a full set of DVDs? This is a bit of a compromise option - if
a given machine will not boot from DVD, but can boot from CD and
get the rest of its packages from a network share then all's good.

 4. ??? - what else would be a sane option?


(I'd better disclose a conflict of interest - I sell Debian CDs and DVDs).

I'd quite like there to be full sets for i386 and amd64. I think an 
inexperienced user could find it quite discouraging to have to install 
using a mapped drive.


What about a modification of 3?  For the less popular arches we provide 
the first couple of CD images, but the other CDs are only available as 
jigdo downloads. Does that make sense? You'd still have to create every 
CD image, of course, but the mirrors would have to carry much less data 
/ traffic.


Thanks,
Paul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: table view wnpp page now on wnpp.debian.net

[Sebastian Pipping]

Tim Cutts wrote:

Hm, can you help with creating a good set of colors?


There are a number of programs around which can help with this.  I use 
Color Oracle:  http://colororacle.cartography.ch/


It sits in a Gnome panel, and will temporarily change your entire 
display's colours  to simulate three different kinds of colour blindness.


While I do like the concept of this application, it seems
to be closed source and (probably?) does not take choosing
colors off my shoulders.

I'd be happy to put in new colors if somebody could help me
with this. It feels wrong to me to try myself again as
selecting the current color set was hard already.
I hope you don't mind my position.



Sebastian


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What CDs and DVDs should we produce for lenny?

[Anthony Towns]

On Sun, Mar 16, 2008 at 11:59:52PM +, Steve McIntyre wrote:
>  2 small CDs per arch (business card, netinst)
>  ~30 CDs per arch for a full CD set
>  ~4 DVDs per arch for a full DVD set
>  (total 353 CDs, 51 DVDs, 426 GB)

Bluray image? Apparently there's been a winner in the format wars,
and we could probably fit an entire arch on a single disc...

Should we be counting a live CD/DVD/BD image in there too?

Is it possible to do a javascript implementation of jigdo, so we could
reasonably just publish a list of the files that need to go on most of
the CDs instead of the entire iso images? If you can download an image
via jigdo just by clicking in your browser, that'd seem like we could
rely on jigdo much more heavily than we have.

How many different boot images do we have these days? We used to have
a different boot image on each of the first N CDs, do we still do that?

Is there really a lot of value in the netinst image, versus the business
card? You're going to be downloading stuff anyway, so the only difference
I can see is if your system can download once you've got base installed,
but can't from the installer. Would it be simpler just to expect that
class of people to grab a full CD/DVD image (and thus have more than just
base available once they've rebooted and are trying to get net working)?

At a bare minimum:

- installer - downloadable (business card)
- installer+base - jigdo-only? (netinst)
- CD - disk 1 downloadable, disk 2+ jigdo-only
- DVD - disk 1 downloadable, disk 2+ jigdo-only
- BD - one image jigdo-only

That's 25MB + 650MB + 4GB of images per-arch, for about 61GB in total,
plus a whole bunch of jigdo images (about 500?).

Is it possible to create a jigdo image without creating the full
ISO? ie, to go from a list of files you want on the ISO straight to a
jigdo template without the intervening step of actually copying all the
files around?

If so, then the cost of having all sorts of images available becomes
pretty small: generate a jigdo, let people who want it download the
image using a javascript capable web browser.

Cheers,
aj



signature.asc
Description: Digital signature

Proposing a new source control header to link to upstream BTSs

[Martín Ferrari]

Dear -devel:

Following the trend to add metadata to the debian/control file that
allows for the creation of new and powerful tools, I thought about the
usefulness of a header that'd allow to automatically relate to
upstream bug trackers.

It could be used to automatically forward bugs, track which bugs are
open that we don't know about today, and simply to avoid the need to
look up manually where should one submit a bug.

So, my proposal would be to add two headers that are better explained
by an example:

Upstream-Bug-Browser: http://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Curl
Upstream-Bug-Submitter: http://rt.cpan.org/Public/Bug/Report.html?Queue=WWW-Curl

This could easily support systems where submission is by email. And if
there's no bug tracking system, the upstream maintainer email could be
used, without adding the -Browser header.

What do you think of this?

-- 
Martín Ferrari

Re: Proposing a new source control header to link to upstream BTSs

[Russ Allbery]

"Martín Ferrari" <[EMAIL PROTECTED]> writes:

> Following the trend to add metadata to the debian/control file that
> allows for the creation of new and powerful tools, I thought about the
> usefulness of a header that'd allow to automatically relate to upstream
> bug trackers.
>
> It could be used to automatically forward bugs, track which bugs are
> open that we don't know about today, and simply to avoid the need to
> look up manually where should one submit a bug.
>
> So, my proposal would be to add two headers that are better explained
> by an example:
>
> Upstream-Bug-Browser: 
> http://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Curl
> Upstream-Bug-Submitter: 
> http://rt.cpan.org/Public/Bug/Report.html?Queue=WWW-Curl
>
> This could easily support systems where submission is by email. And if
> there's no bug tracking system, the upstream maintainer email could be
> used, without adding the -Browser header.
>
> What do you think of this?

I think that if the goal is to support automated tools, pointing to
straight web pages isn't particularly useful without some additional
information.  At the least, I'd think we'd want to specify the type of bug
system that upstream is using so that any automated tools would know what
screen scraping or (hopefully) SOAP/REST interfaces they can use.

Straight URLs pointing to the HTML version of upstream's bug system are
probably mostly useful for people, and Homepage should hopefully already
give people a reasonable starting point.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: Proposing a new source control header to link to upstream BTSs

[Paul Wise]

On Mon, Mar 17, 2008 at 2:38 PM, Martín Ferrari
<[EMAIL PROTECTED]> wrote:

>  Following the trend to add metadata to the debian/control file that
>  allows for the creation of new and powerful tools, I thought about the
>  usefulness of a header that'd allow to automatically relate to
>  upstream bug trackers.

That sort of information (like watch files and homepages) changes
independently of the source package, so it would be better if it were
not added to debian/control.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise

Re: Proposing a new source control header to link to upstream BTSs

[William Pitcock]

On Mon, 2008-03-17 at 02:38 -0300, Martín Ferrari wrote:
> Dear -devel:
> 
> Following the trend to add metadata to the debian/control file that
> allows for the creation of new and powerful tools, I thought about the
> usefulness of a header that'd allow to automatically relate to
> upstream bug trackers.
> 
> It could be used to automatically forward bugs, track which bugs are
> open that we don't know about today, and simply to avoid the need to
> look up manually where should one submit a bug.
> 
> So, my proposal would be to add two headers that are better explained
> by an example:
> 
> Upstream-Bug-Browser: 
> http://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Curl
> Upstream-Bug-Submitter: 
> http://rt.cpan.org/Public/Bug/Report.html?Queue=WWW-Curl
> 
> This could easily support systems where submission is by email. And if
> there's no bug tracking system, the upstream maintainer email could be
> used, without adding the -Browser header.
> 
> What do you think of this?
> 

I don't see what purpose this has that Homepage: does not, because it is
not likely that there will ever be an automated reporting tool. It is
just more metadata, and as such, is generally wasteful since it doesn't
usually provide anything that Homepage: does not.

William


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