|
Home > Archive > Debian Developers > May 2007 > Mysterious NMU (Bug #423455)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Mysterious NMU (Bug #423455)
|
|
| Stefan Hornburg 2007-05-12, 7:20 am |
| Hello,
I just got a bug on pure-ftpd (#423455). Someone else uploaded a broken NMU, now pure-ftpd is
unstallable. My problem now is who did the upload and with what purpose, because it is not
listed in package tracking system, and apt-get source only downloads 1.0.21-8.
Any idea what happened ?
Regards
Racke
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adeodato Simó 2007-05-12, 7:20 am |
| * Stefan Hornburg [Sat, 12 May 2007 13:59:19 +0200]:
> Hello,
Hi Stefan,
> I just got a bug on pure-ftpd (#423455). Someone else uploaded a broken NMU,
> now pure-ftpd is unstallable. My problem now is who did the upload and with
> what purpose, because it is not listed in package tracking system, and
> apt-get source only downloads 1.0.21-8.
> Any idea what happened ?
Yes, please have a look at http://wiki.debian.org/binNMU. Also, when you
upload a new version to fix this uninstallability, it's a good opportunity
to make your package binNMUable so that this does not happen again.
(There are tips on the linked page about how to do it, and lintian will
warn you if it's still not binNMUable.)
Thanks,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
When all is summed up, a man never speaks of himself without loss; his
accusations of himself are always believed; his praises never.
-- Michel de Montaigne
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Neil Williams 2007-05-12, 1:17 pm |
| On Sat, 12 May 2007 13:59:19 +0200
Stefan Hornburg <deblists@linuxia.de> wrote:
> Hello,
>
> I just got a bug on pure-ftpd (#423455). Someone else uploaded a broken NMU, now pure-ftpd is
> unstallable. My problem now is who did the upload and with what purpose, because it is not
> listed in package tracking system, and apt-get source only downloads 1.0.21-8.
>
> Any idea what happened ?
pure-ftpd is not binary NMU safe:
Depends: pure-ftpd-common (=${Source-Version}), ${shlibs:Depends}
Should be :
Depends: pure-ftpd-common (= ${binary:Version}), ${shlibs:Depends}
i.e. the original fault is in pure-ftpd, it just took a binary NMU to reveal it.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
| |
| Adeodato Simó 2007-05-12, 1:17 pm |
| * Neil Williams [Sat, 12 May 2007 13:14:13 +0100]:
> Depends: pure-ftpd-common (=${Source-Version}), ${shlibs:Depends}
> Should be :
> Depends: pure-ftpd-common (= ${binary:Version}), ${shlibs:Depends}
^^^^^^
Should be ${source:Version}. pure-ftpd-common is arch:all.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
You cannot achieve the impossible without attempting the absurd.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stefan Hornburg 2007-05-12, 1:17 pm |
| Adeodato Simó wrote:
> * Neil Williams [Sat, 12 May 2007 13:14:13 +0100]:
>
>
> ^^^^^^
> Should be ${source:Version}. pure-ftpd-common is arch:all.
>
I changed that and uploaded new packages. Thanks for you quick help!
Regards
Racke
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Francesco P. Lovergine 2007-05-14, 7:25 am |
| On Sat, May 12, 2007 at 04:59:21PM +0200, Stefan Hornburg wrote:
> Adeodato Simó wrote:
>
> I changed that and uploaded new packages. Thanks for you quick help!
>
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422717
As you can see, it does not help: proftpd-ldap is (was starting from
next upload, thanks God) an all-type fake package with a ${source:Version}
dependency in place. That strict dep was probably supefluous in the upgrading
path for etch, but that's another aspect...
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Raphael Hertzog 2007-05-14, 7:25 am |
| On Mon, 14 May 2007, Francesco P. Lovergine wrote:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422717
>
> As you can see, it does not help: proftpd-ldap is (was starting from
> next upload, thanks God) an all-type fake package with a ${source:Version}
> dependency in place. That strict dep was probably supefluous in the upgrading
> path for etch, but that's another aspect...
Your case is different. Arch: all can't depend on arch: any with a
equal-versioned dependency since they are not regenerated during a bin-NMU.
However the example above was the contrary, an arch: any package depending
on an arch: all. And Dato was right.
Your case is probably better handled with a simple higher-or-equal dependency.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roberto C. Sánchez 2007-05-14, 7:25 am |
| On Mon, May 14, 2007 at 09:24:35AM +0200, Raphael Hertzog wrote:
> On Mon, 14 May 2007, Francesco P. Lovergine wrote:
>
> Your case is different. Arch: all can't depend on arch: any with a
> equal-versioned dependency since they are not regenerated during a bin-NMU.
> However the example above was the contrary, an arch: any package depending
> on an arch: all. And Dato was right.
>
> Your case is probably better handled with a simple higher-or-equal dependency.
>
Maybe I misunderstand, but wouldn't something like (>= 1.0.1-1) and (<<
1.0.1-2) be more correct? That way the package is still binNMU safe and
also safe from breaking if incompatibilities are introduced in the next
source upload?
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
| |
| Raphael Hertzog 2007-05-14, 7:25 am |
| On Mon, 14 May 2007, Roberto C. Sánchez wrote:
>
> Maybe I misunderstand, but wouldn't something like (>= 1.0.1-1) and (<<
> 1.0.1-2) be more correct? That way the package is still binNMU safe and
> also safe from breaking if incompatibilities are introduced in the next
> source upload?
Yes but this is a bit tricky to auto-generate and in many cases the
stricter dependency doesn't bring much (ie packages get upgraded at the
same time since they are generated from the same source and made available
together).
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roberto C. Sánchez 2007-05-14, 1:21 pm |
| On Mon, May 14, 2007 at 01:56:30PM +0200, Raphael Hertzog wrote:
> On Mon, 14 May 2007, Roberto C. Sánchez wrote:
>
> Yes but this is a bit tricky to auto-generate and in many cases the
> stricter dependency doesn't bring much (ie packages get upgraded at the
> same time since they are generated from the same source and made available
> together).
>
Yes, but that assumes that the user does a dist-upgrade or an upgrade of
all packages together. IMHO, that is not a safe assumption.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
| |
| Goswin von Brederlow 2007-05-15, 1:21 pm |
| Roberto C. Sánchez <roberto@connexer.com> writes:
> On Mon, May 14, 2007 at 09:24:35AM +0200, Raphael Hertzog wrote:
> Maybe I misunderstand, but wouldn't something like (>= 1.0.1-1) and (<<
> 1.0.1-2) be more correct? That way the package is still binNMU safe and
> also safe from breaking if incompatibilities are introduced in the next
> source upload?
>
> Regards,
>
> -Roberto
(>= version) and (<< next-version).
The problem is knowing next-version. 1.0.1-2 is not the next
version. For example a NMU of 1.0.1-1.1 is less. Also 1.0.1-1lenny1
(security update for lenny) is less than 1.0.1-2. There could also be
an 1.0.1-2~rc1, again less than 1.0.1-2.
And now for something really ugly:
% dpkg --compare-versions "1.0.1-1lenny1" "<<" "1.0.1-1+b1" && echo yes
yes
So a security upload of the package has a smaller version than a
binNMU upload. At that point you are pretty much screwed.
One way around the problem is
Package: foo-any
Provides: foo-any-source-version
Package: foo-all
Depends: foo-any-source-version
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Mike Hommey 2007-05-15, 1:21 pm |
| On Tue, May 15, 2007 at 03:49:07PM +0200, Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
> Roberto C. Sánchez <roberto@connexer.com> writes:
>
>
> (>= version) and (<< next-version).
>
> The problem is knowing next-version. 1.0.1-2 is not the next
> version. For example a NMU of 1.0.1-1.1 is less. Also 1.0.1-1lenny1
> (security update for lenny) is less than 1.0.1-2. There could also be
> an 1.0.1-2~rc1, again less than 1.0.1-2.
A rule that works pretty good:
>= ${source:Version} and <= ${source:Version}.1~
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roberto C. Sánchez 2007-05-15, 1:21 pm |
| On Tue, May 15, 2007 at 03:49:07PM +0200, Goswin von Brederlow wrote:
> Roberto C. Sánchez <roberto@connexer.com> writes:
>
>
> (>= version) and (<< next-version).
>
> The problem is knowing next-version. 1.0.1-2 is not the next
> version. For example a NMU of 1.0.1-1.1 is less. Also 1.0.1-1lenny1
> (security update for lenny) is less than 1.0.1-2. There could also be
> an 1.0.1-2~rc1, again less than 1.0.1-2.
>
Yes, but in reality what is the likelihood that either a security update
or NMU would introduce an incompatible change? I would say that such a
possibility is extremely low.
> And now for something really ugly:
>
> % dpkg --compare-versions "1.0.1-1lenny1" "<<" "1.0.1-1+b1" && echo yes
> yes
>
> So a security upload of the package has a smaller version than a
> binNMU upload. At that point you are pretty much screwed.
>
Perhaps the policy should change so that security uploads are done with
x.y.z-(w++)~lenny1? That is, the Debian version number gets
incremented.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
| |
| Lennart Sorensen 2007-05-15, 1:21 pm |
| On Tue, May 15, 2007 at 12:20:22PM -0400, Roberto C. S?nchez wrote:
> Yes, but in reality what is the likelihood that either a security update
> or NMU would introduce an incompatible change? I would say that such a
> possibility is extremely low.
Why couldn't a security change require making incompatible changes to
something? A bin NMU would hopefully never change any such thing
though.
> Perhaps the policy should change so that security uploads are done with
> x.y.z-(w++)~lenny1? That is, the Debian version number gets
> incremented.
But isn't the idea that the version in test/unstable should _always_ be
higher than the version in stable including security versions? That
makes incrementing 'w' not an option.
--
Len Sorensen
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roberto C. Sánchez 2007-05-15, 7:17 pm |
| On Tue, May 15, 2007 at 01:14:01PM -0400, Lennart Sorensen wrote:
> On Tue, May 15, 2007 at 12:20:22PM -0400, Roberto C. S?nchez wrote:
>
> Why couldn't a security change require making incompatible changes to
> something? A bin NMU would hopefully never change any such thing
> though.
>
I am not saying that such a thing couldn't happen, simply that a
security update is much less likely to cause it.
>
> But isn't the idea that the version in test/unstable should _always_ be
> higher than the version in stable including security versions? That
> makes incrementing 'w' not an option.
>
Well, the ~ character is stated to be evaluated to be less than the
empty string. If a package is the target of a security upload in
stable, you can be certain that the testing/unstable version will also
increase when the new package is introduced to fix the problem there as
well.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
| |
| Felipe Sateler 2007-05-16, 1:18 am |
| Roberto C. Sánchez wrote:
> Well, the ~ character is stated to be evaluated to be less than the
> empty string. If a package is the target of a security upload in
> stable, you can be certain that the testing/unstable version will also
> increase when the new package is introduced to fix the problem there as
> well.
What if it's a NMU?
--
Felipe Sateler
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roberto C. Sánchez 2007-05-16, 7:17 am |
| On Tue, May 15, 2007 at 10:05:56PM -0400, Felipe Sateler wrote:
> Roberto C. Sánchez wrote:
>
>
> What if it's a NMU?
>
Well, an NMU would go into unstable directly and not into stable.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
| |
| Roberto C. Sánchez 2007-05-17, 1:19 am |
| On Wed, May 16, 2007 at 10:54:09PM -0400, Felipe Sateler wrote:
> Roberto C. Sánchez wrote:
>
>
> Yes, but the version in stable (x.y.z-(w+1)~lenny1) would be higher than the
> one in unstable (x.y.z-w.n)
>
OK. I misread your question. I was not thinking of the security issue
being fixed in unstable by a NMU. Good point.
I'm stumped.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
| |
| Felipe Sateler 2007-05-17, 1:19 am |
| Roberto C. Sánchez wrote:
> On Tue, May 15, 2007 at 10:05:56PM -0400, Felipe Sateler wrote:
> Well, an NMU would go into unstable directly and not into stable.
Yes, but the version in stable (x.y.z-(w+1)~lenny1) would be higher than the
one in unstable (x.y.z-w.n)
--
Felipe Sateler
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2007-05-22, 7:19 am |
| Roberto C. Sánchez <roberto@connexer.com> writes:
> On Tue, May 15, 2007 at 03:49:07PM +0200, Goswin von Brederlow wrote:
> Yes, but in reality what is the likelihood that either a security update
> or NMU would introduce an incompatible change? I would say that such a
> possibility is extremely low.
>
> Perhaps the policy should change so that security uploads are done with
> x.y.z-(w++)~lenny1? That is, the Debian version number gets
> incremented.
>
> Regards,
>
> -Roberto
I suggested 1.2-3+s.lenny.1 in the past. More specifically:
1.2-3+a0... for local/vendor recompiles without source changes.
1.2-3+bX for binary NMU
1.2-3+c0... for local/vendor changes with source changes
1.2-3+s... for security updates
So for example an ubuntu patched package of foo would be
1.2-3+c0.ubunt.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|