Re: Bug#839046: debootstrap: enable --merged-usr by default
On 02/13/2018 04:29 PM, Raphael Hertzog wrote: > I believe that we have had quite some testing already last time and I > would be surprised if we got many more RC bugs on dpkg that had to be fixed > on a short timeframe. I guess nobody can give you any assurance but > I'm sure that you can downgrade those bugs pointing to this discussion > and showing that this was part of the deal. > If we break user systems we don't get to downgrade bugs on the basis that "we knew we were doing a half assed job with this transition". That's not part of the deal we're making with our users. Cheers, Julien
Bug#888448: ftp.debian.org,dpkg: dpkg-source and dak disagree on tarball signatures for format 1.0 source packages
Package: ftp.debian.org, dpkg Severity: important Hi, In the past, dpkg-source -x would refuse to unpack a source package with format 1.0 referencing such a file. As a result, dak would reject such uploads that couldn't be unpacked (https://anonscm.debian.org/git/mirror/dak.git/commit/?id=fe8fc1bfe57b90) As of dpkg 1.19.0, dpkg-source -b now includes upstream tar signatures when building source packages with format 1.0, thus creating source packages that get rejected on upload. That seems like a bad situation to be in. Can we please revert either the recent dpkg-source -b change or the older dak change? Thanks, Julien
Re: Bug#836525: debootstrap: doesn't support arch-qualified dependencies
On 12/19/2016 02:41 PM, Guillem Jover wrote: > Hi! > > On Mon, 2016-12-19 at 13:59:51 +0100, Julien Cristau wrote: >> Control: severity -1 normal >> >> On 12/19/2016 10:58 AM, Sven Joachim wrote: >>> Control: severity -1 serious >>> >>> On 2016-11-12 20:32 +0100, Sven Joachim wrote: >>>> On 2016-09-04 19:28 +0200, Sven Joachim wrote: >>>>> The attached patch should fix the problem with arch-qualifiers in >>>>> debootstrap, tested with >>>>> "debootstrap --variant=minbase --include=autoconf-dickey" which fails >>>>> right now in unstable but succeeds with the patch (autoconf-dickey >>>>> depends on perl:any). >>>> >>>> It should be noted that dpkg-dev in unstable now also depends on >>>> perl:any. This does not cause problems yet, but only because >>>> libdpkg-perl depends on perl and debootstrap silently ignores any >>>> dependencies it cannot resolve, which is a bug in itself. >>>> >>>> This bug is a ticking time bomb, would be nice to apply my patch before >>>> it explodes. >>> >>> The latest dpkg upload (1.18.17) changed the dependency of libdpkg-perl >>> to perl:any as well, and now "debootstrap --variant=buildd" fails >>> because it no longer downloads perl. > > Oww, sorry, had forgotten about your previous thread where you > mentioned this. :/ > >> I think that needs to be reverted in dpkg, we really want to be able to >> create sid chroots with stable debootstrap. > > Hmm, certainly right, I'll queue the revert for 1.18.18. > Do you have an ETA for that release? Right now our buildd chroots are affected by #848422 and it'd be nice if the next regular update (tomorrow evening) would be pick up a fixed version, so I'd like to know if I need to go and add --include perl as a workaround before then. (I'm also willing to NMU dpkg with that one d/control change today or tomorrow if that's easier.) Cheers, Julien
Re: Bug#836525: debootstrap: doesn't support arch-qualified dependencies
Control: severity -1 normal On 12/19/2016 10:58 AM, Sven Joachim wrote: > Control: severity -1 serious > > On 2016-11-12 20:32 +0100, Sven Joachim wrote: > >> On 2016-09-04 19:28 +0200, Sven Joachim wrote: >> >>> Control: tags -1 + patch >>> >>> The attached patch should fix the problem with arch-qualifiers in >>> debootstrap, tested with >>> "debootstrap --variant=minbase --include=autoconf-dickey" which fails >>> right now in unstable but succeeds with the patch (autoconf-dickey >>> depends on perl:any). >> >> It should be noted that dpkg-dev in unstable now also depends on >> perl:any. This does not cause problems yet, but only because >> libdpkg-perl depends on perl and debootstrap silently ignores any >> dependencies it cannot resolve, which is a bug in itself. >> >> This bug is a ticking time bomb, would be nice to apply my patch before >> it explodes. > > The latest dpkg upload (1.18.17) changed the dependency of libdpkg-perl > to perl:any as well, and now "debootstrap --variant=buildd" fails > because it no longer downloads perl. > I think that needs to be reverted in dpkg, we really want to be able to create sid chroots with stable debootstrap. Cheers, Julien
Re: tarball signatures in source packages and jessie
On Sun, May 22, 2016 at 19:39:53 +0200, Guillem Jover wrote: > BTW, do you think it would make sense to cherry pick > d01212f2d7e59fc713c66b5d60421ac2296c1463 in dpkg 1.17.x for stable, > given that there's a point release quite soon, and then we could > consider reenabling inclusiong of signatures for source format 1.0 > in unstable once the point release is done? (Taking into account Ian's > remark that just the change being in stable-updates is not good enough.) > That was my initial question in this thread... I have a vested interest in that all my packages are format 1.0, and I'd be interested in uploading signatures for them. OTOH I can also just wait a year. I have a related question though: if upstream ships a binary signature, e.g. https://www.x.org/archive/individual/proto/xproto-7.0.29.tar.gz.sig how should that be handled on the debian side? gpg --enarmor the file and ship the result as orig.tar.gz.asc, or is there a better way? Cheers, Julien
Re: tarball signatures in source packages and jessie
On Fri, May 20, 2016 at 19:47:19 +0200, Guillem Jover wrote:
> Hi!
>
> On Fri, 2016-05-20 at 13:12:37 +0200, Julien Cristau wrote:
> > dpkg-source in sid now picks up orig.tar.gz.asc files and lists them in
> > the source package. Unfortunately dpkg-source in jessie then explodes
> > on such source packages because it doesn't know what to do with them.
>
> Actually this only happens for version 1.0 format. Formats >= 2.0
> should be handled correctly in stable.
>
> > Arguably that would have called for a minor version bump, but in the
> > interest of allowing these files in the archive, would it make sense to
> > cherry-pick
> > http://anonscm.debian.org/git/dpkg/dpkg.git/commit/?id=d01212f2d7e59fc713c66b5d60421ac2296c1463
> > to jessie's dpkg?
>
> Actually I don't think signatures for 1.0 format should be allowed in
> the archive yet. And that's why I filed #823190 before the dpkg
> upload so that they would get rejected by lintian. But, I guess that
> was really the wrong way to go about it, and I'll just claim temporary
> dementia due to eagerness to get this out of the way. O:)
>
> Given that I don't see any 1.0 format sources in the archive just yet
> (hope nothing gets uploaded in the interim!):
>
> $ egrep -h '^ [0-9a-f]{32} .*\.asc$' /var/lib/apt/lists/*_Sources
> 813d2cdfd10a02a43f3d8f1aeef1fcec 819 libbsd_0.8.3.orig.tar.xz.asc
> d5cda03b1180452d72df0e096158a40f 173 vlc_2.2.3.orig.tar.xz.asc
>
There can't be any, because they'd get rejected by dak:
- until today, with something like
https://lists.debian.org/debian-x/2016/05/msg00160.html
- now, with a dpkg-source error:
https://lists.debian.org/debian-x/2016/05/msg00168.html
(I attempted to fix the first reject with
http://anonscm.debian.org/git/mirror/dak.git/commit/?id=ac7962e07a871d2619b475c54f6be2b3a79616ee
which only managed to show the second error; I've now got a patch at
http://anonscm.debian.org/cgit/users/jcristau/dak.git/commit/?h=formatone-no-tar-sig
to properly reject 1.0 source packages with orig.tar.gz.asc)
> I'll just disable picking up tarball signatures for 1.0 format for
> now in the next upload, which I'll try to rush out during the weekend.
>
OK, thanks.
Cheers,
Julien
tarball signatures in source packages and jessie
Hi Guillem, dpkg-source in sid now picks up orig.tar.gz.asc files and lists them in the source package. Unfortunately dpkg-source in jessie then explodes on such source packages because it doesn't know what to do with them. Arguably that would have called for a minor version bump, but in the interest of allowing these files in the archive, would it make sense to cherry-pick http://anonscm.debian.org/git/dpkg/dpkg.git/commit/?id=d01212f2d7e59fc713c66b5d60421ac2296c1463 to jessie's dpkg? Thanks, Julien
Re: Heads up: Upcoming dpkg-buildpackage -j precedence change
On Sun, May 10, 2015 at 18:49:25 +0100, Wookey wrote: I'm happy if you change this - it seems like fixing a bug to me, but I will just throw in this observation from recent arm64 archive-rebuilds, that -j and DEB_BUILD_OPTIONS=parallel= are not exactly the same. Is that expected? If not then it should perhaps be considered/investigated in case other builds are sensitive to the difference? here is a message from Ed Grimley-Evans, checking the FTBFS: --- freecdb illustrates the problem repeatably: works: DEB_BUILD_OPTIONS=parallel=4 dpkg-buildpackage -b fails: dpkg-buildpackage -b -j4 I haven't worked out precisely what goes wrong, but it seems to have something to do with a version of debian/implicit from 2005/2006, which was perhaps written with the assumption that dependencies are built one at a time in order. The whole package is that old, in fact. Anyway, what's the bug? Are packages that won't build with dpkg-buildpackage -j4 buggy, or is it a bug that man pages suggest using dpkg-buildpackage -j4 rather than DEB_BUILD_OPTIONS=parallel=4 dpkg-buildpackage -b? This seems to be reproducible even on a dual-core amd64 machine. dpkg-buildpackage -j is buggy. It sets MAKEFLAGS whether the package supports parallel builds or not. Whereas setting DEB_BUILD_OPTIONS lets the package know it's allowed to use more processes if it wants to / can, but doesn't have to. Cheers, Julien signature.asc Description: Digital signature
Re: Bug#768156: general: dpkg frontend inconsistent
On Tue, Dec 16, 2014 at 12:01:00 +0100, Holger Levsen wrote: reassign 768156 dpkg,ucf thanks On Mittwoch, 5. November 2014, Julien Cristau wrote: On Wed, Nov 5, 2014 at 17:53:50 +0100, Holger Levsen wrote: On Mittwoch, 5. November 2014, Michal Suchanek wrote: I was upgrading my system and several times I was asked for installing a new configuration file. Sometimes the question is posed in teletype style frontend sometimes in colour character terminal TUI style frontend. which tool did you use (how) to upgrade? Pretty sure this is ucf vs dpkg's conffile prompt. reassigning, so this can be sorted out between those two packages. Meh. This should be closed, not reassigned. Improving dpkg's conffile prompt has been a wishlist item for a decade or so already... Cheers, Julien signature.asc Description: Digital signature
Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'
On Wed, May 14, 2014 at 19:44:45 +0200, Guillem Jover wrote: It is needed on NFS mounts, where the locks are going to be most needed, as it's easier to get into a situation that several uncoordinate remote systems are building the same thing in parallel, but those are also not portably detectable. And unfortunately this is now a Recommends only due to http://bugs.debian.org/675947, as it was causing issues when introduceing new perl ABI versions. Does anyone actually do that? (Build packages concurrently from the same build directory on NFS) Yes, installing something in a pbuilder/cowbuilder chroot that isn't a Build-Depends (or Depends of the base system) is a problem in the sense that it somehow defeats the whole purpose of using a chroot for that in the first place. :) Well, it's still just a warning, would people feel less pestered if it was a simple info notice? I'd be fine with this immediate compromise for 1.17.10, and can queue a patch for that right now. That would be just as annoying, as far as I'm concerned. Cheers, Julien signature.asc Description: Digital signature
Re: Bug#582109: debian-policy: document triggers where appropriate
On Thu, Jul 25, 2013 at 08:00:55 +0900, Charles Plessy wrote: does the current patch (attached) address your concerns ? If yes, would you second it ? Sorry, I don't feel confident to second anything trigger-related. Cheers, Julien signature.asc Description: Digital signature
Re: Bug#582109: debian-policy: document triggers where appropriate
On Wed, Jul 17, 2013 at 09:27:19 +0200, Raphael Hertzog wrote: Hi, On Wed, 17 Jul 2013, Charles Plessy wrote: About the problem of triggers being called with Depends not satisfied, can you give more explanations or suggest some text for the warning ? Would it be enough to add a notice that the triggered postinst script may be called when the package is Unpacked, which is a state that does not require that the packages that are depended on are configured ? Julien is referring to this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671711 It might be fixed for jessie, at least I hope so, but he seems to doubt it. It doesn't really matter whether it's fixed for jessie. Since it's not fixed in wheezy, it's relevant for packages in jessie when they're upgraded. Cheers, Julien signature.asc Description: Digital signature
Re: Bug#582109: debian-policy: document triggers where appropriate
On Thu, Jul 4, 2013 at 11:26:01 +0900, Charles Plessy wrote: Le Sun, May 12, 2013 at 10:09:17AM +0200, Raphael Hertzog a écrit : On Sun, 12 May 2013, Charles Plessy wrote: I also added through the ttinterst/tt or ttactivate/tt directives after When a configured package activates a trigger. I applied the other changes you proposed as well, with minor rewording: - prgndpkg/prgn keeps a list, ttTriggers-Awaited/tt of - interested packages whose trigger processing is awaited. Every + prgndpkg/prgn keeps a list of interested packages whose trigger + processing is awaited, which is stored in the + ttTriggers-Awaited/tt field in dpkg's status database. Every I attached an updated version of the patch. Thanks, I agree that your improved wording is better. Seconded. Dear all, now that Wheezy is released, I hope that everybody has more time to review the patch to integrate triggers in the Policy and confirm Raphaël's seconding or propose extra corrections or improvements. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=87;filename=policy-triggers.diff;att=1;bug=582109 That patch has a bunch of typos (I noticed a few in spelling package). Also it doesn't seem to warn against triggers being called with Depends not satisfied, which caused no end of trouble for upgrades to wheezy, and which is probably going to bite us again for jessie. Cheers, Julien signature.asc Description: Digital signature
Re: Temporary solution for changelog problem in binNMUs
On Fri, May 17, 2013 at 14:14:20 +0200, Thomas Preud'homme wrote: Also, it wouldn't help for the case of a binNMU on a subset of all arches since only some of them would have the entry. The solution proposed by ansgar cover this case. No it doesn't. dpkg will still refuse to install a m-a same package at different versions. Cheers, Julien signature.asc Description: Digital signature
Re: Temporary solution for changelog problem in binNMUs
On Mon, May 13, 2013 at 15:16:57 +0200, Guillem Jover wrote: I've mentioned this before, I find this completely unsatisfactory, because (at least): 1) the changelog stops representing the actual changelog of the package. Irrelevant, that's already the case today for anything but the first binNMU. 2) the changelog is metadata anyway. Maybe. Maybe not. There seems to be disagreement on that one. It doesn't contain anything tools need to know, unlike symbols/shlibs files or the various maintainer scripts, so I'd argue they're quite different. 3) even if temporary, extractors might start looking into it. What for? And even then, so what? 4) even if temporary, we'll end up with uploaded packages with the information in a different place, if we go with a different solution, that will be 3 places where this can be found, and need supporting. FSVO need. 5) we could instead just decide now, and change the packaging helpers once and be done with it, new packages will not suffer the problem any more. The solution to consider changelogs metadata is also the easiest one, just place them in the DEBIAN dir, that's it. I'll prepare a proposal for at least debhelper later today. This is Debian. To just decide is going to take months. There's no consensus on your solution, and the current situation is just broken. 6) once “solved” I see there will be very low incentive to fix this properly, or that “solution” might just end up being entrenched, see what happened with the build flags being set by default by dpkg-buildpackage... Again, so what? Once solved the practical issues will go away. The cosmetic issues can wait until there's a consensus, which doesn't seem to exist today. Also detecting for now if a package cannot be binNMUed should be pretty strightforward, just checking if it builds M-A:same packages should be enough. Detecting is one thing. We'll still need to rebuild those packages. Sourceful uploads are much more costly, and I for one am not going to bother. Cheers, Julien signature.asc Description: Digital signature
Re: Temporary solution for changelog problem in binNMUs
On Mon, May 13, 2013 at 13:14:51 -0700, Jonathan Nieder wrote: One problem that that doesn't solve is what to do when a package would be able to borrow its /doc/package directory from another package (using a symlink) but for the changelog and copyright (which gets even harder when binnmus are involved). See http://bugs.debian.org/556015 Nobody said it solved that. It solves the multiarch binnmu co-installability issue, that's all anyone's said afaict. I'm not sure conflating that with another much older and much less severe issue helps anyone. Cheers, Julien signature.asc Description: Digital signature
Bug#671711: Bug#685243: vlc: breaks squeeze-wheezy upgrade into very bad state
On Sat, Aug 18, 2012 at 18:20:48 +, Daniel Pocock wrote: Package: vlc-nox Version: 1.1.3-1squeeze6 Severity: important My box is amd64, running squeeze I started an upgrade to wheezy, apt-get upgrade was successful. Then I ran apt-get dist-upgrade and it failed here: Processing triggers for vlc-nox ... /usr/lib/vlc/vlc-cache-gen: error while loading shared libraries: libvlccore.so.5: cannot open shared object file: No such file or directory dpkg: error processing vlc-nox (--unpack): subprocess installed post-installation script returned error exit status 127 configured to not write apport reports Errors were encountered while processing: vlc-nox E: Sub-process /usr/bin/dpkg returned an error code (1) Please provide the full upgrade log and contents of /var/lib/dpkg/status before and after the upgrade. I suspect this is yet another case of dpkg triggering unconfigured packages (#671711). Which dpkg maintainers don't plan on fixing, and recommend working around in other packages. Except I'm not aware of any work-around having been suggested. Cheers, Julien signature.asc Description: Digital signature
Re: Bug#571776: document symbols
On Sun, Aug 12, 2012 at 14:25:12 -0700, Russ Allbery wrote: Okay, once more for the win. Here is the current version of the patch, incorporating substantial improvements from Jonathan Nieder and hopefully incorporating all the feedback in subsequent discussion. I'm looking for seconds so that we can finally merge this monster. Presented as a diff since that was the request last time, but the branch has also been pushed to the Policy Git repository, so if you want to review it various other ways, you can start at: http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=shortlog;h=refs/heads/bug571776-rra or with a Policy Git checkout and look at the bug571776-rra branch. Seconded. Cheers, Julien signature.asc Description: Digital signature
Re: Bug#680626: Squeeze-Wheezy: dist-upgrade fails, /usr/bin/python unable to load libssl.so.1.0.0
On Tue, Aug 7, 2012 at 14:37:10 +0200, berta...@ptitcanardnoir.org wrote: However, when I ldd /usr/bin/python, it seems to be linked against libssl, so I'm wondering if this bug isn't related to the python package missing a dependency against libssl. It also seem to be linked against libcrypto, which is also missing when the dist-upgrade fails. python2.7-minimal in wheezy does depend on libssl1.0.0. However that's not enough to ensure unpack ordering. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120807131916.ga6...@crater2.logilab.fr
Re: Bug#680626: Squeeze-Wheezy: dist-upgrade fails, /usr/bin/python unable to load libssl.so.1.0.0
On Fri, Aug 3, 2012 at 11:04:25 +0200, Bill Allombert wrote: The current behaviour of triggers is well documented. triggers.txt.gz says Packages in t-awaited and t-pending demand satisfaction of their dependencies just like package in installed. The current behaviour doesn't seem to satisfy that at least for t-pending, unless I'm missing something. Either way, we need a fix for this in the squeeze to wheezy upgrade, which means not involving dpkg or squeeze packages, and probably not involving rewriting 10 packages to not use triggers (though I guess that would be an option if there's no better idea). Cheers, Julien signature.asc Description: Digital signature
Re: Bug#680626: Squeeze-Wheezy: dist-upgrade fails, /usr/bin/python unable to load libssl.so.1.0.0
On Mon, Jul 16, 2012 at 14:19:03 +0200, Julien Cristau wrote: On Sun, Jul 15, 2012 at 18:26:50 +0200, Guillem Jover wrote: W/o having looked yet at the details I'd say this *seems* like #671711, which I'm not planning on fixing for wheezy as it would introduce regressions on other situations, and given that this behaviour has been around since the introduction of triggers, and while quite unfortunate it's something that will have to be worked around on the affected packages because older dpkg will not be able to handle this correctly anyway. Going to look now, to make sure the above is the case. That seems likely. What is the recommended workaround here? Should package postinsts just ignore failures when called with 'triggered', or is there a better way? Ping? Any ideas? Cheers, Julien signature.asc Description: Digital signature
Re: Next upload 2012-06-26 (dpkg 1.16.5)
On Mon, Jul 23, 2012 at 15:14:15 +0100, Neil McGovern wrote: That is of course, your perogative. However, if you could kindly prepare a patchset between 1.16.5 and whatever you want to migrate, with all the translation and documentation changes stripped out, lets see how big that is. ITYM 1.16.4.3. Cheers, Julien signature.asc Description: Digital signature
Re: Bug#681332: debian-cd BoF at DebConf
On Fri, Jul 20, 2012 at 20:12:32 -0500, Jonathan Nieder wrote: Dpkg development has been happening pretty quickly lately, so there are a lot of changes between the versions in wheezy and sid. At this point quick development should target experimental, not sid. Cheers, Julien signature.asc Description: Digital signature
Re: Bug#680626: Squeeze-Wheezy: dist-upgrade fails, /usr/bin/python unable to load libssl.so.1.0.0
On Sun, Jul 15, 2012 at 18:26:50 +0200, Guillem Jover wrote: W/o having looked yet at the details I'd say this *seems* like #671711, which I'm not planning on fixing for wheezy as it would introduce regressions on other situations, and given that this behaviour has been around since the introduction of triggers, and while quite unfortunate it's something that will have to be worked around on the affected packages because older dpkg will not be able to handle this correctly anyway. Going to look now, to make sure the above is the case. That seems likely. What is the recommended workaround here? Should package postinsts just ignore failures when called with 'triggered', or is there a better way? Thanks, Julien signature.asc Description: Digital signature
Re: Bug#680626: Squeeze-Wheezy: dist-upgrade fails, /usr/bin/python unable to load libssl.so.1.0.0
On Sat, Jul 7, 2012 at 14:51:32 +0200, bertagaz wrote: In an attempt to test upgrading Squeeze to Wheezy now that the Big Wheezy Freeze has come, it failed at the dist-upgrade step. I installed a fresh Debian Squeeze and tested from it. I wanted first to see if it would be possible to upgrade with a simple and graphical method (using update-manager and synaptic), as it was quite complicated for the Lenny-Squeeze upgrade. Ended up with this result, so I also tested using plain apt-get upgrade and dist-upgrade. Same result, dist-upgrade fails on python-support postintallation script with the following error: Processing triggers for python-support ... /usr/bin/python: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory dpkg: error processing python-support (--unpack): subprocess installed post-installation script returned error exit status 127 Looks like dpkg is running triggers from packages that aren't configured. Can dpkg folks have a look at this? Bug#680626 has the details. Thanks, Julien signature.asc Description: Digital signature
Re: BinNMU changelog handling for Multi-Arch: same packages
On Wed, Jul 11, 2012 at 09:23:05 +0200, Raphael Hertzog wrote: I know that in the long term you're in favor of moving the changelog in the package metadata and I agree with this plan. But IMO we must find an interim solution in the mean time. Whatever solution ends up being chosen in the end (whether it's dropping the binNMU changelog, moving it to a separate file, or moving the whole changelog away, I don't hugely care), it's too late to make these changes for wheezy IMO. Cheers, Julien signature.asc Description: Digital signature
Bug#679959: dpkg: 1.16.5 breaks binNMUs
Package: dpkg Version: 1.16.5 Severity: grave When binNMUing a package with dpkg 1.16.5, the debs end up with a missing version in the Source field of their control file. See e.g. https://buildd.debian.org/status/fetch.php?pkg=libgdal-grassarch=kfreebsd-i386ver=1.9.0-1%2Bb2stamp=1341244875 compared to https://buildd.debian.org/status/fetch.php?pkg=libgdal-grassarch=kfreebsd-amd64ver=1.9.0-1%2Bb1stamp=1340892254 (the former has 1.16.5, the latter 1.16.4.3). 1.16.6 is also broken. Cheers, Julien signature.asc Description: Digital signature
Bug#679959: dpkg: 1.16.5 breaks binNMUs
tag 679959 patch
kthxbye
On Mon, Jul 2, 2012 at 19:14:58 +0200, Julien Cristau wrote:
Package: dpkg
Version: 1.16.5
Severity: grave
When binNMUing a package with dpkg 1.16.5, the debs end up with a
missing version in the Source field of their control file.
This seems to work:
--- /usr/bin/dpkg-gencontrol2012-06-30 21:51:22.0 +0200
+++ ../dpkg-gencontrol 2012-07-02 19:24:18.0 +0200
@@ -308,10 +308,10 @@
}
}
-my $verdiff = $binaryversion ne $sourceversion;
+my $verdiff = $substvars-{'vars'}{'binary:Version'} ne
$substvars-{'vars'}{'source:Version'};
if ($oppackage ne $sourcepackage || $verdiff) {
$fields-{'Source'} = $sourcepackage;
-$fields-{'Source'} .= ( . $sourceversion . ) if $verdiff;
+$fields-{'Source'} .= ( . $substvars-{'vars'}{'source:Version'} . )
if $verdiff;
}
if (!defined($substvars-get('Installed-Size'))) {
Cheers,
Julien
signature.asc
Description: Digital signature
Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'
Package: dpkg-dev Version: 1.16.4.2 Severity: normal Hi, dpkg-gencontrol makes annoying noise like this: dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe Please silence it. Cheers, Julien -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677474: Substvars for Build-Depends in the .dsc file
On Thu, Jun 14, 2012 at 10:19:58 +0200, Joachim Breitner wrote: currently a Debian source package specifies its build dependencies in debian/control; this information gets copied by dpkg-source to the .dsc file. From there it reaches the Source file which is taken into account by our infrastructure, e.g. the build daemons and tools like apt-get build-dep. Therefore, the data in .dsc is the effective copy. Absolutely not. We need to be able to install build-deps and run dpkg-buildpackage from a source package without any Sources index. Cheers, Julien -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#571776: document symbols
On Mon, Mar 19, 2012 at 17:26:04 -0500, Jonathan Nieder wrote: These dependencies must be added to the binary package when it is built, since they may change This means packages must not hard-code library dependencies. It also seems like good policy, but I suspect it would render packages such as chromium that use dlopen() and hard-code the corresponding library name in dependencies RC-buggy. They're already broken. What about libraries like glib (assuming one only uses old symbols) that are never supposed to change soname? What about them? [...] To allow these dependencies to be constructed, shared libraries must provide either a filesymbols/file file or a fileshlibs/file file, which provide information on the package dependencies required to ensure the presence of this library. Subject/verb agreement: s/provide/provides/ Clarity: s/this library/interfaces provided by this library/ p These two mechanisms differ in the degree of detail that they provide. A filesymbols/file file documents every symbol that is part of the library ABI and, for each, the version of the package in which it was introduced. Maybe, since minimal-version is not always the version in which the symbol was introduced: and, for each, a minimal version of the library needed to use that symbol, which is typically the version of the package in which it was introduced. [...] fileshlibsfile files also have a flawed representation of library SONAMEs, making it difficult to use fileshlibs/file files in some unusual corner cases. I'm not sure what this passage is referring to. Can you say more? (Maybe in a footnote.) libfooN.shlibs says 'libfoo N' not the actual SONAME, so if the SONAME doesn't match one of the two expected formats (libfoo-N.so or libfoo.so.N) it can't be represented. [...] udebs must also use fileshlibs/file, since the udeb infrastructure does not use filesymbols/file. To avoid confusion it might be worth forbidding symbols files in udebs, or at least symbols files without a corresponding shlibs file accompanying them. That makes no sense. udebs don't have those files, when building an udeb the dependency information is read from the shlibs files of the debs corresponding to the libraries you depend on. [...] If you have multiple binary packages, you will need to call prgndpkg-shlibdeps/prgn on each one which contains compiled libraries or binaries, using the tt-T/tt option to the ttdpkg/tt utilities to specify a different filesubstvars/file file for each binary package.footnote An alternative is to clear substvars between builds of different binary packages. Who does that? I don't think it's necessary to document all the twisted ways to make things not break. [...] loads ttlibbar/tt. A package should depend on the libraries it directly uses, but not the libraries it indirectly uses. Pedantry: what if my package uses the same library both directly and indirectly? but not the libraries it only uses indirectly would avoid that question. There are two types of ABI changes: ones that are backward-compatible and ones that are not. An ABI change is backward-compatible if any binary was linked with the previous version of the shared library will still work correctly with the new version of the shared library. Adding new symbols to the shared library is a backward-compatible change. Removing symbols from the shared library is not. If I remove a symbol that was documented to be private or change the behavior of a function when given invalid arguments, is that a backward-compatible change? If I add change the implementation in such a way that the library becomes so large that some large programs cannot use it any more, is that a backward-incompatible change? I'm not sure policy should go into such details. And anyway, that's answered by the previous sentence (an incompatible change is one that breaks reverse deps). The last two are simple examples. Cheers, Julien signature.asc Description: Digital signature
Bug#642802: dpkg predependency against tar = 1.23, objections?
On Thu, Sep 29, 2011 at 18:50:35 +0200, Raphael Hertzog wrote: Hello, On Sun, 25 Sep 2011, Guillem Jover wrote: $ sudo apt-get install dpkg-dev [...] tar: unrecognized option `--warning=no-timestamp' Try `tar --help' or `tar --usage' for more information. dpkg-deb: error: subprocess tar returned error exit status 64 dpkg: error processing /var/cache/apt/archives/dpkg-dev_1.16.1_all.deb (--unpack): subprocess dpkg-deb --control returned error exit status 2 [...] I manually unpacked the latest tar package (version 1.26-2) with ar and tar, and overwrote /bin/tar . dpkg worked again. The tar version introducing those options was 1.23, present in squeeze. So it seems you are trying to upgrade a system with packages still from lenny to a mix of squeeze and sid? This is generally not supported, but I also agree this outcome is not desirable either, I'll probably add a versioned Pre-Depends on the required tar, after running it through debian-devel. So cc-ing debian-devel with this mail. Does anyone have an objection against dpkg adding this tar (= 1.23) pre-dependency? For reference it's the fix for #640298 that added the --warning=no-timestamp option. Couldn't dpkg figure out from tar --version whether it can add the option? Cheers, Julien -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: binNMUs?
On Mon, Sep 12, 2011 at 15:26:16 +0100, Steve Langasek wrote: On Thu, Aug 25, 2011 at 08:19:09PM +0200, Julien Cristau wrote: On Mon, Aug 1, 2011 at 15:31:56 +0200, Andreas Barth wrote: Also, I think we still have a reason for +b(something) as sometimes we just need to rebuild on a single architecture (because something strange has happend there), and I don't want to get rid of that ability. The more I think about it, the more I think we should move the binNMU changelog out of /usr/share/doc and allow co-installation of different binNMU versions of multi-arch: same packages. (IOW: agreed) Any reason not to ship it as /usr/share/doc/$pkg/changelog.$arch? (I.e., I think /usr/share/doc is still the right place for it, even if it can't be changelog.Debian.gz anymore.) Depends where it's handled, and how the binNMU changelog+version end up being passed to the build, I think. Cheers, Julien -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110912203301.gc5...@radis.liafa.jussieu.fr
Re: binNMUs?
On Mon, Aug 1, 2011 at 15:31:56 +0200, Andreas Barth wrote: Also, I think we still have a reason for +b(something) as sometimes we just need to rebuild on a single architecture (because something strange has happend there), and I don't want to get rid of that ability. The more I think about it, the more I think we should move the binNMU changelog out of /usr/share/doc and allow co-installation of different binNMU versions of multi-arch: same packages. (IOW: agreed) I guess that would need some work in dpkg and sbuild. Anything else that needs to care about it? Cheers, Julien -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110825181909.gt2...@radis.liafa.jussieu.fr
Bug#610991: apt-get install udev removes emacs
On Mon, Jan 24, 2011 at 21:37:01 +0100, Sven Joachim wrote: Hi, I wonder whether the Breaks against the emacs2[12] packages need to be taken out as well. In a chroot the upgrade process removes emacs and its dependencies: Possibly the breaks is a bad idea for anything that's more than just an info viewer. Cheers, Julien signature.asc Description: Digital signature
Bug#610991: [PATCH] debian/control: add install-info to dpkg Depends
On Mon, Jan 24, 2011 at 16:38:23 -0600, Jonathan Nieder wrote: Rather than forcing the removal or upgrade of various info browsers before dpkg, let dpkg provide the install-info functionality for another release. Other packages will still depend on install-info directly so the dependency can be dropped in wheezy. The cost is around 256 KiB. Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- Jonathan Nieder wrote: Julien Cristau wrote: Possibly the breaks is a bad idea for anything that's more than just an info viewer. Info viewers, too, right? Not so much I think. At least info viewers should be easier to upgrade and less of a loss if removed. And they're actually broken by a missing install-info. konqueror and emacs aren't. In other words, how about something like this patch? I don't think that's a good idea at this point. A year ago, maybe. One issue Sven mentioned on irc is that an unknown number of packages would start shipping /usr/share/info/dir.gz on rebuild if we were to do this. Cheers, Julien signature.asc Description: Digital signature
Re: Accepted bup 0.17b-2squeeze1 (source i386)
On Tue, Jan 4, 2011 at 10:03:00 +, Jon Dowland wrote: bup (0.17b-2squeeze1) testing-proposed-updates; urgency=low . * use python-support to tightly version python dependency, needed due to the binary extensions. Thanks Jakub Wilk. Closes: #608568. *sigh* if you're going to use dpkg v3, could you please avoid the automatic patch feature? It turns a trivial fix into 5 files changed, 70 insertions(+), 61 deletions(-) because patches/debian-changes-0.17b-1 | 58 patches/debian-changes-0.17b-2squeeze1 | 59 + Anyway, approved. Cheers, Julien signature.asc Description: Digital signature
Bug#584254: dpkg should support a --force-unsafe-io option or such
On Wed, Oct 20, 2010 at 22:20:31 +0300, Modestas Vainius wrote: Btw, how will I be able to enable --force-unsafe-io for dpkg when it's run under apt/aptitude? Maybe environment variable and/or /etc/dpkg/dpkg.cfg option is a better solution then? -o DPkg::options=--force-unsafe-io? Cheers, Julien signature.asc Description: Digital signature
Re: Bug#593909: Names of Fields in Control Files
On Wed, Oct 13, 2010 at 00:18:49 +0900, Charles Plessy wrote: From: Charles Plessy ple...@debian.org Date: Wed, 13 Oct 2010 00:14:42 +0900 Subject: [PATCH] Clarification of the format of control files, Closes: #501930, #593909. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Specifies field names similarly to RFC 822/5832; - Distinguishes simple, folded and mulitiline fields; - Clarifies paragraph separators (#501930); - The order of paragraphs is significant; - Fields can have different types or purposes in different control files; - Moved the description of comments from §5.2 to §5.1; - Documented that relationship fields can only be folded in debian/control. Seconded. Cheers, Julien signature.asc Description: Digital signature
Bug#597340: dpkg-gencontrol: implicit substvar at the end of every field
On Sun, Sep 19, 2010 at 23:07:44 +0200, Raphael Hertzog wrote: On Sun, 19 Sep 2010, Steve McIntyre wrote: CCing -devel and Joey Hess to have some input on this idea. Do you think it would be useful ? Do you have comments and suggestions ? I'm uncomfortable with the idea of (even more?) build-time package settings being hidden away outside of debian/control. :-/ On the flip side, it means less possibilities of mistakes for debhelper users, a simpler learning curve to newbies who don't have to know about substvars right from the start, etc. But I can understand your feeling and we will probably need options to disable this behaviour in some cases. I'm at least as uncomfortable with new options as I am with new magic. dpkg-source has way too many options already. Cheers, Julien signature.asc Description: Digital signature
Re: Processed: Re: Bug#536482: dpkg-shlibdeps: Weired warnings about libc symbols
On Sun, Jul 12, 2009 at 14:24:57 +0200, Aurelien Jarno wrote: Given it's a dpkg bug and not a bug in eglibc, I think this should be handled by binNMU. Could the release team please schedule them? Thanks in advance. As already mentioned, the issue with binNMUs here is they don't ensure the fixed dpkg-dev is installed. A source upload with temporarily bumped b-dep would do that. Cheers, Julien -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
reassign 532739 to dpkg
reassign 532739 dpkg 1.15.2 -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
reassign 530633 to dpkg
reassign 530633 dpkg -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
reassign 530643 to dpkg, retitle 530643 to update-alternatives b0rkage?
reassign 530643 dpkg retitle 530643 update-alternatives b0rkage? -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#522858: tar: causes dpkg-source extract failures
clone 522858 -1 reassign -1 dpkg kthxbye On Mon, Apr 6, 2009 at 17:45:33 -0700, Daniel Schepler wrote: Since installing the latest version of tar, I'm getting failures in attempting to extract certain deb packages. For example, with telepathy-glib: frobozz:/tmp$ dpkg-source -x telepathy-glib_0.7.29-1.dsc dpkg-source: extracting telepathy-glib in telepathy-glib-0.7.29 dpkg-source: info: unpacking telepathy-glib_0.7.29.orig.tar.gz dpkg-source: failure: gunzip died from signal 13 frobozz:/tmp$ ls telepathy-glib-0.7.29.orig/ frobozz:/tmp$ Same here. Looking at the tar changelog it's likely this is due to: 2008-11-25 Sergey Poznyakoff g...@gnu.org.ua Do not try to drain the input pipe before closing the archive. tar closes its input fd, which sends SIGPIPE to gunzip, and dpkg errors out. I'd argue this is a bug in dpkg-source, which ought to ignore this. Cheers, Julien -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#454057: please move dpkg-architecture
On Wed, Dec 5, 2007 at 00:14:53 +0100, Raphael Hertzog wrote: Or we can change type-handling too. Apparently xorg only uses the fact that type-handling provides not+sparc but it doesn't use the type-handling program which is the real user of dpkg-architecture. Is that right? Yes, that's correct. Maybe type-handling could be split with an empty package whose sole purpose is to Provides some virtual packages while type-handling stays the program with its dpkg-dev dependency. I think this solution would be my first preference. My preference would be for dpkg to allow 'Depends: foo [arch]' in arch:all packages, but failing that, I agree. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342465: French man dpkg is truncated at --set-selections
tags 342465 patch kthxbye On Wed, Dec 7, 2005 at 13:50:59 -0500, Filipus Klutiero wrote: Package: dpkg Version: 1.13.11.0.1 Severity: normal Tags: l10n French dpkg manpage reads at --set-selections: modifie la liste des sélections des paquets en lisant un fichier sur l'entrée standard. Le format de ce fichier doit être de la forme ou « purge ». There's obviously something missing between forme and ou. There's a line beginning with a ' (ascii 0x27) between these words. Since this is a control character when it starts a line, and it's not followed by a valid roff request, the whole line is ignored. The attached patch fixes this problem. Cheers, Julien Cristau diff -ru dpkg-1.13.11/man/fr/dpkg.1 dpkg-1.13.11.new/man/fr/dpkg.1 --- dpkg-1.13.11/man/fr/dpkg.1 2005-06-06 06:22:16.0 +0200 +++ dpkg-1.13.11.new/man/fr/dpkg.1 2005-12-07 20:33:25.0 +0100 @@ -213,10 +213,11 @@ .TP .B dpkg \-\-set\-selections modifie la liste des sélections des paquets en lisant un fichier sur -l'entrée standard. Le format de ce fichier doit être de la forme -'paquet état', où état vaut «\ install\ », «\ hold\ », «\ deinstall\ » -ou «\ purge\ ». Les lignes vides ou les lignes de commentaires débutant par -«\ #\ » sont autorisées. +l'entrée standard. +Le format de ce fichier doit être de la forme 'paquet état', où état vaut +«\ install\ », «\ hold\ », «\ deinstall\ » ou «\ purge\ ». +Les lignes vides ou les lignes de commentaires débutant par «\ #\ » sont +autorisées. .TP .B dpkg \-\-yet\-to\-unpack
