Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi Aurelien, Trimmed Cc list for glibc matters. On Wed, Jun 05, 2024 at 11:16:50PM +0200, Aurelien Jarno wrote: > Oops, I was convinced that #1071462 was filled with severity serious. > Nevermind. It migrated anyway. :) > Ok, a simultaneous experimental NMU sounds good. Ok, will do with a bit of delay. > Note however that people often downgrade glibc when they have suspicions > (like in the fakeroot case above), or even the hard way with dpkg once > their system is broken. Therefore we should at least test that case to > see how much breakage to expect, and also to easily spot patterns where > a system went through a glibc downgrade possibly followed by an upgrade. Thanks for the pointer. I tested a downgrade. It seems to work without loosing files, but two protective diversions remain in place. One is issued by libc6 against itself (such that it is immune to its own diversion) and the other is issued on behalf of base-files and properly owned by base-files after upgrading base-files. So the downgrade situation is not exactly the situation before the downgrade, but close enough, it works and after upgrading again it's all as it should be. I think this is fine. Doing final checks then uploading it all. Helmut
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi Aurelien, On Tue, Jun 04, 2024 at 06:58:00PM +0200, Aurelien Jarno wrote: > It would be really great if glibc can migrate before as it fixes an RC > bug. That said there are suspicions that it introduced bug #1072521, so > it might be worth investigating before it gets pushed into testing. > Unfortunately, on my side, I am unable to reproduce the issue. I looked and couldn't spot the RC bug you are referring to. The highest severity one I could spot is the systemd/debianutils/sbuild where telinit kills the build, but that isn't RC. Am I missing something? I also looked at #1072521 and am fairly certain that it is not a glibc regression. For sure, #1072521 is not trivially reproducible. In fact, I am not aware of anyone other than the submitter reproducing it. Beyond that, it is very likely that the submitter uses a non-default file descriptor soft limit (even though raising it does not reproduce the problem). In general, I agree with glibc migrating before doing the synced upload and that's also what Paul asked for. From my side the urgency here is risk management. Doing it later makes it harder for me to provide resources to fix fallout and I'm trying to find a good balance. Given that both util-linux and glibc need to migrate, deferring to Thursday (still leaves time until the Sunday cron) or even Monday looks most reasonable to me. > Please go ahead with a NMU. I wonder about experimental, do we want to > do the changes at the same time, or a bit after? Said otherwise is > moving files from /usr to /lib supported? I don't want to support such moves in any way. Hence, I think the best option would be to simultaneously NMU experimental. dash is affected in the same way. Admittedly, I'm not too worried about experimental upgrades failing. We have a number of packages that move files the wrong way in experimental and it doesn't seem to bother people (nor me). Helmut
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
On Wed, May 29, 2024 at 03:14:59PM +0200, Helmut Grohne wrote: > Since noble includes these changes and I'd get this done sooner rather > than later, how about moving forward with June 5th after 22:30 UTC (such > that all buildds have regenerated their chroots before the upload)? I got vaguely positive feedback from Paul Gevers on this date. Hence, I plan to upload after the June 5th mirror push and allocate time for handling unexpected fallout. dash, base-files and bash are fully migrated at the time of this writing. glibc migrated -11 and -12 still has 5 autopkgtest regressions. util-linux migrated -6, -7 has a piuparts regression and -8 hopefully gets tested soon. I hope that both migrate before the planned upload and will consult with the release team on whether to bump back or go ahead. I have rebased and retested the patches in https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo. Andrew, Aurelien, Chris, Matthias, Santiago: Any objections? You may send me signed uploads (.dsc + source chanages) and I will otherwise move ahead with regular NMUs. If you send signed changes, I recommend encrypting them using my gpg key. Helmut
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi release team, On Wed, Mar 13, 2024 at 10:55:09AM +0100, Helmut Grohne wrote: > I propose April 11th on the condition that all relevant packages > (including cryptsetup and e2fsprogs) have migrated. I'll also check with > Aurelien on feasibility after Easter. Stuff wasn't ready back then and we kept bumping the /usr-move back. I think we need to fix dates soon. During the past months, I reserved time for the essential fallout and I cannot promise that in second-half-June, July and first-half-August. Meanwhile all the relevant stuff has migrated including the glibc upstream release. So we basically have the following options: * Pick a date before June 7th and go ahead soon. * Go for later and I'll handle the fallout best-effort. (i.e. similar t64 fallout) * Pick a date August 12th or later. Since noble includes these changes and I'd get this done sooner rather than later, how about moving forward with June 5th after 22:30 UTC (such that all buildds have regenerated their chroots before the upload)? There also is little to be done from the release team's side beyond installing a block for base-files, bash, dash, glibc, util-linux and then lifting the block once all of them are ready turn that block into a force hint such that they really migrate together. (There is no dependency relation between them ensuring concurrent migration as that would make upgrades more difficult.) Other than the bootstrap matter, we're down to 350 affected packages and dumat is finding one to five issues per week most of which are undeclared file conflicts. As a result of the dumat work, I haven't seen an actual end user report about a /usr-move problem in quite a while. A list of affected packages is at https://subdivi.de/~helmut/usrmove.ddlist (not entirely current). I'll propose a MBF for the remaining no-change sourceful uploads as well as the remaining "Build-Depends: dh-sequence-movetousr" uploads. All other moves already have bugs. I also plan to bump the severity of these bugs to important soon. Do you also agree with bumping these bugs to serious severity once their number goes below 200? Keep in mind that they are all actionable in the sense that one of the following applies: * No-change sourceful upload fixes * An upload adding "Build-Depends: dh-sequence-movetousr" fixes * The attached patch fixes * Rarely maintainer feedback has been requested Chris has already performed a number of NMUs and we'll need to do some more to eventually get us down to 0 aliased packages. A while ago I removed 10 affected source packages that were FTBFSing for two stable releases already. Helmut
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi, On Sat, Mar 09, 2024 at 09:50:11PM +0100, Sebastian Ramacher wrote: > > I'd now like to coordinate a time of upload. Given that chroots are > > rebuilt in Wednesday and Sunday, I suggest we pick a Thursday morning > > for the actual upload. If I unexpectedly break stuff, I still have a few > > days to fix. How about March 21st? > > If and only if time64_t is done by then. Adding more changes where > transition has to be coordinated to the ongoing mega transition does not > help. Aurelien also said that glibc doesn't really build at this time. Furthermore, cryptsetup needs to migrate to testing before the upload and cryptsetup -> openssl -> dpkg is also entangled in time64. I propose April 11th on the condition that all relevant packages (including cryptsetup and e2fsprogs) have migrated. I'll also check with Aurelien on feasibility after Easter. Helmut
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi release team and essential maintainers, On Mon, Sep 04, 2023 at 10:33:54PM +0200, Helmut Grohne wrote: > Once these issues have been resolved, we can move most files except for > a small set of essential packages. For those, a coordinated upload > moving their files will be needed as will be an upload of base-files > adding the aliasing symlinks there. We're well into this now. Most of the essential set is moved and I've most of the remaining pieces. I hope that within one week, we're left with only: - base-files - bash - dash - glibc - util-linux Patches for these have been prepared. The current patches are available from https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo. These changes have been uploaded to Ubuntu noble already and feedback has been incorporated. In particular, base-files will now divert to dot files to avoid cluttering the / view during the transition and base-files will remove unnecessary diversions (those where it ships symlinks). I'd now like to coordinate a time of upload. Given that chroots are rebuilt in Wednesday and Sunday, I suggest we pick a Thursday morning for the actual upload. If I unexpectedly break stuff, I still have a few days to fix. How about March 21st? Once this has uploaded, we need to ensure that these packages migrate together. Also note that dash's autopkgtest will fail unless it uses the updated base-files, but it cannot depend on base-files. If you prefer, I can mark the relevant test case as flaky and unmark it in a second upload. Having a temporary migration block on these packages would also be a good idea. Once agreed, I shall announce this change to d-d-a as I cannot fully rule out it being disruptive despite the extensive testing performed. > We probably have to use NMUs to convert remaining packages at this > point. Once everything is moved, we may think we're done, but we're not. Speaking of the rest of packages. At the time of this writing, the numbers are: * 224 source packages can be moved via dh-sequence-movetousr. * 191 source packages have a dep17 usertagged bug report (most with patches). * 141 source packages can be moved with a no-change sourceful upload. This is about Arch:all packages as we already binNMUed the others. * 35 source packages cannot be analyzed, because they FTBFS (reported). * A 1-digit number of packages (e.g. the bootstrap ones above) needs special handling, but this is communicated and monitored. I hope that these numbers go down moving forward (especially the patches one). At some point, I want to mass-NMU the remaining packages. > As packages are restructured throughout the release cycle, they may > introduce file loss scenarios. Continued monitoring for problems until > trixie is released is crucial. The biggest chunk of findings was due to time64. I think the reports are timely and actionable. Generally, I hope that we'll run into less fallout moving forward as the "big" stuff is being handled. One exception here is that time64 has introduced a pile of "risky replaces". These are not accounted as buggy in the above numbers but need to be addressed before we can mass-NMU. That'll happen once the dust settles on time64. Any objections so far? Helmut
Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
On Sat, Jan 06, 2024 at 01:20:11PM +0100, Paul Gevers wrote: > We're not there yet, so please hold your horses. Although I tend to think we > should allow this too for the use cases you describe. So unless it's really > the intent of a (source) package or small (source) package set to be meant > to be used in a multi architecture environment I think we should demand that > dependencies are not be exclusively fulfilled by packages from another > architecture (:any is OK, :$arch is not). So indeed, each should require > manual review. While writing this that *could* mean that britney2 grows > support for cross-architecture dependencies while still blocking them if not > forced. I second this. I think we are already issuing a little too many :native and :any annotations that occasionally fire back (when changing M-A:no to M-A:foreign or M-A:allowed to M-A:same). Allowing :$arch for a reviewed set enables a few useful corner cases and avoids use where it is not appropriate. Before we drop -$arch-cross packages, we should consult with Matthias though. I think he has more reasons for them than britney2. One of them is that we can perform basic cross compilation to non-release architectures using only release-architecture packages. If we were to drop them, I'm not sure how gcc-$VER-cross-ports could exist. Helmut
Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
Hi Simon, Thanks for your work on gobject-introspection cross building! On Wed, Jan 03, 2024 at 07:22:26PM +, Simon McVittie wrote: > - gobject-introspection-little-endian:any, a virtual package provided > by g-i-bin, which is Multi-Arch: allowed > (experimentally, apt and dpkg both seem to be happy to assume that > this makes the gobject-introspection-little-endian virtual package > behave as though it was also Multi-Arch: allowed) Let me guess that this is the culprit. I also Cc apt maintainers for their input. > Or do I need to make gobject-introspection-bin Multi-Arch: foreign, > drop the :any from gobject-introspection-little-endian:any, and > replace the gobject-introspection-bin | qemu-user | qemu-user-static > dependency by python3 | qemu-user | qemu-user-static or similar? I am not sure that you are the one who should express a qemu dependency. When we reason about dependencies, we care about how they behave assuming that you can run them. Whether you can run an executable from a package or not is something that is not expressed in our package relationships. It's also rather difficult. Consider a few corner cases: * Some amd64 can run i386. * Most arm64, but not all, can run armhf. * You may operate in a chroot with some external qemu-binfmt and thus execute any arch. * You cannot run hurd-i386 on amd64 even in the presence of qemu-user. I probably have caused this in our discussion back in Cambridge where I suggested to you that having a dependency on qemu could be ok. Given the above, qemu quite likely needs more thought. > My goal here is that you can install gobject-introspection:amd64 on an > amd64 machine, or on any other little-endian machine that will be able to > cross-compile amd64 binaries and then run them by explicitly invoking them > via qemu-user, as discussed with Helmut Grohne at the recent Cambridge > miniDebconf. (It has to be little-endian because g-ir-inspect and similar > tools don't currently support byte-swapping fields in binary typelibs.) When we considered whether cross building should imply disabling tests, we went for "no, but yes by default". When you cross build a package for i386 on amd64, sbuild and pbuilder will automatically add nocheck to DEB_BUILD_OPTIONS and DEB_BUILD_PROFILES. However, you can opt out of this behaviour to really run tests despite performing a cross build. I think we need a similar mechanism for qemu integration. When we talked about this, I was having in mind (but probably didn't express this explicitly) that such qemu dependencies would happen in Build-Depends only. This is different from what you do here and has multiple implications: * Your satisfiability problem with britney2 probably goes away. * Every package that uses gobject-introspection needs to be modified for this. * We can annotate such qemu dependencies with a build profile e.g. . By default, such dependencies would only become active for cross builds, but the second profile enables you to skip them when you know that no emulator is required. Other than this, let me note that M-A:allowed always seemed a little annoying to me, because it makes an implementation detail visible to consumers. Whenever you think you need M-A:allowed, you may instead introduce a layer of indirection. In principle, you could add a real binary packages: gobject-introspection-any-endian with Arch:any M-A:foreign Depends:gobject-introspection-bin and architecture-dependent provides. Then you can just depend on gobject-introspection-little-endian without thinking about whether you have to add :any. Let me also note that the way you have gobject-introspection (the binary package) now fills a similar role to pkgconf/pkg-config and qt5-qmake as well as binutils-for-host and hopefully soon also gcc-for-host. That pattern seems to work out rather well. This probably isn't the final solution, but I hope my feedback moves you forward in some way. Helmut
Re: /usr-move: Do we support upgrades without apt?
On Wed, Jan 03, 2024 at 08:07:53PM +0100, Wouter Verhelst wrote: > Presumably the reason for this requirement in policy is that without it, > debootstrap cannot function. That is, debootstrap first unpacks all > Essential packages, without running any preinst or postinst scripts, and > *then* runs all the maintainer scripts. If an Essential package would > not function without its maintainer scripts being run, then debootstrap > could fail halfway through. The requirement you reference above probably is 3.8: Essential is defined as the minimal set of functionality that must be available and usable on the system at all times, even when packages are in the “Unpacked” state. I note that this does not apply to bootstrap as is later clarified: Since dpkg will not prevent upgrading of other packages while an essential package is in an unconfigured state, all essential packages must supply all of their core functionality even when unconfigured after being configured at least once. The "at least once" was added precisely, because packages are not required to work before having been configured at least once. What happens during debootstrap is rather unspecified by policy. The requirement really aims at upgrade scenarios where the other packages are being configured when an essential package is unpacked but not yet configured. This is precisely the situation we break here (if using dpkg directly in unfortunate ways). > Running debootstrap cannot trigger the issue, because it does not > involve upgrades; and I do not believe that apt will special-case > Essential packages other than that it refuses to remove them unless > the user enters The Phrase[1], so we can consider that if it's something > that would work for a regular package, it will work for an Essential > one, too. I agree: The file loss cannot be encountered with bootstrapping tools and as long as we are interacting via apt (or some apt using tool), we cannot create the broken situation (there actually is no proof of this, just hope and having tried to break it) as long as there is no mutual conflict. > Perhaps if the above assumptions are correct, policy should be updated > such that the requirement is relaxed to only apply for initial > installation? Policy has been updated via #1020267 to *not* apply to the bootstrapping scenario. Helmut
Re: /usr-move: Do we support upgrades without apt?
Thanks for the feedback. Given the replies, I consider that most people expect upgrades to be performed with apt (or some apt-using tool). Upgrades using dpkg (directly) are at least partially unsupported. In more detail: On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote: > ## Options (combinations possible) > > When mitigating P3, we can avoid the mutual conflicts. For molly-guard > that has been more involved, but it seems manageable. For other > packages (that do not need to access diverted files), it becomes > simpler. We'll be doing this. It is implemented in molly-guard and submitted for gzip #1059533 / zutils #1059534. Hence, upgrades with apt-dependent tools will not experience the failure mode. > We can restore lost files in a postinst. For this to work, we must > duplicate (e.g. hard link) affected files in the data.tar. > Example: #1057220 (systemd-sysv upgrade file loss) > Note that this approach is not policy compliant for essential packages > as they must work when unpacked and this is relevant for gzip being > diverted by zutils for instance. We'll be doing this anyway. It is implemented in systemd-sysv.postinst and proposed in the gzip patch above. Yes, we are technically violating policy for gzip then, but I don't really see a technical way not to violate policy. I expect that we do not consider fixing this (unfixable) policy violation release-critical. > We can introduce "barrier" packages (one or more) and have them enforce > conflicting packages removed before the conflictor being unpacked > (thanks Julian). We'll keep this as an option for later, but avoid implementing it now. > We can - and this is the crux of the matter - argue that upgrading with > bare dpkg is unsupported and you get to keep the pieces if you do so > anyway. release-notes already recommend upgrading with apt. In addition we'll: * Extend release-notes to do advise something like `dpkg --verify` post upgrade. * Mitigate file loss in postinst (such that it becomes temporary). If you have any objections to these choices, please tell. Helmut
Re: /usr-move: Do we support upgrades without apt?
Hi Matthew, On Thu, Dec 21, 2023 at 02:42:56PM +, Matthew Vernon wrote: > On 21/12/2023 09:41, Helmut Grohne wrote: > > > Is it ok to call upgrade scenarios failures that cannot be reproduced > > using apt unsupported until we no longer deal with aliasing? Let me thank David for clarifying what "using apt" means in exactly the way I intended it. As a result, I think the only "no" reply, I've seen thus far is from Matthew here. > I incline towards "no"; if an upgrade has failed part-way (as does happen), > people may then reasonably use dpkg directly to try and un-wedge the upgrade > (e.g. to try and configure some part-installed packages, or try installing > some already-downloaded packages). I incline to agreeing with the scenario you depict. This can reasonably happen. I also think that David made a good case for it being unlikely to manage oneself into the buggy situation that way. And then the consequence is that you lost some possibly important files. If you ended up fiddling with dpkg in a failed upgrade, would it be too much to ask for running dpkg --verify? In the event you see missing files, you may reinstall affected packages and thus have cured the symptoms for your installation. Say we extended release-notes saying that you should dpkg --verify after the upgrade and more so if you happened to use dpkg directly in the process and review the output. Would that address your concern? > It may be that the mitigations necessary are worse than the risk, but I > think the behaviour as described in #1058937 is definitely buggy. I hope we all agree this is buggy. That's not the question. The question at hand is whether this is a bug worth fixing or mitigating. We face a lot of bugs in Debian and assign different severities. Here, the preliminary analysis assigned a rc-severity which generally means it is worth fixing. That's the thing I'm questioning here. Also keep in mind that probably the majority of bullseye -> bookworm upgrades have been performed already. In all those upgrades, nobody ran into the issue and reported it. As David pointed out, it was encountered by actively trying to make it break. It's the silent kind of failure, so it may just have happened without people noticing. Maybe we can all run dpkg --verify on our installations (in particular those upgraded to bookworm or later) and report if they show anything suspicious. Then we can better quantify how likely these issues happen in practice. I note that dpkg --verify does not currently work with --path-exclude. I'm not sure whether that's a bug. Being a user of --path-exclude, I note that I ran dpkg --verify on 5 very different systems and didn't spot unusual things. This is anecdotal evidence and cannot prove the absence of problems though. I'd be very keen to see at least one user reporting such problems in a real upgrade rather than me trying to find problems. Helmut
diversions of /sbin/halt and friends
Hello, thanks to all of you Francois, Daniel and Michael for uploading my changes to experimental. Whilst I already tested the patches individually earlier, this gave me the opportunity to test them in cooperation. In particular, the versioned Conflicts issued by systemd-sysv now work as expected. In performed a number of manual tests upgrading from bookworm to experimental and replacing diverters for one another (molly-guard/bfh-container/progress-linux-container) as well as replacing divertees (systemd-sysv/sysvinit-core) and removing packages. When doing this with apt, this all looks good despite systemd-sysv not having added my patch for #1057220. This is expected as that patch mitigates problems resulting from direct usage of dpkg. I also checked the dumat report for these uploads and am generally happy. Given that the current mitigation does make diverters not issue Breaks, molly-guard continues to work with the current sysvinit-core that has not moved its files yet. My patch for progress-linux-container and bfh-container fails to remove /usr/lib/container on package removal. This probably breaks piuparts. I am attaching a followup patch. This defect is unrelated to the /usr-move as far as I can tell. I would prefer systemd-sysv to also address #1057220, but Michael confirmed that he was not intentionally excluding it. Also the systemd-ukify split leaves an unusual file loss scenario while upgrading from bookworm-backports and simultaneously installing systemd-ukify (P1), which Michael will likely mitigate by upgrading Breaks to Conflicts (M7). I also thank Marc for his works-for-me feedback regarding molly-guard. Given all of this, I am happy with all of these changes moving to unstable and trixie. Thanks for your patience. Helmut
/usr-move: Do we support upgrades without apt?
Hi, this installment serves a dual purpose. Let me first give an update of the status quo and then pose a consensus question on how we want to deal with a particular problem. I Cc d-release@l.d.o as upgrades are an integral part of releases. I Cc d-ctte@l.d.o for advisory feedback with experience due to earlier decisions on merged-/usr. # Status As I detailed earlier, diversions have been proving more difficult than anticipated. I spent significant time on molly-guard to get to a working mitigation and thanks to Francois and Daniel, all of the diverters of /sbin/halt and others have been updated in experimental for wider testing. This is looking promising and passing all testing that has been performed thus far. Meanwhile Chris Hofstaedler and kind folks in Cambridge worked a lot on M-A:same shared file loss (DEP17 P7) and got us down to one (reintroduced) issue. Pending further reintroductions, this aspect is done. Cool! I've since uploaded debhelper and dh_installudev will now also install to /usr. udevdir in udev.pc has been changed in a NEW upload to experimental as well and is expected to hit unstable before too long (thanks Michael and Luca). Earlier, I requested a pause of /usr merges. Since we have a better understanding and solutions that seem to be working now, I am happy for you to move stuff again more widely. For moves involving diversions in any way, consider having me review your change ahead of upload. At the time of this writing, there are 1237 source packages in unstable that still ship something aliased. This is the number we need to get down to 0 for trixie. Of these 860 involve a systemd unit and of these 761 only have systemd units aliased many of which can be converted by a no-change upload due to changed debhelper and systemd.pc behaviour. # The problem with conflicts The idea in DEP17 was to use Conflicts as a mitigation strategy in agreement with a naive reading of Debian policy. As it turns out, that doesn't exactly match reality (#1057199 debian-policy) and there are situations where files can be lost despite Conflicts having been declared. In theory, this subtlety should be irrelevant and unobservable, but aliasing (which breaks dpkg's assumptions) makes this observable. We move a file from / to /usr in $PKGA. AND one of The file is also being moved to a different package (causing DEP17 P1). OR The file is being diverted (causing DEP17 P3). AND The mitigation involves declaring a Conflict for unpack ordering (i.e. M7 for P1 or M18 for P3). AND one of The upgrade is being performed using a direct dpkg invocation without apt in a way that unpacks the package declaring the conflict before the conflicted package is removed. Example: #1058937 (Ben's libnfsidmap1 bug) OR The involved packages declare a mutual conflict (or mutual conflicts + breaks) and therefore apt invokes dpkg as in the earlier point. Example: An earlier version of the molly-guard mitigation declared versioned Breaks for systemd-sysv. This condition is complex, so let me try to break it down into something simpler. We'll have somewhere between 20 and 100 instances of P1 + P3 I guess and we aimed for mitigating most of them using Conflicts (i.e. first two conditions). The horny part is the last one. It basically says that as long as we only ever use apt and avoid mutual conflicts, the issue is not practically observable. That mutual conflict condition is delicate on its own. There are basically two ways to trigger it. The way my molly-guard patch did it was having two versioned Conflicts or Breaks declarations. I checked the archive and there is no instance of any package combination doing this. Hypothetically, another way to trigger this is unversioned Conflicts combined with a package that drops Provides in a later version (thanks David), but we haven't seen any practical instance and I haven't figured a good way to gauge this problem yet. ## Options (combinations possible) When mitigating P1, we can opt for protective diversions (M8) instead of Conflicts (M7), though that is more fragile. When mitigating P3, we can avoid the mutual conflicts. For molly-guard that has been more involved, but it seems manageable. For other packages (that do not need to access diverted files), it becomes simpler. We can restore lost files in a postinst. For this to work, we must duplicate (e.g. hard link) affected files in the data.tar. Example: #1057220 (systemd-sysv upgrade file loss) Note that this approach is not policy compliant for essential packages as they must work when unpacked and this is relevant for gzip being diverted by zutils for instance. We can introduce "barrier" packages (one or more) and have them enforce conflicting packages removed before the conflictor being unpacked (thanks Julian). We can - and this is the crux of the matter - argue that upgrading with bare dpkg is unsupported and you get to keep the pieces if you do so anyway.
Pause /usr-merge moves
Hi developers, I have unfortunate news regarding /usr-merge. I uncovered yet another problem that we haven't seen mentioned earlier. We do not yet know how to deal with it and it may take some time to come up with a good compromise. As a result, please pause further moves from / to /usr. Exceptions: * With more uploads, more systemd units will move. While such moves may trigger the new problem, I expect that to be rare. * Continue fixing RC bugs, in particular those that are due to dh_installsystemd or systemd.pc having moved to /usr. * Continue applying DEP17P7 mitigations for udev rules. Patches for these have been sent by Christian Hofstaedler and a few people from the Cambridge miniconf. These are unrelated. The rest of this mail is lots of funky details for those interested in understanding what went wrong here. Others are encouraged to do something more joyful :) Before we go, let me express sincere thanks to so many people that helped me track this down. In particular, the input of David Kalnischkies, Guillem Jover and Julian Andres Klode was invaluable. Fundamentally, Conflicts do not reliably prevent concurrent unpacking of packages as policy §7.4 may suggest. I have reported this as #1057199. Consequently, what we look at here is situations where Conflicts are used to mitigate file loss in the face of aliasing changes. Debian policy §6.6 is more precise and details that when unpacking a package, conflicting packages may be deconfigured and removed after the unpack. In theory, the difference should not be noticeable, because dpkg accurately tracks ownership of files with respect to packages. Aliasing changes this and can cause file loss. The situation arises when installing or upgrading a package to a version that happens to be in conflict with another package to be removed. A simple example is upgrading a bookworm system with molly-guard and systemd-sysv to sid and in the process deleting molly-guard. A similar issue happens when upgrading a bookworm system with busybox-static to sid and in that process installing busybox and thus removing busybox-static. The situation is hard to come by, because apt tends to remove the package that goes away early when it can. I have implemented a reproducer without apt for systemd-sysv #1057220. There are also situations where apt reproduces this available from the policy bug mentioned earlier. In particular, when one package has versioned Conflicts for another and the other has versioned Breaks for the former, this reproduces with apt. This essentially breaks DEP17 proposed mitigations M7 and M18. I have also locally extended dumat to produce a report of affected Conflicts and am attaching it to this mail. The only packages that have not yet migrated and have this problem are systemd-sysv, busybox/busybox-static and resolvconf and I have filed RC bugs for them. There are other instances in trixie already. I welcome ideas for solving these problems. Let me summarize those I already am aware of. Julian Andres Klode proposes adding a "barrier package" that we may call usrmerge-support (or repurpose usr-is-merged). Affected Conflicts can be moved to the barrier package and the conflicting package would then express Pre-Depends on the barrier package. When the barrier's postinst runs, any conflicting package definitely has been removed and due to using Pre-Depends, the conflicting package definitely has not been unpacked yet. Another option is duplicating affected files (e.g. using hard links) in the data.tar and then restoring lost files during postinst. Depending on what problem we are solving, we may also move to protective diversions (DEP17 M8). It also is not clear how easy it is to reproduce this bug class in an actual upgrade. It took long to find the issue for a reason. Depending on what files go missing, we may get away with asking users to dpkg --audit and then apt reinstall affected packages. That barrier package approach sounds relatively promising to me, but there is no implementation of that approach as of this writing. If you want to support finding a solution, please contribute to this email thread of join #debian-usrmerge on oftc. Helmut ineffective_conflicts.yaml Description: application/yaml
Bug#1053657: dhcpcd-base has ineffective Replaces due to /usr-merge and looses files in upgrade
Package: dhcpcd-base Version: 9.4.1-24~deb12u2 Severity: serious Justification: file loss during upgrade X-Debbugs-Cc: debian-release@lists.debian.org User: helm...@debian.org Usertags: dep17p1 Unfortunately, the stable update of dhcpcd5 introduced a regression relevant to upgrades from bullseye. The bullseye dhcpcd5 package contained the files - /lib/dhcpcd/dhcpcd-hooks/01-test - /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf - /lib/dhcpcd/dhcpcd-hooks/30-hostname - /lib/dhcpcd/dhcpcd-hooks/60-ntp-common.conf - /lib/dhcpcd/dhcpcd-hooks/62-chrony.conf - /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf - /lib/dhcpcd/dhcpcd-hooks/68-openntpd.conf - /lib/dhcpcd/dhcpcd-run-hooks and these have been moved into dhcpcd-base in that particular stable update. The update correctly declares Replaces for this. Unfortunately, it also moves these files from /lib to /usr/lib. Therefore, the declared Replaces have no effect (regarding these files) and as a consequence, an upgrade may delete the affected files. Fortunately, a very simple upgrade from bullseye to bookworm with only dhcpcd5 installed unpacks the new dhcpcd5 package before unpacking dhcpcd-base and therefore the issue is not trivially reproducible and probably does not affect the majority of users. We cannot rule out other upgrade scenarios though and we can also construct a breaking scenario using mmdebstrap. mmdebstrap bullseye /dev/null --variant=apt --include dhcpcd5 --chrooted-customize-hook='sed -i -e s/bullseye/bookworm/ /etc/apt/sources.list && apt update && apt-get install -y libc6 usrmerge && apt-get download dhcpcd-base && dpkg --auto-deconfigure --unpack ./dhcpcd-base_*.deb && dpkg -r dhcpcd5 && ls /usr/lib/dhcpcd/dhcpcd-hooks' If you run this, it ends with: | Selecting previously unselected package dhcpcd-base. | dpkg: considering deconfiguration of dhcpcd5, which would be broken by installation of dhcpcd-base ... | dpkg: yes, will deconfigure dhcpcd5 (broken by dhcpcd-base) | (Reading database ... 6731 files and directories currently installed.) | Preparing to unpack .../dhcpcd-base_9.4.1-24~deb12u2_amd64.deb ... | De-configuring dhcpcd5 (7.1.0-2+b1) ... | Unpacking dhcpcd-base (9.4.1-24~deb12u2) ... | Replacing files in old package dhcpcd5 (7.1.0-2+b1) ... | (Reading database ... 6752 files and directories currently installed.) | Removing dhcpcd5 (7.1.0-2+b1) ... | ls: cannot access '/usr/lib/dhcpcd/dhcpcd-hooks': No such file or directory This kind of problem has been categorized in the https://subdivi.de/~helmut/dep17.html as P1 and the recommended mitigation M7 is changing Breaks+Replaces to Conflicts. I think this mitigation is fully applicable here, because apt will by default unpack the updated dhcpcd5 package first and then the conflict is resolved. The additional constraint is satisfied by the default solution of apt. I am not sure why dhcpcd-base has moved these files from / to /usr in violation of the file move moratorium that was meant to prevent precisely this kind of bug. In any case, please do *not* move them back as that could cause further trouble. I'm sorry for not having spotted this before the point release and will now monitor stable p-u suites for similar problems to raise this earlier. Can I assume that a package sits in p-u for at least three days before migrating to a stable release? Helmut
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi Sebastian, On Tue, Sep 12, 2023 at 09:24:45AM +0200, Sebastian Ramacher wrote: > thanks for the detailed explanation. thanks for following up in detail. > On 2023-09-04 22:33:54 +0200, Helmut Grohne wrote: > Skipping all the technical details, as I would not classify this as a > transition where the release team needs to be involved. We can of course > help with the rebuilds of the affected packages, but this change does > not require us to check for outdated binary packages in testing or to > make sure that everything migrates together. It certainly is not a usual transition and also will not migrate together. In that sense, I agree. Yet, I think this is something that the release team wants to know is going on and consider how it interacts with other transitions (e.g. time64). In essence, I think we agree. :) > For the systemd change, the following steps should be enough in general: > > 1. debhelper with support for service files in /usr migrates to testing. done > 2. Rebuild packages which currently have their service files. A guinea pig package "location" has been uploaded with support from Jochen. I don't have numbers on the number of packages that manually install to /lib, but it is many. So this will likely require collective effort rather than me sending patches. > 3. debhelper installing service files to /usr per default migrates to testing. I'm unsure when to do this as I see a moderate risk here. The dumat report currently looks promising, but we also might run into a stream of RC bugs. > 4. Rebuild all packages with service files. I note that the deadline for this practically is trixie and that this doesn't really block any other part of the transition. > For packages where these steps are not enough, bugs are filed along > while preparing 1. and 3. This will include all packages which include > service files in Arch: all packages as we cannot binNMU them. > > Depending on the number of packages in step 4., this would ideally not > be done during the time_t transition to avoid any surprises. I'd hope half of the packages that could be binNMUed have a maintainer upload in the relevant time frame. That also has the benefit of spreading any bad effects over time rather than breaking the archive at once. Regarding the time64 transition, I expect bad interaction. Essentially, time64 will restructure a large amount of packages (moving files from one binary package to another retaining the name on 64bit architectures and thus employing Replaces). As we combine this with mass-moving files from / to /usr, we get exactly that DEP17-P1 scenario that the moratorium was meant to prevent. This interaction is not avoidable by clever timing, because it affects upgrades from bookworm to trixie. I've talked to Steve already to make him aware. The current plan is to just handle this on an individual level and applying the proposed mitigations to issues detected by dumat. > The other / to /usr file moves will need uploads anyway. So we cannot > help here (except for monitoring the status of the bugs during the > freeze). Regarding the move on d-i's side, please coordinate this change > with Cyril. From your explanation it is however not clear to me whether > we are blocked on finishing the /usr-merge change in the main archive by > d-i or not. Let me clarify that in filing this transition bug, my intention was not to get assistance from the release team, but making you aware of what is going on and giving you a reasonable chance to object. The d-i part is rather critical from my point of view. Since d-i still is unmerged, moving files from / to /usr in udebs is likely to break d-i. This explicitly does not cover systemd units though when systemd drops support for split-/usr (next release), d-i will likely be broken anyway. So until d-i is fixed, the remaining moratorium should cover at least all source packages that build udebs. Some of this may be overly cautious, but I'd rather be cautious than temporarily break the archive and that way cause lots of work to unsuspecting developers. Developer time is a scarce resource and some of what we're up to has a risk of consuming lots of that. In any case, I take that at least Paul and Sebastian do not veto moving forward with this. Cyril will probably take some time, but will unlikely comment non-udeb aspects. No clue about Graham. I therefore intend to slowly move forward with the actual conversion in a way that causes least possible disruption and will keep you updated when I expect non-trivial disruption. Helmut
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Dear release team, you may be aware from d-devel@l.d.o discussions that things got rolling regarding a way forward from our current /usr-merge state. The results of various discussions have been recorded in DEP17[1]. The rough idea is that files in all packages move from / to /usr. I think this change qualifies as a transition and should be coordinated with you. If you disagree with this and do not want to get involved, please just close this transition request. A major blocker regarding this finalization is the file move moratorium. I note that this is given as advice/recommendation rather than being mandatory (thanks Ansgar). However, the release team also indicated enforcement[2] of it. The current best idea is to progressively lift the moratorium by documenting the current state of lifting at https://wiki.debian.org/UsrMerge (not yet documented there) and then officially repealing the moratorium while recommending to follow those guides. As we move files, we will run into issues such as lost files. Some of the issues are automatically identified by the Debian Usr Merge Analysis Tool https://salsa.debian.org/helmutg/dumat. I'm regularly updating the output https://subdivi.de/~helmut/dumat.yaml. The intention is to automatically file RC bugs for some classes of issues (e.g file conflicts), but at the time of this writing I'm still filing bugs manually. The exact way of lifting the moratorium is not clear at this time. It shall be adapted depending on the amount of (expected and unexpected) issues we face. In total, there are around 2000 affected binary packages. More than half of them is only affected due to installing systemd units. As such moving those units from / to /usr is the first step. We first move those where upstream build systems install them and debhelper is prepared to recognize units below /usr. Once that works reasonably well, dh_installsystemd shall be changed to install to /usr. This change will cause latent issues. When packages are restructured or renamed the famous file loss scenario may happen. The dumat service shall run for the entire release period and detect such issues before they hit testing. Moving beyond this step requires more preparation. While systemd still deals nicely with users in / or /usr, other tools may not and our buildds are still unmerged. We'll have to wait until DSA has updated debootstrap to SPU request from Simon McVittie. Also moving files may affect udebs and the debian-installer is still unmerged. The relevant MR addressing this needs to be merged. Once these issues have been resolved, we can move most files except for a small set of essential packages. For those, a coordinated upload moving their files will be needed as will be an upload of base-files adding the aliasing symlinks there. We probably have to use NMUs to convert remaining packages at this point. Once everything is moved, we may think we're done, but we're not. As packages are restructured throughout the release cycle, they may introduce file loss scenarios. Continued monitoring for problems until trixie is released is crucial. As problems are located, context-dependent mitigations from DEP17 are to be applied. We'll recommend that maintainers upload restructuring changes to experimental first and given quick bug filing that should reduce the number of issues in unstable and keep most issues out of testing. In any case, you can only call this transition bug finished once trixie is released. For the purpose of keeping bugs out of testing, I intend to file all relevant bugs (such as file conflicts, file loss, directory loss, ineffective diversions, missing trigger invocations, etc.) at RC severity. I hope this all makes sense to you. Let me know if you disagree about any of this. Quite probably I am missing some important aspects here. Unless there is disagreement, I intend to move forward with moving systemd units on the grounds that the moratorium only is a recommendation and this transition request. Helmut [1] https://salsa.debian.org/dep-team/deps/-/merge_requests/5 rendered version at https://subdivi.de/~helmut/dep17.html [2] https://lists.debian.org/debian-devel-announce/2022/07/msg2.html
Re: How important are empty directories?
Hi Paul,
thanks for taking the time to respond.
On Tue, Aug 29, 2023 at 08:09:24PM +0200, Paul Gevers wrote:
> > In the majority of cases, such empty directories are more of a bug than
> > a feature and we can simply delete them. In some cases, they really are
> > used though.
>
> Can you elaborate? My imagination might be limited, but all I could come up
> with is that maintainer scripts expect a directory to be there and try to
> write to it without checking (is that also the case for the issue that you
> referred to in [1] mentioned by Jochen?). I *think* that if a package needs
> the directory to installs a file into, the directory will be created (or
> will dpkg fail as it assumes the directory already exists)?
I'm not sure I understand openrc yet. It installs /lib/rc/tmp and I
hunted this for like half an hour. I guess that it uses this as a
temporary mount point for performing a pivot_root. If that is correct,
its absence makes the system unbootable.
For systemd we actually found that some cryptsetup-related autopkgtest
was failing as systemd dropped one of the empty directories. That test
has since been adapted.
So yeah, this can fail. Subtly.
> > When they are used, we need to do something about that
> > deletion and I've submitted e.g.
> > https://salsa.debian.org/systemd-team/systemd/-/merge_requests/208 where
> > I got negative feedback on the need to address this.
>
> Which has been fixed nevertheless.
By deleting all empty directories.
> I agree that *only* pleasing piuparts is not the best time spent by
> maintainers, *if* that's really the only problem we're solving. I guess
> we're having a hard time with this check to find a real life problem. I
> *think* that https://bugs.debian.org/1050606 (linked from that MR) points at
> an example of this problem, right? So that's at least one.
The problem with not pleasing piuparts is that this can break testing
migration of *other* packages. So I think we have to do something.
Patching piuparts is a possible way forward, but that is not without
cost either. Possibly, pleasing piuparts poses a lower cost.
> If everybody agrees that the only place where this causes real life issues
> is piuparts, than I rather have piuparts ignore this problem. After we're
> fully canonized, are we safe again and could we turn the check on again?
> Looking at that example bug above though, I'm not sure we can only see this
> class of problems in piuparts.
Yes, once we're done we can turn the check back on.
> > On the flip side, systemd has been the last package for me to file a
> > patch where this issue has practical consequences already. All others
> > have been filed already. Beyond these, there are five more cases on the
> > horizon that likely need to be mitigated when we lift the moratorium.
>
> With patches ready?
Those five ones don't have patches yet. I started looking and at least
firmware-b43-installer is a non-issue, because its postinst has
mkdir -p "${FIRMWARE_INSTALL_DIR}/${B43}"
which is the empty directory in question, so it already is mitigated. I
guess firmware-b43legacy-installer is similar. printer-driver-foo2zjs is
likely affected for real, but a simple mkdir in its maintainer script
(without the trigger mess) can save it as no other package contains
/lib/firmware/hp. Other than openrc, there is netplan-generator which
likely isn't worse than pkgconf-bin. In any case, I think you may assume
that patches appear in time.
> > So while the mitigation is ugly, the low number of affected packages and
> > the temporary nature of the mitigation made me conclude that doing this
> > is a reasonable trade-off. Do you agree?
> >
> > Another example for the ugliness is #1050412.
>
> Will the next time that pkgconf-bin is installed (reinstall or upgrade)
> recreate the directory again (without your patch)? Or will the directory be
> lost forever?
When the cause for loosing a directory has been resolved (i.e. no
package installs files into the corresponding aliased location), any
reinstall or upgrade of the affected package will restore empty
directories. So the problem is self-healing over time.
> I'm not totally sure you got the answer to the question you raised, but I'm
> also not totally sure what you wanted to hear.
Not the answers I wanted, but still moving forward. I think we either
need a volunteer for patching piuparts or bump these issues to RC later.
That is bumping pcp, libswe-dev and pkgconf-bin and figuring those other
five (see above). I think that creating the patches is less work than
producing a piuparts patch, but that only matters if you don't want to
hack piuparts yourself.
Helmut
How important are empty directories?
Hi release team, as part of finishing the /usr-merge, I've written down the most important bits at https://subdivi.de/~helmut/dep17.html. In this mail, I'm concerned with P6, i.e. loss of empty directories. The general scenario is that one package ships an empty directory and another package also ships that directory (empty or not) with different aliasing (e.g. one package has an empty /usr/lib/foo and the other has /lib/foo). When removing (or upgrading) the other package, the empty directory may be deleted causing an inconsistency between the dpkg database and the filesystem. This inconsistency is detected e.g. by piuparts, which may fail. This is how Andreas Beckmann originally discovered this problem class. As a result, I've started filing patches for this problem class. https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helmutg%40debian.org=dep17p6 In the majority of cases, such empty directories are more of a bug than a feature and we can simply delete them. In some cases, they really are used though. When they are used, we need to do something about that deletion and I've submitted e.g. https://salsa.debian.org/systemd-team/systemd/-/merge_requests/208 where I got negative feedback on the need to address this. So how important is it to have these empty directories? I concur with Michael on the aspect that their loss rarely poses a practical issue. It can make piuparts fail however and when it does, the failing package tends to not be the one that is able to fix the failure. So in effect, keeping these bugs would cause latent migration blockers. For this reason, I was assuming the bug class to be release critical. Do you concur? If we want it to not be release critical, I think we'd have to augment piuparts in a way that it ignores such directory loss. On the flip side, systemd has been the last package for me to file a patch where this issue has practical consequences already. All others have been filed already. Beyond these, there are five more cases on the horizon that likely need to be mitigated when we lift the moratorium. So while the mitigation is ugly, the low number of affected packages and the temporary nature of the mitigation made me conclude that doing this is a reasonable trade-off. Do you agree? Another example for the ugliness is #1050412. Helmut
Bug#1050334: bookworm-pu: package reprepro/5.3.1-1+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: repre...@packages.debian.org, b...@debian.org Control: affects -1 + src:reprepro reprepro uses internal decompressors for most compression formats except zstd. When dealing with zstd compressed .debs (such as those for Ubuntu), decompression may fail due to a race condition. Naturally, this bug originally surfaced in Ubuntu as https://bugs.launchpad.net/ubuntu/+source/reprepro/+bug/2008508. While originally, it seemed only reproducible on s390x, it turned out that if you generate Contents indices, it is more widely reproducible. I can reliably reproduce it on Freexian infrastructure and filed #1050321. [ Reason ] The condition for reproducing the issue seem sufficiently common: * Interact with zstd-compressed .debs * Enable Contents indices [ Impact ] Once a zstd compressed .deb is included, most interactions leave messages such as the following and Contents indices are incomplete. zstd: /*stdout*\: Broken pipe reading data.tar within './pool/main/p/php7.0/php7.0_7.0.33-67+freexian22.04.1+php+1_all.deb' failed: /usr/bin/unzstd exited with code 1 [ Tests ] Simon Chopin, who originally fixed the bug in Ubuntu, was only able to reproduce it with a wrapper to unzstd. By enabling Contents indices, I was able to reproduce it reliably on amd64 both in bookworm and unstable. Once updating to experimental (where the Simon's MR is merged), the issue went away. I've also deployed the proposed update to the affected Freexian server and the issue is gone there as well. [ Risks ] When not dealing with zstd-compressed .debs, the patched code paths are not exercised. Therefore, there only really is any risk for people interacting with zstd-compressed .debs. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [ ] the issue is verified as fixed in unstable -> The issue is only fixed in experimental as of this writing, but the maintainer intends to upload to unstable and Ubuntu uses a very similar backport. [ Changes ] I think Simon Chopin does a much better job in is git commit message than I could do here. The message is included in the .debdiff [ Other info ] The maintainer agreed to me doing the SPU. Thanks for considering Helmut diff --minimal -Nru reprepro-5.3.1/debian/changelog reprepro-5.3.1/debian/changelog --- reprepro-5.3.1/debian/changelog 2022-07-19 19:00:04.0 +0200 +++ reprepro-5.3.1/debian/changelog 2023-08-23 12:33:31.0 +0200 @@ -1,3 +1,14 @@ +reprepro (5.3.1-1+deb12u1) bookworm; urgency=medium + + * Upload to stable with ack from maintainer. + + [ Simon Chopin ] + * d/p/0001-uncompress-wait-until-the-child-as-exited-to-close-t.patch: +Fix a race condition when using external decompressors +(Closes: #1050321, LP: #2008508) + + -- Helmut Grohne Wed, 23 Aug 2023 12:33:31 +0200 + reprepro (5.3.1-1) unstable; urgency=medium * Update debhelper-compat to level 12 diff --minimal -Nru reprepro-5.3.1/debian/patches/0001-uncompress-wait-until-the-child-as-exited-to-close-t.patch reprepro-5.3.1/debian/patches/0001-uncompress-wait-until-the-child-as-exited-to-close-t.patch --- reprepro-5.3.1/debian/patches/0001-uncompress-wait-until-the-child-as-exited-to-close-t.patch 1970-01-01 01:00:00.0 +0100 +++ reprepro-5.3.1/debian/patches/0001-uncompress-wait-until-the-child-as-exited-to-close-t.patch 2023-08-23 12:33:05.0 +0200 @@ -0,0 +1,149 @@ +From 1b5a3c557b1ae842ee95b6a7e333046e56632559 Mon Sep 17 00:00:00 2001 +From: Simon Chopin +Date: Wed, 1 Mar 2023 17:53:28 +0100 +Subject: [PATCH] uncompress: wait until the child as exited to close the pipe + +Since we sometimes interrupt the decompression mid-stream as we're only +looking for specific data, e.g. the control file in control.tar.zstd, it +can happen that the child process still has a backlog of data to write +out to the pipes before exiting. If we close its stdout pipe before +calling waitpid(), it's going to encounter an EPIPE rather than +gracefully exit. + +The fix is to only close the pipe fd after waitpid() successfully exits. + +However, that introduces a new theoretical issue: the child process could +be blocking while writing into its stdout if the pipe is full, thus +leading to a deadlock. To avoid this, we have to drain the pipe before +waiting. Technically this should probably be done in a loop, but since +it's fairly unlikely to be blocked on stdout in the first place, having +enough pending data to fill the pipe *twice* seems too rare to bother +with in the first place. + +The initial problem has first been noticed in Ubuntu autopkgtests on +s390x when upgrading to libarchive 3.6.2, where unzstd would loudly +complain about an -EPIPE (Ubuntu is using zstd as its defa
Should bookworm release notes recommend migrating to pipewire
Hi, I recently upgraded one of my non-gnome systems and noticed that it still was using pulseaudio rather than pipewire. To me, this was unexpected, but I've since learned that only gnome installations migrate to pipewire by default when upgrading to bookworm. I had a brief exchange with Simon. It seems that pulseaudio is on life support and pipewire is where things happen. I guess that before too long, people will not like to support pulseaudio anymore and ask users to migrate to pipewire. Any kind of wayland session should prefer pipewire to enable screen sharing. As anecdotal evidence, I've personally migrated most systems from pulseaudio to pipewire and it was a "it just works" kind of experience. Great work. On the flip side, Simon notes that pipewire is still in its 0.x phase of rapid change. There also seems to be anecdotal evidence that some setups don't just work on pipewire while they do work with pulseaudio. I think that this situation is something we can reasonably mention in release-notes: * There is a long transition from pulseaudio to pipewire ongoing and in the bookworm release, users can choose with ease. * If using gnome, we expect upgrades to automatically migrate to pipewire. * One can switch from one to the other by installing the packages pulseaudio and pipewire-audio respectively. * Optionally: We recommend migrating to pipewire in bookworm. Do the pulseaudio and pipewire maintainers agree with all of this? Also with the migration recommendation? Helmut
Re: Bug#1036705: override: adduser:admin/required
On Wed, May 24, 2023 at 06:54:01PM +0200, Cyril Brulebois wrote: > Watching from the sideline, this seems to come in horribly late. How am I not to agree with this? > > apt used to depend on adduser and apt is required, so adduser is > > transitively required in bullseye. Johannes and myself worked towards > > making apt not depend on adduser and that work succeeded. > > FSVO “success” then, given the rest of the mail… I'm really sorry about this. None of us saw the deluser breakage coming. After all, we were "just" killing a dependency. We should have noticed that it was the last and thus possibly having bad effects, yes. We did not. When I caught one of Andreas' bug reports about this, I immediately informed the release team to not loose any further time. It was already horribly late back then. :-( > Via olasd/#debian-release: adduser got that field, not apt. Thanks. > Same question as before, why not just add the dependency back? That dependency is conceptually wrong now. apt does not need adduser anymore. I think the initial idea was to add it back, but Julian rightly pushed back on this. A major technical goal was to push adduser out of the essential+apt package set (which hints that we should have paid more attention, sorry). Adding this dependency breaks that goal while adding protected or required does not, so we'd actually get what we wanted. > Aren't we risking a redux of “we turned another knob, and now we're > discovering yet another issue”? It is very difficult to disagree with this one given that I thought "Protected: yes" to be harmless earlier. > But I'm very much worried about possible side effects at this critical > stage of the freeze. I will not stand in the way of turning this back and adding the dependency back to apt. It seemed to me though that this was not the preferred solution and that a (FSVO) better solution was available. In theory, "Protected: yes" should solve the issue for purging. It just happens that piuparts does deal well with this, so the remaining issue is one of having broken a QA tool rather than having broken something for real. I can try talking to Nicolas about possibilites of adapting piuparts instead. Helmut
Bug#1036705: override: adduser:admin/required
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: override X-Debbugs-Cc: addu...@packages.debian.org, debian-b...@lists.debian.org, debian-release@lists.debian.org, jo...@debian.org, de...@lists.debian.org, piuparts-de...@alioth-lists.debian.net Control: affects -1 + src:adduser Hi, I am requesting to override the priority of adduser to become required. Rationale apt used to depend on adduser and apt is required, so adduser is transitively required in bullseye. Johannes and myself worked towards making apt not depend on adduser and that work succeeded. Unfortunately, that also removed adduser from the transitively required set and now debootstrap --variant=minbase no longer contains adduser while it earlier did. In the mean time, packages started using deluser for postrm purge, so they effectively assume that it was essential, which it isn't. We've now fixed such postrm scripts to no longer do that, but we agreed with the release team that it should be difficult to remove for bookworm in order to make purging packages left over from bullseye just work after and upgrade to bookworm. Originally, the idea was to add back the dependency from apt. Instead, we made apt "Protected: yes". This still doesn't install it by default, but makes removal difficult which is what saves postrm purge scripts, so all should be good. Except that this makes piuparts unhappy as it tries to remove adduser and apt being unhappy about it. This is presently breaking testing migration for a number of packages. So now we thought about it again and got to the conclusion that adduser should also be Priority: required for bookworm (and unstable until bookworm is released). Doing so is a late change, I know. However, it gets us back to the bullseye state and in being required, debootstrap --variant=minbase will install adduser again, which will fix piuparts. So an we do that? Helmut
Re: non-essential adduser poses problems to purging packages
Hi Marc, On Wed, May 17, 2023 at 11:51:25AM +0200, Marc Haber wrote: > Can somebody in the audience please take a look at the piuparts failure > on salsa (https://salsa.debian.org/debian/adduser/-/jobs/4223693) and > confirm that this might be a failure that is caused either by the > pipeline/job being broken and/or the issue we're discussing here? The failure here arises from piuparts trying to remove adduser and apt refusing to do so. This confirms that our change is working as intended, but it also makes the pipeline fail. I looked into the bullseye run on piuparts.d.o for comparison and see that it does not attempt removing adduser there. I suspect that adduser comes preinstalled there and thus isn't removed. It no longer is preinstalled. Very likely, we need a change to piuparts here to eliminiate the removal test, because we're in the unusual situation where we don't want to install adduser unconditionally, but once installed it shall be difficult to remove, because doing so may break the postrm purge script of some package that once pulled adduser. Added piuparts-de...@alioth-lists.debian.net to Cc for help. Helmut
Re: non-essential adduser poses problems to purging packages
On Sun, May 07, 2023 at 08:16:14PM +0200, Julian Andres Klode wrote: > I don't have a problem pushing a 2.6.1 out with this in the coming days. Is > this the best solution though - maybe setting Essential on adduser might be > easier and formally fix the issue for now. I was also thinking that maybe it really should be essential for now. > We generally do not expect stuff to depend on apt. This seems to be a gap > in piuparts, that it has apt installed while testing packages. Even if we made apt depend on adduser again, packages would still fail purging if you removed apt and adduser beforehand. Julian also pointed out another advantage on IRC: By using the Essential flag, we can forcefully remove adduser while keeping apt. This option is unavailable given a dependency. By making it essential, we recognize the status quo and document it. We can the proceed with retrying adduser removal in a more structured way. I'm sorry for having messed up this transition. I failed to see it coming. Helmut
Re: non-essential adduser poses problems to purging packages
Control: tags -1 + bookworm Hi Sebastian, On Sun, May 07, 2023 at 10:49:40AM +0200, Sebastian Ramacher wrote: > > Even if we fix these bugs in the packages, people may still upgrade > > their systems and remove them rather than upgrading. Then, once the > > upgrade is finished (and adduser is removed), they may consider purging > > them and boom things go bad without any way of us fixing those packages. > > > > So fixing these bugs (and probably not removing users in purge) is the > > way to go, but this also raises the question of whether we want to limit > > the possible damage in trixie by making adduser temporarily essential > > for trixie. What do you think? > > I suppose you meant s/trixie/bookworm/. We are very late in the release > cycle, so dear apt maintainers, please re-instante the dependency on > adduser for bookworm. Once bookworm is released, removing adduser from > the pseudo-essential set can be revisited. I did. Thanks for correcting. > With such a change I would have expected upgrade/piuparts tests from > bullseye to bookworm that tried to remove adduser a various stages and > check for the fallout. Given that Andreas is only doing them now, that's > too late for changes to the pseudo-essential set. I contend that: 1. This change is in unstable since 2022-10-31, i.e. more than half a year. 2. While having adduser drop from the essential+apt set is caused by apt dropping it, this was an implementation detail and any package using adduser without a dependency was (invisibly) buggy before. So I don't quite buy the reasoning of "too late" or it being apt's fault. On the flip side, I think it would technically have been the responsibility of the proponents of dropping adduser to do the testing. The proponents have been Josch and my self and we ultimately failed to do so. Thanks to Andreas for doing it for us. In any case, I agree that this is a release team judgement call, so convincing arguments are less of a concern. Helmut
Bug#1034428: unblock: vmdb2/0.27-1
On Fri, May 05, 2023 at 07:00:16PM +0200, Cyril Brulebois wrote: > Gunnar Wolf (2023-04-14): > > vmdb2 is a leaf package. The code changes are quite minor. While there > > are several alternatives to vmdb2 in Debian, switching from one image > > generating system to another might be quite heavy for the users. > > Spotted by Helmut (cc-ed): that's not true (in either stable or unstable), > since autopkgtest depends on it… and it seems that update would break it. To be precise, Helmut Grohne rather than Helmut Geyer. ;) > I'll let Helmut expand, and possibly formulate a plan. autopkgtest-build-qemu uses vmdb2. In particular, when you pass a non-native architecture, it uses vmdb2 with qemu-debootstrap. You can trigger that using i386 on amd64 already. So you definitely need to declare Breaks for the current version of autopkgtest in bookworm and unstable until it is fixed to not use qemu-debootstrap. Also sbuild-qemu is a direct reverse dependency of vmdb2. I haven't looked deep there. I think both should be tested before proceeding here and autopkgtest definitely needs an upload to make it work. So much for a leaf package... There is a reason for why the release team tends to say "no": Experience. Helmut
non-essential adduser poses problems to purging packages
Hi release team, Andreas Beckmann does wonderful QA work and recently figured that some packages use deluser during purge (e.g. #1035494 and #1035495). deluser is shipped with adduser and adduser used to be practically essential, becaue apt used to depend on it, but that dependency was removed on my request. Now apt never was essential to begin with, but having a Debian installation without apt is a relatively rare thing. So while this was theoretically buggy at all times, it is now practically observable. Even if we fix these bugs in the packages, people may still upgrade their systems and remove them rather than upgrading. Then, once the upgrade is finished (and adduser is removed), they may consider purging them and boom things go bad without any way of us fixing those packages. So fixing these bugs (and probably not removing users in purge) is the way to go, but this also raises the question of whether we want to limit the possible damage in trixie by making adduser temporarily essential for trixie. What do you think? Of course, I really like small essential and want it gone, but we need to balance that with possible breakage. I think this primarily is a decision that belongs to the release managers with the default choice being "do nothing about it". Helmut
Re: dash: remove unnecessary diversion of /bin/sh
Hi, On Mon, May 01, 2023 at 12:07:52AM +0100, Luca Boccassi wrote: > On Sat, 29 Apr 2023 16:32:23 +0100 Luca Boccassi > wrote: > > > > MR: https://salsa.debian.org/debian/dash/-/merge_requests/19 > > > > I think we should ship these changes in bookworm. Why? > > > > - we get diversion-less essential package set already in bookworm > > - we get diversion-less uber-essential dash already in bookworm > > - we get maintainer-script free uber-essential dash in trixie > > - in case we need to go down the canonicalization-by-dh forced > > migration path in trixie to lift the moratorium on moving files, we > > don't have /bin/sh diversions as a blocker and the path remains open > > > > Yes, I realize it is late, and I wish I had come across this ticket > > some months ago. But we still have time, and the benefits are great > :-) > > Alright, this is now in experimental (thanks Andrej), please help with > testing if you can! Let me record this in email: * I am the primary author of these changes and still think we should perform them at a convenient time. * As far as I understand it, the main motivation from Luca is improving the /usr-merge transition. * Given that dash is one of the rare cases diverting files from itself rather than from other packages, I think that the benefit to the /usr-merge transition of doing this before bookworm is minor. Removing other kinds of unnecessary diversions would be more useful to the transition. * I think these changes are not in line with the freeze policy. * For these reasons, I recommend not trying to ship them in bookworm (despite removing unnecessary diversions being a good thing in general). * Breakage can happen in unexpected places (e.g. DPKG_ROOT, which is the origin of my work on this). * If you proceed in bookworm anyway, I expect you to own any kind of breakage that results from this (including DPKG_ROOT breakage). And with this, I'll leave it up to you until bookworm is released. Helmut
Re: librust---dev: missing Breaks+Replaces for librust-mio-dev when upgrading from bullseye
Hi Peter, On Fri, Apr 28, 2023 at 01:24:16AM +0100, Peter Green wrote: > Summarising a number of bug reports by Helmut Ghrone: > > > Please ensure that librust---dev has sufficient Breaks and > > Replaces declarations. > > The issue specifically appears to be that the breaks+replaces are declared > against a virtual package, it seems dpkg is honoring the breaks against the > virtual package but not the replaces. So it correctly marks the package from > stable as broken, but fails to actually unpack the package from testing. Thanks for looking into this so quickly. I concur: The Breaks are ok, but the Replaces are not. Debian policy section 7.6.1 explicitly says that Replaces don't work on virtual packages. > Declaring against the physical package is also problematic becase Debian > package > relationships don't support version ranges. What this would likely mean in > practice is it would be possible to co-install the "current" semver alongside > one previous semver, but it would not be possible to co-install two different > previous semvers. Can you go into more detail as to what you mean with "don't support version ranges"? In principle, you could declare the Replacs to be slightly broader than necessary (i.e. instead of declaring against the specific range, you can replace all old packages). Do you agree that this is feasible? > Another option may be to use "Conflicts" instead of "Breaks". This should > force > the old package to be upgraded or removed before the semver-specific package > can be unpacked. It's a big hammer. It'll work. It's a hammer we're looking into as part of the DEP 17 thread on debian-de...@lists.debian.org currently, but I recommend avoiding it if possible. Possible it seems in this case. > I feel the timing of these bugs is very unfortunate. I don't object to > people running QA checks, but it's generally easier to deal with bugs if > they are reported earlier in the freeze process. The timing of these bugs > leaves little time for discussion if we are to get the fixes in before the > full freeze. I am sorry about that. This is a side-effect of earlier discussions having stalled and only recently been picked up. However, these tests should likely be running more continuously. > As I see it we have a few options to deal with this for bookworm. > > 1. Make debcargo Use Conflicts instead of Breaks. > 2. Make debcargo declare Breaks/Replaces against the physical package >version using a << dependency. This will allow the non-semver suffixed >package to be installed alongside one semver-suffixed package, but with >our current virtual packages scheme would not allow two semver-suffixed >packages of the same crate to be coinstalled. > 3. Add manual breaks/replaces for the versions in bullseye, this will >paper over the issue for bullseye-bookworm upgrades, but is not a long >term fix. 4. Continue to use Breaks the way they are. Declare Replaces against the physical package using a << relation. This would not allow the semver-suffixed package to be installed alongside, but Breaks and Replaces would no longer match up and that could make lintian unhappy. 5. In a different bug, Samuel Thibault observed that the target package was not part of bullseye. As such, an upgrade scenario involving it was unlikely. All of the 6 affected librus-*-dev packages are not part of bullseye. We could argue that the risk of these effects showing up in practice is not big enough to warrant an invasive fix. Rather, we'd downgrade them to important (and upgrade to serious when we see them in the wild) and close them after bookworm (since we don't support skip upgrades). > Do any other members of the rust team have an opinion on this? I'm > personally inclined towards option 1 and intend to implement it if > noone objects in the next couple of days. Let me know if you see 4 as a viable option. > Do the release team have an opinion on this? It looks like only one of > the packages involved (rust-env-logger-0.7) is a key package. I filed these as serious, because these are policy violations with a trivial fix. You made it quite clear that the premise of the fix being trivial is false here. If the cure is worse than the symptoms, maybe we should consider not applying the cure and select option 5. Helmut
Bug#1034510: bullseye-pu: package protobuf/3.12.4-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: proto...@packages.debian.org, g...@debian.org,
debian-secur...@lists.debian.org
Control: affects -1 + src:protobuf
[ Reason ]
This update aims to fix three vulnerabilities in the protobuf package:
* Fix CVE-2021-22569 (DoS in Java)
* Fix CVE-2021-22570 (NULL pointer dereference)
* Fix CVE-2022-1941 (memory DoS)
[ Impact ]
Ideally, a user wouldn't notice anything changed.
[ Tests ]
Testing was accidentally disabled in bullseye. See #1033989. This upload
re-enables testing. The patch for CVE-2022-1941 extends the test suite.
[ Risks ]
All of the patches deviate significantly from their respective upstream
commits. In case of CVE-2021-22569 and CVE-2022-1941, significant
porting was required. In case of CVE-2021-22570, the relevant change was
buried in a large commit. There definitely is a risk involved here. I do
appreciate a review of these patches.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Beyond fixing the vulnerabilities (see Reason section), this upload also
re-enables running tests during build.
Helmut
diff --minimal -Nru protobuf-3.12.4/debian/changelog
protobuf-3.12.4/debian/changelog
--- protobuf-3.12.4/debian/changelog2021-01-16 23:12:54.0 +0100
+++ protobuf-3.12.4/debian/changelog2023-04-04 11:41:41.0 +0200
@@ -1,3 +1,13 @@
+protobuf (3.12.4-1+deb11u1) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * Reenable test suite (Closes: #1033989)
+ * Fix CVE-2021-22569 (DoS in Java)
+ * Fix CVE-2021-22570 (NULL pointer dereference)
+ * Fix CVE-2022-1941 (memory DoS)
+
+ -- Helmut Grohne Tue, 04 Apr 2023 11:41:41 +0200
+
protobuf (3.12.4-1) unstable; urgency=medium
* New upstream release.
diff --minimal -Nru protobuf-3.12.4/debian/elpa-test
protobuf-3.12.4/debian/elpa-test
--- protobuf-3.12.4/debian/elpa-test1970-01-01 01:00:00.0 +0100
+++ protobuf-3.12.4/debian/elpa-test2023-04-04 11:41:41.0 +0200
@@ -0,0 +1 @@
+disable=please_run_dh_auto_test
diff --minimal -Nru protobuf-3.12.4/debian/patches/CVE-2021-22569.patch
protobuf-3.12.4/debian/patches/CVE-2021-22569.patch
--- protobuf-3.12.4/debian/patches/CVE-2021-22569.patch 1970-01-01
01:00:00.0 +0100
+++ protobuf-3.12.4/debian/patches/CVE-2021-22569.patch 2023-04-04
11:41:41.0 +0200
@@ -0,0 +1,482 @@
+From 9638a5e5315bf73f5e7148c16181676372321892 Mon Sep 17 00:00:00 2001
+From: Adam Cozzette
+Date: Wed, 5 Jan 2022 08:50:29 -0800
+Subject: [PATCH] Improve performance of parsing unknown fields in Java (#9371)
+
+Credit should go to @elharo for most of these Java changes--I am just
+cherry-picking them from our internal codebase. The one thing I did
+change was to give the UTF-8 validation tests their own Bazel test
+target. This makes it possible to give the other tests a shorter
+timeout, which is important for UnknownFieldSetPerformanceTest in
+particular.
+---
+ Makefile.am | 1 +
+ java/core/BUILD | 24 +-
+ .../com/google/protobuf/UnknownFieldSet.java | 427 +-
+ .../UnknownFieldSetPerformanceTest.java | 78
+ .../google/protobuf/UnknownFieldSetTest.java | 182 +++-
+ java/lite/pom.xml | 1 +
+ 6 files changed, 499 insertions(+), 214 deletions(-)
+ create mode 100644
java/core/src/test/java/com/google/protobuf/UnknownFieldSetPerformanceTest.java
+
+Backport:
+ * Drop bazel BUILD file changes as Debian builds using ant
+ * Drop test cases as Debian does not run them
+ * Drop unnecessary de-finalization
+ * Drop unnecessary diamonds conversion
+
+diff --git a/java/core/src/main/java/com/google/protobuf/UnknownFieldSet.java
b/java/core/src/main/java/com/google/protobuf/UnknownFieldSet.java
+index ba2f9df08..5c482d62d 100644
+--- a/java/core/src/main/java/com/google/protobuf/UnknownFieldSet.java
b/java/core/src/main/java/com/google/protobuf/UnknownFieldSet.java
+@@ -43,13 +43,13 @@ import java.util.Map;
+ import java.util.TreeMap;
+
+ /**
+- * {@code UnknownFieldSet} is used to keep track of fields which were seen
when parsing a protocol
++ * {@code UnknownFieldSet} keeps track of fields which were seen when parsing
a protocol
+ * message but whose field numbers or types are unrecognized. This most
frequently occurs when new
+ * fields are added to a message type and then messages containing those
fields are read by old
+ * software that was compiled before the new types were added.
+ *
+ * Every {@link Message} contains an {@code UnknownFieldSet} (and every
{@link Message.Builder}
+- * contains an {@link Builder}).
++ * contains a {@link Builder}).
+ *
+ * Most users will never need to use
Bug#1033578: bullseye-pu: package joblib/0.17.0-4+deb11u1
Package: release.debian.org
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: job...@packages.debian.org, Chiara Marmo
, Graham Inggs
Control: affects -1 + src:joblib
[ Reason ]
Fix no-dsa security vulnerability CVE-2022-21797.
[ Impact ]
The n_jobs parameter of the parallel_backend, which used to be a string
containing a Python expression, becomes restricted to fairly basic
arithmetic expressions. Using it in another way was not intended.
[ Tests ]
Upstream test suite is extended and run during build.
[ Risks ]
Someone may have used n_jobs in ways not intended by upstream.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
I cherry-picked the relevant upstream commit and updated the hunk
context.
[ Other info ]
The security team tagged this vulnerability no-dsa.
Upstream had multiple attempts at fixing this and buster includes a
vulnerable patch. This cherry-pick skips the vulnerable patch and goes
to the real fix directly.
I am not interested in refining the updated (unless it also affects
buster). This is a drive-by contribution as part of an LTS upload.
Helmut
diff --minimal -Nru joblib-0.17.0/debian/changelog
joblib-0.17.0/debian/changelog
--- joblib-0.17.0/debian/changelog 2021-06-12 10:19:09.0 +0200
+++ joblib-0.17.0/debian/changelog 2023-03-27 15:25:19.0 +0200
@@ -1,3 +1,10 @@
+joblib (0.17.0-4+deb11u1) bullseye; urgency=high
+
+ * Non-maintainer upload.
+ * Fix CVE-2022-21797 (Closes: #1020820)
+
+ -- Helmut Grohne Mon, 27 Mar 2023 15:25:19 +0200
+
joblib (0.17.0-4) unstable; urgency=medium
* Team upload
diff --minimal -Nru joblib-0.17.0/debian/patches/CVE-2022-21797.patch
joblib-0.17.0/debian/patches/CVE-2022-21797.patch
--- joblib-0.17.0/debian/patches/CVE-2022-21797.patch 1970-01-01
01:00:00.0 +0100
+++ joblib-0.17.0/debian/patches/CVE-2022-21797.patch 2023-03-27
15:25:08.0 +0200
@@ -0,0 +1,121 @@
+From 54f4d21f098591c77b48c9acfffaa4cf0a45282b Mon Sep 17 00:00:00 2001
+From: Adrin Jalali
+Date: Mon, 12 Sep 2022 17:17:28 +0200
+Subject: [PATCH] FIX parse pre-dispatch with AST instead of calling eval
+ (#1327)
+
+---
+ CHANGES.rst | 2 +-
+ joblib/_utils.py | 44 +++
+ joblib/parallel.py| 7 +++
+ joblib/test/test_utils.py | 27
+ 4 files changed, 75 insertions(+), 5 deletions(-)
+ create mode 100644 joblib/_utils.py
+ create mode 100644 joblib/test/test_utils.py
+
+diff --git a/joblib/_utils.py b/joblib/_utils.py
+new file mode 100644
+index 0..2dbd4f636
+--- /dev/null
b/joblib/_utils.py
+@@ -0,0 +1,44 @@
++# Adapted from https://stackoverflow.com/a/9558001/2536294
++
++import ast
++import operator as op
++
++# supported operators
++operators = {
++ast.Add: op.add,
++ast.Sub: op.sub,
++ast.Mult: op.mul,
++ast.Div: op.truediv,
++ast.FloorDiv: op.floordiv,
++ast.Mod: op.mod,
++ast.Pow: op.pow,
++ast.USub: op.neg,
++}
++
++
++def eval_expr(expr):
++"""
++>>> eval_expr('2*6')
++12
++>>> eval_expr('2**6')
++64
++>>> eval_expr('1 + 2*3**(4) / (6 + -7)')
++-161.0
++"""
++try:
++return eval_(ast.parse(expr, mode="eval").body)
++except (TypeError, SyntaxError, KeyError) as e:
++raise ValueError(
++f"{expr!r} is not a valid or supported arithmetic expression."
++) from e
++
++
++def eval_(node):
++if isinstance(node, ast.Num): #
++return node.n
++elif isinstance(node, ast.BinOp): #
++return operators[type(node.op)](eval_(node.left), eval_(node.right))
++elif isinstance(node, ast.UnaryOp): # e.g., -1
++return operators[type(node.op)](eval_(node.operand))
++else:
++raise TypeError(node)
+diff --git a/joblib/parallel.py b/joblib/parallel.py
+index 1c2fe18f7..6e7b1b19a 100644
+--- a/joblib/parallel.py
b/joblib/parallel.py
+@@ -27,6 +27,7 @@
+ LokyBackend)
+ from .externals.cloudpickle import dumps, loads
+ from .externals import loky
++from ._utils import eval_expr
+
+ # Make sure that those two classes are part of the public joblib.parallel API
+ # so that 3rd party backend implementers can import them from here.
+@@ -1051,7 +1052,9 @@ def _batched_calls_reducer_callback():
+ else:
+ self._original_iterator = iterator
+ if hasattr(pre_dispatch, 'endswith'):
+-pre_dispatch = eval(pre_dispatch)
++pre_dispatch = eval_expr(
++pre_dispatch.replace("n_jobs", str(n_jobs))
++)
+ self._pre_dispatch_amount = pre_dispatch = i
Bug#1033404: unblock: debvm/0.2.10
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: de...@packages.debian.org Control: affects -1 + src:debvm Please unblock package debvm [ Reason ] debvm is fairly new and was stabilizing right into the freeze. Thus there are a few late changes that I hope to get into bookworm. [ Impact ] There are some notable changes indeed: * The biggest chunk of difference is documentation updates in various places. In particular, this includes adding examples for usage. * The biggest user facing change is the deprecation of the --architecture option for debvm-create. I paid attention to not just delete it (to avoid breaking things that already use it), but it no longer is documented and getting rid of it in bookworm already would make phasing it out later easier. * The --graphical option to debvm-run is fixed and improved. * Support for using 64bit kernels on mipsel. * An autopkgtest workaround for kernel bug #1029270 is being deleted. [ Tests ] autopkgtests succeed. The reason for the need on an unblock is that I had to disable 32bit arm, because qemu tcg emulation is too slow to boot Linux there. Other than that, it would migrate as a non-key package with autopkgtests. On salsa, more tests are run. I've used the updated version for quite some time now and not encountered more issues. [ Risks ] The affected functionality is not central to debvm or (in case of --architecture) explicitly kept backwards-compatible. Thus I see little risk for breakage. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] There is one possible change missing. Due to the archival of jessie, using it with debvm now requires passing a mirror. If there is a need for another update of debvm in bookworm, I intend to piggy-back an example to the documentation about how to use jessie with archive.debian.org. unblock debvm/0.2.10 Thanks in advance Helmut diff --git a/README.md b/README.md index 6fdda9e..1ccda36 100644 --- a/README.md +++ b/README.md @@ -77,9 +77,11 @@ The debvm tools are licensed under the MIT license. Contributors + * Arnd Bergmann + * Gioele Barabucci * Helmut Grohne (main author) - * Johannes Schauer Marin Rodrigues (main author of `mmdebstrap`) * Jochen Sprickerhof + * Johannes Schauer Marin Rodrigues (main author of `mmdebstrap`) [^1] This technically is a lie. It employs user namespaces and thus requires the setuid binary `newuidmap` as well as a suitable subuid allocation. diff --git a/bin/debvm-create b/bin/debvm-create index 89256eb..1c7c29d 100755 --- a/bin/debvm-create +++ b/bin/debvm-create @@ -11,7 +11,7 @@ debvm-create - Create a VM image for various Debian releases and architectures =head1 SYNOPSIS -B [B<-a> I] [B<-h> I] [B<-k> F] [B<-o> F] [B<-r> I] [B<-s> ] [B<-z> I] [B<--> I] +B [B<-h> I] [B<-k> F] [B<-o> F] [B<-r> I] [B<-s> ] [B<-z> I] [B<--> I] =head1 DESCRIPTION @@ -26,12 +26,6 @@ No user account is created and root can login without specifying a password. =over 8 -=item B<-a> I, B<--architecture>=I - -Specify a Debian architecture name. -By default, the native architecture is being used. -A suitable kernel image is automatically selected and installed into the image. - =item B<-h> I, B<--hostname>=I Set the hostname of the virtual machine. @@ -131,15 +125,43 @@ All options beyond a double dash are passed to B after the suite and This can be used to provide additional hooks for image customization. You can also request additional packages to be installed into the image using B's B<--include> option. Any positional arguments passed here will be treated as mirror specifications by B. +In particular, you can also change the architecture of the resulting image using the B<--architecture> option. =back =head1 EXAMPLES -In order to create images for Debian ports architectures, you can pass two options to mmdebstrap: +When creating an image with multiple architectures, the kernel selection will prefer the sibling 64bit architecture. + +debvm-create ... -- --architecture=armhf,arm64 + +In order to create images for Debian ports architectures, you can pass two options to mmdebstrap. debvm-create ... -- http://deb.debian.org/debian-ports --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg +You can also install a graphical desktop environment. + +debvm-create ... -- --hook-dir=/usr/share/mmdebstrap/hooks/useradd --aptopt='Apt::Install-Recommends "true"' --include=linux-image-generic,task-gnome-desktop + +Here the hook creates a password-less user C. +In order for C to work reasonably well, C should be enabled. +By default a C<-cloud> kernel that lacks graphics
Re: Bug#1033167: usrmerge: messes with /etc/shells
Hi Marco, On Sun, Mar 19, 2023 at 03:01:20AM +0100, Marco d'Itri wrote: > It is expected that /etc/shells can be edited by system administrators, > I have been doing that forever in my career as a professional system > administrator and until now I was not even aware of these programs from > debianutils. That applies to configuration files in general, right? However, configuration files have an owner from a packaging point of view. > Hence my reasoning that having convert-etc-shells modify the file would > not be harmful, and so far I am not aware of any practical problem that > this has ever caused. If convert-etc-shells were some administrative tool not to be run by maintainer scripts, that would actually be correct. > I also see that you wrote update-shells in 2021, but convert-etc-shells > was added to usrmerge in 2016. update-shells is an attempt at fixing long-standing bugs in add-shell and remove-shell. Prior to update-shells, those were the canonical tools to modify /etc/shells by packages and except for usrmerge, everyone else used those interfaces. Of course, those interfaces are not up to the task posed by usrmerge, so using them wasn't really an option. However, cooperating with debianutils would have been. > Right. But both update-shells and usr-is-merged are new to bookworm, and > I remember that having the /usr/ paths in /etc/shells is not usually > needed, so this explains why nobody has reported actual problems so far. Yeah, it popped up as a reproducibility issue now. > (Also, would you mind moving /var/lib/shells.state to /var/lib/misc/?) Thank you for suggesting this. I agree that that choice of path is better. When opening that can of worms, I would like to figure out whether there are even better places. update-shells is meant to be run by maintainer scripts only. If an administrator were to run it without changes to shells.d, the expected behaviour is noop. Thus, I am wondering whether something below /usr would be a better choice wrt. hermetic /usr. I think the major question here is what should happen if /etc/shells is deleted. If it should be populated with shells by update-shells, then its state file also needs to be deleted. This would be a reason for the location in /var, which would likekly be discarded together with /etc. If however, we see update-shells purely as a packaging tool, then something below /usr could be better (in a similar vein as we consider moving the dpkg database to /usr). Would you be able to help with finding an answer to this question? Then I wonder what severity that change in location should bear. Is it something we want to do during freeze? Is it worth the effort or more like a time travel fix? In any case, I think this is a separate issue. Would you clone it if you care deeply enough? I also noticed one other flaw in my proposal: Running convert-etc-shells as part of update-shells would cause /usr variants of shells to be re-added after having been removed by administrators. So the convert-etc-shells should be a one time conversion action instead and only happen on the first run of update-shells after a /usr-merge. I think this can be achieved by adding a flag-value to shells.state. I've prepared an update for debianutils and tested it in the following cases: * Installation on a pre-merged chroot -> /usr/bin/sh is added to /etc/shells. * Installation on a chroot merged by usrmerge -> no difference * Installation on an unmerged system. Manual merge without convert-etc-shells. Manual update-shells. -> Looks the same as after convert-etc-shells. Does anyone see any bugs? Helmut diff --minimal -Nru debianutils-5.7/debian/changelog debianutils-5.7/debian/changelog --- debianutils-5.7/debian/changelog2022-11-02 17:31:14.0 +0100 +++ debianutils-5.7/debian/changelog2023-03-19 15:00:09.0 +0100 @@ -1,3 +1,10 @@ +debianutils (5.7-0.5) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Absorb usrmerge's convert-etc-shells into update-shells. + + -- Helmut Grohne Sun, 19 Mar 2023 15:00:09 +0100 + debianutils (5.7-0.4) unstable; urgency=medium * Non-maintainer upload diff --minimal -Nru debianutils-5.7/debian/patches/absorb-convert-etc-shells debianutils-5.7/debian/patches/absorb-convert-etc-shells --- debianutils-5.7/debian/patches/absorb-convert-etc-shells1970-01-01 01:00:00.0 +0100 +++ debianutils-5.7/debian/patches/absorb-convert-etc-shells2023-03-19 15:00:09.0 +0100 @@ -0,0 +1,112 @@ +Absorb the script convert-etc-shells from usrmerge to obtain reproducible +behaviour. usrmerge will stop running convert-etc-shells and instead trigger +the shells update in debianutils. + +--- a/update-shells b/update-shells +@@ -1,11 +1,15 @@ + #!/bin/sh + # SPDX-License-Identifier: GPL-2.0-or-later + # Copyright 2021 Helmut Grohne +- ++# + # A "hashset" is a shell variable containing a sequence of elements
Bug#1033167: usrmerge: messes with /etc/shells
Package: usrmerge Version: 25 Severity: serious Justification: violates policy section 10.7.4 Control: affects -1 + debianutils dash X-Debbugs-Cc: jo...@debian.org, cl...@debian.org, andre...@debian.org, debian-release@lists.debian.org Hi, I think that it is quite obvious that /etc/shells is debianutils' territory. When I found that on some systems /etc/shells was out of sync with /var/lib/shells.state, I was quite puzzled until I noticed that usrmerge messes with this file. This really is debianutils' configuration file and usrmerge has no business in touching it in uncoordinated ways. Refer to policy section 10.7.4 for details, so usrmerge is technically rc-buggy. However, usrmerge does have reason to touch it, so the solution is not simply to drop convert-etc-shells with no replacement. Let us dive a bit into how an essential system can come to be. 1. We start either merged (e.g. debootstrap or mmdebstrap with --hook-dir=.../merged-usr) or unmerged (mmdebstrap without hook or an old debootstrap --no-merged-usr). 2. We either install usrmerge or usr-is-merged. Though we cannot combine starting unmerged with usr-is-merged for obvious reasons. 3. The last invocation of update-shells happens before or after usrmerge.postinst. (Not relevant in case of usr-is-merged) So what happens in these cases? If and only if usrmerge is used, convert-etc-shells turns /bin/sh into /usr/bin/sh. So whenever we start out merged and use usr-is-merged, /usr/bin/sh goes missing. If usrmerge is used, the order of entries in /etc/shells depends on whether update-shells is run after it or not. Likewise /var/lib/shells.state also depends. This is not some mmdebstrap-specific problem. You can easily observe this with debootstrap --no-merged-usr and installing usrmerge vs just doing debootstrap. This is bad from a reproducibility point of view and it is rooted in usrmerge not cooperating with other packages, but instead doing things behind their back, which happens to violate policy. So how to fix this? For one thing, the /bin/sh difference is rooted in the fact that /bin/sh is a standard value of debianutils and not managed using shells.d even though dash ships plain /bin/sh these days. I think dash should just add /bin/sh to /usr/share/debianutils/shells.d/dash and we'd be done as all entries in shells.d are correctly managed wrt. merged-/usr by update-shells. The next thing is that convert-etc-shells needs to go away from usrmerge. In the age of systems with usr-is-merged, there is no convert-etc-shells (as there is no usrmerge), so it must work without somehow anyway. When you run update-shells after a merge, it will pick up the merged shell locations (for shells managed in shells.d) and add them to /etc/shells. So usrmerge should ensure that update-shells is called after having performed the merge. This is the only way to get reproducibility. (That doesn't quite answer yet when to run it, how to run it, nor whether that makes convert-etc-shells unnecessary though.) Then we still have add-shell and remove-shell and most packages using them induce policy violations (reverting admin changes on upgrade), so we want to change them to the shells.d mechanism in the long run, but that's not where we are today and especially not what we can rely on in bookworm. So for these entries, we still do need convert-etc-shells and indeed we cannot just delete it. convert-etc-shells compensates for the difference in behaviour of add-shell pre-merge vs post-merge. I think the best solution here would be merging convert-etc-shells into update-shells. Whenever we run update-shells, it should check whether the system is already merged and when it is, perform the equivalent to convert-etc-shells. Then usrmerge can just install an empty (except for a comment) /usr/share/debianutils/shells.d/usrmerge to trigger update-shells and things become fully reproducible in all cases, because no matter how we started, we will run update-shells post merge and that'll do the right thing. And since usrmerge now uses the tools provided by debianutils, this fully resolves the policy violation. Also note that usr-is-merged does not have to invoke the trigger as debianutils is configured after /usr is merged. So unless I am mistaken, this leads to the following action items: * update-shells absorbs convert-etc-shells. * dash adds /bin/sh to shells.d/dash. * usrmerge creates an empty shells.d/usrmerge file. * usrmerge depends on a version of debianutils that has absorbed convert-etc-shells. Does that make sense to you? I haven't actually implemented and tested this yet. Do you see any obvious flaws in the arguments or the proposed solution? I'm Ccing release managers as it looks like we're starting a transition of an essential package right in the middle of the freeze. Not good, but this looks still manageable to me. Helmut
Re: Bug#1024261: debhelper: dbgsym packages contain directoryr writable by build user
Hi,
On Mon, Nov 21, 2022 at 06:08:22PM +0100, Niels Thykier wrote:
> Axel Beckert:
> > Could this be https://bugs.debian.org/1023286 in fakeroot as well as
> > Niels pointed out in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024520#37 ?
>
> It is.
So the underlying fakeroot bug has been fixed since. I don't think this
actually is a debhelper bug anymore and suggest to just close it once
the pratical effects have been mitigated.
> Helmut and I discussed this on IRC and Helmut's findings is based on that
> IRC discussion between him and I in relation to #1023286. (Which people not
> IRC had no chance of knowing, so putting the context here for good measure)
Given that the fakeroot bug has been fixed, I have rerun the dbgsym
importer (now that no new problems can be added). Quite a number of
packages have fixed themselves since the last run. Very few were added.
I'm attaching a list of affected packages in format
"binarypackage_version_architecture". Can I ask the release team to just
binNMU all of them?
What is a bit unclear to me is whether this is sufficient. We know
-dbgsym packages to be affected (and which), but how about regular
packages? Can they be affected as well?
If yes, we could download all .debs and record owner/group/mode for each
file after normalizing s,/${DEB_HOST_MULTIARCH}/,/, and highlight all
packages where these aspects vary accross architectures (with the
intuition that 64bit achitectures should generally be right). Does this
make sense? Does this likely encounter issues? Is this approach
exhaustive?
In any case, binNMUing the packages from the attached list is something
actionable right now. It's just 500 packages on four architectures left.
Helmut
ypserv-dbgsym_4.2-1+b1_mipsel
xserver-xorg-input-synaptics-dbgsym_1.9.2-1_mipsel
wings3d-dbgsym_2.2.9-2_mipsel
w1retap-dbgsym_1.4.6-1.1+b1_mipsel
vlock-dbgsym_2.2.2-11_mipsel
vmfs6-tools-dbgsym_0.2.1-1_mipsel
libv4lconvert0-dbgsym_1.22.1-5+b1_mipsel
libv4l-0-dbgsym_1.22.1-5+b1_mipsel
dvb-tools-dbgsym_1.22.1-5+b1_mipsel
v4l-utils-dbgsym_1.22.1-5+b1_mipsel
unar-dbgsym_1.10.7+ds1+really1.10.1-2+b1_mipsel
triggerhappy-dbgsym_0.5.0-1.1+b1_mipsel
torcs-dbgsym_1.3.7+dfsg-5+b1_mipsel
sysrepo-dbgsym_2.0.53-6+b2_mipsel
libsuperlu-dist8-dbgsym_8.1.2+dfsg1-1_mipsel
libsuperlu-dist-dev-dbgsym_8.1.2+dfsg1-1_mipsel
sslh-dbgsym_1.20-1+b1_mipsel
squid-dbgsym_5.7-1+b1_mipsel
squid-openssl-dbgsym_5.7-1+b1_mipsel
spice-vdagent-dbgsym_0.22.1-3+b1_mipsel
source-highlight-dbgsym_3.1.9-4.2+b2_mipsel
sndio-tools-dbgsym_1.9.0-0.3+b1_mipsel
shotwell-dbgsym_0.30.17-1_mipsel
shapelib-dbgsym_1.5.0-3_mipsel
uidmap-dbgsym_1:4.13+dfsg1-1_mipsel
login-dbgsym_1:4.13+dfsg1-1_mipsel
passwd-dbgsym_1:4.13+dfsg1-1_mipsel
scitokens-cpp-dbgsym_0.7.3-1_mipsel
schroot-dbgsym_1.6.13-3+b1_mipsel
scalapack-mpi-test-dbgsym_2.2.1-2_mipsel
rxvt-unicode-dbgsym_9.30-2+b2_mipsel
libruli-bin-dbgsym_0.36-3_mipsel
roger-router-dbgsym_2.4.2-3+b1_mipsel
r-cran-zip-dbgsym_2.2.2-1_mipsel
qflow-dbgsym_1.3.17+dfsg.1-3_mipsel
libpmix-bin-dbgsym_4.2.2-1_mipsel
libpmix2-dbgsym_4.2.2-1_mipsel
pmacct-dbgsym_1.7.7-1_mipsel
ploop-dbgsym_1.15-12_mipsel
libplib1-dbgsym_1.8.5-14_mipsel
postgresql-15-ogr-fdw-dbgsym_1.1.3-1+b1_mipsel
perl-tk-dbgsym_1:804.036-1+b1_mipsel
pdl-dbgsym_1:2.081-1_mipsel
dolphin-owncloud-dbgsym_2.11.0.8354+dfsg-1_mipsel
libowncloudsync0-dbgsym_2.11.0.8354+dfsg-1_mipsel
osmo-hlr-dbgsym_1.5.0+dfsg1-3_mipsel
osmo-ggsn-dbgsym_1.9.0-3_mipsel
osmo-bsc-bs11-utils-dbgsym_1.9.0-3_mipsel
osmo-bts-dbgsym_1.5.0+dfsg1-2_mipsel
osmo-bsc-meas-utils-dbgsym_1.9.0-3_mipsel
osmo-bsc-ipaccess-utils-dbgsym_1.9.0-3_mipsel
osdsh-dbgsym_0.7.0-11_mipsel
orthanc-postgresql-dbgsym_4.0-7+b1_mipsel
opensmtpd-dbgsym_6.8.0p2-4+b3_mipsel
openmpi-bin-dbgsym_4.1.4-3_mipsel
topp-dbgsym_2.6.0+cleaned1-3+b3_mipsel
libopenms2.6.0-dbgsym_2.6.0+cleaned1-3+b3_mipsel
libopenmesh1-dbgsym_9.0-4_mipsel
libopenmpi3-dbgsym_4.1.4-3_mipsel
libopenmesh-apps-dbgsym_9.0-4_mipsel
libcoarrays-openmpi-dev-dbgsym_2.10.1-1_mipsel
libcoarrays-mpich-dev-dbgsym_2.10.1-1_mipsel
odr-dabmux-dbgsym_4.2.1-1_mipsel
oddjob-mkhomedir-dbgsym_0.34.7-1+b1_mipsel
oddjob-dbgsym_0.34.7-1+b1_mipsel
ntfs-3g-dev-dbgsym_1:2022.10.3-1_mipsel
ntfs-3g-dbgsym_1:2022.10.3-1_mipsel
nethack-common-dbgsym_3.6.6-3+b1_mipsel
ndisc6-dbgsym_1.0.5-1+b1_mipsel
myproxy-admin-dbgsym_6.2.14-2+b1_mipsel
myproxy-dbgsym_6.2.14-2+b1_mipsel
mutt-dbgsym_2.2.9-1_mipsel
miredo-dbgsym_1.2.6-7.1+b1_mipsel
lua-socket-dbgsym_3.1.0-1_mipsel
lua-readline-dbgsym_3.2-1_mipsel
lldpd-dbgsym_1.0.16-1_mipsel
linuxptp-dbgsym_3.1.1-4+b1_mipsel
libxtrxll0-dbgsym_0.0.1+git20201202.1b6eddf-1_mipsel
libtheora0-dbgsym_1.1.1+dfsg.1-16.1_mipsel
libtheora-bin-dbgsym_1.1.1+dfsg.1-16.1_mipsel
libiec61883-dev-dbgsym_1.2.0-6_mipsel
fido2-tools-dbgsym_1.12.0-2_mipsel
libdrm-tests-dbgsym_2.4.114-1_mipsel
libleatherman1.12.1-dbgsym_1.12.1+dfsg-1.2+b4_mipsel
lcdproc-extra-drivers-dbgsym_0.5.9-6+b1_mipsel
lcdproc-dbgsym_0.5.9-6+b1_mipsel
kyotocabinet-utils-dbgsym_1.2.79-2_mipsel
Bug#1032933: unblock: sox/14.4.2+git20190427-3.5
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: s...@packages.debian.org, secur...@debian.org
Control: affects -1 + src:sox
Please unblock package sox
[ Reason ]
I recently performed a security update of sox in unstable and that
happened to migrate to testing. Now it was reported (#1032082) that sox
would no longer be able to parse WAV GSM files. This turns out to be a
regression in my fix for CVE-2021-33844. The .5 upload fixes this
regression and adds a test case.
[ Impact ]
sox will be able to parse WAV GSM files again.
[ Tests ]
The patch adds a test case to the upstream test suite.
[ Risks ]
The diff is short, but the original change was believed not to be risky
already and it turned out to be bad, so keep the fingers crossed. I
appreciate if someone actually reviews the change to avoid me looking
bad again.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
The bug was backported to stable and oldstable. We plan to update them
via a regression DSA and a regression DLA. SRM involvement not needed.
unblock sox/14.4.2+git20190427-3.5
Helmut
diff --minimal -Nru sox-14.4.2+git20190427/debian/changelog
sox-14.4.2+git20190427/debian/changelog
--- sox-14.4.2+git20190427/debian/changelog 2023-02-07 22:21:09.0
+0100
+++ sox-14.4.2+git20190427/debian/changelog 2023-03-12 10:07:49.0
+0100
@@ -1,3 +1,11 @@
+sox (14.4.2+git20190427-3.5) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix regression in wav-gsm decodeing introduced via fixing CVE-2021-33844.
+(Closes: #1032082)
+
+ -- Helmut Grohne Sun, 12 Mar 2023 10:07:49 +0100
+
sox (14.4.2+git20190427-3.4) unstable; urgency=medium
* Non-maintainer upload.
diff --minimal -Nru sox-14.4.2+git20190427/debian/patches/CVE-2021-33844.patch
sox-14.4.2+git20190427/debian/patches/CVE-2021-33844.patch
--- sox-14.4.2+git20190427/debian/patches/CVE-2021-33844.patch 2023-01-28
19:34:07.0 +0100
+++ sox-14.4.2+git20190427/debian/patches/CVE-2021-33844.patch 2023-03-12
10:07:49.0 +0100
@@ -14,15 +14,22 @@
uint32_t wFmtSize;
uint16_t wExtSize = 0;/* extended field for non-PCM */
-@@ -587,6 +587,11 @@
- lsx_readdw(ft, ); /* Average bytes/second */
- lsx_readw(ft, &(wav->blockAlign)); /* Block align */
- lsx_readw(ft, ); /* bits per sample per channel */
-+if (wBitsPerSample == 0)
-+{
-+lsx_fail_errno(ft, SOX_EHDR, "WAV file bits per sample is zero");
-+return SOX_EOF;
-+}
- len -= 16;
+@@ -954,6 +959,11 @@
+ break;
- if (wav->formatTag == WAVE_FORMAT_EXTENSIBLE)
+ default:
++if (ft->encoding.bits_per_sample == 0)
++{
++lsx_fail_errno(ft, SOX_EHDR, "WAV file bits per sample is zero");
++return SOX_EOF;
++}
+ wav->numSamples = div_bits(qwDataLength,
ft->encoding.bits_per_sample) / ft->signal.channels;
+ ft->signal.length = wav->numSamples * ft->signal.channels;
+ }
+--- a/src/testall.sh
b/src/testall.sh
+@@ -67,3 +67,4 @@
+ t vox -r 8130
+ t wav
+ t wve
++t wav -e gsm-full-rate
Bug#1025601: bullseye-pu: package leptonlib/1.79.0-1.1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: j...@debian.org
[ Reason ]
CVE-2022-38266 is a low impact vulnerability where leptonlib would crash
with arithmetic exceptions on certain JPEG files. Since this is only
DoS, it does not go via bullseye-security.
[ Impact ]
It no longer crashes on relevant inputs.
[ Tests ]
Included test suite passes. The reproducer from
https://github.com/tesseract-ocr/tesseract/issues/3498 does not trigger
as the image is rejected at an earlier stage.
[ Risks ]
This affects corner case parameters. The chance of encountering them
accidentally is fairly low.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Various convolution functions are updated to return a copy of the
original image when kernel sizes are implausible.
[ Other info ]
I've Cced the maintainer for his input. I'm happy to defer the actual
upload to him, if he agrees. This update is a by-product of LTS work.
Helmut
diff --minimal -Nru leptonlib-1.79.0/debian/changelog
leptonlib-1.79.0/debian/changelog
--- leptonlib-1.79.0/debian/changelog 2021-04-18 10:03:02.0 +0200
+++ leptonlib-1.79.0/debian/changelog 2022-12-06 15:59:12.0 +0100
@@ -1,3 +1,10 @@
+leptonlib (1.79.0-1.1+deb11u1) bullseye-security; urgency=medium
+
+ * Non-maintainer upload by the LTS Team.
+ * Fix CVE-2022-38266
+
+ -- Helmut Grohne Tue, 06 Dec 2022 15:59:12 +0100
+
leptonlib (1.79.0-1.1) unstable; urgency=medium
* Non-maintainer upload by the LTS Team.
diff --minimal -Nru leptonlib-1.79.0/debian/patches/CVE-2022-38266.patch
leptonlib-1.79.0/debian/patches/CVE-2022-38266.patch
--- leptonlib-1.79.0/debian/patches/CVE-2022-38266.patch1970-01-01
01:00:00.0 +0100
+++ leptonlib-1.79.0/debian/patches/CVE-2022-38266.patch2022-12-06
15:59:12.0 +0100
@@ -0,0 +1,202 @@
+From f062b42c0ea8dddebdc6a152fd16152de215d614 Mon Sep 17 00:00:00 2001
+From: Dan Bloomberg
+Date: Wed, 28 Oct 2020 17:37:30 -0700
+Subject: [PATCH] Issue 26393: morphapp_fuzzer: Divide-by-zero in blockconvLow
+ * Removed the code that allowed divide by zero for tiny pix * Ditto for 4
+ other block convolution functions.
+
+---
+ src/convolve.c | 90 ++
+ 1 file changed, 40 insertions(+), 50 deletions(-)
+
+diff --git a/src/convolve.c b/src/convolve.c
+index 72afa9415..fda032ba6 100644
+--- a/src/convolve.c
b/src/convolve.c
+@@ -114,7 +114,7 @@ static void blocksumLow(l_uint32 *datad, l_int32 w,
l_int32 h, l_int32 wpl,
+ /*!
+ * \brief pixBlockconv()
+ *
+- * \param[in]pix 8or 32 bpp; or 2, 4 or 8 bpp with colormap
++ * \param[in]pix 8 or 32 bpp; or 2, 4 or 8 bpp with colormap
+ * \param[in]wc, hc half width/height of convolution kernel
+ * \return pixd, or NULL on error
+ *
+@@ -122,9 +122,10 @@ static void blocksumLow(l_uint32 *datad, l_int32 w,
l_int32 h, l_int32 wpl,
+ * Notes:
+ * (1) The full width and height of the convolution kernel
+ * are (2 * wc + 1) and (2 * hc + 1)
+- * (2) Returns a copy if both wc and hc are 0
++ * (2) Returns a copy if either wc or hc are 0
+ * (3) Require that w >= 2 * wc + 1 and h >= 2 * hc + 1,
+- * where (w,h) are the dimensions of pixs.
++ * where (w,h) are the dimensions of pixs. Otherwise,
++ * return a copy.
+ *
+ */
+ PIX *
+@@ -139,17 +140,14 @@ PIX *pixs, *pixd, *pixr, *pixrc, *pixg, *pixgc,
*pixb, *pixbc;
+
+ if (!pix)
+ return (PIX *)ERROR_PTR("pix not defined", procName, NULL);
+-if (wc < 0) wc = 0;
+-if (hc < 0) hc = 0;
++if (wc <= 0 || hc <= 0)
++return pixCopy(NULL, pix);
+ pixGetDimensions(pix, , , );
+ if (w < 2 * wc + 1 || h < 2 * hc + 1) {
+-wc = L_MIN(wc, (w - 1) / 2);
+-hc = L_MIN(hc, (h - 1) / 2);
+-L_WARNING("kernel too large; reducing!\n", procName);
+-L_INFO("wc = %d, hc = %d\n", procName, wc, hc);
++L_ERROR("kernel is too large: w = %d, wc = %d, h = %d, hc = %d\n",
++procName, w, wc, h, hc);
++return pixCopy(NULL, pix); /* no-op */
+ }
+-if (wc == 0 && hc == 0) /* no-op */
+-return pixCopy(NULL, pix);
+
+ /* Remove colormap if necessary */
+ if ((d == 2 || d == 4 || d == 8) && pixGetColormap(pix)) {
+@@ -205,9 +203,10 @@ PIX *pixs, *pixd, *pixr, *pixrc, *pixg, *pixgc,
*pixb, *pixbc;
+ * returning; otherwise, just use the input accum pix.
+ * (2) The full width and height of the convolution kernel
+ * are (2 * wc + 1) and (2 * hc + 1).
+- * (3) Returns a copy if both wc and hc are 0.
++
Re: Bug#1024261: debhelper: dbgsym packages contain directoryr writable by build user
Hi Niels,
On Wed, Nov 16, 2022 at 05:06:42PM +0100, Chris Hofstaedtler wrote:
> util-linux dbgsym packages install /usr/lib/debug/.dwz/i386-linux-gnu/
> (and other multiarch triplets) writable by an essential random uid
> (= uid of the user running the build on the build system).
I've hacked up a custom dissector (attached) for the debian-dedup[1]
engine to check binary packages. It ends up downloading the entire
debian-debug archive, which is about 750GB. You need a fast network to
run it. In essence, it looks at every file in the data.tar of every
binary package and checks whether user and group are root (both numeric
and name). Any difference is flagged. That yields a number of binary
packages:
308 armel
313 armhf
316 i386
613 mipsel
I think it is fairly safe to say that the problem affects 32bit
architectures.
Full results attached. I leave the mapping of binary packages to source
packages to you. You can rerun it at any time.
Hope this helps
Helmut
[1] https://dedup.debian.net/
https://git.subdivi.de/?p=~helmut/debian-dedup.git;a=summary
#!/usr/bin/python3
from contextlib import closing
import logging
import multiprocessing
import queue
from urllib.request import urlopen
from debian import deb822
from dedup.debpkg import DebExtractor
from dedup.utils import open_compressed_mirror_url
class ProcessingFinished(Exception):
pass
class DdebOwnerExtractor(DebExtractor):
def __init__(self):
DebExtractor.__init__(self)
self.files = set()
def handle_data_tar(self, tarfileobj):
for elem in tarfileobj:
if elem.uid == 0 and elem.gid == 0 and elem.uname == "root" and elem.gname == "root":
continue
self.files.add(elem.name)
raise ProcessingFinished
def process_one_package(item):
pkg, url = item
try:
extractor = DdebOwnerExtractor()
with closing(urlopen(url)) as pkgfile:
try:
extractor.process(pkgfile)
except ProcessingFinished:
pass
return (pkg, extractor.files)
except:
logging.exception("while processing %s", pkg)
return (pkg, set())
def consume_items(dct):
while True:
try:
yield dct.popitem()
except KeyError:
break
def bounded_imap_unordered(bound, pool, function, iterable):
iterable = iter(iterable)
results = queue.Queue()
outstanding = 0
while iterable or outstanding:
if iterable:
for elem in iterable:
pool.apply_async(function, (elem,), callback=results.put)
outstanding += 1
if outstanding >= bound or not results.empty():
break
else:
iterable = None
if outstanding:
yield results.get()
outstanding -= 1
def main():
logging.basicConfig(level=logging.DEBUG)
pkgs = dict()
mirror = "http://deb.debian.org/debian-debug;
for arch in ("amd64", "arm64", "armel", "armhf", "i386", "mips64el", "mipsel", "ppc64el", "s390x"):
url = "%s/dists/unstable-debug/main/binary-%s/Packages" % (mirror, arch)
with closing(open_compressed_mirror_url(url)) as pkglist:
for pkg in deb822.Packages.iter_paragraphs(pkglist):
pkgs["%s_%s_%s" % (pkg["package"], pkg["version"], pkg["architecture"])] = pkg["filename"]
with multiprocessing.Pool() as pool:
iterator = bounded_imap_unordered(32, pool, process_one_package,
((pkg, "%s/%s" % (mirror, filename))
for pkg, filename in consume_items(pkgs)))
for pkg, files in iterator:
if files:
print(pkg)
if __name__ == "__main__":
main()
ypserv-dbgsym_4.2-1+b1_mipsel
erlang-yaws-dbgsym_2.1.1+dfsg-1.1_mipsel
python3-yarl-dbgsym_1.8.1-1+b1_mipsel
python3-yara-dbgsym_4.2.0-1+b2_mipsel
xserver-xorg-input-synaptics-dbgsym_1.9.2-1_mipsel
xrootd-server-dbgsym_5.5.1-2_mipsel
xrootd-plugins-dbgsym_5.5.1-2_mipsel
xrootd-client-plugins-dbgsym_5.5.1-2_mipsel
xrootd-server-plugins-dbgsym_5.5.1-2_mipsel
xrootd-ceph-plugins-dbgsym_5.5.1-2_mipsel
xrootd-client-dbgsym_5.5.1-2_mipsel
libxrdposix3-dbgsym_5.5.1-2_mipsel
xserver-xorg-core-dbgsym_2:21.1.4-3_mipsel
libxerces-c-samples-dbgsym_3.2.3+debian-3+b2_mipsel
xalan-dbgsym_1.12-6+b2_mipsel
libxalan-c112-dbgsym_1.12-6+b2_mipsel
python3-wxgtk-webview4.0-dbgsym_4.2.0+dfsg-1+b1_mipsel
python3-wxgtk-media4.0-dbgsym_4.2.0+dfsg-1+b1_mipsel
python3-wxgtk4.0-dbgsym_4.2.0+dfsg-1+b1_mipsel
wings3d-dbgsym_2.2.9-2_mipsel
w1retap-dbgsym_1.4.6-1.1+b1_mipsel
vulkan-tools-dbgsym_1.3.231.1+dfsg1-1_mipsel
wabt-dbgsym_1.0.30-1_mipsel
vulkan-validationlayers-dbgsym_1.3.231.1-1_mipsel
vmfs6-tools-dbgsym_0.2.1-1_mipsel
vlock-dbgsym_2.2.2-11_mipsel
virgl-server-dbgsym_0.10.3-2_mipsel
vdr-plugin-examples-dbgsym_2.6.0-1+b1_mipsel
vdr-dbgsym_2.6.0-1+b1_mipsel
Bug#1001639: bullseye-pu: package python-hbmqtt/0.9.6-1+deb11u1
Hi Adam, On Tue, Mar 15, 2022 at 09:15:16PM +, Adam D. Barratt wrote: > Please go ahead; sorry for the delay. In the mean time, hbmqtt has been deleted from unstable as unmaintained. As such, I now prefer spending my time on migrating stuff away from hbmqtt and propose removing the (dysfunctional) package from stable. The sooner we get rid of it, the fewer people will try using something that isn't sustainable. Do you concur? If yes, can you directly turn this bug into an appropriate RM request? Sorry for the delay. Helmut
Bug#1001639: bullseye-pu: package python-hbmqtt/0.9.6-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: team+pyt...@tracker.debian.org
Control: found 998912 0.9.6-1
Control: forwarded 998912 https://github.com/beerfactory/hbmqtt/issues/223
python3-hbmqtt can be used for connecting to a mqtt broker or for
running a mqtt broker. I guess that the former is more widespread. The
version of python3-hbmqtt cannot connect to a broker at all.
[ Reason ]
In python the way asyncio Lock objects can be used has changed. This
results in a traceback when the hbmqtt client attempts to acquire such a
Lock object. For full details, please refer to 998912.
[ Impact ]
Any attempt to connect to a mqtt broker using the hbmqtt client fails.
This renders hbmqtt mostly unusable. The fact that nobody noticed
suggests that few people use hbmqtt.
[ Tests ]
If the code had been tested, this would likely have been noticed
earlier. The version in unstable now has autopkgtests to cover for this,
but adding such tests in stable does not seem reasonable to me.
If you run a mqtt broker on localhost (e.g. mosquitto), the following
command can be used to test for the issue:
python3 -c 'from hbmqtt.client import MQTTClient as C;
__import__("asyncio").get_event_loop().run_until_complete(C().connect("mqtt://localhost"))'
[ Risks ]
The proposed solution is minimally invasive. It changes precisely the
code that currently raises an exception in a relatively obvious way.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
In older versions of python, it was possible to do:
with (yield from somelock): ...
That no longer works. The preferred method now is:
async with somelock: ...
However hbmqtt does not yet use the async/await syntax. So the
contextmanager can be emulated:
yield from somelock.acquire()
try:
finally:
somelock.release
While this is verbose, it works in all relevant Python versions.
[ Upstreaming ]
While the proposed fix has not been upstreamed, it has been reported
upstream as https://github.com/beerfactory/hbmqtt/issues/223. The
preferred solution there is switching to the async/await syntax. As
such, upstreaming does not seem reasonable.
[ Hats ]
I am not a python-mqtt maintainer. I intend to NMU this fix. The issue
was fixed in unstable using a NMU by me.
Helmut
diff --minimal -Nru python-hbmqtt-0.9.6/debian/changelog
python-hbmqtt-0.9.6/debian/changelog
--- python-hbmqtt-0.9.6/debian/changelog2020-12-04 23:52:25.0
+0100
+++ python-hbmqtt-0.9.6/debian/changelog2021-12-13 15:16:34.0
+0100
@@ -1,3 +1,10 @@
+python-hbmqtt (0.9.6-1+deb11u1) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix MQTTClient.connect. (Closes: #998912)
+
+ -- Helmut Grohne Mon, 13 Dec 2021 15:16:34 +0100
+
python-hbmqtt (0.9.6-1) unstable; urgency=low
[ Debian Janitor ]
diff --minimal -Nru python-hbmqtt-0.9.6/debian/patches/fix-connect.patch
python-hbmqtt-0.9.6/debian/patches/fix-connect.patch
--- python-hbmqtt-0.9.6/debian/patches/fix-connect.patch1970-01-01
01:00:00.0 +0100
+++ python-hbmqtt-0.9.6/debian/patches/fix-connect.patch2021-12-13
15:16:17.0 +0100
@@ -0,0 +1,15 @@
+--- a/hbmqtt/mqtt/protocol/handler.py
b/hbmqtt/mqtt/protocol/handler.py
+@@ -442,8 +442,11 @@ class ProtocolHandler:
+ @asyncio.coroutine
+ def _send_packet(self, packet):
+ try:
+-with (yield from self._write_lock):
++yield from self._write_lock.acquire()
++try:
+ yield from packet.to_stream(self.writer)
++finally:
++self._write_lock.release()
+ if self._keepalive_task:
+ self._keepalive_task.cancel()
+ self._keepalive_task =
self._loop.call_later(self.keepalive_timeout, self.handle_write_timeout)
diff --minimal -Nru python-hbmqtt-0.9.6/debian/patches/series
python-hbmqtt-0.9.6/debian/patches/series
--- python-hbmqtt-0.9.6/debian/patches/series 2020-12-04 23:36:55.0
+0100
+++ python-hbmqtt-0.9.6/debian/patches/series 2021-12-13 15:16:02.0
+0100
@@ -1 +1,2 @@
0001-Move-scripts-module-into-hbmqtt-module.patch
+fix-connect.patch
Bug#1000785: bullseye-pu: package curl/7.74.0-1.3+deb11u1
Dear curl maintainers, Adam has acked my stable upload. Consequently, I've uploaded my proposed NMU. In accordance with devrev, it went to delayed/5. Please let me know if that doesn't work for you. The diff is exactly the one I sent previously. Helmut
Bug#1000785: bullseye-pu: package curl/7.74.0-1.3+deb11u1
Control: tags -1 - moreinfo Hi Adam, On Tue, Nov 30, 2021 at 08:25:57PM +, Adam D. Barratt wrote: > What's the potential impact of the change? Is "curl-config --configure" > consumed by anything, other than human eyeballs? curl-config is mainly meant for machine consumption. It kinda is a predecessor of pkg-config. Preconditions to be affected: * You must perform a build of a software using one of the libcurl*-*-dev packages. * Your build must not use pkg-config (very uncommon), but rather use curl-config. * Your build consumes curl-config --cflags (roughly equivalent to pkg-config --cflags libcurl). As such I think that the number of affected users is fairly small (due to the requirement of not using pkg-config). If all of these are met, then your cflags now lost a flag: -file-prefix-map=$build_path_used_while_building_curl=. This flag should not be used by your build in the first place. Since our buildd build paths are generated randomly, it is very unlikely that any of the files you are building matches this prefix. The flag normally does not have any effect on your build. As such, dropping it normally does not change your build. As such, I think that the risk of breaking something is fairly low. Keep in mind that oldstable lacks this bug (and this flag). If something was seriously broken there, we'd surely have received a bug report by now. Even switching to pkg-config would drop that flag and it really doesn't belong there in the first place. It was injected there by the reproducible builds folks in order to make the curl build unreproducible err I meant reproducible. Whatever. Helmut
Bug#1000785: bullseye-pu: package curl/7.74.0-1.3+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: Alessandro Ghedini , Samuel Henrique , Sergio Durigan Junior libcurl4-gnutls-dev is not multiarch-coinstallable in bullseye despite being marked Multi-Arch: same. When attempting to coinstall it, dpkg issues an unpack error. That's a very bad thing to do. The issue has been reported as #990128 and has been fixed in unstable. Reproducible builds added compiler flags that include the build directory (which varies per build) and those build flags made it into curl-config. As such, reproducible builds made curl unreproducible. This issue has been well understood and for a different compiler flag, a workaround was already in place in debian/rules. The solution was to extend the workaround in the obvious way (stripping that other flag). I think that the risk/benefit ratio is good. The only affected piece is curl-config, the change is fairly obvious and it makes unpack errors from dpkg go away. It also has been in testing for a while now. buster is unaffected by this issue. Note that I am not a curl maintainer, but I provided the solution for unstable. I intend to NMU this change. I've put the curl maintainers into X-Debbugs-Cc in case they wish to pick this up. The full (small) .debdiff is attached. Helmut diff --minimal -Nru curl-7.74.0/debian/changelog curl-7.74.0/debian/changelog --- curl-7.74.0/debian/changelog2021-06-25 20:59:54.0 +0200 +++ curl-7.74.0/debian/changelog2021-11-28 06:38:09.0 +0100 @@ -1,3 +1,10 @@ +curl (7.74.0-1.3+deb11u1) bullseye; urgency=medium + + * Non-maintainer upload. + * Also remove -ffile-prefix-map from curl-config. (Closes: #990128) + + -- Helmut Grohne Sun, 28 Nov 2021 06:38:09 +0100 + curl (7.74.0-1.3) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru curl-7.74.0/debian/rules curl-7.74.0/debian/rules --- curl-7.74.0/debian/rules2021-06-25 20:59:54.0 +0200 +++ curl-7.74.0/debian/rules2021-11-28 06:37:57.0 +0100 @@ -101,11 +101,13 @@ # 3. Likewise, replace the architecture name used for --build (and #build_alias) with a literal backquoted call to dpkg-architecture. # 4. In --configure output, remove -#-fdebug-prefix-map=/buildd/specific/random/path=. +#-fdebug-prefix-map=/buildd/specific/random/path=. and +#-ffile-prefix-map=/buildd/specific/random/path=. sed -e "/-lcurl /s|`krb5-config --libs gssapi`|\`krb5-config --libs gssapi\`|" \ -e "/--prefix/s|/$(DEB_HOST_MULTIARCH)'|/'\`dpkg-architecture -qDEB_HOST_MULTIARCH\`|g" \ -e "/--prefix/s|=$(DEB_BUILD_GNU_TYPE)'|='\`dpkg-architecture -qDEB_BUILD_GNU_TYPE\`|g" \ -e "/-fdebug-prefix-map=/s|\(-fdebug-prefix-map=\)/[^ ]*=.||" \ + -e "/-ffile-prefix-map=/s|\(-ffile-prefix-map=\)/[^ ]*=.||" \ -i `find . -name curl-config` override_dh_installchangelogs:
Re: debianutils still blocked from migration
Hi, On Tue, Oct 05, 2021 at 06:02:11AM +0200, Bastian Blank wrote: > This bug was "fixed" by adding breaks. Also there is still a CTTE bug > open. I am aware of both. You might have noticed that I did contribute to the CTTE bug. If you disagree with the way the bug was addressed (which seems to be a reasonable position to me), the bug should be reopened. Otherwise the maintainer is not aware that there is a problem. Using a CTTE bug itself as a reason for blocking a package sounds bad to me as we all know how long CTTE bugs take to resolve. My suggestion to issue a temporary ruling seems to have been ignored entirely. At least it has been delayed for so long that it no longer makes sense. It seems most likely to me that the CTTE is going to decline overruling the maintainer here. Neither of these issues are actionable for the maintainer, so neither are good reasons for continuing to block debianutils. I am not denying that there might be good reasons to continue blocking, but then I find it unfair to not communicate them clearly by means of an rc-bug. Continuing to block debianutils on the grounds of a closed bug feels passive aggressive to me. It attempts to hide the underlying conflict instead of taking steps to resolve it. That way it harms our community. Please continue Ccing me. Helmut
debianutils still blocked from migration
Hi, I was looking into why debianutils doesn't migrate and saw the block hint from Sebastian Ramacher: | # 20210818 | # #992399: removes interface from an essential package without finishing that transition in a stable release first | block debianutils The bug mentioned above is marked as done in unstable. As such, the reason for the block seems to have gone away. Please consider lifting it. Alternatively, if there still is a reason for blocking debianutils from migrating, please ensure that there is a relevant rc bug filed such that the maintainer is aware of action being needed. I am interested in having debianutils migrate, because the update-shells transition is blocked on it. Please Cc me in replies. Helmut
Bug#983099: perl FTCBFS: cross configs outdated
Source: perl Version: 5.32.1-2 Severity: important X-Debbugs-Cc: debian-release@lists.debian.org User: debian-cr...@lists.debian.org Usertags: ftcbfs perl currently fails to cross build from source, due to a minor version bump. Whenever the version is updated, the cross compilation configs need to be updated and this didn't happen for perl. Such temporary ftcbfs are usual for perl. What makes this worthy of reporting is that this version will end up in bullseye. There are a number of embedded distributions now that are based on Debian and due to perl's central role to Debian it should be cross buildable in stable. The risk of breaking anything by fixing this bug is quite low as these cross configs are used for nothing but cross building perl and updating them is a routine task to Niko. I've Cced d-release in case they want to object now before Niko files an unblock request. Helmut
Bug#982524: nmu: gcc-11_11-20210207-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-...@lists.debian.org nmu gcc-11_11-20210207-1 . ANY . experimental . -m "rebuild with downgraded binutils" binutils was downgraded from 2.36 to 2.35. As a consequence, sections with the "R" flag are no longer supported, but gcc still generates them. The compilation of the following program fails: __attribute__((used)) int i; A binNMU will make gcc-11 detect the absence of this feature. I request urgently handling this issue as gcc-11 is presently completely broken. Helmut
Bug#961843: buster-pu: package lighttpd/1.4.53-4
Hi SRMs and Glenn, On Sat, May 30, 2020 at 04:44:34AM -0400, Glenn Strauss wrote: > Greetings! I am an upstream maintainer of lighttpd. > > Please accept this backport of important patches from > lighttpd 1.4.54 (released 2019.05.27) > lighttpd 1.4.55 (released 2020.01.31) > > The patches to backport have been hand-selected from the release > available in buster-backports lighttpd 1.4.55-1~bpo10+1 since 2020.03.06 > > These patches fix important bugs from upstream lighttpd issue tracker > https://redmine.lighttpd.net/issues (direct links below) > including a couple in the Debian Bug Tracker > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954759 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929203 I'm an uploader of the lighttpd Debian package and I second Glenn's request. I intend to perform this upload once there is an SRM ack. > From the debian/changelog: > * backport security, bug, portability fixes from lighttpd 1.4.54, 1.4.55 > + mod_evhost, mod_flv_streaming: > [regression] %0 pattern does not match hostnames without the domain part > https://redmine.lighttpd.net/issues/2932 > + mod_magnet: Lighttpd crashes on wrong return type in lua script > https://redmine.lighttpd.net/issues/2938 > + failed assertion on incoming bad request with server.error-handler > https://redmine.lighttpd.net/issues/2941 > + mod_wstunnel: fix wstunnel.ping-interval for big-endian architectures > https://redmine.lighttpd.net/issues/2944 > + fix abort in server.http-parseopts with url-path-2f-decode enabled > https://redmine.lighttpd.net/issues/2945 > + remove repeated slashes in server.http-parseopts with > url-path-dotseg-remove, including leading "//" > + [regression][Bisected] lighttpd uses way more memory with POST since > 1.4.52 > https://redmine.lighttpd.net/issues/2948 (closes: #954759) > + OPTIONS should return 2xx status for non-existent resources if Allow is > set > https://redmine.lighttpd.net/issues/2939 > + use high precision stat timestamp (on systems where available) in etag > + mod_authn_ldap/mod_cgi race condition, "Can't contact LDAP server" > https://redmine.lighttpd.net/issues/2940 > + SUN_LEN in sock_addr.c (1.4.53, 1.4.54) > https://redmine.lighttpd.net/issues/2962 > + Embedded vim command line in conf file with no comment (#) hangs server > https://redmine.lighttpd.net/issues/2980 > + mod_authn_gssapi: 500 if fail to delegate creds > https://redmine.lighttpd.net/issues/2967 > + mod_authn_gssapi: option to store delegated creds > https://redmine.lighttpd.net/issues/2967 > + mod_auth: require digest uri= match original URI > HTTP digest authentication not compatible with some clients > https://redmine.lighttpd.net/issues/2974 > + mod_auth: send Authentication-Info nextnonce when nonce is approaching > expiration > + mod_auth: http_auth_const_time_memeq improvement > + mod_auth: http_auth_const_time_memeq_pad() > + mod_auth: use constant time comparison when comparing digests > + stricter request header parsing: reject WS following header field-name > https://redmine.lighttpd.net/issues/2985 > + stricter request header parsing: reject Transfer-Encoding + > Content-Length > https://redmine.lighttpd.net/issues/2985 > + mod_openssl: reject invalid ALPN > + mod_accesslog: parse multiple cookies > https://redmine.lighttpd.net/issues/2986 > + preserve %2b and %2B in query string > https://redmine.lighttpd.net/issues/2999 > + mod_auth: close connection after bad password > mitigation slows down brute force password attacks > https://redmine.lighttpd.net/boards/3/topics/8885 > + do not accept() > server.max-connections > + update /var/run -> /run for systemd (closes: #929203) Contrary to the expected process, we do not fix a Debian bug of severity important or higher here, because we believe that replicating the relevant upstream issues in the Debian bts is not useful. This is already established practice for larger components such as chromium, firefox, mariadb or postgresql as far as I can see. In any case, all of the changes performed here are part of bullseye for at least two months. Let us know whether this works for you. > debdiff attached. I think it may be easier to review the contents of > the files in debian/patches to see that the patches are generally small. Glenn, this is not a debdiff. What you attached the diff containing the debian directory. What was asked for is the output of the debdiff command for two source packages: debdiff lighttpd_1.4.53-4.dsc lighttpd_1.4.53-4+deb10u1.dsc > lighttpd_1.4.53-4+deb10u1.debdiff This is very briefly mentioned in the developers reference section 5.5.1. If you think that the text is ambiguous there, I suggest opening a bug against developers-reference to improve the wording there. A possible
Bug#950151: Fwd: transition: pkg-js-tools
Control: clone -1 -2 -3 -4 -5 Control: submitter -2 ! Control: submitter -3 ! Control: submitter -4 ! Control: submitter -5 ! Control: reassign -2 dolphin-owncloud Control: retitle -2 confuses DEB_HOST_MULTIARCH and DEB_HOST_GNU_TYPE Control: reassign -3 fswatch Control: retitle -3 confuses DEB_HOST_MULTIARCH and DEB_HOST_GNU_TYPE Control: reassign -4 libhmsbeagle-dev Control: retitle -4 confuses DEB_HOST_MULTIARCH and DEB_HOST_GNU_TYPE Control: reassign -5 likwid Control: retitle -5 confuses DEB_HOST_MULTIARCH and DEB_HOST_GNU_TYPE Hi Paul, On Fri, Jan 31, 2020 at 02:18:29PM +0100, Paul Gevers wrote: > >> dolphin-owncloud Buggy: https://sources.debian.org/src/owncloud-client/2.5.1.10973+dfsg-1/debian/rules/#L12 > >> fswatch Buggy: https://sources.debian.org/src/fswatch/1.14.0+repack-13/debian/rules/#L16 > >> libhmsbeagle-dev Buggy: https://sources.debian.org/src/libhmsbeagle/3.1.2+dfsg-7/debian/rules/#L66 > >> likwid Buggy: https://sources.debian.org/src/likwid/4.3.3+dfsg1-1/debian/rules/#L19 > I scheduled the node pages on this list (minus node-node-sass, it > FTBFS). Do these non-node packages need inspection first? The non-node ones need sourceful uploads. Helmut
Bug#950151: Fwd: transition: pkg-js-tools
Hi Xavier, On Wed, Jan 29, 2020 at 06:54:36PM +0100, Xavier wrote: > FYI, I opened a transition BTS to fix bad install to i386 arch > (DEB_HOST_MULTIARCH problem) If you tell me about a bug report, please include the bug number. You can even do so in the initial submission using X-Debbugs-Cc. > I didn't find in doc how to discriminate afected packages. The only way to > see if a package is OK is to look at > `debc|grep usr/lib/i686-linux-gnu/nodejs`: files have to be installed in > usr/lib/i386-linux-gnu instead. The multiarch hinter has the relevant data for unstable: SELECT distinct package.name FROM package JOIN content ON content.pid = package.id WHERE architecture = 'i386' AND filename LIKE './usr/lib/i686-linux-gnu/%'; dolphin-owncloud fswatch libhmsbeagle-dev likwid node-iconv node-modern-syslog node-node-sass node-nodedbi node-re2 node-sqlite3 node-ws node-zipfile This looks like very few affected packages and it is strictly providing an upper bound. The non-node packages are likely just buggy. Unless I am mistaken, lintian also has a tag for this symptom, but I cannot find it at the moment. Helmut
Bug#948589: nmu: file_1:5.38-3
Hi, On Fri, Jan 10, 2020 at 04:58:22PM +0100, Christoph Biedl wrote: > This leaves me somewhat confused since I understand your rationale > the file package needs itself to be built, in other words, a circular > build dependency. This should not happen, and I'd like to eliminate > that. > > Mind to shed some light on this? How was libmagic wrongly built, how did > this manifest? Well, the circle is implicit. file is used by debhelper/dpkg to generate shared library dependencies. libmagic1 misses its library dependencies on a number of architectures. Aurelien suggested that someone greps .buildinfo files on coccia for packages built with 1:5.38-2: ./01/06/girara_0.3.4-1_all.buildinfo ./01/06/girara_0.3.4-1_amd64.buildinfo ./01/06/girara_0.3.4-1_arm64.buildinfo ./01/06/girara_0.3.4-1_armel.buildinfo ./01/06/file_5.38-3_amd64.buildinfo ./01/06/file_5.38-3_arm64.buildinfo ./01/06/girara_0.3.4-1_armhf.buildinfo ./01/06/girara_0.3.4-1_i386.buildinfo ./01/06/file_5.38-3_armel.buildinfo ./01/06/girara_0.3.4-1_ppc64el.buildinfo ./01/06/girara_0.3.4-1_s390x.buildinfo ./01/06/file_5.38-3_armhf.buildinfo ./01/06/file_5.38-3_i386.buildinfo ./01/06/file_5.38-3_mips64el.buildinfo ./01/06/file_5.38-3_ppc64el.buildinfo ./01/06/file_5.38-3_s390x.buildinfo ./01/06/python3.8_3.8.1-2_amd64.buildinfo Looks like we want to binNMU girara and python3.8 as well. Helmut
Bug#948589: nmu: file_1:5.38-3
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Control: affects -1 + libmagic1 nmu file_1:5.38-3 . ANY . unstable . -m "rebuild with a #948269 fixed file" The file package was built with a broken version file wrt #948269. As such libmagic1 lacks shared library dependencies. A simple rebuild fixes the problem. Helmut
Bug#940992: firefoxdriver: does not work with firefox > 47 at all
Package: firefoxdriver Version: 3.14.1-1 Severity: grave Justification: unusable by everyone This is what happens when you try to use firefoxdriver in the most obvious way from python on buster: | $ dpkg -l python3-selenium | ... | ii python3-selenium 3.14.1+dfsg1-1 all Python3 bindings for Selenium | $ python3 | Python 3.7.3 (default, Apr 3 2019, 05:39:12) | [GCC 8.3.0] on linux | Type "help", "copyright", "credits" or "license" for more information. | >>> import selenium.webdriver | >>> selenium.webdriver.Firefox() | Traceback (most recent call last): | File "/usr/lib/python3/dist-packages/selenium/webdriver/common/service.py", line 76, in start | stdin=PIPE) | File "/usr/lib/python3.7/subprocess.py", line 775, in __init__ | restore_signals, start_new_session) | File "/usr/lib/python3.7/subprocess.py", line 1522, in _execute_child | raise child_exception_type(errno_num, err_msg, err_filename) | FileNotFoundError: [Errno 2] No such file or directory: 'geckodriver': 'geckodriver' | | During handling of the above exception, another exception occurred: | | Traceback (most recent call last): | File "", line 1, in | File "/usr/lib/python3/dist-packages/selenium/webdriver/firefox/webdriver.py", line 164, in __init__ | self.service.start() | File "/usr/lib/python3/dist-packages/selenium/webdriver/common/service.py", line 83, in start | os.path.basename(self.path), self.start_error_message) | selenium.common.exceptions.WebDriverException: Message: 'geckodriver' executable needs to be in PATH. | | >>> A little research reveals that this problem already has surfaced elsewhere e.g. at https://askubuntu.com/questions/1104721/sudo-apt-install-firefoxdriver-does-what. A more detailed answer at https://stackoverflow.com/questions/43272919/difference-between-webdriver-firefox-marionette-webdriver-gecko-driver/43920453 indicates that the extenstion-powered method employed by firefoxdriver only works until firefox 47. Later versions need "marionette" which usually manifestst as "geckodriver" which is missing from the firefoxdriver package. Given that even old-old-stable has firefox 52 already, I think we can safely conclude that the present firefoxdriver is broken for everyone. For unstable, I guess geckodriver needs to be packaged. For buster it may be best to simply remove the package in a point release. Also an autopkgtest would be a very good addition for this package to catch similar issues earlier. Helmut
Bug#929917: unblock: tt-rss/18.12+dfsg-1.1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package tt-rss
The updated package fixes #923661, which practically breaks the default
installation (i.e. mysql, not postgresql). The actual failure is a
regression triggered by updating PHP to 7.3 in the sql logging backend.
The upload fixes the relevant php code and additionally defaults to
logging to syslog. Doing so is more in line with best practises and
avoids the previously problematic sql logging code. Sebastian Reichel
(maintainer) agreed with that change, but presently lacks time.
unblock tt-rss/18.12+dfsg-1.1
Helmut
diff --minimal -Nru tt-rss-18.12+dfsg/debian/changelog
tt-rss-18.12+dfsg/debian/changelog
--- tt-rss-18.12+dfsg/debian/changelog 2019-02-06 00:04:47.0 +0100
+++ tt-rss-18.12+dfsg/debian/changelog 2019-06-03 06:15:55.0 +0200
@@ -1,3 +1,11 @@
+tt-rss (18.12+dfsg-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload acknowledged by Sebastian Reichel.
+ * Cherry pick JShrink PHP 7.3 compatibility patch. (Closes: #923661)
+ * Default to using syslog as log backend rather than sql.
+
+ -- Helmut Grohne Mon, 03 Jun 2019 06:15:55 +0200
+
tt-rss (18.12+dfsg-1) unstable; urgency=medium
* New upstream release
diff --minimal -Nru tt-rss-18.12+dfsg/debian/patches/config.php-dist.patch
tt-rss-18.12+dfsg/debian/patches/config.php-dist.patch
--- tt-rss-18.12+dfsg/debian/patches/config.php-dist.patch 2019-02-06
00:04:47.0 +0100
+++ tt-rss-18.12+dfsg/debian/patches/config.php-dist.patch 2019-06-03
06:14:40.0 +0200
@@ -6,10 +6,8 @@
Author: Sebastian Reichel
Last-Update: 2013-02-17
-Index: tt-rss/config.php-dist
-===
tt-rss.orig/config.php-dist
-+++ tt-rss/config.php-dist
+--- tt-rss-18.12+dfsg.orig/config.php-dist
tt-rss-18.12+dfsg/config.php-dist
@@ -3,12 +3,13 @@
// *** Database configuration (important!) ***
// ***
@@ -44,3 +42,12 @@
// Local cache directory for RSS feed content.
define('ICONS_DIR', "feed-icons");
+@@ -165,7 +166,7 @@
+ // Disabling auth_internal in this list would automatically disable
+ // reset password link on the login form.
+
+- define('LOG_DESTINATION', 'sql');
++ define('LOG_DESTINATION', 'syslog');
+ // Error log destination to use. Possible values: sql (uses internal
logging
+ // you can read in Preferences -> System), syslog - logs to system log.
+ // Setting this to blank uses PHP logging (usually to http server
diff --minimal -Nru tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch
tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch
--- tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch 1970-01-01
01:00:00.0 +0100
+++ tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch 2019-06-03
06:15:08.0 +0200
@@ -0,0 +1,30 @@
+From 91105810dafedba0390608d7465abd602beb6410 Mon Sep 17 00:00:00 2001
+From: Sergei Morozov
+Date: Fri, 14 Sep 2018 19:55:03 -0700
+Subject: [PATCH] Fixed test failures on PHP 7.3
+
+1. continue in break shoud target the while loop directly
(php/php-src@04e3523).
+2. strpos() doesn't longer accept non-string needles
(https://wiki.php.net/rfc/deprecations_php_7_3#string_search_functions_with_integer_needle).
+ src/JShrink/Minifier.php | 4 ++--
+ 2 files changed, 4 insertions(+), 3 deletions(-)
+
+--- tt-rss-18.12+dfsg.orig/vendor/JShrink/Minifier.php
tt-rss-18.12+dfsg/vendor/JShrink/Minifier.php
+@@ -181,7 +181,7 @@
+ // new lines
+ case "\n":
+ // if the next line is something that can't stand alone
preserve the newline
+-if (strpos('(-+{[@', $this->b) !== false) {
++if ($this->b !== false && strpos('(-+{[@', $this->b) !==
false) {
+ echo $this->a;
+ $this->saveString();
+ break;
+@@ -224,7 +224,7 @@
+ // check for some regex that breaks stuff
+ if ($this->a === '/' && ($this->b === '\'' ||
$this->b === '"')) {
+ $this->saveRegex();
+-continue;
++continue 3;
+ }
+
+ echo $this->a;
diff --minimal -Nru tt-rss-18.12+dfsg/debian/patches/series
tt-rss-18.12+dfsg/debian/patches/series
--- tt-rss-18.12+dfsg/debian/patches/series 2019-02-06 00:04:47.0
+0100
+++ tt-rss-18.12+dfsg/debian/patches/series 2019-06-03 06:14:46.0
+0200
@@ -1,3 +1,4 @@
config.php-dist.patch
remove-tt-rss-layer.patch
fix-db-updater-script.patch
+jshrink_php7.3_fix.patch
Bug#927294: unblock: lighttpd/1.4.53-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package lighttpd
The upload fixes a security issue (crash) in a non-default
configuration. #926885 aka CVE-2019-11072. In addition, this update
fixes a number of other crashes which total to 5 patches some of which
include new test cases. We hope that these patches are acceptable for
buster. Please let us know if we need to reduce them. You'll find the
full .debdiff attached for review.
unblock lighttpd/1.4.53-4
Helmut
diff --minimal -Nru lighttpd-1.4.53/debian/changelog
lighttpd-1.4.53/debian/changelog
--- lighttpd-1.4.53/debian/changelog2019-02-23 08:51:11.0 +0100
+++ lighttpd-1.4.53/debian/changelog2019-04-13 06:00:00.0 +0200
@@ -1,3 +1,15 @@
+lighttpd (1.4.53-4) unstable; urgency=high
+
+ * QA upload.
+ * fix mixed use of srv->split_vals array (regression)
+ * mod_magnet:fix invalid script return-type crash
+ * fix assertion with server.error-handler
+ * mod_wstunnel:fix wstunnel.ping-interval for big-endian architectures
+ * fix abort in server.http-parseopts with url-path-2f-decode enabled
+CVE-2019-11072 (closes: #926885)
+
+ -- Glenn Strauss Sat, 13 Apr 2019 00:00:00 -0400
+
lighttpd (1.4.53-3) unstable; urgency=medium
* QA upload.
diff --minimal -Nru lighttpd-1.4.53/debian/lighttpd.conf
lighttpd-1.4.53/debian/lighttpd.conf
--- lighttpd-1.4.53/debian/lighttpd.conf2019-01-28 12:33:22.0
+0100
+++ lighttpd-1.4.53/debian/lighttpd.conf2019-04-13 06:00:00.0
+0200
@@ -26,7 +26,7 @@
"url-ctrls-reject"=> "enable",# recommended
"url-path-2f-decode" => "enable",# recommended highly (unless breaks
app)
#"url-path-2f-reject" => "enable",
- "url-path-dotseg-remove" => "enable",# recommended
+ "url-path-dotseg-remove" => "enable",# recommended highly (unless breaks
app)
#"url-path-dotseg-reject" => "enable",
#"url-query-20-plus" => "enable",# consistency in query string
)
diff --minimal -Nru
lighttpd-1.4.53/debian/patches/core-fix-abort-in-http-parseopts-fixes-2945.patch
lighttpd-1.4.53/debian/patches/core-fix-abort-in-http-parseopts-fixes-2945.patch
---
lighttpd-1.4.53/debian/patches/core-fix-abort-in-http-parseopts-fixes-2945.patch
1970-01-01 01:00:00.0 +0100
+++
lighttpd-1.4.53/debian/patches/core-fix-abort-in-http-parseopts-fixes-2945.patch
2019-04-13 06:00:00.0 +0200
@@ -0,0 +1,44 @@
+commit 32120d5b8b3203fc21ccb9eafb0eaf824bb59354
+Author: Glenn Strauss
+Date: Wed, 10 Apr 2019 11:28:10 -0400
+
+[core] fix abort in http-parseopts (fixes #2945)
+
+fix abort in server.http-parseopts with url-path-2f-decode enabled
+
+(thx stze)
+
+x-ref:
+ "Security - SIGABRT during GET request handling with url-path-2f-decode
enabled"
+ https://redmine.lighttpd.net/issues/2945
+
+diff --git a/src/burl.c b/src/burl.c
+index 51182628..c4b928fd 100644
+--- a/src/burl.c
b/src/burl.c
+@@ -252,8 +252,10 @@ static int burl_normalize_2F_to_slash_fix (buffer *b, int
qs, int i)
+ }
+ }
+ if (qs >= 0) {
+-memmove(s+j, s+qs, blen - qs);
+-j += blen - qs;
++const int qslen = blen - qs;
++memmove(s+j, s+qs, (size_t)qslen);
++qs = j;
++j += qslen;
+ }
+ buffer_string_set_length(b, j);
+ return qs;
+diff --git a/src/t/test_burl.c b/src/t/test_burl.c
+index 7be9be50..f7a16815 100644
+--- a/src/t/test_burl.c
b/src/t/test_burl.c
+@@ -97,6 +97,8 @@ static void test_burl_normalize (void) {
+ flags |= HTTP_PARSEOPT_URL_NORMALIZE_PATH_2F_DECODE;
+ run_burl_normalize(psrc, ptmp, flags, __LINE__,
CONST_STR_LEN("/a/b?c=/"), CONST_STR_LEN("/a/b?c=/"));
+ run_burl_normalize(psrc, ptmp, flags, __LINE__,
CONST_STR_LEN("/a/b?c=%2f"), CONST_STR_LEN("/a/b?c=/"));
++run_burl_normalize(psrc, ptmp, flags, __LINE__, CONST_STR_LEN("%2f?"),
CONST_STR_LEN("/?"));
++run_burl_normalize(psrc, ptmp, flags, __LINE__, CONST_STR_LEN("/%2f?"),
CONST_STR_LEN("//?"));
+ run_burl_normalize(psrc, ptmp, flags, __LINE__, CONST_STR_LEN("/a%2fb"),
CONST_STR_LEN("/a/b"));
+ run_burl_normalize(psrc, ptmp, flags, __LINE__, CONST_STR_LEN("/a%2Fb"),
CONST_STR_LEN("/a/b"));
+ run_burl_normalize(psrc, ptmp, flags, __LINE__,
CONST_STR_LEN("/a%2fb?c=/"), CONST_STR_LEN("/a/b?c=/"));
diff --minimal -Nru
lighttpd-1.4.53/debian/patches/core-fix-assertion-with-server.error-handler-fixes-2.patch
lighttpd-1.4.53/debian/patches/core-fix-assertion-with-server.error-handler-fixes-2.patch
---
lighttpd-1.4.53/debian/patches/core-fix-assertion-with-server.error-handler-fixes-2.patch
1970-01-01 01:00:00.0 +0100
+++
lighttpd-1.4.53/debian/patches/core-fix-assertion-with-server.error-handler-fixes-2.patch
2019-04-13 06:00:00.0 +0200
@@ -0,0 +1,25 @@
+commit 5440f04e8a9476e9a8665a93db3934a566f8beec
+Author: Glenn Strauss
+Date: Wed, 13 Mar 2019 00:46:49 -0400
+
+[core] fix
Bug#927051: unblock: cross-gcc/230
nstall-location-patch.patch 2019-03-27 17:18:10.0 +0100 @@ -1,4 +1,4 @@ -From 70052b73c166b011f75e6824509c0e769e4fa0c6 Mon Sep 17 00:00:00 2001 +From 39d4f354c25bbaaa7b51f25fb8a36b9bbd4c764d Mon Sep 17 00:00:00 2001 From: Dima Kogan Date: Mon, 15 Dec 2014 14:48:09 -0800 Subject: [PATCH 04/10] added multi-arch-specific install-location patch @@ -397,10 +397,10 @@ + case $multi_os_directory in + .) ;; # Avoid trailing /. diff --git a/debian/rules.patch b/debian/rules.patch -index 6ff8b44..f69f6dd 100644 +index cf61486..e6f5bc6 100644 --- a/debian/rules.patch +++ b/debian/rules.patch -@@ -251,9 +251,13 @@ debian_patches += arm-multilib-defaults +@@ -252,9 +252,13 @@ debian_patches += arm-multilib-defaults ifeq ($(DEB_CROSS),yes) debian_patches += cross-fixes diff --minimal -Nru cross-gcc-226/patches/gcc-7/0005-setting-all-the-various-paths-options-for-with_deps_.patch cross-gcc-230/patches/gcc-7/0005-setting-all-the-various-paths-options-for-with_deps_.patch --- cross-gcc-226/patches/gcc-7/0005-setting-all-the-various-paths-options-for-with_deps_.patch 2019-02-17 02:54:26.0 +0100 +++ cross-gcc-230/patches/gcc-7/0005-setting-all-the-various-paths-options-for-with_deps_.patch 2019-03-27 17:18:10.0 +0100 @@ -1,4 +1,4 @@ -From e8dac0a6a2b4616f063430142f3f75ded58d717b Mon Sep 17 00:00:00 2001 +From b77f7d7af2bd3a8c32a70780a55f937f720b26f0 Mon Sep 17 00:00:00 2001 From: Dima Kogan Date: Sun, 3 May 2015 19:28:33 -0700 Subject: [PATCH 05/10] setting all the various paths, options for diff --minimal -Nru cross-gcc-226/patches/gcc-7/0006-Allow-target-selection-via-dpkg-buildpackage-target-.patch cross-gcc-230/patches/gcc-7/0006-Allow-target-selection-via-dpkg-buildpackage-target-.patch --- cross-gcc-226/patches/gcc-7/0006-Allow-target-selection-via-dpkg-buildpackage-target-.patch 2019-02-17 02:54:26.0 +0100 +++ cross-gcc-230/patches/gcc-7/0006-Allow-target-selection-via-dpkg-buildpackage-target-.patch 2019-03-27 17:18:10.0 +0100 @@ -1,4 +1,4 @@ -From 6bf0b33e2fd6193c4ed79f3c3e951ff6e97edaba Mon Sep 17 00:00:00 2001 +From 28884a4559c3d43af43debd681f0c7fbb9e2e663 Mon Sep 17 00:00:00 2001 From: Helmut Grohne Date: Thu, 18 Dec 2014 14:39:19 -0800 Subject: [PATCH 06/10] Allow target selection via dpkg-buildpackage diff --minimal -Nru cross-gcc-226/patches/gcc-7/0007-Skip-libjit-when-we-re-cross-building.patch cross-gcc-230/patches/gcc-7/0007-Skip-libjit-when-we-re-cross-building.patch --- cross-gcc-226/patches/gcc-7/0007-Skip-libjit-when-we-re-cross-building.patch 2019-02-17 02:54:26.0 +0100 +++ cross-gcc-230/patches/gcc-7/0007-Skip-libjit-when-we-re-cross-building.patch 2019-03-27 17:18:10.0 +0100 @@ -1,4 +1,4 @@ -From 79da7cb24cad81737e73fed59e134087455a9a88 Mon Sep 17 00:00:00 2001 +From a0063698227706da29aa763795502b74af3e5ddf Mon Sep 17 00:00:00 2001 From: Dima Kogan Date: Mon, 27 Apr 2015 11:08:31 -0700 Subject: [PATCH 07/10] Skip libjit when we're cross-building diff --minimal -Nru cross-gcc-226/patches/gcc-7/0008-g-include-directories-functional-again.patch cross-gcc-230/patches/gcc-7/0008-g-include-directories-functional-again.patch --- cross-gcc-226/patches/gcc-7/0008-g-include-directories-functional-again.patch 2019-02-17 02:54:26.0 +0100 +++ cross-gcc-230/patches/gcc-7/0008-g-include-directories-functional-again.patch 2019-03-27 17:18:10.0 +0100 @@ -1,4 +1,4 @@ -From 15289b7e0594734a483590c4ad73245b3718ba31 Mon Sep 17 00:00:00 2001 +From 4b8c908806ee41b55433c9c98e8693eda2c4f482 Mon Sep 17 00:00:00 2001 From: Dima Kogan Date: Wed, 29 Apr 2015 16:56:53 -0700 Subject: [PATCH 08/10] g++ include directories functional again diff --minimal -Nru cross-gcc-226/patches/gcc-7/0009-gcc-.-base-dependencies-reverted-to-gcc-VER-base-whe.patch cross-gcc-230/patches/gcc-7/0009-gcc-.-base-dependencies-reverted-to-gcc-VER-base-whe.patch --- cross-gcc-226/patches/gcc-7/0009-gcc-.-base-dependencies-reverted-to-gcc-VER-base-whe.patch 2019-02-17 02:54:26.0 +0100 +++ cross-gcc-230/patches/gcc-7/0009-gcc-.-base-dependencies-reverted-to-gcc-VER-base-whe.patch 2019-03-27 17:18:10.0 +0100 @@ -1,4 +1,4 @@ -From e42921f655aec2d60e0ea2007d93ffceb31a8225 Mon Sep 17 00:00:00 2001 +From 3e8f3433e844ea05f2326d33dd6f55e7990b450d Mon Sep 17 00:00:00 2001 From: Dima Kogan Date: Tue, 26 May 2015 01:12:13 -0700 Subject: [PATCH 09/10] gcc-...-base dependencies reverted to gcc-VER-base when diff --minimal -Nru cross-gcc-226/patches/gcc-7/0010-base-now-part-of-lib_binaries-again-not-arch_binarie.patch cross-gcc-230/patches/gcc-7/0010-base-now-part-of-lib_binaries-again-not-arch_binarie.patch --- cross-gcc-226/patches/gcc-7/0010-base-now-part-of-lib_binaries-again-not-arch_binarie.patch 2019-02-17 02:54:26.0 +0100 +++ cross-gcc-230/patches/gcc-7/0010-base-now-part-of-lib_binaries-again-not-arch_binarie.patch 2019-03-27 17:18:10.0 +0100 @@
Bug#926690: unblock: pillow/5.4.1-2
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package pillow
Matthias fixed the important bug #926552 (fails loading some PNG files)
in pillow/5.4.1-2. While the bug is not release critical, it breaks
operation of dedup.debian.net. The bug is well understood upstream and
Matthias essentially cherry-picked the relevant upstream patch. Would
you consider including this change in buster?
unblock pillow/5.4.1-2
Thank you for considering
Helmut
diff --minimal -Nru pillow-5.4.1/debian/changelog pillow-5.4.1/debian/changelog
--- pillow-5.4.1/debian/changelog 2019-01-18 11:05:56.0 +0100
+++ pillow-5.4.1/debian/changelog 2019-04-07 02:53:28.0 +0200
@@ -1,3 +1,9 @@
+pillow (5.4.1-2) unstable; urgency=medium
+
+ * Allow for unknown PNG chunks after image data. Closes: #926552.
+
+ -- Matthias Klose Sun, 07 Apr 2019 02:53:28 +0200
+
pillow (5.4.1-1) unstable; urgency=medium
* New upstream version.
diff --minimal -Nru
pillow-5.4.1/debian/patches/4e0a73b4faf4c0b16c6b3912b64f4ad7a6c99acf.diff
pillow-5.4.1/debian/patches/4e0a73b4faf4c0b16c6b3912b64f4ad7a6c99acf.diff
--- pillow-5.4.1/debian/patches/4e0a73b4faf4c0b16c6b3912b64f4ad7a6c99acf.diff
1970-01-01 01:00:00.0 +0100
+++ pillow-5.4.1/debian/patches/4e0a73b4faf4c0b16c6b3912b64f4ad7a6c99acf.diff
2019-04-07 02:53:18.0 +0200
@@ -0,0 +1,43 @@
+Allow for unknown PNG chunks after image data
+
+diff --git a/Tests/test_file_png.py b/Tests/test_file_png.py
+index c94f8eaad..84017 100644
+--- a/Tests/test_file_png.py
b/Tests/test_file_png.py
+@@ -596,6 +596,7 @@ def test_apng(self):
+ im = Image.open("Tests/images/iss634.apng")
+ self.assertEqual(im.get_format_mimetype(), 'image/apng')
+
++# This also tests reading unknown PNG chunks (fcTL and fdAT) in
load_end
+ expected = Image.open("Tests/images/iss634.webp")
+ self.assert_image_similar(im, expected, 0.23)
+
+diff --git a/src/PIL/PngImagePlugin.py b/src/PIL/PngImagePlugin.py
+index f3a2eaf21..0669ab216 100644
+--- a/src/PIL/PngImagePlugin.py
b/src/PIL/PngImagePlugin.py
+@@ -533,14 +533,6 @@ def chunk_acTL(self, pos, length):
+ self.im_custom_mimetype = 'image/apng'
+ return s
+
+-def chunk_fcTL(self, pos, length):
+-s = ImageFile._safe_read(self.fp, length)
+-return s
+-
+-def chunk_fdAT(self, pos, length):
+-s = ImageFile._safe_read(self.fp, length)
+-return s
+-
+
+ #
+ # PNG reader
+@@ -682,6 +674,9 @@ def load_end(self):
+ break
+ except EOFError:
+ ImageFile._safe_read(self.fp, length)
++except AttributeError:
++logger.debug("%r %s %s (unknown)", cid, pos, length)
++ImageFile._safe_read(self.fp, length)
+ self._text = self.png.im_text
+ self.png.close()
+ self.png = None
diff --minimal -Nru pillow-5.4.1/debian/patches/series
pillow-5.4.1/debian/patches/series
--- pillow-5.4.1/debian/patches/series 2019-01-18 11:05:56.0 +0100
+++ pillow-5.4.1/debian/patches/series 2019-04-07 02:53:28.0 +0200
@@ -1,3 +1,4 @@
toplevel-setup.py
generate-webp-file
js-script-file.diff
+4e0a73b4faf4c0b16c6b3912b64f4ad7a6c99acf.diff
Bug#924683: binnmus for multiarch coinstallability
Hi Ivo,
On Sun, Mar 17, 2019 at 10:48:52AM +0100, Ivo De Decker wrote:
> Just out of curiosity:
>
> What query did you use to generate this list?
This list was generated manually. I started with the dose results from
my cross buildd and filtered for reasons with "skew". That gave me a
list of binary packages + affected source packages. Then I went to
buildd.debian.org and checked which archs needed syncing. Given the low
number, I didn't automate it beyond this.
If you want to sync up packages regularly, I'd expect that a udd query
can produce such a list.
The following query could serve as a starting point:
select pa.package, pa.architecture, pa.version, pb.version, pb.architecture
from packages as pa join packages as pb on pa.package = pb.package where
pa.release = 'sid' and pb.release = 'sid' and pa.version < pb.version and
pa.architecture in ('amd64', 'arm64', 'armel', 'armhf', 'mips', 'mipsel',
'mips64el', 's390x', 'ppc64el', 'i386') and pb.architecture in ('amd64',
'arm64', 'armel', 'armhf', 'mips', 'mipsel', 'mips64el', 's390x', 'ppc64el',
'i386') and (pa.version like '%+b%' or pb.version like '%+b%');
Helmut
Bug#924683: binnmus for multiarch coinstallability
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Dear release team, We don't epxect much churn in unstable anymore, so it is a good time to cover up for past mistakes in binNMUing Multi-Arch: same packages and make them coinstallable again. I know that you dislike excessive binNMUs just to get the versions right, but the last time I asked was before the release of stretch. It turns out than there are only 7 skewed packages left. Would you be so kind and binNMU them to make their versions match? # 61 affected nmu libxt . amd64 arm64 armel armhf i386 mips64el ppc64el s390x . unstable . -m "multiarch sync" # 32 affected nmu libxdamage . amd64 arm64 armel armhf i386 mips mipsel ppc64el s390x . unstable . -m "multiarch sync" # 19 affected nmu rustc . amd64 arm64 armel armhf i386 mips64el ppc64el s390x . unstable . -m "multiarch sync" # 8 affected nmu libxkbfile . amd64 arm64 armel armhf i386 mips64el ppc64el s390x . unstable . -m "multiarch sync" # 5 affected nmu libxmu . amd64 arm64 armel armhf i386 mips64el ppc64el s390x . unstable . -m "multiarch sync" # 3 affected nmu libidl . amd64 arm64 armel armhf i386 mips64el ppc64el s390x . unstable . -m "multiarch sync" # 1 affected nmu libglu . amd64 arm64 armel armhf i386 mips64el ppc64el s390x . unstable . -m "multiarch sync" I expect this to be my only binNMU request for multiarch syncing during the buster cycle. Helmut
Bug#883533: nmu: db5.3, tcl8.6, libjpeg-turbo, wayland, fftw3, nspr, libgudev, tk8.6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu I would like to ask for binNMUing 8 packages. All of them happen to be +b1 for mips64el and "normal" for all other architectures. Fixing these resolves all binNMU-induced skews affecting dependency satisfaction of source packages with popcon of at least 8000, so this limited set has a noticeable impact to cross build QA. I hope I got the wanna-build invocation right: nmu db5.3_5.3.28-13.1 . ANY -mips64el . -m "unskew multiarch" nmu tcl8.6_8.6.7+dfsg-1 . ANY -mips64el . -m "unskew multiarch" nmu libjpeg-turbo_1:1.5.2-2 . ANY -mips64el . -m "unskew multiarch" nmu wayland_1.14.0-1 . ANY -mips64el . -m "unskew multiarch" nmu fftw3_3.3.6p2-2 . ANY -mips64el . -m "unskew multiarch" nmu nspr_2:4.16-1 . ANY -mips64el . -m "unskew multiarch" nmu libgudev_232-1 . ANY -mips64el . -m "unskew multiarch" nmu tk8.6_8.6.7-1 . ANY -mips64el . -m "unskew multiarch" Barring errors with binNMU handling of M-A:same packages, I don't expect to send more of such batches. This is the big fish to me. Most other skews I am seeing are caused by arch-specific FTBFS. Scheduling them at low priority is fine. QA will benefit as soon as they hit unstable. Helmut
Re: Bug#857296: [hol88-library] hol88-library is an empty package on arm64, hppa, and m68k
severity -1 serious thanks On Tue, Mar 21, 2017 at 01:32:55PM -0400, Camm Maguire wrote: > Greetings and thanks for your report! Am looking into this now It seems your looking takes longer than expected and you didn't give any reason for downgrading the severity. I don't think stretch should release with such a broken hol88-library. This bug is release-critical for two reasons: * The arm64 package is completely useless (actually qualifies for grave). * It violates policy by not checking for build failures. So given little maintainer interest, I hereby ask the autoremover to do its work. Helmut
Bug#856050: unblock: pkgconf/0.9.12-3
On Sun, Feb 26, 2017 at 01:44:17PM +0100, Andrew Shadura wrote: > On 26/02/17 11:19, Niels Thykier wrote: > > Andrew Shadura: > >> Niels, Helmut, how about the diff I attached? > > > Ok with me. > > I forgot one bit, which is renaming /usr/lib/pkg-config.multiarch to > /usr/lib/pkgconf.multiarch. For consistency, I think you should also rename pkg-config-crosswrapper to pkgconf-crosswrapper (and thus remove a diversion). As long as it succeeds the dpkg --unpack test, it should be technically fine though. I didn't perform the test on -4, because it didn't hit my mirror yet. Another test to perform could be cross building a reverse dependency of pkg-config with pkgconf. That can be done using sbuild, by passing --host=$arch (choosing $arch from armel, armhf, mipsel, arm64, ppc64el) and --add-depends=pkgconf. I didn't perform one. pkg-config users that should just work include pam, dpkg, and apt. Helmut
Bug#856050: unblock: pkgconf/0.9.12-3
On Sat, Feb 25, 2017 at 04:14:11PM +0100, Andrew Shadura wrote: > On 25/02/17 08:35, Niels Thykier wrote: > > I got one question about the "Breaks". Why Breaks and why a versioned > > breaks rather than an unconditional Conflicts? AFAICT, pkgconf attempts > > to be an "mutually exclusive alternative" to pkg-config (a la exim vs. > > postfix). The reason for me proposing breaks instead of conflicts was that unpacking both packages can actually work (due to the use of diversions), whereas running both maintainer scripts ends up in unpredictable chaos (both managing the same set of symlinks). We know that conflicts are harder to solve by apt and thus - generally - have a slight preference on using breaks. > Hmm, honestly, I'm not sure what's better in this case. In #842529, > Helmut mentioned Breaks, so I just went with that. As it is now, pkgconf > is still co-installable with earlier versions of pkg-config (diversions > are still in place), but the symlinks make it not possible to have both > pkg-config 0.29-1 and pkgconf installed (and that's not really needed > anymore as I added the versioned Provides). The version restriction initially confused me, but the explanation makes sense to me. > If you think Conflicts is more appropriate, I may add change that in the > upload to unstable. > > Helmut, what's your opinion, by the way? I don't think that it matters much in this case. I imagine that breaks vs replaces is not going to make a big difference for apt here. Whether to use the weakest form (versioned breaks) or a strong form (conflicts) is up to you. Looking at the experimental binary package however, I note that I fail to find a diversion for pkg-config-dpkghook and its hook-config. Thus the experimental package would actually need a conflicts relation now. See e.g.: | # dpkg -B --unpack pkgconf_0.9.12-2_amd64.deb | dpkg: considering deconfiguration of pkg-config, which would be broken by installation of pkgconf ... | dpkg: yes, will deconfigure pkg-config (broken by pkgconf) | (Reading database ... 9798 files and directories currently installed.) | Preparing to unpack pkgconf_0.9.12-2_amd64.deb ... | De-configuring pkg-config (0.29-4) ... | Adding 'diversion of /usr/bin/pkg-config to /usr/bin/pkg-config.real by pkgconf' | Adding 'diversion of /usr/share/aclocal/pkg.m4 to /usr/share/aclocal/pkg.real.m4 by pkgconf' | Adding 'diversion of /usr/share/man/man1/pkg-config.1.gz to /usr/share/man/man1/pkg-config.real.1.gz by pkgconf' | Adding 'diversion of /usr/share/pkg-config-crosswrapper to /usr/share/pkg-config-crosswrapper.real by pkgconf' | Unpacking pkgconf (0.9.12-2) ... | dpkg: error processing archive pkgconf_0.9.12-2_amd64.deb (--unpack): | trying to overwrite '/etc/dpkg/dpkg.cfg.d/pkg-config-hook-config', which is also in package pkg-config 0.29-4 | Errors were encountered while processing: | pkgconf_0.9.12-2_amd64.deb | # So I consider the experimental package rc buggy and propose either renaming the conflicting files or adding a conflicts relation. Since neither /usr/share/pkg-config-crosswrapper nor /etc/dpkg/dpkg.cfg.d/pkg-config-hook-config are part of the pkg-config API, I'd just rename both to avoid the need for diversions here. Even when using conflicts, conffiles will not go away and reusing the hook-config file from pkg-config can result in a mess of its own. So I actually recommend doing the renaming (s/pkg-config/pkgconf/) in any case (even when adding conflicts). If you end up using conflicts, all the other diversions can go away as well. Helmut
Bug#842459: nmu: zlib_1:1.2.8.dfsg-2
Hi Emilio, On Sun, Oct 30, 2016 at 11:47:35PM +0100, Emilio Pozuelo Monfort wrote: > To clarify: if this one package is blocking your cross-build efforts (which I > appreciate), I can do it. I don't want to end up doing this, then those two > other packages, then some more stuff... Instead, this should be fixed in the > right place. I hesitated quite a bit before filing this nmu request, precisely because I know that it means busywork for you. These skews are kinda frequent and mostly come and go away. Just zlib is special here in that it has a low upload frequency combined with a high impact (1/4 of the archive). I do agree that a better solution should be found. I just don't see any good solutions that could be applied. There are basically two approaches: * Whenever you nmu a Multi-Arch: same package, nmu it for all architectures. This obviously wastes buildd resources somewhat, but we know that it works. The nmu tooling would need better support for automatically handling this correctly in all cases. * Teach dpkg to coinstall different binNMU versions. I know that Guillem Jover has been slowly working towards this (e.g. by trying to turn packaging more declarative), but there are more problems outside the scope of dpkg. Multi-Arch: same requires that shared files must have exactly matching content. If one rebuilds a package with differently versioned dependencies, we risk content changes in shared files. This is not a theoretical issue (e.g. formerly libxdmcp). So even if dpkg supported this mode, we'd get binNMUs that are broken from a Multi-Arch perspective and would have to nmu them again. nmuing just zlib has a significant impact on cross build qa. I do not see nmuing Multi-Arch skews as a frequent operation. Towards the end of the freeze we should consider nmuing all remaining skews in one block. The reproducible builds folks likely also want nmus, so maybe we can consolidate them. So do you think this request is reasonable now? Either way, let's not discuss it further. Either nmu or not and close this bug. Helmut
Bug#842459: nmu: zlib_1:1.2.8.dfsg-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear release team, a significant number of packages cannot be cross built to mipsel, because their version of zlib1g is different. Even though there are a number of packages version skews, zlib is unique in that it affects very many reverse dependencies (~3000). Please consider bumping its version to make cross build testing feasible again. nmu zlib_1:1.2.8.dfsg-2+b1 . amd64 arm64 armel armhf i386 powerpc ppc64el . unstable . -m "bump to +b2 for Multi-Arch" If nmuing another package is ok, I'd suggest attr and bzip2: nmu attr_1:2.4.47-2 . amd64 arm64 armel armhf i386 powerpc ppc64el . unstable . -m "bump to +b1 for Multi-Arch" nmu bzip2_1.0.6-8 . amd64 arm64 armel armhf i386 powerpc ppc64el . unstable . -m "bump to +b1 for Multi-Arch" Thanks in advance Helmut
Bug#776321: unblock: wv/1.2.9-4.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package wv
The wv binary package links its documentation to libwv-1.2-4 without
using dh_installdocs --linkdoc and lacks the (= ${binary:Version})
dependency required by the Debian policy. #776253
I uploaded an updated wv with the maintainers permission and the
corresponding .debdiff is attached.
unblock wv/1.2.9-4.1
Helmut
diff -Nru wv-1.2.9/debian/changelog wv-1.2.9/debian/changelog
--- wv-1.2.9/debian/changelog 2014-10-02 11:35:37.0 +0200
+++ wv-1.2.9/debian/changelog 2015-01-26 20:30:49.0 +0100
@@ -1,3 +1,11 @@
+wv (1.2.9-4.1) unstable; urgency=medium
+
+ * Non-maintainer upload. Acknowledged by Daniel Walrond.
+ * Tighten dependency wv - libwv-1.2-4 to meet policy 12.3.
+(Closes: #776253)
+
+ -- Helmut Grohne hel...@subdivi.de Mon, 26 Jan 2015 20:30:47 +0100
+
wv (1.2.9-4) unstable; urgency=medium
* debian/control:
diff -Nru wv-1.2.9/debian/control wv-1.2.9/debian/control
--- wv-1.2.9/debian/control 2014-10-02 11:34:13.0 +0200
+++ wv-1.2.9/debian/control 2015-01-26 20:24:52.0 +0100
@@ -11,7 +11,7 @@
Package: wv
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}, libwv-1.2-4 (= ${binary:Version})
Suggests: texlive, ghostscript, elinks | links | lynx, imagemagick, gv |
postscript-viewer
Description: Programs for accessing Microsoft Word documents
wvWare (previously known as mswordview) is a library that allows access
Bug#775172: unblock: nettle/2.7.1-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
The nettle package in sid fixes an unhandled directory to symlink
conversion in nettle-dbg (#774919). This is a regression introduced in
2.7.1-4 which started using dh_installdocs --link-doc and was recently
unblocked.
Please find the debdiff attached. The unblock command should be:
unblock nettle/2.7.1-5
Helmut
diff -Nru nettle-2.7.1/debian/changelog nettle-2.7.1/debian/changelog
--- nettle-2.7.1/debian/changelog 2014-12-21 01:14:22.0 +0100
+++ nettle-2.7.1/debian/changelog 2015-01-11 20:27:22.0 +0100
@@ -1,3 +1,11 @@
+nettle (2.7.1-5) unstable; urgency=medium
+
+ * Add code to transition /usr/share/doc/nettle-dbg from directory to
+symlink (Closes: #774919).
+ * Also add missing Pre-Depends: multiarch-support to nettle-dbg.
+
+ -- Magnus Holmgren holmg...@debian.org Sun, 11 Jan 2015 20:27:20 +0100
+
nettle (2.7.1-4) unstable; urgency=medium
* Use dh_installdocs --link-doc to create symlinks and add correct
diff -Nru nettle-2.7.1/debian/control nettle-2.7.1/debian/control
--- nettle-2.7.1/debian/control 2014-12-21 00:42:17.0 +0100
+++ nettle-2.7.1/debian/control 2015-01-11 20:27:22.0 +0100
@@ -108,6 +108,7 @@
Section: debug
Priority: extra
Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
Depends: libnettle4 (= ${binary:Version}) | libhogweed2 (= ${binary:Version})
| nettle-bin (= ${binary:Version}), ${misc:Depends}
Description: low level cryptographic library (debugging symbols)
Nettle is a cryptographic library that is designed to fit easily in more or
diff -Nru nettle-2.7.1/debian/nettle-dbg.maintscript
nettle-2.7.1/debian/nettle-dbg.maintscript
--- nettle-2.7.1/debian/nettle-dbg.maintscript 1970-01-01 01:00:00.0
+0100
+++ nettle-2.7.1/debian/nettle-dbg.maintscript 2015-01-11 20:27:22.0
+0100
@@ -0,0 +1 @@
+dir_to_symlink /usr/share/doc/nettle-dbg libnettle4 2.7.1-5~ nettle-dbg
Bug#767846: unblock: mpd/0.19.3-1
Control: tags -1 + moreinfo
Hi Florian,
On Thu, Nov 13, 2014 at 10:22:20PM +0100, Florian Schlichting wrote:
in the meantime, another bugfix release, mpd 0.19.3 was released;
changelog below, debdiff attached. This upload would additionally fix
#768094 (important: crashes with std::logic_error on database update)
and #769436 (normal: Fails to play some audio streams)
As much as I would like to see the latest and greatest mpd in jessie, I
think that these changes are out of scope for the freeze policy (not
speaking for the release team here, but assuming that they agree).
diff -Nru mpd-0.19.1/configure.ac mpd-0.19.3/configure.ac
--- mpd-0.19.1/configure.ac 2014-10-11 20:25:57.0 +0200
+++ mpd-0.19.3/configure.ac 2014-11-05 18:24:15.0 +0100
@@ -293,7 +293,9 @@
AC_ARG_ENABLE(libmpdclient,
AS_HELP_STRING([--enable-libmpdclient],
[enable support for the MPD client]),,
- enable_libmpdclient=$database_auto)
+ enable_libmpdclient=auto)
+MPD_DEPENDS([enable_libmpdclient], [enable_database],
+ [Cannot use --enable-libmpdclient with --disable-database])
AC_ARG_ENABLE(expat,
AS_HELP_STRING([--enable-expat],
All these new MPD_DEPENDS are clearly improvements, but I don't think
this qualifies as important for jessie.
diff -Nru mpd-0.19.1/doc/doxygen.conf mpd-0.19.3/doc/doxygen.conf
--- mpd-0.19.1/doc/doxygen.conf 2014-10-11 20:26:19.0 +0200
+++ mpd-0.19.3/doc/doxygen.conf 2014-11-05 18:24:29.0 +0100
@@ -534,7 +534,7 @@
# directories like /usr/src/myproject. Separate the files or directories
# with spaces.
-INPUT = /home/max/git/mpd/src/
+INPUT = /home/max/git/stable-mpd/src/
# This tag can be used to specify the character encoding of the source files
# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is
Even though 0.19.3 claims to be a bug-fix release it contains quite a
few non-functional changes like this one.
Another recurring example of this kind is adding #ifdef HAVE_GLIB even
though Debian's mpd always enables glib.
diff -Nru mpd-0.19.1/NEWS mpd-0.19.3/NEWS
--- mpd-0.19.1/NEWS 2014-10-19 01:03:36.0 +0200
+++ mpd-0.19.3/NEWS 2014-11-11 11:21:38.0 +0100
@@ -1,3 +1,38 @@
+ver 0.19.3 (2014/11/11)
+* protocol
+ - fix (null) result string to list when AlbumArtist is disabled
+* database
+ - upnp: fix breakage due to malformed URIs
+* input
+ - curl: another fix for redirected streams
+* decoder
+ - audiofile: fix crash while playing streams
+ - audiofile: fix bit rate calculation
+ - ffmpeg: support opus
New feature.
+ - opus: fix bogus duration on streams
+ - opus: support chained streams
New feature.
+ - opus: improved error logging
+* fix distorted audio with soxr resampler
+* fix build failure on Mac OS X with non-Apple compilers
Unrelated to Debian.
diff -Nru mpd-0.19.1/src/output/plugins/RoarOutputPlugin.cxx
mpd-0.19.3/src/output/plugins/RoarOutputPlugin.cxx
--- mpd-0.19.1/src/output/plugins/RoarOutputPlugin.cxx2014-09-28
13:24:40.0 +0200
+++ mpd-0.19.3/src/output/plugins/RoarOutputPlugin.cxx2014-10-27
09:26:34.0 +0100
@@ -46,7 +46,7 @@
struct roar_connection con;
struct roar_audio_info info;
mutable Mutex mutex;
- volatile bool alive;
+ bool alive;
public:
RoarOutput()
This change seems undocumented in changelog and NEWS. It is not clear,
why this should suddenly become safe when it wasn't earlier.
diff -Nru mpd-0.19.1/src/util/UriUtil.cxx mpd-0.19.3/src/util/UriUtil.cxx
--- mpd-0.19.1/src/util/UriUtil.cxx 2014-10-10 22:43:40.0 +0200
+++ mpd-0.19.3/src/util/UriUtil.cxx 2014-11-01 12:51:30.0 +0100
@@ -54,6 +54,23 @@
return suffix;
}
+const char *
+uri_get_suffix(const char *uri, UriSuffixBuffer buffer)
+{
+ const char *suffix = uri_get_suffix(uri);
+ if (suffix == nullptr)
+ return nullptr;
+
+ const char *q = strchr(suffix, '?');
+ if (q != nullptr size_t(q - suffix) sizeof(buffer.data)) {
+ memcpy(buffer.data, suffix, q - suffix);
+ buffer.data[q - suffix] = 0;
+ suffix = buffer.data;
+ }
+
+ return suffix;
+}
+
static const char *
verify_uri_segment(const char *p)
{
Refactoring is going on here. Not bad in itself, but maybe inappropriate
for jessie.
On a whole, the size of the diff makes it hard to correlate individual
hunks to chaneglog or NEWs. This ultimately makes the diff harder to
review and goes against the freeze policy.
Violated freeze policy items:
* Do not package new upstream releases
* Document all changes verbosely
* Non-documentation changes of severity important
Based on the sheer number of violations I am tagging the bug moreinfo
already and ask you to provide less intrusive changes.
Please don't shoot the messenger. I'm trying to avoid releasing without
mpd.
Bug#767768: unblock: doxygen/1.8.8-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package doxygen
The 1.8.8-5 upload fixes two rc bugs:
#762272: Doxygen segfaults while building src:efl. Resolve by
cherry-picking upstream commit.
#767658: src:doxygen FTBFS since dpkg no longer accepts the old
Build-Profiles syntax.
Please find a .debdiff between jessie and sid attached. Unblock command
likely is:
unblock doxygen/1.8.8-5
Helmut
diff -Nru doxygen-1.8.8/debian/changelog doxygen-1.8.8/debian/changelog
--- doxygen-1.8.8/debian/changelog 2014-10-05 17:52:05.0 +0200
+++ doxygen-1.8.8/debian/changelog 2014-11-02 15:08:03.0 +0100
@@ -1,3 +1,10 @@
+doxygen (1.8.8-5) unstable; urgency=medium
+
+ * Cherry pick c83db38ea83499be19d9ff242bfa22ae534ee80c. (Closes: #762272)
+ * Fix FTBFS: Update syntax of Build-Profiles header. (Closes: #767658)
+
+ -- Helmut Grohne hel...@subdivi.de Sun, 02 Nov 2014 15:07:52 +0100
+
doxygen (1.8.8-4) unstable; urgency=medium
* Cherry pick 6d4044ad43ae1424a256eb1c26992301e7c64f4a. (Closes: #760700)
diff -Nru doxygen-1.8.8/debian/control doxygen-1.8.8/debian/control
--- doxygen-1.8.8/debian/control2014-10-05 17:37:48.0 +0200
+++ doxygen-1.8.8/debian/control2014-11-02 14:17:44.0 +0100
@@ -86,7 +86,7 @@
Depends: doxygen, ${shlibs:Depends}, ${misc:Depends}
Suggests: doxygen-doc
Replaces: doxygen ( 1.2.14)
-Build-Profiles: !stage1
+Build-Profiles: !stage1
Description: GUI configuration tool for doxygen
Doxygen is a documentation system for C, C++, Java, Objective-C, Python, IDL
and to some extent PHP, C#, and D. It can generate an on-line class browser
diff -Nru doxygen-1.8.8/debian/patches/fix-762272.diff
doxygen-1.8.8/debian/patches/fix-762272.diff
--- doxygen-1.8.8/debian/patches/fix-762272.diff1970-01-01
01:00:00.0 +0100
+++ doxygen-1.8.8/debian/patches/fix-762272.diff2014-11-02
14:15:43.0 +0100
@@ -0,0 +1,76 @@
+From: Dimitri van Heesch dimi...@stack.nl
+Subject: Debian Bug 762272: segfault with cyclic subgroups
+Bug-Debian: https://bugs.debian.org/762272
+Last-Modified: 2014-11-02
+Origin:
https://github.com/doxygen/doxygen/commits/c83db38ea83499be19d9ff242bfa22ae534ee80c
+
+Index: doxygen/src/groupdef.cpp
+===
+--- doxygen.orig/src/groupdef.cpp 2014-11-02 14:15:33.0 +0100
doxygen/src/groupdef.cpp 2014-11-02 14:15:33.0 +0100
+@@ -510,7 +510,31 @@
+
+ bool GroupDef::containsGroup(const GroupDef *def)
+ {
+-return this==def || groupList-find(def) = 0;
++ if (this==def)
++ {
++return TRUE;
++ }
++ else if (groupList-find(def)=0)
++ {
++return TRUE;
++ }
++ else // look for subgroups as well
++ {
++GroupList *groups = partOfGroups();
++if (groups)
++{
++ GroupListIterator it(*groups);
++ GroupDef *gd;
++ for (;(gd=it.current());++it)
++ {
++if (gd-containsGroup(def))
++{
++ return TRUE;
++}
++ }
++}
++ }
++ return FALSE;
+ }
+
+ void GroupDef::addGroup(const GroupDef *def)
+@@ -1229,16 +1253,23 @@
+ for (;(g=gli.current());++gli)
+ {
+ GroupDef *gd=0;
+-if (!g-groupname.isEmpty()
(gd=Doxygen::groupSDict-find(g-groupname))
+- !gd-containsGroup(subGroup) )
+-{
+- gd-addGroup(subGroup);
+- subGroup-makePartOfGroup(gd);
+-}
+-else if (gd==subGroup)
++if (!g-groupname.isEmpty()
(gd=Doxygen::groupSDict-find(g-groupname)))
+ {
+- warn(root-fileName,root-startLine,Trying to add group %s to itself!,
+- gd-name().data());
++ if (gd==subGroup)
++ {
++warn(root-fileName,root-startLine,Refusing to add group %s to
itself,
++gd-name().data());
++ }
++ else if (gd-containsGroup(subGroup))
++ {
++warn(root-fileName,root-startLine,Refusing to add group %s to
group %s, since the latter is already a
++subgroup of the former\n,
subGroup-name().data(),gd-name().data());
++ }
++ else
++ {
++gd-addGroup(subGroup);
++subGroup-makePartOfGroup(gd);
++ }
+ }
+ }
+ }
diff -Nru doxygen-1.8.8/debian/patches/series
doxygen-1.8.8/debian/patches/series
--- doxygen-1.8.8/debian/patches/series 2014-10-05 16:56:26.0 +0200
+++ doxygen-1.8.8/debian/patches/series 2014-10-31 23:28:33.0 +0100
@@ -10,3 +10,4 @@
clang-configure.diff
sqlite3-configure.diff
fix-760700.diff
+fix-762272.diff
Bug#764496: RM: ssdeep/all suites -- ROM; non-distributable
Package: ftp.debian.org Severity: normal Thorsten Alteholz pointed (#764357) out that ssdeep contains source from trn, which is licensed under a non-commercial license. It therefore is not DFSG free. What makes matters bad is that it links non-commercial source with GPL source (in libfuzzy2). Thus the resulting binaries become non-distributable. Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141008151953.ga12...@alf.mars
Bug#752465: closed by Emilio Pozuelo Monfort po...@debian.org (Re: Processed: Re: libgdbm3: please rebuild against texinfo 5.2)
reopen 752465 reassign 752465 libgdbm3 severity 752465 serious retitle 752465 Multi-Arch:same file conflict for any pair of architectures thanks On Thu, Jun 26, 2014 at 09:21:05PM +, Debian Bug Tracking System wrote: Scheduled. I'm opening another bug against gdbm so this isn't necessary in the future. Emilio Hmm. That was not the expected outcome. gdbm doesn't use debhelper and is now in a state more broken than before the binNMU. It causes file conflicts for usr/share/doc/libgdbm3/changelog.Debian.gz for any pair of architectures. Any sourceful upload will fix this bug, but more effort is required for making the package binNMU+M-A safe. That effort is the scope of bug #752830. Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140627104403.ga28...@alf.mars
Bug#751477: wheezy-pu: package squid3/3.1.20-2.2+deb7u1 (NMU)
Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: Luigi Gangitano lu...@debian.org
Dear release team,
I intend to NMU squid3/3.1.20-2.2+deb7u1 to stable to fix #712754. The
bug is about squid3 occasionally dieing from an assertion failure. The
bug is hard to trigger and the only parameter that is known to have an
influence is load. After the main squid worker dies it is automatically
restarted by its supervisor process. Still this bug causes pages to be
truncated when squid crashes.
Please find the proposed .debdiff attached. I am running it on my
wheezy/amd64 server for testing and did not observe similar crashes or
regressions since switching to the patched package.
Can I go ahead an upload the fixed package?
Helmut
diff -Nru squid3-3.1.20/debian/changelog squid3-3.1.20/debian/changelog
--- squid3-3.1.20/debian/changelog 2013-02-23 15:07:26.0 +0100
+++ squid3-3.1.20/debian/changelog 2014-06-12 23:21:22.0 +0200
@@ -1,3 +1,11 @@
+squid3 (3.1.20-2.2+deb7u1) stable-proposed-updates; urgency=medium
+
+ * Non-maintainer upload.
+ * Add fix-712754-assertion-failure-commHandleRead.patch. Fix sporadic
+assertion failure under high load. (Closes: #712754)
+
+ -- Helmut Grohne hel...@subdivi.de Thu, 12 Jun 2014 23:02:19 +0200
+
squid3 (3.1.20-2.2) unstable; urgency=low
* Non-maintainer upload.
diff -Nru
squid3-3.1.20/debian/patches/fix-712754-assertion-failure-commHandleRead.patch
squid3-3.1.20/debian/patches/fix-712754-assertion-failure-commHandleRead.patch
---
squid3-3.1.20/debian/patches/fix-712754-assertion-failure-commHandleRead.patch
1970-01-01 01:00:00.0 +0100
+++
squid3-3.1.20/debian/patches/fix-712754-assertion-failure-commHandleRead.patch
2014-06-12 22:59:34.0 +0200
@@ -0,0 +1,36 @@
+Description: fix assertion failure in commHandleRead
+Origin: upstream, http://bugs.squid-cache.org/attachment.cgi?id=2276
+Bug: http://bugs.squid-cache.org/show_bug.cgi?id=3048
+Bug-Debian: http://bugs.debian.org/712754
+Author: Alex Rousskov
+Last-Update: 2014-06-12
+Applied-Upstream: yes
+
+Fix for comm.cc:322 commio_has_callback(fd, IOCB_READ, ccb) assertion
+may also be applicable to a similar IOCB_WITE assertion.
+
+When we start closing a descriptor, we call commio_finish_callback() to remove
+I/O callbacks. If this is not done from commHandleRead or commHandleWrite,
+then select(2) structures may still have our descriptor registration and will
+call Comm back to read or write before the descriptor is closed for good. This
+will trigger a commio_has_callback() assertion.
+
+=== modified file 'src/comm.cc'
+--- a/src/comm.cc 2010-05-06 05:01:14 +
b/src/comm.cc 2010-05-09 21:32:23 +
+@@ -1635,11 +1635,13 @@
+ commStopHalfClosedMonitor(fd);
+ commSetTimeout(fd, -1, NULL, NULL);
+
+-// notify read/write handlers
++// notify read/write handlers after canceling select reservations, if any
+ if (commio_has_callback(fd, IOCB_WRITE, COMMIO_FD_WRITECB(fd))) {
++commSetSelect(fd, COMM_SELECT_WRITE, NULL, NULL, 0);
+ commio_finish_callback(fd, COMMIO_FD_WRITECB(fd), COMM_ERR_CLOSING,
errno);
+ }
+ if (commio_has_callback(fd, IOCB_READ, COMMIO_FD_READCB(fd))) {
++commSetSelect(fd, COMM_SELECT_READ, NULL, NULL, 0);
+ commio_finish_callback(fd, COMMIO_FD_READCB(fd), COMM_ERR_CLOSING,
errno);
+ }
+
+
diff -Nru squid3-3.1.20/debian/patches/series
squid3-3.1.20/debian/patches/series
--- squid3-3.1.20/debian/patches/series 2013-02-23 15:07:26.0 +0100
+++ squid3-3.1.20/debian/patches/series 2014-06-12 22:56:57.0 +0200
@@ -4,3 +4,4 @@
20-ipv6-fix
30-CVE-2012-5643-CVE-2013-0189.patch
fix-701123-regression-in-cachemgr.patch
+fix-712754-assertion-failure-commHandleRead.patch
Bug#750222: wheezy-pu: package unbound (NMU)
On Mon, Jun 02, 2014 at 04:21:03PM -0400, Robert Edmonds wrote: I've built test binaries from tag debian/1.4.17-3+deb7u1 and they are available here: http://people.debian.org/~edmonds/build/unbound/1.4.17-3+deb7u1/ If this looks good to the release team, I will be happy to upload to -pu, no NMU required. Can you explain why the actual package uploaded to wheezy-pu reverts * Update IPv4 address hint for D.ROOT-SERVERS.NET? The debdiff showing the reversion can be found at https://release.debian.org/proposed-updates/stable_diffs/unbound_1.4.17-3+deb7u1.debdiff Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609055018.ga25...@alf.mars
Bug#750222: wheezy-pu: package unbound/1.4.17-3+deb7u1
Control: retitle -1 wheezy-pu: package unbound/1.4.17-3+deb7u1 On Mon, Jun 02, 2014 at 04:21:03PM -0400, Robert Edmonds wrote: I've built test binaries from tag debian/1.4.17-3+deb7u1 and they are available here: http://people.debian.org/~edmonds/build/unbound/1.4.17-3+deb7u1/ If this looks good to the release team, I will be happy to upload to -pu, no NMU required. Thanks. I no longer intend to NMU unbound. Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140603174248.ga7...@alf.mars
Bug#750222: wheezy-pu: package unbound (NMU)
Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: Robert S. Edmonds edmo...@debian.org
Dear release team and unbound maintainer,
I would like to NMU unbound to stable, because it crashes when
validating DNSSEC on multiple threads simultaneously. The relevant
Debian bug #691528 is fixed upstream, in unstable and I sent a
backported patch to that bug (also attached for convenience). Is this
patch suitable for wheezy?
Helmut
diff -Nru unbound-1.4.17/debian/changelog unbound-1.4.17/debian/changelog
--- unbound-1.4.17/debian/changelog 2013-02-17 18:35:34.0 +0100
+++ unbound-1.4.17/debian/changelog 2014-03-11 17:36:53.0 +0100
@@ -1,3 +1,10 @@
+unbound (1.4.17-3+wheezy1) stable-proposed-updates; urgency=low
+
+ * Non-maintainer upload.
+ * Fix crash when using DNSSEC and num-threads 1; closes: #691528.
+
+ -- Helmut Grohne hel...@subdivi.de Tue, 11 Mar 2014 17:33:23 +0100
+
unbound (1.4.17-3) testing; urgency=low
* Update IPv4 address hint for D.ROOT-SERVERS.NET.
diff -Nru unbound-1.4.17/debian/patches/series
unbound-1.4.17/debian/patches/series
--- unbound-1.4.17/debian/patches/series2013-02-17 18:54:32.0
+0100
+++ unbound-1.4.17/debian/patches/series2014-03-11 17:27:03.0
+0100
@@ -1 +1,2 @@
debian-changes
+unbound-1.4.18-openssl-threads.patch
diff -Nru unbound-1.4.17/debian/patches/unbound-1.4.18-openssl-threads.patch
unbound-1.4.17/debian/patches/unbound-1.4.18-openssl-threads.patch
--- unbound-1.4.17/debian/patches/unbound-1.4.18-openssl-threads.patch
1970-01-01 01:00:00.0 +0100
+++ unbound-1.4.17/debian/patches/unbound-1.4.18-openssl-threads.patch
2014-03-11 17:31:22.0 +0100
@@ -0,0 +1,109 @@
+Description: fix crash when using DNSSEC and num-threads 1
+Bug-Debian: http://bugs.debian.org/691528
+Last-Update: 2014-03-11
+Applied-Upstream: revision 2733
+
+Index: unbound-1.4.17/daemon/daemon.c
+===
+--- unbound-1.4.17.orig/daemon/daemon.c2014-03-11 17:26:28.541719650
+0100
unbound-1.4.17/daemon/daemon.c 2014-03-11 17:26:32.621688573 +0100
+@@ -203,6 +203,10 @@
+ comp_meth = (void*)SSL_COMP_get_compression_methods();
+ #endif
+ (void)SSL_library_init();
++# if defined(OPENSSL_THREADS) !defined(THREADS_DISABLED)
++ if(!ub_openssl_lock_init())
++ fatal_exit(could not init openssl locks);
++# endif
+ #ifdef HAVE_TZSET
+ /* init timezone info while we are not chrooted yet */
+ tzset();
+@@ -555,6 +559,9 @@
+ ERR_remove_state(0);
+ ERR_free_strings();
+ RAND_cleanup();
++# if defined(OPENSSL_THREADS) !defined(THREADS_DISABLED)
++ ub_openssl_lock_delete();
++# endif
+ checklock_stop();
+ #ifdef USE_WINSOCK
+ if(WSACleanup() != 0) {
+Index: unbound-1.4.17/util/net_help.c
+===
+--- unbound-1.4.17.orig/util/net_help.c2014-03-11 17:26:28.541719650
+0100
unbound-1.4.17/util/net_help.c 2014-03-11 17:26:32.621688573 +0100
+@@ -697,3 +697,54 @@
+ }
+ return ssl;
+ }
++
++/** global lock list for openssl locks */
++static lock_basic_t *ub_openssl_locks = NULL;
++
++/** callback that gets thread id for openssl */
++static unsigned long
++ub_crypto_id_cb(void)
++{
++ return (unsigned long)ub_thread_self();
++}
++
++static void
++ub_crypto_lock_cb(int mode, int type, const char *ATTR_UNUSED(file),
++ int ATTR_UNUSED(line))
++{
++ if((modeCRYPTO_LOCK)) {
++ lock_basic_lock(ub_openssl_locks[type]);
++ } else {
++ lock_basic_unlock(ub_openssl_locks[type]);
++ }
++}
++
++int ub_openssl_lock_init(void)
++{
++#ifdef OPENSSL_THREADS
++ size_t i;
++ ub_openssl_locks = (lock_basic_t*)malloc(
++ sizeof(lock_basic_t)*CRYPTO_num_locks());
++ if(!ub_openssl_locks)
++ return 0;
++ for(i=0; iCRYPTO_num_locks(); i++) {
++ lock_basic_init(ub_openssl_locks[i]);
++ }
++ CRYPTO_set_id_callback(ub_crypto_id_cb);
++ CRYPTO_set_locking_callback(ub_crypto_lock_cb);
++#endif /* OPENSSL_THREADS */
++ return 1;
++}
++
++void ub_openssl_lock_delete(void)
++{
++#ifdef OPENSSL_THREADS
++ size_t i;
++ if(!ub_openssl_locks)
++ return;
++ for(i=0; iCRYPTO_num_locks(); i++) {
++ lock_basic_destroy(ub_openssl_locks[i]);
++ }
++#endif /* OPENSSL_THREADS */
++}
++
+Index: unbound-1.4.17/util/net_help.h
+===
+--- unbound-1.4.17.orig/util/net_help.h2014-03-11 17:26:28.541719650
+0100
unbound-1.4.17/util/net_help.h 2014-03-11 17:26:32.621688573 +0100
+@@ -369,4 +369,15 @@
+ */
+ void* outgoing_ssl_fd(void* sslctx, int fd);
+
++/**
++ * Initialize openssl locking for thread safety
Re: sgml-base related conffile prompt
Thanks for looking into this. On Fri, Apr 12, 2013 at 03:58:27PM +0200, Niels Thykier wrote: Just if I understand it correctly - the requirement for triggering this bug is to: * install the Squeeze version of one of the affected packages below * remove said package (but do not purge it) * install the Wheezy version of the affected package Is that correctly asserted of me? Yes. This is the issue that would be fixed by rebuilding against a newer debhelper. Note that older versions than squeeze would likely do as well. So if you removed one ages ago and then decide to install it on wheezy or newer again, you'll be bitten. If my assertion above is correct, then I inclined to agree. Though if there are other ways to trigger the issue in these packages we might want to at least fix a couple of arch:all cases as well (e.g. sgml-base has a popcon of 70k and it is not the only one). Plus we might as well get those 4 packages binNMU'ed regardless since they are practically free fixes. I am not aware of any other way to trigger this. After all this issue was not discovered by actual users complaining, but reported by Andreas Beckmann from piuparts testing. Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130412141039.ga16...@alf.mars
sgml-base related conffile prompt
Dear release team, TL;DR: This issue is fixable with 18 binNMUs of which 14 are arch:all. On Sun, Apr 07, 2013 at 05:46:57PM +0100, Adam D. Barratt wrote: We can move discussion of the conffile issue to a new bug / thread if needed. Let me give you some data on this. The basic issue was first found by Andreas Beckmann as #681194. Packages built with squeeze debhelper would create package catalogs using packaging scripts and only remove them on purge. With the wheezy version package catalogs were turned into conffiles, but I forgot to properly handle the removed-but-not-purged case. Upon installation of a rebuilt package the previous left-over package catalog would be treated as a modified configuration file. This was fixed in debhelper/9.20120830 (migrated). It can indeed affect upgrades from squeeze to wheezy, if a package removed by an administrator is later reintroduced as a dependency during the upgrade. Being a bug in the debhelper snippet the only way to solve this issue is to rebuild all packages using dh_installcatalogs. This absolutely cannot be fixed with a single upload of sgml-base, because it isn't hooked into preinst. This issue can also not be tracked using the transition tracker, because there is no difference in depended-upon versions. To track completion of this issue, the relevant binary packages have to be grepped. I wrote two simple scripts to do the analysis. The first is to collect relevant packages. = #!/bin/sh apt-cache rdepends sgml-base | grep '^ ' | xargs apt-cache show -t unstable | sed 's,^Filename: ,http://your-mirror/debian/,;t;d' | sort -u = Once you have a set of .deb files, they can be analyzed with a second script. = VER=`dpkg-deb -f $1 Depends | sed 's_.*sgml-base\([^,]*\).*_\1_;t;d'` if test $VER != (= 1.26+nmu2); then echo $1: unrelated; exit 0 fi if dpkg-deb -I $1 preinst | grep -q '^if test -f /etc/sgml/.* -a ( \$1 = upgrade -o \$1 = install -a -n \$2 ) '; then echo $1: fixed; exit 0 fi if dpkg-deb -I $1 preinst | grep -q '^if \[ \$1 = upgrade \] ! dpkg-query -S /etc/sgml/.* /dev/null 21; then'; then echo $1: affected; exit 0 fi echo $1: undetermined = Here is the result from my sid work machine (as a lower bound of what would need to be fixed). = debiandoc-sgml_1.2.27_all.deb: affected docbook-dsssl_1.79-7_all.deb: affected docbook-ebnf_1.2~cr1-5.1_all.deb: affected docbook-html-forms_1.1.0-4.1_all.deb: affected docbook-mathml_1.1CR1-2_all.deb: affected docbook-simple_1.1-4.1_all.deb: affected docbook-slides_3.4.0-5_all.deb: fixed docbook-website_2.5.0.0-8_all.deb: affected docbook-xml_4.5-7.1_all.deb: affected docbook_4.5-5.1_all.deb: affected docutils-common_0.10-1_all.deb: fixed festival_2.1~release-5.1_amd64.deb: fixed jade_1.2.1-47.1+b1_amd64.deb: affected libcommons-validator-java_1.3.1-9_all.deb: affected linuxdoc-tools_0.9.68_amd64.deb: affected metacity-common_2.34.3-4_all.deb: fixed muffin-common_1.7.2-1_all.deb: fixed openjade1.3_1.3.2-11.1+b1_amd64.deb: affected openjade_1.4devel1-20.1+b1_amd64.deb: affected opensp_1.5.2-10_amd64.deb: unrelated psgml_1.3.2-14_all.deb: unrelated sgml-base-doc_1.99.1_all.deb: unrelated sgml-data_2.0.8_all.deb: affected sgml2x_1.0.0-11.3_all.deb: affected sgmltools-lite_3.0.3.0.cvs.20010909-17_all.deb: unrelated w3-dtd-mathml_2.0.0.0-5_all.deb: affected w3c-dtd-xhtml_1.2-4_all.deb: affected xemacs21-support_21.4.22-4_all.deb: unrelated xml-core_0.13+nmu2_all.deb: fixed xml2rfc_1.36-5_all.deb: fixed xmlto_0.0.25-2_amd64.deb: unrelated = Summary ~~~ unrelated: 6 fixed: 7 affected: 18 - all: 14 - any: 4 What do you think about the RCness of this issue? Should it be fixed for wheezy? Adam already indicated that he leans towards no. Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130408085805.ga21...@alf.mars
Bug#683847: unblock: sgml-base/1.26+nmu4
On Sun, Mar 17, 2013 at 12:14:24AM +, Adam D. Barratt wrote:
So, having procrastinated on this for far too long, I did some tests.
Thanks for looking into this.
Starting from a freshly debootstrapped squeeze chroot with
gnome-desktop-environment installed, I added a local repo containing
just sgml-base from sid and dist-upgraded.
This /should/ not be a way to discover issues nor to discover
differences between 1.26+nmu{3,4}. (Besides noise during nmu3 triggers.)
Unfortunately I don't have a typescript to check for any warning
messages, but the dist-upgrade completed without any apparent issues.
Thanks. But this test is not that useful for sgml-base. All you would be
seeing here had you upgraded to just wheezy would be noisy please
rebuild messaged emitted from preinst calls to update-catalog by
packages being upgraded.
The real problems are not related to upgrading/installing/removing. They
are related to using sgml tools. As far as I understand converting an
xml file using xmlto should discover some of the issues. Errors that
point to sgml-base failures are either catalog files that do not exist
or missing definitions (because the catalogs are not listed).
To trigger sgml-base related issues in wheezy try one of the following:
* Remove but not purge a sgml-base rdep. Observe missing files errors
from sgml tools. #676717
* Upgrade squeeze - wheezy without upgrading dpkg (or upgrading dpkg
late). Observe missing definitions from sgml tools. #678902
* Install squeeze. Install a sgml-base rdep. Remove it (not purge).
Upgrade the system to wheezy. Now install it again. Observe a
conffile prompt.
* Just upgrade squeeze - wheezy. Observe noise about rebuilding
packages that are already rebuilt.
As the NMUer of sgml-base I recommend to the release team to unblock
sgml-base, because it fixes real issues and has not shown any new issues
in the past months. The changes I made were minimal to the best of my
knowledge and in the spirit of RC bug fixes and freeze policy. I am
happy to attempt different solutions at your preference. In my opinion
at least the first two issues mentioned above must be fixed for wheezy
and the sid version does that. Please don't hesitate to bug me with
further questions.
Helmut
signature.asc
Description: Digital signature
Bug#683847: unblock: sgml-base/1.26+nmu4
[Dropping Adam from CC since he should receive this Mail via the bug report as well.] On Tue, Dec 18, 2012 at 04:44:28PM +, Adam D. Barratt wrote: Apologies if I missed it, but is there somewhere a concise and current list of the remaining issues affecting: I don't think that there is such a list. Thank you for bringing this up. a) packages in sid I am not aware of any release critical issues affecting a fresh sid install of sgml-base. b) packages in wheezy From the original unblock: | #676717: sgml-base produces broken super catalog when packages are in | rc state This issue affects wheezy as is. It can be reproduced by installing a reverse dependency of sgml-base and then removing but not purging it. c) the squeeze to wheezy upgrade process From the original unblock: | #678902: sgml-base needs to Pre-Depend on dpkg 1.16.4 This issue can be reproduced by upgrading sgml-base and its reverse dependencies very early and only then upgrading dpkg. In that case the triggers will not run in correct order and some package catalogs will be missing from the super catalog. In addition some packages are not yet built with the most recent version of debhelper which fixes #681194. This bug can be triggered in any package that uses dh_installcatalogs by installing it in squeeze, removing it, upgrading the rest of the system to wheezy and installing the package again. In this case a conffile prompt will show up even though the user did not change the package. The solution to this kind of problem is a rebuild of the affected package against a more recent version of debhelper. A notable exception here is xml2rfc, which was even buggier in this respect (#680291), but is already fixed in wheezy. Finally there is a theoretical issue I was unable to reproduce. It has no bug report associated, but is mentioned on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678902#62. The issue supposed being that sgml-base uses a perl feature that is not present in squeeze and in that case could generate an empty super catalog. I did not NMU the package for this possible issue, but prepared a trivial fix (added versioned dependency on perl http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678902#72). Just highlighting this here for completeness. If you believe that this should be fixed, I can turn it into an RC bug and fix it. Not an RC bug, but Julien Cristau complained about misleading warning messages during package upgrades. Those are removed in the sid version. To the best of my knowledge this is an exhaustive list of issues concerning sgml-base. If you have further questions please don't hesitate to ask. Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121219093739.ga31...@alf.mars
Bug#695355: unblock: libwmf/0.2.8.4-10.2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libwmf
The version in unstable fixes
* #685802 RC. Failure to load fonts.
* #677786 missing Multi-Arch blocks ia32-libs-gtk.
Please find a debdiff from wheezy to sid attached. Observe that the only
two files changed are debian/changelog and debian/control.
unblock libwmf/0.2.8.4-10.2
Helmut
diff -Nru libwmf-0.2.8.4/debian/changelog libwmf-0.2.8.4/debian/changelog
--- libwmf-0.2.8.4/debian/changelog 2012-01-06 00:53:36.0 +0100
+++ libwmf-0.2.8.4/debian/changelog 2012-11-29 17:28:35.0 +0100
@@ -1,3 +1,20 @@
+libwmf (0.2.8.4-10.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Add Multi-Arch headers. (Closes: #677786)
+The support was basically there. libwmf0.2-7 already ships libraries in
+/usr/lib/triplet. No changes besides adding headers were necessary.
+
+ -- Helmut Grohne hel...@subdivi.de Thu, 29 Nov 2012 17:26:47 +0100
+
+libwmf (0.2.8.4-10.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * debian/control
+- libwmf-bin: Depends: gsfonts fixes font load error (Closes: #685802)
+
+ -- Hideki Yamane henr...@debian.org Thu, 20 Sep 2012 13:09:11 +0900
+
libwmf (0.2.8.4-10) unstable; urgency=low
* Read libwmf binary package name from control in rules.
diff -Nru libwmf-0.2.8.4/debian/control libwmf-0.2.8.4/debian/control
--- libwmf-0.2.8.4/debian/control 2012-01-06 00:29:18.0 +0100
+++ libwmf-0.2.8.4/debian/control 2012-11-29 17:26:39.0 +0100
@@ -22,6 +22,7 @@
Pre-Depends: ${misc:Pre-Depends}
Depends: ${misc:Depends}, ${shlibs:Depends}
Recommends: gsfonts
+Multi-Arch: same
Description: Windows metafile conversion library
Windows metafile (WMF) is a picture format used by many Windows
programs, e.g. Microsoft Word. libwmf is a library for interpreting
@@ -34,6 +35,8 @@
Section: graphics
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
+Recommends: gsfonts
+Multi-Arch: foreign
Description: Windows metafile conversion tools
Windows metafile (WMF) is a picture format used by many Windows
programs, e.g. Microsoft Word. libwmf is a library for interpreting
Bug#683847: unblock: sgml-base/1.26+nmu4
Thanks for pinging the issue. On Tue, Nov 27, 2012 at 09:20:38PM -0500, Samuel Bronson wrote: Anyway, *someone* should probably do *something* here... Just what? As far as I can see the most fundamental question has not received a final answer: Will wheezy ship sgml catalogs as configuration files or as conffiles? I am explicitly deferring this question to the release managers now. There is no obviously correct answer, but we can only solve problems after there is an answer. If you (release team) need more insight into the issue(s), feel free to ask me via mail or irc (helmut). Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121129134614.ga28...@alf.mars
Bug#691222: unblock: python-gnupg/0.3.0-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Control: block -1 by 682648 Please unblock package python-gnupg The python-gnupg currently has a single bug. Unfortunately it is a FTBFS #682648. The test suite hangs, cause the virtualized host cannot gather random bits in a reasonable amount of time (1 hour). A new upstream version was suggested as a workaround, but it was never uploaded and it didn't seem to be in the spirit of minimal changes. So I prepared my own NMU shipping a wrapper binary for gpg, that adds --quick-random if --gen-key is also present. This speeds up the test suite and should make it terminate on virtualized systems as well. Please find the full .debdiff attached, but note that the executable permission of debian/bin/gpg cannot be represented in the diff. The upload currently sits in DELAYED (thanks to Paul Tagliamonte) to give the maintainer time to react. unblock python-gnupg/0.3.0-1.1 Helmut diff -Nru python-gnupg-0.3.0/debian/bin/gpg python-gnupg-0.3.0/debian/bin/gpg --- python-gnupg-0.3.0/debian/bin/gpg 1970-01-01 01:00:00.0 +0100 +++ python-gnupg-0.3.0/debian/bin/gpg 2012-10-22 23:26:17.0 +0200 @@ -0,0 +1,7 @@ +#!/bin/sh +GPG=`which -a gpg | uniq | tail -n+2 | head -n1` +if echo $* | grep -q gen-key; then + exec $GPG --quick-random $@ +else + exec $GPG $@ +fi diff -Nru python-gnupg-0.3.0/debian/changelog python-gnupg-0.3.0/debian/changelog --- python-gnupg-0.3.0/debian/changelog 2012-05-18 12:04:19.0 +0200 +++ python-gnupg-0.3.0/debian/changelog 2012-10-22 23:30:49.0 +0200 @@ -1,3 +1,11 @@ +python-gnupg (0.3.0-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Work around test suite hangs by adding --quick-random when generating +keys. Closes: #682648 + + -- Helmut Grohne hel...@subdivi.de Mon, 22 Oct 2012 23:30:19 +0200 + python-gnupg (0.3.0-1) unstable; urgency=low * New upstream release diff -Nru python-gnupg-0.3.0/debian/rules python-gnupg-0.3.0/debian/rules --- python-gnupg-0.3.0/debian/rules 2012-05-17 11:16:39.0 +0200 +++ python-gnupg-0.3.0/debian/rules 2012-10-22 23:30:14.0 +0200 @@ -18,12 +18,12 @@ override_dh_auto_test: ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS))) set -ex; for py in $(shell pyversions -r -v); do \ - PYTHONPATH=$(CURDIR)/build/lib.*-$$py python$$py test_gnupg.py ;\ + PATH=$(CURDIR)/debian/bin:$$PATH PYTHONPATH=$(CURDIR)/build/lib.*-$$py python$$py test_gnupg.py ;\ done set -ex; for python in $(shell py3versions -r); do \ cp test_gnupg.py test_gnupg_3.py ;\ 2to3 -w test_gnupg_3.py ;\ - PYTHONPATH=$(CURDIR)/build/lib $$python test_gnupg_3.py ;\ + PATH=$(CURDIR)/debian/bin:$$PATH PYTHONPATH=$(CURDIR)/build/lib $$python test_gnupg_3.py ;\ rm test_gnupg_3.py ;\ done endif
Bug#690528: unblock: xml2rfc/1.36-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock unblock xml2rfc/1.36-5 The squeeze version of xml2rfc fails to remove /etc/sgml/xml2rfc.cat on either remove or purge. Upgrading such a system and then installing wheezy's xml2rfc results in a conffile prompt as discovered by Andreas Beckmann using piuparts in #680291. Note that the behaviour of the squeeze package is a policy violation. The updated version solves the conffile prompt for the left over file. I attched the full debdiff between the version currently in wheezy and the fixing version in sid. Helmut diff -Nru xml2rfc-1.36/debian/changelog xml2rfc-1.36/debian/changelog --- xml2rfc-1.36/debian/changelog 2012-08-31 20:16:57.0 +0200 +++ xml2rfc-1.36/debian/changelog 2012-10-15 01:31:22.0 +0200 @@ -1,3 +1,11 @@ +xml2rfc (1.36-5) unstable; urgency=low + + [ Helmut Grohne ] + * Always remove /etc/sgml/xml2rfc.cat when it is not a conffile. +(Closes: #680291) + + -- Daniel Kahn Gillmor d...@fifthhorseman.net Sun, 14 Oct 2012 19:30:24 -0400 + xml2rfc (1.36-4) unstable; urgency=low * Bump Standards-Version to 3.9.3 (no changes needed) diff -Nru xml2rfc-1.36/debian/preinst xml2rfc-1.36/debian/preinst --- xml2rfc-1.36/debian/preinst 1970-01-01 01:00:00.0 +0100 +++ xml2rfc-1.36/debian/preinst 2012-10-15 01:29:51.0 +0200 @@ -0,0 +1,15 @@ +#!/bin/sh +set -e + +# xml2rfc version 1.35-1 as of Debian squeeze did not properly clean its +# package catalog upon removal or purge. This results in a conffile prompt when +# installing a dh_installcatalogs managed version. This is also known as +# #680291. The issue affects the upgrade from squeeze to wheezy. Once wheezy is +# released. This preinst file should be removed unless something else is added +# to it. +CENTCAT=/etc/sgml/xml2rfc.cat +if test -f $CENTCAT ! dpkg-query -S $CENTCAT /dev/null 21; then + mv $CENTCAT $CENTCAT.old +fi + +#DEBHELPER#
Bug#683847: unblock: sgml-base/1.26+nmu4
On Tue, Oct 09, 2012 at 09:23:20AM +0200, Julien Cristau wrote: Get rid of the triggers and get back to something that actually works. I believe that you are a bit late into this discussion. Initially I proposed[63] a solution not involving triggers in the spirit of minimal changes. Then Daniel Leidert being a member of the XML/SGML Group requested[78] that the package catalogs be created at build time and be shipped as conffiles. Later Joey Hess[164] requested that the central catalog be generated using triggers. At that time both requests made sense (and to me they still do). There were no objections and I did not see the dpkg conffile trigger issue #676062 coming. So I implemented both. The current state is that there are no non-transition issues left. Once you are on sid, there are no sgml-base specific rc bugs affecting you. Going back will not make the transitioning part any easier. At least I don't see how that would work, but maybe your yet hidden solution can surprise me? Helmut [63]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477751#63 [78]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477751#78 [164]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477751#164 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121009085641.gb30...@alf.mars
Bug#683847: unblock: sgml-base/1.26+nmu4
On Tue, Oct 09, 2012 at 09:15:32AM +0200, Raphael Hertzog wrote: On Mon, 08 Oct 2012, Helmut Grohne wrote: 1) Add a pre-dependency on dpkg such that dpkg is already upgraded before deconfiguring sgml-base. This does not guarantee to solve the issue, because the old dpkg may still be running, but it makes it highly unlikely. IIRC when apt upgrades dpkg, it configures it immediately so that any package processed after dpkg is guaranteed to be processed by the upgraded dpkg. Thanks for the explanation. Do you also know whether aptitude and cupt show the same behaviour? In any case the conclusion should be that the pre-dependency sufficiently solves the issue. Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121009081031.ga30...@alf.mars
Bug#683847: unblock: sgml-base/1.26+nmu4
On Tue, Oct 09, 2012 at 11:43:19AM +0200, Julien Cristau wrote: I'm not interested in you are on sid so much as you're upgrading from squeeze to wheezy. And considering the amount of bugs this whole thing has uncovered (whether in the transition stuff itself, in dpkg, or somewhere else) I'm fairly convinced this whole thing is in the not worth it category. And even in the you've already upgraded situation, dpkg's failing at trigger handling means I'm fairly nervous about the next dist-upgrade. I do see your reasoning here. On the bright side, I can say that the stream of bugs seems to have stopped. During the last two months the only new thing that popped up was a revival of #680291 which is due to xml2rfc being buggy in squeeze. It is not the case that our previous state worked that well. Instead what we see here is simultaneous rising of quality levels by doing more extensive piuparts tests and declaring failures as rc instead of important. Not blaming you, as you couldn't have predicted most of these bugs, just saying at some point you have to stop the trainwreck. Thanks. What I fail to see here is how to stop the trainwreck. You cannot simply take the squeeze packages, bump their versions and upload. That would severely break sid and wheezy. You would have to reverse the transition. So what I am suggesting here is that the brake is the worse option in terms of breakage to wheezy. Note that even though I invested a fair amount of time in developing the trigger based sgml-base catalog update, I am trying not to be biased by having that work done. If you can show me a different solution, I will try to have an honest look. go back is just too vague to count as a solution at this point. Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121009100115.ga12...@alf.mars
Bug#683847: unblock: sgml-base/1.26+nmu4
On Mon, Oct 08, 2012 at 12:49:57PM +0200, Julien Cristau wrote: On Sun, Oct 7, 2012 at 22:20:54 +0200, Helmut Grohne wrote: In addition a number of people on #-mentors suggested that a Pre-Dependency on dpkg shouldn't be too bad since dpkg should be upgraded early in any case. Sounds like a myth to me. Reference? It may be a myth. suggested is no evidence, but more like a guess. I just listed it as an explanation for my reasoning. Since #-mentors is not a logged channel, I cannot provide a reference, besides desktop-base[1]. Maybe we can move to more technical grounds and find a suitable solution there? So initially the reason for the pre-dependency was #678902. The reason is that an old version of dpkg invokes the trigger before the conffile is present which results in the conffile not being listed in /etc/sgml/catalog. In my view there is no doubt of the RC-ness of this issue. So what would be your preferred resolution? 1) Add a pre-dependency on dpkg such that dpkg is already upgraded before deconfiguring sgml-base. This does not guarantee to solve the issue, because the old dpkg may still be running, but it makes it highly unlikely. 2) Fix dpkg to invoke all triggers when upgrading to the fixed version. I do not see this happening. 3) Work around this bug, by explicitly invoking the trigger in postinst at which time the conffile is guaranteed to be present. This kind of defeats the purpose of triggers. 4) Your solution? Helmut [1] http://packages.debian.org/changelogs/pool/main/d/desktop-base/current/changelog#version7.0.0_exp1 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121008111307.ga6...@alf.mars
Bug#683847: unblock: sgml-base/1.26+nmu4
On Wed, Oct 03, 2012 at 06:23:17PM +0200, Julien Cristau wrote: Can you provide a pointer to the dpkg pre-dependency discussion? To comply with the Debian policy I asked[33] about the pre-dependency on debian-devel@l.d.o and Ian Jackson suggested[38] that this should be fixed in dpkg instead. I therefore pulled[43] in debian-dpkg@l.d.o as the maintainer address for dpkg. I never saw an answer nor any follow up question from a dpkg maintainer. Given that dpkg is highly critical infrastructure and the freeze I concluded that the dpkg maintainers would not be able to implement the necessary changes in a timely manner. In addition a number of people on #-mentors suggested that a Pre-Dependency on dpkg shouldn't be too bad since dpkg should be upgraded early in any case. The desktop-base package was given as an example for adding that pre-dependency without discussion. Helmut [33] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678902#33 [38] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678902#38 [43] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678902#43 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121007202053.ga4...@alf.mars
Re: xml2rfc: fails to install, remove, distupgrade, and install again
Control: block 680291 by 681194 Hi Emanuele, Thank you very much for notifying me of this issue. Also sorry for not having answered earlier. On Mon, Aug 13, 2012 at 11:52:30AM +0200, Emanuele Rocca wrote: This seems to be related to the changes introduced to dh_installcatalogs (see #477751). This is correct. Helmut, I took the liberty to put you in CC as you probably have some hints for how to proceed? Note that other packages might show the same behavior reported here: docbook-website comes to mind. This issue is an instance of #681194. In order to fix this issue, this package needs to be rebuild (that means sourceful upload with new revision) using an updated version of debhelper. It is yet unclear whether Joey Hess intends to fix this as he hasn't spoken up yet. Note that if these issues are to be tagged wheezy-ignore, they can be closed as well, as they only affect upgrades from squeeze. The release team being queried about which course of action they desire also has not replied thus far. So this issue serves as a good example to ping both. Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120829201713.ga16...@alf.mars
Bug#683847: unblock: sgml-base/1.26+nmu4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: block -1 by 683844
Dear release team,
Please
unblock sgml-base/1.26+nmu4
The version intends to fix all remaining RC bugs of sgml-base:
#678902: sgml-base needs to Pre-Depend on dpkg 1.16.4
#676717: sgml-base produces broken super catalog when packages are in
rc state
The patch is the same as attached to the respective bug logs. The
pre-dependency has been discussed with -devel and deemed appropriate,
because the dpkg maintainers will not be able to provide the necessary
dpkg feature (since they failed to reply in a timely manner). The
intrusive part of parsing catalogs has been contributed and reviewed by
Jakub Wilk. The patch also removes some useless and annoying messages as
requested by Julien Cristau.
The attached .debdiff is between wheezy and the not yet sponsored sid
version. The sponsorship bug #683844 blocks this bug.
Helmut
diff -Nru sgml-base-1.26+nmu3/debian/changelog
sgml-base-1.26+nmu4/debian/changelog
--- sgml-base-1.26+nmu3/debian/changelog2012-05-28 21:11:52.0
+0200
+++ sgml-base-1.26+nmu4/debian/changelog2012-06-27 21:04:29.0
+0200
@@ -1,3 +1,16 @@
+sgml-base (1.26+nmu4) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * update-catalog --update-super ignores catalogs referencing non-existent
+files. (Closes: #676717) Thanks to Jakub Wilk for contributing the parser.
+ * Remove warning about rebuilding packages as it may confuse users.
+ * Quieten update-catalog during trigger and postinst, to avoid warnings for
+packages in rc state.
+ * Pre-Depend on dpkg = 1.16.4 (Closes: #678902). Removed dependency on
+dpkg = 1.14.18. sgml-base highlights a bug in dpkg's trigger processing.
+
+ -- Helmut Grohne hel...@subdivi.de Thu, 21 Jun 2012 16:09:07 +0200
+
sgml-base (1.26+nmu3) unstable; urgency=low
* Non-maintainer upload.
diff -Nru sgml-base-1.26+nmu3/debian/control sgml-base-1.26+nmu4/debian/control
--- sgml-base-1.26+nmu3/debian/control 2012-05-28 13:58:23.0 +0200
+++ sgml-base-1.26+nmu4/debian/control 2012-06-27 20:38:49.0 +0200
@@ -11,7 +11,8 @@
Priority: optional
Architecture: all
Conflicts: sgml-data (= 0.02), sgmltools-2 (= 2.0.2-4)
-Depends: ${perl:Depends}, dpkg (= 1.14.18)
+Depends: ${perl:Depends}
+Pre-Depends: dpkg (= 1.16.4)
Suggests: sgml-base-doc
Description: SGML infrastructure and SGML catalog file support
This package creates the SGML infrastructure directories and provides
diff -Nru sgml-base-1.26+nmu3/debian/sgml-base.postinst
sgml-base-1.26+nmu4/debian/sgml-base.postinst
--- sgml-base-1.26+nmu3/debian/sgml-base.postinst 2012-05-28
13:58:23.0 +0200
+++ sgml-base-1.26+nmu4/debian/sgml-base.postinst 2012-06-22
17:22:31.0 +0200
@@ -61,12 +61,12 @@
fi
## --
-update-catalog --update-super
+update-catalog --quiet --update-super
ln -sf /var/lib/sgml-base/supercatalog /etc/sgml/catalog
fi
if [ $1 = triggered ]
then
-update-catalog --update-super
+update-catalog --quiet --update-super
fi
## --
diff -Nru sgml-base-1.26+nmu3/tools/update-catalog
sgml-base-1.26+nmu4/tools/update-catalog
--- sgml-base-1.26+nmu3/tools/update-catalog2012-05-28 21:11:52.0
+0200
+++ sgml-base-1.26+nmu4/tools/update-catalog2012-06-27 21:04:45.0
+0200
@@ -4,6 +4,7 @@
## --
## Copyright (c) 2001-2004 Ardo van Rangelrooij
## Copyright (c) 2012 Helmut Grohne
+## Copyright (c) 2012 Jakub Wilk
##
## This is free software; see the GNU General Public Licence version 2
## or later for copying conditions. There is NO warranty.
@@ -138,8 +139,6 @@
print Invocation of dpkg-trigger failed with status $?.\n;
print Forcing update of the super catalog...\n;
update_super;
-} else {
-print update-catalog: Please rebuild the package being set up with a
version of debhelper fixing #477751.\n;
}
}
elsif ( $add )
@@ -240,17 +239,71 @@
}
## --
+# Reference: https://www.oasis-open.org/specs/a401.htm
+sub check_catalog($)
+{
+my($catalog)=shift;
+my $base = $catalog;
+$base =~ s,/[^/]+$,,;
+my $catalog_tokens = qr{
+( (?: \s+ | -- .*? --)+ # whitespace and comments
+| ' .*? ' | .*? # literal
+| \S+ # other tokens
+)
+}sx;
+unless(open(PKGCAT, , $catalog)) {
+print Warning: Ignoring unreadable catalog file `$catalog'.\n
+unless $quiet;
+return 0;
+};
+local $/;
+my $contents = PKGCAT;
+close PKGCAT;
+my $prevtoken = 0;
+while ($contents =~ m/$catalog_tokens/g) {
+my $token
[PING] Re: sgml-base again
Dear release team, On Sat, Jul 21, 2012 at 08:17:19PM +0200, Andreas Beckmann wrote: 1) #681194 Symptom: For any package using dh_installcatalogs if you install, remove, upgrade from squeeze to wheezy and then install that package, you can see a useless conffile prompt. Fixing this: Any fix requires a *transition* involving about 20 packages. A fix would need a debhelper (dh_installcatalogs) update, Helmut should have the details and a patch as discussed on irc. Thereafter it needs probably redoing http://release.debian.org/transitions/html/sgml-base.html with the fixed debhelper - this will need sourceful uploads (NMUs) since most of the affected packages are arch:all I attached and tested a patch[1] to debhelper. How can we proceed with this issue? I basically see three options. 1) Ignore this issue entirely. It is only relevant for upgrades from squeeze. 2) Ignore the symptoms of this issue, but fix debhelper. No transition. (Imo this option doesn't make that much sense.) 3) Fix this issue and restart the transition of about 25 packages during the freeze. We should reach a decision ASAP, since any non-ignoring action will take time and therefore might delay the release. For the other issues see my unblock #683847. Helmut [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681194#10 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120804185813.ga25...@alf.mars
sgml-base again
Dear release team,
There are currently four RC bugs related to sgml-base.
1) #681194
Symptom: For any package using dh_installcatalogs if you
install, remove, upgrade from squeeze to wheezy and then install
that package, you can see a useless conffile prompt.
Fixing this: Any fix requires a *transition* involving about 20
packages.
Question: Can we wheezy-ignore this issue?
2) #676717 (#675462 is a duplicate)
Symptom: If any package using dh_installcatalogs is in state rc, it
breaks all your catalogs.
Fixing this: Attached patch.
3) #678902
Symptom: After an upgrade from squeeze to wheezy you may end up with
a broken super catalog due to missing dpkg triggers.
Fixing this: A proper fix requires a patch to dpkg, but the dpkg
team did not respond. A workaround is to Pre-Depend on dpkg.
Attached patch.
Question: Should I get the attached debdiff uploaded to sid, so it can
propagate to wheezy via an unblock?
(Please CC me in reply)
Thanks
Helmut
diff -Nru sgml-base-1.26+nmu3/debian/changelog
sgml-base-1.26+nmu4/debian/changelog
--- sgml-base-1.26+nmu3/debian/changelog2012-05-28 21:11:52.0
+0200
+++ sgml-base-1.26+nmu4/debian/changelog2012-06-27 21:04:29.0
+0200
@@ -1,3 +1,16 @@
+sgml-base (1.26+nmu4) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * update-catalog --update-super ignores catalogs referencing non-existent
+files. (Closes: #676717) Thanks to Jakub Wilk for contributing the parser.
+ * Remove warning about rebuilding packages as it may confuse users.
+ * Quieten update-catalog during trigger and postinst, to avoid warnings for
+packages in rc state.
+ * Pre-Depend on dpkg = 1.16.4 (Closes: #678902). Removed dependency on
+dpkg = 1.14.18. sgml-base highlights a bug in dpkg's trigger processing.
+
+ -- Helmut Grohne hel...@subdivi.de Thu, 21 Jun 2012 16:09:07 +0200
+
sgml-base (1.26+nmu3) unstable; urgency=low
* Non-maintainer upload.
diff -Nru sgml-base-1.26+nmu3/debian/control sgml-base-1.26+nmu4/debian/control
--- sgml-base-1.26+nmu3/debian/control 2012-05-28 13:58:23.0 +0200
+++ sgml-base-1.26+nmu4/debian/control 2012-06-27 20:38:49.0 +0200
@@ -11,7 +11,8 @@
Priority: optional
Architecture: all
Conflicts: sgml-data (= 0.02), sgmltools-2 (= 2.0.2-4)
-Depends: ${perl:Depends}, dpkg (= 1.14.18)
+Depends: ${perl:Depends}
+Pre-Depends: dpkg (= 1.16.4)
Suggests: sgml-base-doc
Description: SGML infrastructure and SGML catalog file support
This package creates the SGML infrastructure directories and provides
diff -Nru sgml-base-1.26+nmu3/debian/sgml-base.postinst
sgml-base-1.26+nmu4/debian/sgml-base.postinst
--- sgml-base-1.26+nmu3/debian/sgml-base.postinst 2012-05-28
13:58:23.0 +0200
+++ sgml-base-1.26+nmu4/debian/sgml-base.postinst 2012-06-22
17:22:31.0 +0200
@@ -61,12 +61,12 @@
fi
## --
-update-catalog --update-super
+update-catalog --quiet --update-super
ln -sf /var/lib/sgml-base/supercatalog /etc/sgml/catalog
fi
if [ $1 = triggered ]
then
-update-catalog --update-super
+update-catalog --quiet --update-super
fi
## --
diff -Nru sgml-base-1.26+nmu3/tools/update-catalog
sgml-base-1.26+nmu4/tools/update-catalog
--- sgml-base-1.26+nmu3/tools/update-catalog2012-05-28 21:11:52.0
+0200
+++ sgml-base-1.26+nmu4/tools/update-catalog2012-06-27 21:04:45.0
+0200
@@ -4,6 +4,7 @@
## --
## Copyright (c) 2001-2004 Ardo van Rangelrooij
## Copyright (c) 2012 Helmut Grohne
+## Copyright (c) 2012 Jakub Wilk
##
## This is free software; see the GNU General Public Licence version 2
## or later for copying conditions. There is NO warranty.
@@ -138,8 +139,6 @@
print Invocation of dpkg-trigger failed with status $?.\n;
print Forcing update of the super catalog...\n;
update_super;
-} else {
-print update-catalog: Please rebuild the package being set up with a
version of debhelper fixing #477751.\n;
}
}
elsif ( $add )
@@ -240,17 +239,71 @@
}
## --
+# Reference: https://www.oasis-open.org/specs/a401.htm
+sub check_catalog($)
+{
+my($catalog)=shift;
+my $base = $catalog;
+$base =~ s,/[^/]+$,,;
+my $catalog_tokens = qr{
+( (?: \s+ | -- .*? --)+ # whitespace and comments
+| ' .*? ' | .*? # literal
+| \S+ # other tokens
+)
+}sx;
+unless(open(PKGCAT, , $catalog)) {
+print Warning: Ignoring unreadable catalog file `$catalog'.\n
+unless $quiet;
+return 0;
+};
+local $/;
+my $contents = PKGCAT;
+close PKGCAT;
+my $prevtoken = 0;
+while ($contents =~ m
Re: binnmus for #477751
Status update ahead. Thanks to Jakub Wilk for rebuilding the packages via NMUs and thanks to Emanuele Rocca for doing QA uploads for two of the affected packages. The following packages still need binNMUs: festival openjade openjade1.3 jade linuxdoc-tools (i386 only) The following packages need NMUs with changes and have patches attached: xml2rfc#674911 (maintainer requested debhelper conversion, asked for review and maintainer upload) sgml-data #675488 #674913 Information about good and unrelated packages can be found at the end of this mail. So we are down to 7 packages of which 5 need binNMUs and 2 have patches. Here is my attempt at a wanna-build file: nmu festival 1:2.1~release-5 . ALL nmu openjade 1.4devel1-20.1 . ALL nmu openjade1.3 1.3.2-11.1 . ALL nmu jade 1.2.1-47.1 . ALL nmu linuxdoc-tools 0.9.68 . i386 Helmut The following packages have already been rebuilt or fixed: debiandoc-sgml libcommons-validator-java metacity docbook-mathml #675478 docbook-slides #675480 python-docutils#675489 w3-dtd-mathml docbook#675473 docbook-dsssl #675475 docbook-html-forms #675477 xml-core #675483 docbook-ebnf #675476 docbook-simple #675479 docbook-xml#675482 dtd-ead#675496 sgml2x #675490 w3c-dtd-xhtml #677199 docbook-website#675481 sgmltools-lite #674914 (this package really is ok, even though it shows up as bad on the transition tracker) w3c-dtd-xhtml #677199 The following unrelated packages how up on the transition tracker: psgml xmlto opensp -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120619092109.GA16582@localhost
Re: binnmus for #477751
Dear release team, On Sun, Jun 03, 2012 at 10:06:56AM +0200, Helmut Grohne wrote: Please hold on. The rebuilt packages are currently causing FTBFS for other packages. See #675613 for details. TL;DR: The triggers are executed too early. Guillem Jover intends to solve this in dpkg. Thanks to Guillem Jover for quickly fixing #675613. I verified that the issue with sgml-base is actually solved by his fix. So here we go with the actual transition part. The following packages have already been rebuilt: debiandoc-sgml libcommons-validator-java metacity docbook-mathml #675478 docbook-slides #675480 python-docutils#675489 w3-dtd-mathml The following packages need binNMUs: festival openjade openjade1.3 jade linuxdoc-tools The following packages need sourceful uploads and have bugs filed: docbook#675473 docbook-dsssl #675475 docbook-html-forms #675477 xml-core #675483 docbook-ebnf #675476 docbook-simple #675479 docbook-website#675481 docbook-xml#675482 dtd-ead#675496 sgml2x #675490 The following packages need extra work: sgmltools-lite #674914 xml2rfc#674911 w3c-dtd-xhtml missing sgml-data #675488 #674913 The following unrelated packages how up on the transition tracker: psgml xmlto opensp I will work on the four packages needing extra work and hope to get them ready before the freeze. Thanks for your help and patience with this bug. Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120608200312.ga...@alf.mars
Re: binnmus for #477751
Dear release team, On Mon, May 28, 2012 at 10:34:08PM +0200, Helmut Grohne wrote: The following set of packages can be updated using binNMUs: festival jade linuxdoc-tools metacity-common:metacity mutter openjade openjade1.3 Please hold on. The rebuilt packages are currently causing FTBFS for other packages. See #675613 for details. TL;DR: The triggers are executed too early. Guillem Jover intends to solve this in dpkg. Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120603080656.ga...@alf.mars
Re: binnmus for #477751
On Mon, May 28, 2012 at 10:34:08PM +0200, Helmut Grohne wrote: We now have sgml-base 1.26+nmu3 and debhelper 9.20120528 in sid. The final step to fix #477751 is to get rid of update-catalog invocations embedded by debhelper. I came up with a ben file for this. title = sgml-base #477751; is_affected = .depends ~ /sgml-base \(/; is_bad = .depends ~ /sgml-base \(= 1\.1[0-9]\)/; is_good = .depends ~ /sgml-base \(= 1\.26\+nmu2\)/; Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120529091118.ga14...@alf.mars
sgml-base #674933 breakage
Dear release team, (please CC me in reply) My upload of sgml-base 1.26+nmu2 introduced #674933 which causes packages using sgml to emit broken builds. The build does not fail. The issue was immediately fixed in 1.26+nmu3. In the mean time 63 packages have been uploaded: tdb otrs2 tcl8.5 apr aria2 cdbs gmod libpam-encfs libpdl-netcdf-perl slang2 spyder tcl8.6 debdelta grml2usb typo3-src cdbs ecasound libssh2 sugar-calculate-activity octave-gsl onscripter s3cmd clxclient sugar-etoys-activity transmission gridlock.app jlha-utils libxml2 links2 apache2 gworkspace irrlicht twms xfce4-battery-plugin an debhelper syncmaildir virt-viewer amora-server cdbs pegasus-wms sugar-chat-activity-0.86 libdr-tarantool-perl sugar-calculate-activity libfakekey mecab-ipadic nova ruby-metaid sugar-toolkit-gtk3 tiff tomoyo-tools voms-mysql-plugin x264 kdiff3 ovito sugar-pippy-activity unbound lice5 psignifit3 shatag sogo x-loader pdl I manually determined that only 5 directly build-depend on docbook related stuff and those are: tdb - seems unaffected slang2 - definitely affected, needs binNMU grml2usb - no build onscripter - definitely affected, needs binNMU pegasus-wms - build failed for other reason So I believe that I only need binNMUs for slang2 onscripter to solve the issues introduced in #674933. Thanks for your help Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120528200835.ga3...@alf.mars
Re: sgml-base #674933 breakage
On Mon, May 28, 2012 at 10:08:36PM +0200, Helmut Grohne wrote: slang2 onscripter kdiff3 is also affected. Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120528202623.ga6...@alf.mars
binnmus for #477751
Dear release team, We now have sgml-base 1.26+nmu3 and debhelper 9.20120528 in sid. The final step to fix #477751 is to get rid of update-catalog invocations embedded by debhelper. To discover the packages needing work I used the following command: find /srv/lintian.debian.org/laboratory/ -type f -path */control/p* -print0 | xargs -0r grep -C3 update-catalog The output is attached. The following set of packages can be updated using binNMUs: festival jade linuxdoc-tools metacity-common:metacity mutter openjade openjade1.3 The following set of packages builds arch:all packages and needs manual NMUs: debiandoc-sgml docbook docbook-dsssl docbook-ebnf docbook-html-forms docbook-mathml docbook-simple docbook-slides docbook-website docbook-xml dtd-ead libcommons-validator-java python-docutils sgml-data sgml2x w3-dtd-mathml w3c-dtd-xhtml xml-core How to proceed with them? The following set of packages needs extra work: xml2rfc #674911 (does not use dh_installcatalogs, manual conversion) sgml-data #674913 (remove transitional update-catalog calls) sgmltools-lite #674914 (remove transitional update-catalog calls) Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120528203407.ga7...@alf.mars
