Bug#1077714: release.debian.org: Have the auto-remover emails include details on how managet the RC bugs
Paul Gevers: Hi Niels, On 01-08-2024 08:09, Niels Thykier wrote: It seems to me that the emails could serve the relevant documentation (or a link to it) and thereby hopefully reduce the number of times the question(s) get raised. Thanks for the idea. I started a Wiki page [1] based on your initial text that I intend to link in the autoremoval mail. Can you (and other readers) check for (obvious) mistakes? Paul [1] https://wiki.debian.org/Autoremoval Seems like a decent enough start to me. :) I have no remarks / changes for the wiki page. Best regards, Niels
Bug#1077845: release.debian.org: Should non-free-firmware require being built on buildd?
Roland Clobus: On 03/08/2024 18:30, Niels Thykier wrote: Had a quick look at the testing `Sources` file for non-free-firmware. We are 10/15 on `Autobuild: yes` with remaining 5 not having the header. ... The 5 that are not `Autobuild: yes` would be: atmel-firmware bluez-firmware I was informed on IRC about https://salsa.debian.org/bluetooth-team/bluez-firmware/-/merge_requests/4, so I presume bluez-firmware might disappear dahdi-firmware live-tasks-non-free-firmware This is a 'meta' package, that only refers to other firmware packages, it does not contain firmware itself. Thanks Roland. That sounds like it trivially could be converted to an `Autobuild: yes` package. midisport-firmware (as far as my wetware was able to eyeball) With kind regards, Roland Clobus That leaves us with 3/15 and the question whether we want to commit for future firmware. Best regards, Niels
Bug#1077845: release.debian.org: Should non-free-firmware require being built on buildd?
Paul Gevers: Hi, On 03-08-2024 11:55, Niels Thykier wrote: Since the non-free is entirely opt-in and you had to be very active about opt'ing in as a admin, this seem fine. With the change to non-free-firmware now being enabled by d-i by default, we now have non-free-firmware packages installed by default that can use this opt-out and for me, that changes the game a bit. I totally agree. I have not checked whether all non-free-firmware is auto-buildable It would be good if we had the answer to this question, because changing britney2 to do the check for all binaries is trivial [1], and adding a hint explicitly for those that aren't auto-buildable seems maintainable (there are currently only 15 sources in non-free-firmware in sid). Paul [1] https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/policy.py?ref_type=heads#L1543 Had a quick look at the testing `Sources` file for non-free-firmware. We are 10/15 on `Autobuild: yes` with remaining 5 not having the header. No clue whether they could get that or we have to compromise already here. Though, even if they can, there is also the aspect of whether we are ready to commit to all new firmware being `Autobuild: yes`. I figured `d-boot` might have an opinion on that (which is why I have CC'ed them on this bug). The 5 that are not `Autobuild: yes` would be: atmel-firmware bluez-firmware dahdi-firmware live-tasks-non-free-firmware midisport-firmware (as far as my wetware was able to eyeball) Best regards, Niels
Bug#1077845: release.debian.org: Should non-free-firmware require being built on buildd?
Package: release.debian.org Severity: wishlist X-Debbugs-Cc: ni...@thykier.net,debian-b...@lists.debian.org Hi, Historically, we have had a major opt-out for non-free in regards to Policy. One of these opt-outs are that the package does not have to be auto-built on Debian buildds. Since the non-free is entirely opt-in and you had to be very active about opt'ing in as a admin, this seem fine. With the change to non-free-firmware now being enabled by d-i by default, we now have non-free-firmware packages installed by default that can use this opt-out and for me, that changes the game a bit. In my book, ideally, we would require all non-free-firmware to be build on buildds to have it be closer aligned with main since it is now installable by default, where we do not want to trust maintainer build packages (which also makes our contributors less of a target for build-time backdoors). Though, license requirements might prevent that (I have not checked whether all non-free-firmware is auto-buildable), so a second runner up for me would be to have Britney enforce non-free(-firmware) was built on a buildd if the source has `Autobuild` set to `yes`. This would at least close the gap as much as possible. Best regards, Niels
Bug#1077714: release.debian.org: Have the auto-remover emails include details on how managet the RC bugs
On Thu, 1 Aug 2024 07:53:39 +0200 Niels Thykier wrote: Package: release.debian.org Severity: wishlist X-Debbugs-Cc: ni...@thykier.net Hi, The emails from the auto-remover triggers people to ask questions like "how do I prevent the auto-removal?" (usually on d-release or d-mentors). It seems to me that the emails could serve the relevant documentation (or a link to it) and thereby hopefully reduce the number of times the question(s) get raised. Best regards, Niels Examples could include: * How do I prevent removal? (Triage the bug and ensure metadata is correct, Fix or downgrade the bug, ensure timely migration. Periodic updates to the RC bug if those items are stalled) * What do I do when the RC bug is not in my package? (Provide patches, check if the dependency could do with a co-maintainer or need to be salvaged, etc.) * What are the timelines for removals? X days from the bug first appears this removal notice is sent out. Then after Y since the last update to the bug, the auto-removal kicks in. Note: These timelines only apply to automatic removals. The release team can remove packages manually earlier than these timelines if they see the need for it. This another reason why it is good to document progress on the bug even if it does not translate directly into a bug being fixed here and now as that makes the release team aware that you are working on a fix. * What happens if my package is auto-removed from testing? It will be removed from testing. Outside of freezes, this is usually less of a problem, since as soon as the bug and any other testing blockers have been resolved, it can migrate back. For freezes, it is important to stay diligent and resolve these issues in a timely manner. Depending on the stage of the freeze, the package might not be able to re-enter testing once removed. Best regards, Niels
Bug#1077714: release.debian.org: Have the auto-remover emails include details on how managet the RC bugs
Package: release.debian.org Severity: wishlist X-Debbugs-Cc: ni...@thykier.net Hi, The emails from the auto-remover triggers people to ask questions like "how do I prevent the auto-removal?" (usually on d-release or d-mentors). It seems to me that the emails could serve the relevant documentation (or a link to it) and thereby hopefully reduce the number of times the question(s) get raised. Best regards, Niels
Re: Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Michael Biebl: Hello Niels, hello Sebastian Hi Michael, Am 24.03.23 um 16:28 schrieb Niels Thykier: Sebastian Ramacher: [...] Any progress here? If this issue should be fixed for bookworm, time is running short. Cheers I find that anytime I look at this bug my motivation to work on Debian instantly vanishes. In fact, I cannot even motivate myself to read the bug log to figure out what the consensus is. Accordingly, I will play the constitution 2.1.1 and step out of the way. My attempt to raise this issue with debhelper and the release-team was to gather a consensus with how to deal with the affected packages. A change to debhelper seemed liked the most straightforward approach to me. I agree with all of this and I think you were both entitled and correct in raising the issue. I am still open to this being a bug in debhelper. It was not meant as an attempt to force Niels into something he feels uncomfortable with, which he obviously does. I apologize to Niels for that and hereby close this bug report. Michael Your reaction here does not match what I had expected from my email and I suspect my intentions were not perceived by you as I intended them. To start with the most important points: You have done *nothing* to me that requires an apology from you. You have *not* forced me to do something I am uncomfortable with. As far as I am concerned, there was and is *no* conflict between you and I. We are good if you ask me. I am mostly sad that I made you think otherwise, but that is on me. Coming back to what I wanted to communicate: Starting with the context, the timing of my email came after two mails asking for an update on this bug that had not been answered by anyone. I.e., my email was a response to the requests for a update on the bug - both requests were in my view reasonable. As the named maintainer/uploader of debhelper, there is always an implicit assumption that I will be proactive in dealing with bugs, when there is no clear owner of the bug. Especially bugs that affect the upcoming release during the freeze. Given that I did not see a response and I could not easily identify a clear owner of the bug, I felt these emails hanged on me via the implicit assumption. I wanted to make it very clear that I would *not* be able to live up to that assumption. If someone wanted this change, they would have to do it without involving me at any point. I was hoping that someone would take end to end ownership and deliver it without involving me. As opposed to a PR/patch that I would have to review - or leaving me to discuss with the RT what kind of change was acceptable this stage - or leaving me to reopen the discussion with the tech-ctte whether allowing services in /usr is acceptable as it would open up for file moves between /lib and /usr/lib, which they said they would not want when the original bug was filed (#995569). I would not have been able to do that and I doubt I will be able to do that any time soon. But if someone wanted to do that. Great! It would have been a burden off my shoulder. On the flip-side, if no one else was willing to do the work, then I would not have to feel bad about not being able to do it either. Either way would relieve me of the pressure of this bug. Eventually, dh_installsystemd (et al.) will probably have to support /usr/lib. If someone fixes that now, great. If someone fixes later, great. I do not mind the change. I mind the assumption that I will be doing it (in this or in future releases). Feel free to reopen this bug. As long as we all agree that for the timing being, *I* will *not* be interacting with the bug, do any design or review of the solution, or deal with any fallout of implementing the solution. Whoever owns up to dealing with all of that gets to deliver this feature. They get to do it without having to follow the NMU rules as far as I am concerned unless a co-maintainer steps up and takes ownership of this bug, because to me that is part of "stepping out of the way" when you are not volunteering to do the work. In summary: * I do not feel you did anything wrong or owe me an apology. * I mind doing the work; not the change. If you (anyone) want this change and you commit to doing it. Please reopen the bug and go ahead as long as you do not "depend" on or "need" me for any part of it. I hope my intentions were more clear this time. Best regards, Niels
Re: Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Sebastian Ramacher: [...] Any progress here? If this issue should be fixed for bookworm, time is running short. Cheers I find that anytime I look at this bug my motivation to work on Debian instantly vanishes. In fact, I cannot even motivate myself to read the bug log to figure out what the consensus is. Accordingly, I will play the constitution 2.1.1 and step out of the way. If there are any recent debhelper contributors that want to claim this, then I will give preference to them and how they want to handle it. Otherwise, if no debhelper contributor steps up, then I will waive the NMU process on this side of the release on the debhelper package to anyone, who ones to pick this up. Please keep the following in mind: 1) Be adviced that you need to look at multiple helpers that interact with the systemd services. Notably, dh_installsystemd, dh_installsystemduser and dh_installinit - all of which assumes there is one and only one directly for these services. Good luck 2) I would that you push the changes to the salsa repo (it is DD-writable by default, others will have to do a PR) but a nmudiff CC'ed to this bug on top of the main branch in salsa will do. - Please use the main branch, there are some translation changes since last upload, which should be a non-issue. - If you are a DD, just push the changes to main and move on. Do not expect me to review a PR before you upload. 3) I expect that you upload and handle any fall out. Fall out here includes judging consensus, fix FTBFS, RC bugs or deal with discussions including the tech-ctte or the release team about the proposed solution, managing the unblock request (etc.). - Assume I will not be involved in any of these steps. 3) If you do change any translatable strings, please consider to notify the translators. At least pt and de translators recently updated and I feel it would be a shame if they were not 100%. But not enough that I expect I will invest in a follow up upload. My apologies to the release team. Having been on the release team, I know this is probably not the message you wanted this close to the release. Sadly, it is the "best" I can do. With that said and done, as far as bug is concerned, I am out! Best regards, Niels
Bug#1033409: nmu: dbgsym packages affected by fakeroot bug
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debhel...@packages.debian.org, hel...@subdivi.de Hi, I propose the following series of NMUs to close #1024261. The list is based on the set of packages that Helmut found with this script with the following modifications: * binNMU version have been removed * architecture has been removed. I assume we will do ANY binNMUs for them to avoid M-A:same issues and it is easier to overshoot than clean out the packages that are not M-A:same This would solve the dbgsym problems caused by fakeroot. For the changelog entry, allegedly fakeroot fixed the problem by now and we can reference that. Alternatively, debhelper has worked around the fakeroot problem as well in 13.11. This does not solve the non-dbgsym packages but at least we get the ball rolling on the part of the problem we have clearly identified and would enable us to close #1024261. Best regards, Nielsacm-dbgsym_6.0+20200416-1.1 alure-utils-dbgsym_1.2-9 ann-tools-dbgsym_1.1.2+doc-9 aprsdigi-dbgsym_3.10.0-5 argus-client-dbgsym_1:3.0.8.2-6.1 audacious-plugins-dbgsym_4.2-1 ax25mail-utils-dbgsym_0.15-1 colobot-dbgsym_0.2.0-2 connman-dbgsym_1.41-2 connman-vpn-dbgsym_1.41-2 conntrackd-dbgsym_1:1.4.7-1 conserver-server-dbgsym_8.2.7-2 courier-authdaemon-dbgsym_0.71.4-1 courier-authlib-dbgsym_0.71.4-1 courier-authlib-userdb-dbgsym_0.71.4-1 courier-base-dbgsym_1.0.16-3 courier-imap-dbgsym_5.0.13+1.0.16-3 courier-mlm-dbgsym_1.0.16-3 courier-mta-dbgsym_1.0.16-3 courier-pop-dbgsym_1.0.16-3 cutils-dbgsym_1.6-6 dablin-dbgsym_1.14.0-2 dolphin-owncloud-dbgsym_2.11.0.8354+dfsg-1 dvb-tools-dbgsym_1.22.1-5 fastforward-dbgsym_1:0.51-8 fido2-tools-dbgsym_1.12.0-2 freeipmi-ipmidetect-dbgsym_1.6.10-1 freeipmi-tools-dbgsym_1.6.10-1 fuse-dbgsym_2.9.9-6 geomview-dbgsym_1.9.5-4 giggle-dbgsym_0.7-5 globus-gatekeeper-dbgsym_11.4-2 gnome-applets-dbgsym_3.46.0-1 gnome-keyring-dbgsym_42.1-1 gnome-panel-dbgsym_3.46.0-1 gpsshogi-dbgsym_0.7.0-3.1 gspell-1-tests-dbgsym_1.12.0-1 gtklp-dbgsym_1.3.4-3 harp-dbgsym_1.16-1 hashcat-dbgsym_6.2.6+ds1-1 herbstluftwm-dbgsym_0.9.5-3 ibus-kkc-dbgsym_1.5.22-3 ibus-skk-dbgsym_1.4.3-2 ifcico-dbgsym_2.14tx8.10-27 ifgate-dbgsym_2.14tx8.10-27 invada-studio-plugins-ladspa-dbgsym_0.3.1-6 ipe-dbgsym_7.2.26+dfsg1-3 kbd-dbgsym_2.5.1-1 knockd-dbgsym_0.8-2 krb5-admin-server-dbgsym_1.20.1-1 krb5-auth-dialog-dbgsym_43.0-1 krb5-gss-samples-dbgsym_1.20.1-1 krb5-kdc-dbgsym_1.20.1-1 krb5-kdc-ldap-dbgsym_1.20.1-1 krb5-user-dbgsym_1.20.1-1 kup-backup-dbgsym_0.9.1-1 kyotocabinet-utils-dbgsym_1.2.79-2 lcdproc-dbgsym_0.5.9-6 lcdproc-extra-drivers-dbgsym_0.5.9-6 libbabl-0.1-0-dbgsym_1:0.1.98-1 libcoarrays-mpich-dev-dbgsym_2.10.1-1 libcoarrays-openmpi-dev-dbgsym_2.10.1-1 libdb1-compat-dbgsym_2.1.3-22 libdrm-tests-dbgsym_2.4.114-1 libfuse2-dbgsym_2.9.9-6 libiec61883-dev-dbgsym_1.2.0-6 libipe7.2.26-dbgsym_7.2.26+dfsg1-3 libkim-api2-dbgsym_2.3.0-1 libkim-api-dev-dbgsym_2.3.0-1 libleatherman1.12.1-dbgsym_1.12.1+dfsg-1.2 libopenmesh1-dbgsym_9.0-4 libopenmesh-apps-dbgsym_9.0-4 libopenmpi3-dbgsym_4.1.4-3 libopenms2.6.0-dbgsym_2.6.0+cleaned1-3 libowncloudsync0-dbgsym_2.11.0.8354+dfsg-1 libpdl-linearalgebra-perl-dbgsym_0.35-1 libplib1-dbgsym_1.8.5-14 libpmix2-dbgsym_4.2.2-1 libpmix-bin-dbgsym_4.2.2-1 libruli-bin-dbgsym_0.36-3 libsuperlu-dist8-dbgsym_8.1.2+dfsg1-1 libsuperlu-dist-dev-dbgsym_8.1.2+dfsg1-1 libtheora0-dbgsym_1.1.1+dfsg.1-16.1 libtheora-bin-dbgsym_1.1.1+dfsg.1-16.1 libv4l-0-dbgsym_1.22.1-5 libv4lconvert0-dbgsym_1.22.1-5 libxtrxll0-dbgsym_0.0.1+git20201202.1b6eddf-1 linuxptp-dbgsym_3.1.1-4 lldpd-dbgsym_1.0.16-1 login-dbgsym_1:4.13+dfsg1-1 lua-readline-dbgsym_3.2-1 lua-socket-dbgsym_3.1.0-1 miredo-dbgsym_1.2.6-7.1 mutt-dbgsym_2.2.9-1 myproxy-admin-dbgsym_6.2.14-2 myproxy-dbgsym_6.2.14-2 ndisc6-dbgsym_1.0.5-1 nethack-common-dbgsym_3.6.6-3 ntfs-3g-dbgsym_1:2022.10.3-1 ntfs-3g-dev-dbgsym_1:2022.10.3-1 oddjob-dbgsym_0.34.7-1 oddjob-mkhomedir-dbgsym_0.34.7-1 odr-dabmux-dbgsym_4.2.1-1 openmpi-bin-dbgsym_4.1.4-3 opensmtpd-dbgsym_6.8.0p2-4 orthanc-postgresql-dbgsym_4.0-7 osdsh-dbgsym_0.7.0-11 osmo-bsc-bs11-utils-dbgsym_1.9.0-3 osmo-bsc-ipaccess-utils-dbgsym_1.9.0-3 osmo-bsc-meas-utils-dbgsym_1.9.0-3 osmo-bts-dbgsym_1.5.0+dfsg1-2 osmo-ggsn-dbgsym_1.9.0-3 osmo-hlr-dbgsym_1.5.0+dfsg1-3 passwd-dbgsym_1:4.13+dfsg1-1 pdl-dbgsym_1:2.081-1 perl-tk-dbgsym_1:804.036-1 ploop-dbgsym_1.15-12 pmacct-dbgsym_1.7.7-1 postgresql-15-ogr-fdw-dbgsym_1.1.3-1 qflow-dbgsym_1.3.17+dfsg.1-3 r-cran-zip-dbgsym_2.2.2-1 roger-router-dbgsym_2.4.2-3 rxvt-unicode-dbgsym_9.30-2 scalapack-mpi-test-dbgsym_2.2.1-2 schroot-dbgsym_1.6.13-3 scitokens-cpp-dbgsym_0.7.3-1 shapelib-dbgsym_1.5.0-3 shotwell-dbgsym_0.30.17-1 sndio-tools-dbgsym_1.9.0-0.3 source-highlight-dbgsym_3.1.9-4.2 spice-vdagent-dbgsym_0.22.1-3 squid-dbgsym_5.7-1 squid-openssl-dbgsym_5.7-1 sqwebmail-dbgsym_6.0.5+1.0.16-3 sslh-dbgsym_1.20-1 sysrepo-dbgsym_2.0.53-6 topp-dbgsym_2.6.0+cleaned1-3 torcs-dbgsym_1.3.7+dfsg-5
Re: Bug#1024261: debhelper: dbgsym packages contain directoryr writable by build user
Helmut Grohne:
Hi,
Hi Helmut
Thanks for your work - both on this specific problem and in general!
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.
Indeed, will do with this email.
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?
For reference, it was not clear to me that the binNMUs proposed have
been run, so I submitted a formal request to release.debian.org for the
dbgsym packages you already identified (you should get a bug report
about that soon).
I chose to use architecture-less binNMU and recommend an "ANY" binNMU to
avoid M-A:same problems. Feel free to follow up on that bug when you get
the CC from the BTS if you have any concerns in that regard.
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?
In theory, yes. Though I doubt there will be many left that did not
also build a dbgsym. My guess is that we are in the 0-5 range now with
these binNMUs out the door.
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?
I think it is much more reliable and easier to check the owner / group
against the /usr/share/base-passwd/{group,passwd}.master files. For me
this:
1) Avoids having to compare a "correct" vs. a "possible faulty"
version, which reduces the amount of packages needed to be scanned.
We can limit ourselves to the 32bit architectures.
2) Avoids having to do path normalization to detect the problem.
But as mentioned above, I doubt there will many left once the dbgsym
binNMU run is complete. So any analysis done now in this space should
remove duplicates from your previous list.
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
Once again, thanks for your work here. I passed it on to the release
managers.
Best regards,
Niels
Re: Bug#1024261: debhelper: dbgsym packages contain directoryr writable by build user
Axel Beckert: Hi, Helmut Grohne wrote: 308 armel 313 armhf 316 i386 613 mipsel I think it is fairly safe to say that the problem affects 32bit architectures. 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 ? Regards, Axel It is. 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) Thanks, ~Niels
Please assert severity of bug#1017441 (debhelper: building src:shadow wrongly makes passwd depend on systemd | systemd-tmpfiles)
Hi Release team, Bug #1017441 was filed against debhelper in related to a change to dh_installtmpfiles that made it apply an unconditional dependency on "systemd | systemd-tmpfiles". My concern is not the dependency itself (as I understand it, the systemd GR ratifies that). What might be concerning is that the dependency appears in lower levels of the build stack causing additional package to appear in our chroot according to Santiago Vila (quoted below in full). The bug was originally filed as RC but has now been degraded to wishlist. Admittedly, it is not clear to me the downgrade was done with the knowledge that the bug affected our chroots. The question is whether you feel this is an RC bug and would like me to revert the change immediately / before the transition freeze? The alternative is you do not feel this bug is concerning/RC in which case I will keep the current version until people have come to a conclusion on the bug. What is your view on the above question? Thanks, ~Niels PS: Please include the bug in CC with your (formal) answer to that question. Santiago Vila: Hello. As of today, upgrading a sid chroot containing debhelper to the sid of today, systemd, mount, and several other packages are installed into the chroot. This is usually undesired because we want build chroots to be as minimal as possible. Users of debootstrap can certainly use --include and --exclude to fine-tune the contents of the chroot, but as a user of debootstrap, I would expect it to do the right thing (minimal chroot) by default and without having to fine-tune it. On amd64, I've checked that installing systemd-standalone-tmpfiles allows systemd and all the extra packages to be removed again. So I wonder if reversing the dependency created by debhelper: systemd | systemd-tmpfiles would improve this state of things. (Trimming Cc list a little bit, I don't want to spam everybody) Thanks.
Bug#918620: britney: blocks arch:all packages on non-installability on CI archs
Paul Gevers: > Control: tags -1 patch > Control: forwarded -1 > https://salsa.debian.org/release-team/britney2/compare/31e32782...c9e8751c > > Hi all > > On 28-11-2019 10:28, Paul Gevers wrote: >> With the addition of arm64 as a CI architecture, the situation got >> worse. E.g. https://qa.debian.org/excuses.php?package=q2-demux currently >> shows: >> """ >> uninstallable on arch arm64, autopkgtest delayed there >> Additional info: >> q2-demux/i386 unsatisfiable Depends: python3-skbio >> """ >> >> Indeed, the arch:all package q2-demux depends on python3-skbio, which is >> only available on amd64. > > Ivo and I had a discussion about this at the miniDebCamp @ Brussels. I > prepared a solution. > > Paul > Looks good to me! If it passes the relevant tests (props for adding a test case), then I think we should merge it! Thanks, ~Niels
Bug#944190: release.debian.org: Allow britney to consider installability of dependencies of essential packages
Control: tags -1 confirmed patch
Niels Thykier:
> [...]
>
> I looking forward to your test case as it will make this issue a lot
> easier to debug.
>
Hi,
Thanks for the test case. :)
I have pushed it to britney2-tests and flagged it as a known failure.
> What is supposed to happen is that:
>
> * Britney "should" rewrite the relation on "libsystemd0" as
>"libsystemd0 | libelogin0" when building the BinaryPackageUniverse
>(actually as libsystemd0//arch | libsystemd0//arch
> tuples).
>
>- This is also based on the assumption that the Conflicts/Provides
> setup in libelogin0 is done correctly. I /think/ it is - I am just
> being explicit about the assumption.
>
Indeed, I have looked through the state of the test and the relations
are as I expected here.
> [...]> * It /could/ be related to the caching of the pseudo-essential set.
>AFAIUI, the cache should "just work(tm)" if the previous point
>does not have a flaw. At least the current cache code assumes that
>libsystemd0 and libelogin0 will not be resolved by
>_get_min_pseudo_ess_set. Though, it could also be a point where the
>bug hides.
>
> [...]
I think this ends up being the winner. The _get_min_pseudo_ess_set
method builds a set that includes libtest (libsystemd0) from the beginning.
This is technically correct and valid at the start because libprovider
(libelogind0) is *not* in testing at that point (so any selection for
the essential set will always include libtest at the start).
Unfortunately, the cache is never invalidated by adding the alternative
and thus libprovider is immediately rejected as broken.
I have attached the following patch that passes the provided test and
(AFAICT) does what we want. Please feel free to review it; I will come
back to this in a few days.
Note: I do not expect to have a lot of spare time for Debian the coming
week; please ping me on this bug if I have not replied by next Sunday.
Thanks,
~Niels
From 0d5ea5eb8c0276e48f1394f233e1441ab87dcfbc Mon Sep 17 00:00:00 2001
From: Niels Thykier
Date: Sun, 10 Nov 2019 23:08:47 +
Subject: [PATCH] Improve cache invalidation of (pseudo-)essential set
If a new pseudo-essential package was added to testing *and* it is
mutually-exclusive with an existing member, britney would incorrectly
flag it as uninstallable (unless another change triggered a cache
invalidation of the pseudo-essential set).
With this commit, the cache invalidation is now done based on whether
we add something that *might* be in the (effective) pseudo-essential
set. It is an overapproximation as there are cases where the
invalidation is unnecessary, but at the moment it is not a performance
concern.
Closes: https://bugs.debian.org/944190
Signed-off-by: Niels Thykier
---
britney2/installability/tester.py | 12
britney2/utils.py | 21 -
2 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/britney2/installability/tester.py b/britney2/installability/tester.py
index 5ac6ef2..4687cc0 100644
--- a/britney2/installability/tester.py
+++ b/britney2/installability/tester.py
@@ -17,7 +17,7 @@ from functools import partial
import logging
from itertools import chain, filterfalse
-from britney2.utils import iter_except
+from britney2.utils import iter_except, add_transitive_dependencies_flatten
class InstallabilityTester(object):
@@ -52,12 +52,16 @@ class InstallabilityTester(object):
# are essential and packages that will always follow.
#
# It may not be a complete essential set, since alternatives
-# are not always resolved. Noticably cases like "awk" may be
+# are not always resolved. Noticeably cases like "awk" may be
# left out (since it could be either gawk, mawk or
# original-awk) unless something in this sets depends strictly
# on one of them
self._cache_ess = {}
+essential_w_transitive_deps = set(universe.essential_packages)
+add_transitive_dependencies_flatten(universe, essential_w_transitive_deps)
+self._cache_essential_transitive_dependencies = essential_w_transitive_deps
+
def compute_installability(self):
"""Computes the installability of all the packages in the suite
@@ -137,8 +141,8 @@ class InstallabilityTester(object):
# Re-add broken packages as some of them may now be installable
self._suite_contents |= self._cache_broken
self._cache_broken = set()
-if pkg_id in self._universe.essential_packages and pkg_id.architecture in self._cache_ess:
-# Adds new essential => "pseudo-essential" set needs to be
+if pkg_id in self._cache_essential_transitive_dependencies and pkg_id.architecture in self._cache_
Bug#944190: release.debian.org: Allow britney to consider installability of dependencies of essential packages
Mark Hindley: > Neils, > > On Fri, Nov 08, 2019 at 07:03:00AM +0000, Niels Thykier wrote: >> Hi Mark >> >> Thanks for the investigative work and the patch. >> >> I have not had time to review the patch yet in details and hope to have >> a look this weekend. > > Thanks. > Hi Mark, Once again, thanks for trying to fix this. I have had a look at the code and your proposed patch. As I understand it, the bug will still be present but just "harder" to trigger and possibly harder to debug (I suspect we will end up with a corrupted state in the essential set cache). >> Could I convince you to add a small test case for this problem to our >> britney2-tests repo (https://salsa.debian.org/debian/britney2-tests) >> that fails with the current master but succeeds with your patch? This >> would ensure we do not inadvertently regress on this area when >> refactoring code. > > I will happily look at that. I am busy until Sunday, but will look at it > then. > > Many thanks. > > Mark > I looking forward to your test case as it will make this issue a lot easier to debug. What is supposed to happen is that: * Britney "should" rewrite the relation on "libsystemd0" as "libsystemd0 | libelogin0" when building the BinaryPackageUniverse (actually as libsystemd0//arch | libsystemd0//arch tuples). - This is also based on the assumption that the Conflicts/Provides setup in libelogin0 is done correctly. I /think/ it is - I am just being explicit about the assumption. * The InstallabilityTester "should" consider that relation "unsolvable" when building the cache and defer it to later. That is, it should keep the relation in "ess_choices" in _get_min_pseudo_ess_set until it returns. * It /could/ be related to the caching of the pseudo-essential set. AFAIUI, the cache should "just work(tm)" if the previous point does not have a flaw. At least the current cache code assumes that libsystemd0 and libelogin0 will not be resolved by _get_min_pseudo_ess_set. Though, it could also be a point where the bug hides. I think these are the 3 key points of assumptions to verify. Honestly, I *doubt* the first point fails (I would expect a lot more breakage), but I have been wrong before. The below is the loop responsible for pre-computing the essential set. > while ess_base: > self._check_loop(universe, suite_contents, stats, > start, ess_never, cbroken, > ess_choices, ess_base) > if ess_choices: > # Try to break choices where possible > nchoice = set() > for choice in not_satisfied(ess_choices): > b = False > for c in choice: > relations = universe.relations_of(c) > if relations.negative_dependencies <= ess_never > and \ > not > any(not_satisfied(relations.dependencies)): > ess_base.append(c) > b = True > break > if not b: > nchoice.add(choice) > ess_choices = nchoice > else: > break The crucial point here is that: relations.negative_dependencies <= ess_never ... is supposed to be false for *both* libsystemd0 *and* libelogin0, but could become True for libsystemd0 if there is a bug that makes britney pick another package in the pseudo-essential set that mandates (the "real") libsytemd0. Thanks, ~Niels
Bug#944190: release.debian.org: Allow britney to consider installability of dependencies of essential packages
Hi Mark Thanks for the investigative work and the patch. I have not had time to review the patch yet in details and hope to have a look this weekend. Could I convince you to add a small test case for this problem to our britney2-tests repo (https://salsa.debian.org/debian/britney2-tests) that fails with the current master but succeeds with your patch? This would ensure we do not inadvertently regress on this area when refactoring code. The overall work flow for creating a test is basically: # 1. Create the test (I think basic-essential-overapprox or # basic-essential-pseudo-uninst/test-data might be good/related # starting points for your case). $ cp -a t/ t/bug-944190 # 2. Edit test data $ $EDITOR t/bug-944190/expected* t/bug-944190/expected/var/data/*/* \ t/bug-944190/description # 3. Run the test $ rm -fr test-out $ t/runtests t test-out bug-944190 # Rinse and repeat 2+3 until test behaves as expected. For marking the test as a known failure, you can copy the following file into the test "t/basic-essential-uninst/test-data" Thanks, ~Niels
Bug#934995: transition: xfconf
> On Wed, 2019-08-21 at 08:33 +0000, Niels Thykier wrote: >> Ack, please go ahead. > > Thanks, I've started uploading stuff. > >> Please let us know what will need binNMUs and when. > > Sure, I'll let stuff settle a bit after uploading everything and I'll let you > know. > > Regards, > Hi, jmw already scheduled the binNMUs already so everything but xfce4-sntray-plugin has been rebuilt successfully by now (some of the builds are still pending uploads though). I assume you have the ball on xfce4-sntray-plugin (either by filing an RC bug against it or/and uploading a fix). Thanks, ~Niels
Re: vacation 3.3.2 MIGRATED to testing
Ian Jackson:
> Debian testing watch writes ("vacation 3.3.2 MIGRATED to testing"):
>> FYI: The status of the vacation source package
>> in Debian's testing distribution has changed.
>>
>> Previous version: 3.3.1
>> Current version: 3.3.2
>
> Hi. I think something went wrong with testing migration here.
> 3.3.2, which is now in testing, was *not* built on the buildds.
> Yesterday's excuses gave that as the reason for vacation not
> migrating. So I did a source-only re-upload, 3.3.3.
> But it seems that britney has migrated 3.3.2.
>
> https://tracker.debian.org/pkg/vacation
>
> Ian.
>
Hi Ian,
There was a binNMU of vacation/3.3.2 yesterday[1]. I have not looked
into the precise timing but I assume that is the reason why 3.3.2 migrated.
Thanks,
~Niels
[1]
https://buildd.debian.org/status/logs.php?pkg=vacation&ver=3.3.2%2Bb1&arch=amd64&suite=sid
Bug#934996: transition: xfce4-panel
> On Wed, 2019-08-21 at 09:55 +0000, Niels Thykier wrote: >> Could you check if >> https://release.debian.org/transitions/html/xfce4-panel.html matches >> your expectation for the packages affected by this transition? > > I'm a bit surprised we have so few libxfce4panel-1.0 dependencies left, but > that's nice. > > place and weather plugins will have a sourceful upload bumping them to > libxfce4panel-2.0 so they'll disappear from the list. > > I'm still a bit unsure about the behavior of libxfce4panel-2.0 4.14 plugins > when they're loaded in a 4.12 panel, but they shouldn't require a binNMU > anyway. > > Regards, > Ok. Should we binNMU the following packages now then? orage, workrave, xfce4-cpugraph-plugin, xfce4-equake-plugin, xfce4-mailwatch-plugin Thanks, ~Niels
Bug#934996: transition: xfce4-panel
Yves-Alexis Perez: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > the Xfce team would like to upload the Xfce 4.14 release to unstable > (most packages pre-release have been uploaded to experimental). > > Panel plugins might have a tight dependency to the panel they've been > built with, so a while back we added shlibs dependencies to the major > version of the panel the plugins have been built with. So panel plugins > built against xfce4-panel 4.12 have a dependency on: > > xfce4-panel (>= 4.11), xfce4-panel (<< 4.13) > > and panel plugins built against 4.14 will have: > > xfce4-panel (>= 4.13), xfce4-panel (<< 4.15) > > After uploading xfce4-panel 4.14, we'll have to schedule binNMus of > panel plugins without sourceful upload. > > Please authorize us to upload the new xfce4-panel version so we can proceed > with the rest of the Xfce 4.14 uploads. > > I'm not sure I can provide a ben file since it's not a standard library > transition. > > Thanks in advance, and regards, > Hi Could you check if https://release.debian.org/transitions/html/xfce4-panel.html matches your expectation for the packages affected by this transition? Thanks, ~Niels
Bug#934995: transition: xfconf
Control: tags -1 confirmed pending On Sat, 17 Aug 2019 22:02:46 +0200 Yves-Alexis Perez wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi, > > the Xfce team would like to upload the Xfce 4.14 release to unstable > (most packages pre-release have been uploaded to experimental). One > library package, xfconf, has a transition (already tracked at > https://release.debian.org/transitions/html/auto-xfconf.html). > > Please authorize us to upload the new xfconf version so we can proceed > with the rest of the Xfce 4.14 uploads. Only few binNMUs will be needed > since most dependencies will see a sourceful upload. > > Regards, > > [...] Ack, please go ahead. Please let us know what will need binNMUs and when. Thanks, ~Niels
Bug#903211: Checking for removal of BD [was Re: release.debian.org: How to handle unbuildable packages in buster]
Paul Gevers: > Hi all, > > On Thu, 09 Aug 2018 09:32:00 +0000 Niels Thykier wrote: >> 3) Build-Depends are not enforced on removal. That is packages >> /can/ be removed while packages are build depending on them. >> >> Limitation 2+3 are slightly more involved and may take quite a while for >> us to implement. > > Seems like this is really in need of attention. [...] > Ack. > I may be saying something stupid, but shouldn't the build-depends not > *just* be added to the depends in the migration phase? Or is that still > quite involved due to -arch/-indep? > > Paul > The migration phase never concerned itself with source packages (if you are thinking of the is_installable check). And adding Build-Depends(-Indep|-Arch) to a random binary of the source would have its own issues - notably, a binary is not required to be co-installable with its source's build-depends. It is not that it is impossible, it is just a question of spoons, time and test cases. If you have any trivial test cases, please by all means begin to collect/commit them (it makes life so much easier later). Thanks, ~Niels
Bug#933595: transition: pkg-js-tools
Paul Gevers: > Control: tags -1 moreinfo > > Hi Xavier, > > [...] > > Also, as this is a debhelper plugin, can't you couple this to a > debhelper compat level? I believe those were introduced to enable > introduction of backwards incompatible changes, but I have no idea if > that propagates to the helpers. > > [...] As the debhelper maintainer: (As I have _not_ looked at the concrete case, I am _not_ coming with a recommendation for or against using the compat system in this case.) Third-party plugins are welcome to piggy back in the debhelper compat system (several have done so to date) and I am happy to include a note about it in debhelper(7)[1]. Thanks, ~Niels [1] This happened in compat 12 with e.g. the following note: * The third-party dh_golang tool (from dh-golang package) now defaults on honoring DH_GOLANG_EXCLUDES variable for source installation in -dev packages and not only during the building process. Please set DH_GOLANG_EXCLUDES_ALL to false to revert to the previous behaviour. See Debian::Debhelper::Buildsystem::golang(3pm) for details and examples.
Re: Bits from the Release Team: ride like the wind, Bullseye!
Vincent Bernat: > ❦ 7 juillet 2019 02:47 +01, Jonathan Wiltshire : > >> No binary maintainer uploads for bullseye >> = >> >> The release of buster also means the bullseye release cycle is about to >> begin. >> From now on, we will no longer allow binaries uploaded by maintainers to >> migrate to testing. This means that you will need to do source-only uploads >> if >> you want them to reach bullseye. >> >> >> Q: I already did a binary upload, do I need to do a new (source-only) >> upload? >> A: Yes (preferably with other changes, not just a version bump). >> >> Q: I needed to do a binary upload because my upload went to the NEW queue, >> do I need to do a new (source-only) upload for it to reach bullseye? >> A: Yes. We also suggest going through NEW in experimental instead of >> unstable >> where possible, to avoid disruption in unstable. > > I didn't follow carefully the past discussion, but why aren't we just > throwing the uploaded binaries away? > Hi Vincent, I supported this method because it: * reliably catches all maintainer-built packages in main. Some maintainers will still need to bootstrapping in unstable using maintainer-built binaries due to the complexity of their packages. This method will simply stop them in sid until they have been rebuilt on the buildds. Compare with throw-away binaries, where exceptions are not easily tracked out of the box (plus you would need to implement an exception workflow too). * was simple and fast to deploy. It required a trivial policy in Britney plus some code to fetch data and it just works. Compare here with throw-away binaries, where the ftp-masters would have to implement changes to dak to support this and accommodate for the complexity of binary-bootstrapping. * can be combined with throw-away binaries at a later point. If/when we implement a good solution to throw-away, we can deploy that next to this change. As mentioned in past points, there are cases where we would still need maintainer-built binaries temporarily, so we would still need a solution like this to ensure full coverage. I hope this answered your question to satisfaction. Thanks, ~Niels
Bug#929913: unblock: simple-cdd/0.6.7
Vagrant Cascadian: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-Cc: vagr...@debian.org, debian-b...@lists.debian.org > > Please unblock package simple-cdd > > This update fixes several release-critical and important bugs, as well > as documentation updates. > > Several issues were reported with expired keys in the archive keyring > breaking builds with simple-cdd, even when the expired key was not > used to verify the repositories being checked. This was fixed by > allowing expired keys to be present in the keyring used by reprepro > (though are not treated as valid for verifying Release files). > > A typo was fixed that caused a traceback in gpg verification, and now > reports the failing command. > > The --batch argument was added to gpg calls, which are all > non-interactive, which allows it to work in docker environments. > > Contact information in the README was no longer valid, and so it was removed. > > Fix a number of issues with changes in qemu arguments, and re-add the > missing support to pass arbitrary qemu options. > > Update example configuration files, removing obsolete options and > adjusting a syntax change in some options which no longer support > variables. > > The ltsp profile was updated to use the defaults for > ltsp-client-builder, with commented examples for using the non-default > values. NFS is no longer used in LTSP by default, so is no longer > configured, and the example to configure DHCP was updated to use > dnsmasq. > > The test profile was updated with new and changed preseeding options, > as well as options passed to qemu. > > The default profile updated the example to avoid asking to set up > another CD. > > The router profile example ethernet interface name was updated to be > consistant with current naming conventions. > > [...] > > > unblock simple-cdd/0.6.7 > > > Thanks for all your work towards releasing Debian! > > live well, > vagrant > Looks good to me, CC'ing KiBi for a d-i ack before completing the unblock. Thanks, ~Niels
Bug#929912: unblock: ltsp/5.18.12-3
Control: tags -1 confirmed d-i Vagrant Cascadian: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-Cc: vagr...@debian.org, debian-b...@lists.debian.org > > Please unblock package ltsp > > This fixes two release-critical bugs, an important bug, and updates > the debconf translation for Dutch. > > Builds from unsigned CDs failed due to changes in apt being more > strict regarding unsigned repositories. This is fixed by passing the > --trust-file-mirror option introduced in ltsp-build-client upstream, > but not added to the default arguments for the ltsp-client-builder > .udeb. This .udeb is not used in the default debian-installer images, > and thus should have no impact on them. > > The tool to build an LTSP chroot environment failed to detect the > codename in buster now that /etc/debian_version contains a version, > instead passing the version of Debian "10" to debootstrap, resulting > in a failure to build. The upstream fix was to switch back to using > lsb_release, and the patch applied to this version. > > An important issue in the arguments for mounting loopback images was > discovered and fixed upstream, ensuring read-only mounts which might > otherwise lead to filesystem inconsistancies with ext4 or other > writeable filesystems, and fixing a typo in the loop argument passed > to mount. The upstream patch is included in this version. > > Additionally, the Dutch debconf message translation was included in > this version. > > [...] > > unblock ltsp/5.18.12-3 > > > Thanks for all your work on releasing Debian! > > > live well, > vagrant > Looks good to me, CC'ing KiBi for a d-i ack before completing the unblock. Thanks, ~Niels
Bug#929776: unblock: rrdtool/1.7.1-2
Control: tags -1 moreinfo confirmed Jean-Michel Vourgère: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: unblock > Severity: normal > > Please allow me to add an upstream patch in order to fix segfaults in rrdtool > daemon, that occurs when xport'ing an non-existent RRD file. > > unblock rrdtool/1.7.1-2 > Please go ahead with the upload and remove the moreinfo tag when it is ready to be unblocked. Thanks, ~Niels
Bug#924948: unblock: onedrive/2.2.6-2
Norbert Preining: > Hi Paul, > > On Thu, 30 May 2019, Paul Gevers wrote: >> On Tue, 19 Mar 2019 07:50:10 +0900 Norbert Preining > > What a time lag for a release related bug, impressive. > Hi Nobert, I can understand that the delay in the reply is unsatisfying to you - personally, I am not happy about such delays either. However, I find remarks like the above unhelpful and uncalled for at best - not to mention draining energy- and motivation-wise. Please keep future communication professional. A much better approach would have been to ask us an update (in a friendly/professional manner) in case we had forgotten about the request. This might have gotten you a reply much earlier. Thanks, ~Niels
Bug#929731: unblock: flash-kernel/3.99
Control: tags -1 confirmed d-i Vagrant Cascadian: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-Cc: vagr...@debian.org, debian-b...@lists.debian.org > > Please unblock package flash-kernel > > This upload adds support for two additional boards, one additional name > for another board, and updates the Uploaders list. The changes should be > very low risk to existing platforms, and really appreciated by people > with the added boards. > > > [...] > > unblock flash-kernel/3.99 > > > Thanks for considering! > > live well, > vagrant > Hi, Thanks, this is marked OK from a release team PoV. Adding KiBi for a d-i ack before the final unblock. Thanks, ~Niels
Bug#929607: unblock: qemu/1:3.1+dfsg-8 (pre-upload)
Control: tags -1 moreinfo confirmed Michael Tokarev: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Hi! > I've prepared next release of the qemu debian package, with > a few bugfixes, and am asking if it's okay to upload these > changes to unstable (targetting buster). The change includes > 3 security fixes which should go anyway, and 2 "other" fixes > which are questionable, hence the pre-approval bugreport/question. > > All changes are "easy" ones, and are mostly one-liners and are > easy for review. All bugfixes has been appied upstream too. > > Is it okay for the changes to go to buster? > > Thanks, > > /mjt > > [...] > + > unblock qemu/1:3.1+dfsg-8 > > [...] > Please go ahead with the upload and remove the moreinfo tag once it is ready to be unblocked. Thanks, ~Niels
Bug#929215: unblock: systemd/241-4
Michael Biebl: > Am 20.05.19 um 14:06 schrieb Michael Biebl: >> Am 19.05.19 um 12:47 schrieb Niels Thykier: >> >>>> * Add check to switch VTs only between K_XLATE or K_UNICODE. >>>> Switching to K_UNICODE from other than L_XLATE can make the keyboard >>>> unusable and possibly leak keypresses from X. >>>> (CVE-2018-20839, Closes: #929116) >>>> >>>> https://salsa.debian.org/systemd-team/systemd/commit/5a564c6ef3906c0f3885a3a2aafce772393f760a >> >> In the mean time a regression was reported caused by this patch. >> I marked the bug as RC. Given how long it takes to find a solution >> upstream, I will either upload a fix for that or revert/drop the patch >> again. > > I've reverted this patch in 241-5, as no fix is available yet. > No other changes were made in 241-5. > > Regards, > Michael > Ack, thanks for handling this. The changes in 241-5 lgtm. :) Thanks, ~Niels
Bug#929452: release.debian.org: [pre-approval] testing-proposed-updates for unicode changes
Control: tags -1 moreinfo Xavier Guimard: > Package: release.debian.org > Severity: normal > > Hi all, > > dur to unicode change, 2 nodejs packages require an update: > - node-regenerate-unicode-properties > - node-regexpu-core > > These 2 packages have been updated in unstable so can no more be updated > using the normal way. The proposed changes are very few (patch to update > package.json + debian/control dependency update from node-unicode-11.0.0 > to node-unicode-12.0.0). > > These updates are required since they are both dependencies of node-rollup > which is a build dependency of ~20 packages. > > Do you authorize me to upload these 2 +deb10u1 packages in > testing-proposed-updates? Packages are tested locally, build + > autopkgtest OK. > > Sorry for the inconvenience. > > Cheers, > Xavier > > [...] > The versions in unstable: Could they be used / unblocked as-is (without needing anything else)? Thanks, ~Niels
Bug#929387: unblock: libssh/0.8.7-1 (pre-upload approval)
Control: tags -1 moreinfo confirmed Martin Pitt: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Three months ago, a new libssh upstream bug fix release 0.8.7 was done, which > fixes a dozen security issues, crashes, and other bugs: > > https://git.libssh.org/projects/libssh.git/log/?h=stable-0.8 > (the bits between 0.8.6 and 0.8.7) > > (Our package already has the oldest three patches backported) > At first I wanted to cherry-pick, but honestly I think we should have all > these > fixes in buster, including the "Remove SHA384 HMAC" before that hits stable. > > I haven't yet uploaded this new version, as I'd like to get your approval > first. If you do approve, I'll upload it to unstable, otherwise to > experimental > and later through s-p-u. > > I attach the full debdiff between the current unstable/testing version and the > one I'd like to upload. If you prefer looking at it on salsa: > > These are the upstream changes: >https://salsa.debian.org/debian/libssh/commit/aab54d0cc04dd > and the corresponding packaging changes for it (dropping patches): >https://salsa.debian.org/debian/libssh/commit/34591503a1b4b > > I also added valgrinding to the autopkgtest, which exposes a bug: >https://salsa.debian.org/debian/libssh/commit/59593bc7cf4 > > This bug also happens on 0.8.6 and earlier versions (not yet on 0.6.x), so > this > is unrelated to this particular upstream update, but I'd still like to land it > to avoid regressions under valgrind. > > Thanks for considering! > > Martin Pitt > Hi Martin, Please go ahead with the upload (with the debdiff attached to your initial mail in the bug) and remove the moreinfo tag once it is in unstable ready to be unblocked (e.g. autopkgtests have succeeded). Thanks, ~Niels
Bug#929132: unblock (pre-approval): dbus/1.12.14-1
Control: tags -1 d-i confirmed Simon McVittie: > Control: tags -1 - moreinfo > > On Fri, 17 May 2019 at 18:59:00 +0000, Niels Thykier wrote: >> I am ok with these changes on the premise that you are ready to promptly >> rollback to the bare minimum changes in case of regressions (regardless >> of whether we see them before or after the migration). >> >> If you agree with this, please go ahead with the upload and remove the >> moreinfo tag once it is ready to be unblocked. > > Understood. If there are regressions, I can revert individual fixes if > the cause is obvious, or if necessary do a 1.12.14+really1.12.12 upload. > > I'm busy next weekend and will probably be checking email less frequently, > so it would be ideal if you're able to set the age-days to cause migration > on the 27th - that way I'll be more able to respond to any new regression > reports that come from testing users shortly after migration. > > I've uploaded 1.12.14-1 (no further changes, other than mentioning #928877 > in the changelog) and it has built on all release architectures, except > 'all' which is still Needs-Build. > > Thanks, > smcv > Ok. I have added an unblock and age-days 8 hint. Also CC'ing KiBi for a d-i ack before adding an unblock-udeb hint. Thanks, ~Niels
Bug#929215: unblock: systemd/241-4
Control: tags -1 confirmed d-i Michael Biebl: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package systemd > > All patches are cherry-picked from upstream git. > > Annotated changelog: > > systemd (241-4) unstable; urgency=medium > > * journal-remote: Do not request Content-Length if Transfer-Encoding is > chunked (Closes: #927008) > > https://salsa.debian.org/systemd-team/systemd/commit/d8e4bc4487b0f32b39b15152040351261329e92a > > Without this fix, systemd-journal-remote is pretty much completely > broken, that's why I had marked this bug RC for the > systemd-journal-remote package > > > * systemctl: Restore "systemctl reboot ARG" functionality. > Fixes a regression introduced in v240. (Closes: #928659) > > https://salsa.debian.org/systemd-team/systemd/commit/8127cbd86fadf245dd28666c1bfe82a3eb116448 > > > * random-util: Eat up bad RDRAND values seen on AMD CPUs. > Some AMD CPUs return bogus data via RDRAND after a suspend/resume cycle > while still reporting success via the carry flag. > Filter out invalid data like -1 (and also 0, just to be sure). > (Closes: #921267) > > https://salsa.debian.org/systemd-team/systemd/commit/efbcf5102f0ac7b43a2f7b8c79084fdfd2d1fa72 > > RDRAND is used by systemd for its hashmap implementation. On some AMD > CPUs (AMD CPU family 22), RDRAND returns bogus data after > suspend/resume, leading to severe mis-behaviour of systemd. Typical > symptoms are failure to shutdown properly or when trying suspend again. > > > * Add check to switch VTs only between K_XLATE or K_UNICODE. > Switching to K_UNICODE from other than L_XLATE can make the keyboard > unusable and possibly leak keypresses from X. > (CVE-2018-20839, Closes: #929116) > > https://salsa.debian.org/systemd-team/systemd/commit/5a564c6ef3906c0f3885a3a2aafce772393f760a > > > * Document that DRM render nodes are now owned by group "render" > (Closes: #926886) > > https://salsa.debian.org/systemd-team/systemd/commit/e3772a013721083a740ab9dedbf060cf5b3c3709 > > Documentation update, which was explicitly requested for the > video->render change of the the /dev/dri/renderD* devices. > > KiBi (and debian-boot) is in CC > > Full debdiff is attached. > > Regards, > Michael > > unblock systemd/241-4 > > [...] > Ok with with me. Waiting for KiBi to give an ack from the d-i side before I will fully unblock it. Thanks, ~Niels
Bug#929171: unblock: espeakup/1:0.80-15
Control: tags -1 confirmed d-i Samuel Thibault: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Hello, > > As reported on Bug#929169, “the Linux kernel in Buster seems to take > much longer (as much as 12s!) to detect some sound card such as the > widespread Intel HDA. The current timeout in espeakup-udeb is thus way > too short, and makes the Debian installer useless for blind people > having such audio cards.” > > In version 1:0.80-15 (debdiff attached) I have thus made the timeout > longer. A proper solution would be to make espeakup startup event-based, > but that would be very involved at this stage of development. > > This version was confirmed to be fixing the issue on a few user systems. > > Samuel > > unblock espeakup/1:0.80-15 > > [...] Ack from here; CC'ing KiBi for a d-i ack before it is fully unblocked. Thanks, ~Niels
Bug#929029: unblock: apt-cacher-ng/3.2.1-1
Control: tags -1 moreinfo confirmed Eduard Bloch: > Control: retitle -1 [pre-approval] unblock: apt-cacher-ng/3.2.1-1 > > Hallo, > * Niels Thykier [Wed, May 15 2019, 07:53:00PM]: >> Control: tags -1 moreinfo > > Sure, see attachments. As explained before, just a one-liner which uses > existing functionality (same content as before, now from a real package > build and git compare between tag/branch). If the meaning of the change > is not understandable, please check the effect of forgiveDlErrors member > in > https://salsa.debian.org/blade/apt-cacher-ng/blob/upstream/sid/source/cacheman.cc > and maybe related uses in > https://salsa.debian.org/blade/apt-cacher-ng/blob/upstream/sid/source/expiration.cc > . > > BTW, maybe I was not precise enough before: this is a request for > pre-approval, the package is not uploaded yet. > > Best Regards, > Eduard. > Thanks for the extra details. :) Please go ahead with the change and remove the moreinfo tag when it has been uploaded to unstable and it is ready to be unblocked. Thanks, ~Niels
Bug#928908: unblock: libdebian-installer/0.119
Niels Thykier: > Control: tags -1 d-i confirmed > > Asbjørn Sloth Tønnesen: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: unblock >> >> Please unblock libdebian-installer/0.119 fixing RC bug #55 >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=55 >> >> Changes: >> libdebian-installer (0.119) unstable; urgency=medium >> >> [ Cyril Brulebois ] >> * Drop support for arm*/ixp4xx and arm*/iop32x; support for those >> platforms was removed from the Linux kernel and therefore d-i. >> * Remove Christian Perrier from Uploaders, with many thanks for all >> his contributions over the years! (Closes: #927544) >> . >> [ Bastian Blank ] >> * Enlarge maximum line length in Packages and Sources files. >> (closes: #55) >> >> [...] >> > > OK from here. CC'ing KiBi for a d-i ack. > > Thanks, > ~Niels > (This time with KiBi actually in CC... apologies for the delay).
Bug#929132: unblock (pre-approval): dbus/1.12.14-1
Control: tags -1 moreinfo confirmed Simon McVittie: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > I would like to follow the dbus upstream 1.12.x stable branch in buster, > like I did for 1.8.x in jessie and 1.10.x in stretch. I am an upstream > maintainer and prepared all recent upstream releases. > > If the timing of this release is not suitable to make it into > buster r0, it might be a good idea to backport the changes related to > _dbus_rlimit_raise_fd_limit() (Debian bug #928877) as a patch, so that > *those* can go into r0. As a result I haven't uploaded to unstable yet, > to keep it possible to upload a backport via unstable if you'd prefer. > > Annotated diffstat for the attached diff, filtered with "filterdiff -p1 > --exclude=Makefile.in --exclude=aclocal.m4 --exclude=build-aux/ltmain.sh > --exclude=configure --exclude='*/Makefile.in' > --exclude=aminclude_static.am --exclude=m4/libtool.m4": > > [...] > > Release preparation. > > Thoughts? > > Thanks, > smcv > Hi Simon, I am ok with these changes on the premise that you are ready to promptly rollback to the bare minimum changes in case of regressions (regardless of whether we see them before or after the migration). If you agree with this, please go ahead with the upload and remove the moreinfo tag once it is ready to be unblocked. Thanks, ~Niels
Bug#929001: unblock: pacemaker/2.0.1-4
Ferenc Wágner: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package pacemaker > > Dear Release Team, > > Three security issues were discovered in Pacemaker, all of which were > fixed by the GitHub pull request #1749. The main point of this update > is fixing these security bug #927714 by including the relevant changes > of the pull request as quilt patches. > > An additional change is bumping the debhelper compat level from 11 to > 12 to avoid the effect of #887904, that is, the daemon-not-running on > reinstall. Selectively bumping the level for dh_installinit and > dh_installsystemd didn't seem to gain anything in this case, because I > had to disable dh_dwz anyway and the remaining changes don't affect this > package. > > The last user-visible fixup is shipping the /var/log/pacemaker (and > /var/log/pacemaker/bundles) directories, to enable detailed logging in > the default configuration (instead of provoking error messages). > > The test change is just a shorter wait for cluster startup. It isn't > performance related, a wait is part of the startup sequence, we just > have to wait a little longer than that. > > Finally, I dropped a quilt patch (against the build system) which lost > its relevance when the build system was fixed upstream several releases > ago. > > [...] > Unblocked, thanks. ~Niels
Bug#928908: unblock: libdebian-installer/0.119
Control: tags -1 d-i confirmed Asbjørn Sloth Tønnesen: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock libdebian-installer/0.119 fixing RC bug #55 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=55 > > Changes: > libdebian-installer (0.119) unstable; urgency=medium > > [ Cyril Brulebois ] > * Drop support for arm*/ixp4xx and arm*/iop32x; support for those > platforms was removed from the Linux kernel and therefore d-i. > * Remove Christian Perrier from Uploaders, with many thanks for all > his contributions over the years! (Closes: #927544) > . > [ Bastian Blank ] > * Enlarge maximum line length in Packages and Sources files. > (closes: #55) > > [...] > OK from here. CC'ing KiBi for a d-i ack. Thanks, ~Niels
Bug#929029: unblock: apt-cacher-ng/3.2.1-1
Control: tags -1 moreinfo Eduard Bloch: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please advise how to process with a required fix for the package > apt-cacher-ng. > > The change is a one-liner and solves the bug #928957. Without it, the > cache cleanup will fail for a lot of people in the next couple of years. > But it touches the upstream source, that's why I would like to release > it as minor upstream version (3.2.1, currently 3.2, and I am the > upstream). > > I remember how you handled a similar request of mine a couple of years > ago, and this time I DEMAND a proper response here before I upload > anything. Please don't ignore it again for weeks and don't tell me that > this change is impossible to understand or to estimate WRT consequences; > it is using an already existing interface in the exact usecase it was > designed for. (see below) > > Best regards, > Eduard. > > [...] Hi Eduard, I acknowledge that you were not happy with our handling of your previous unblock request for apt-cacher-ng about two releases ago. However, I do not feel this request/email - i.e. the third paragraph of it - is a productive nor a professional way to go about it. I will refuse to consider this request at its current tone, but I am willing to review one written in a professional manner. Thanks, ~Niels
Re: fixing debian-security-support upgrades from stretch (for good)
Sean Whitton: > Hello, > > On Mon 13 May 2019 at 11:52AM +00, Holger Levsen wrote: > >> [re-sent with debian-release list address corrected...] > > Also resending. Sorry. > >> so there is "#928172 debian-security-support: fails to upgrade from >> 'testing': >> dpkg: error: error executing hook" which happens when base-files is upgraded >> before debian-security-support (but doesnt happen if d-s-s is upgraded >> first...) >> >> So I think this can only be fixed properly (=without asking people to >> upgrade to the latest stretch pointrelease but instead allowing upgrades >> to buster from *any* stretch pointrelease) by adding a "pre-depends: >> debian-security-support (>= 2019.04.25)" to base-files in buster. > > I didn't think we supported upgrades from anything but the latest point > release of the previous stable release? > > My belief is based on the release notes saying that you should upgrade > to the latest point relesae first. > My understanding is that we prefer that upgrade paths works regardless of which minor version of the stable release you upgrade from (to the extend possible). Thanks, ~Niels
Bug#928939: unblock: hello/2.10-2
Control: tags -1 moreinfo confirmed Santiago Vila: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Hello. I'm asked to make a release of hello to fix the version skew > created by the test security upload for stretch. Since this package > serves as example, there are several things that I could fix as well, > but I consider "safe enough" the ones in this debdiff. > > This is not uploaded yet. Waiting for approval. > > Thanks. > > [...] > Please go ahead with the upload and remove the moreinfo tag once it is uploaded and ready to be unblocked. Thanks, ~Niels
Bug#928428: unblock: [pre-approval] wicd/1.7.4+tb2-7
Control: tags -1 moreinfo Axel Beckert: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > In the light of dhcpcd5 automremoval (#928056, #928104, #928105), I'd > like to upload a wicd package which relies less on dhcpcd5. [...] > > [...] > Hi Axel, Thanks for looking at improving wicd. AFAICT, the dhcpcd5 issues have been fixed and wicd is at the moment not at risk of being removed from testing on that account. If so, then I would prefer deferring these changes to bullseye in general to reduce the risks of regressions in testing at the moment. Thanks, ~Niels
Bug#926681: unblock: acme-tiny/1:4.0.4-1
Control: tags -1 moreinfo confirmed Samuel Henrique: > I do understand that this is a new upstream release but it should be > unblocked because it's a 198 line python script. > > If we don't fix this, then acme-tiny will have to be removed from Buster. > > @LetsEncrypt team, do you have any words on this? > Sorry for the delay on this. Please go ahead with the upload and remove the moreinfo tag once it is in unstable and ready to be unblocked. Thanks, ~Niels
Bug#928489: unblock: spf-engine/2.9.0-4
Control: tags -1 moreinfo confirmed Scott Kitterman: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package spf-engine > > It's just been reported that postfix-policyd-spf-python is missing a > depends on python3-pkg-resources, which caused me to discover it's also > missing for pyspf-milter from the same source package. > > This was not found up to this point because on most systems it is pulled > in by another package. The fix is minimal and has no regression risk > (see attached debdiff). > > Scott K > > unblock spf-engine/2.9.0-4 > Hi, Please upload the package to unstable and remove the moreinfo tag when it is ready to be unblocked. Thanks, ~Niels
Bug#928715: testing-pu: groonga/9.0.0-1+deb10u1
Control: tags -1 moreinfo confirmed On Thu, 9 May 2019 23:10:14 +0900 Kentaro Hayashi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock groonga package: > > * It fixes #928304. > The bug is reported against 6.1.5-1 on stretch, but it need to be fixed on > testing and unstable package too. so I've prepared the update. > > Note that it is already packages on testing (9.0.0-1) and unstable (9.0.1-1). > 9.0.1-1 contains unrelated changes to #928304, so based on freeze policy, > it seems that update package (9.0.0-1+deb10u1) should be uploaded to > testing-proposed-updates explicitly. > > Here is the debdiff: > > [...] Hi, Please go ahead with the upload and remove the moreinfo tag when the upload is in tpu and ready to be unblocked. Thanks, ~Niels
Re: How to handle daemon-not-running bugs of debhelper compat level 11?
Michael Biebl:
> Am 30.04.19 um 17:26 schrieb Michael Biebl:
>> Am 29.04.19 um 21:53 schrieb Niels Thykier:
>
>>> override_dh_installinit:
>>> DH_COMPAT=12 dh_installinit ...
>>>
>>> override_dh_installsystemd:
>>> DH_COMPAT=12 dh_installsystemd ...
>>>
>>> Note the exact runes needed depend on your existing compat level and
>>> package; the above runes are geared towards compat 11 but are untested.
>>> For compat 10 and earlier you want a similar but slightly different
>>> approach.
>>>
>>> I believe that is the (general) route/path of "least evil/problematic"
>>> for buster (without having looked at the concrete packaging at all).
>>
For reference, I forgot that the packages must have a
Pre-Depends: ${misc:Pre-Depends}
(or an explicit pre dependency on init-system-helpers (>= 1.54~), but
the former is strongly preferred).
>> I picked a package from list.txt at random: uptimed
>> I verified that a "apt install uptimed; apt remove uptimed; apt install
>> uptimed" sequence results in a non-running uptimed.service.
>>
>> I then followed the hints from Niels and tried the attached patch.
>> It seems to fix the issue at hand.
>>
Thanks for confirming. :)
>>
>> I'd be interested to know, how the release team would like to this issue
>> handled. While I did spot a few false positives when glancing over the
>> list (e.g. packages which use --no-start, so are not affected), I would
>> expect the majority of packages to be affected.
>>
>> I can offer to do a MBF if the release team thinks this issue is
>> important enough to be fixed for buster.
>
> If the release teams thinks that this should be fixed for buster, I
> wonder if we shouldn't consider a second approach: Updating debhelper to
> use compat mode 12 behaviour for dh_installinit/dh_installsystemd if
> compat mode is set to 11.
> This would avoid a lot of churn. If we basically update all packages to
> use compat mode 12 behaviour explicitly, we might just as well do that
> change in a single package.
>
> Regards,
> Michael
>
We would still have to issue binNMUs and we can only do this for
arch:any packages with a "Pre-Depends: ${misc:Pre-Depends}" already
(otherwise, it will cause upgrade issues - or for arch:all, the binNMU
will be rejected).
Do you have an estimate of how many packages can be binNMUed vs. how
many will require a manual upload regardless?
Thanks,
~Niels
Bug#928407: unblock: bind9/1:9.11.5.P4+dfsg-5
Control: tags -1 d-i confirmed Bernhard Schmidt: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package bind9 > > -4 and -5 have the following changes over -3 currently in testing. > > - CVE-2018-5743 (Bug#927923) > The patch for this have been pulled directly from upstream. There is an > additional patch needed for platforms without atomic support > - Some additions to the AppArmor policy > The seldomly used case of bind9 directly serving ActiveDirectory zones from > Samba through a DLZ (Dynamically Loadable Zone) module was quite broken > before > because Samba in Buster changed some important paths and the AppArmor policy > only really got enforced in Buster. Thanks to Steven Monai for filing bugs > (928398, 920530) this should be fixed. I consider it low-risk because it > only > adds paths. > - During Buster EDDSA crypto was temporarily disabled because it added a > dependency > on OpenSSL 1.1.1, which was at that point preventing testing migration. In > our eyes it makes no sense to keep it disabled. Ed448 is currently broken > upstream (https://gitlab.isc.org/isc-projects/bind9/issues/225) so there is > an > additional patch to keep that disabled. > > -4 has been in sid for more than a week without reported regressions, -5 only > adds a single line to the AppArmor policy > > unblock bind9/1:9.11.5.P4+dfsg-5 > Hi, I have flagged it as ok from the RT PoV and is CC'ing KiBi for a d-i review before it is finally unblocked. Thanks, ~Niels
Bug#928395: unblock: apt/1.8.1
Control: tags -1 moreinfo confirmed Julian Andres Klode: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package apt > > I'd like to add systemd inhibitor support to apt in buster, so people > don't shoot each other in the foot, in case one admin reboots a machine > while somebody else is installing patches. > > The diff is quite small. > > I'd also love to smuggle in some additional kernel package names in > debian/apt.conf.autoremove - they don't really affect, only Ubuntu - we > share the 1.8.y series for like 9 mo, but it's not an invasive change > (there's like 0 potential of a regression), I think they are: > > linux-buildinfo > linux-image-unsigned > linux-source > > But I have not committed them yet. > > unblock apt/1.8.1 > > [...] Hi, Please go ahead with the upload and remove the moreinfo tag when it is in unstable and ready to be unblocked. Thanks, ~Niels
Bug#928455: [pre-a] unblock: perl6-zef/0.6.2-2
Control: tags -1 moreinfo confirmed Mo Zhou: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-CC: Robert Lemmen , Dominique Dumont > > > Please unblock package perl6-zef > > (explain the reason for the unblock here) > > As I reported in #928454, the outdated mirror URL list renders zef, > the perl6 package manager nearly unusable: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928454 > > Luckily we can fix the package for Buster by simply updating the list: > https://github.com/ugexe/zef/blob/master/resources/config.json#L60-L62 > I asked upstream author on IRC and they acked that the mirror list is > not likely to be changed for the Buster lifecycle. > > (include/attach the debdiff against the package in testing) > > ``` > --- config.json.orig 2019-05-05 03:31:08.251673414 + > +++ config.json 2019-05-05 03:32:01.71262 + > @@ -57,10 +57,9 @@ > "name" : "p6c", > "auto-update" : 1, > "mirrors" : [ > -"http://ecosystem-api.p6c.org/projects1.json";, > -"http://ecosystem-api.p6c.org/projects.json";, > + > "https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json";, > "git://github.com/ugexe/Perl6-ecosystems.git", > - > "https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json"; > +"http://ecosystem-api.p6c.org/projects1.json"; > ] > } > }, > ``` > > unblock perl6-zef/0.6.2-2 > > [...] > Hi, Please go ahead with the upload and remove the moreinfo tag when it is in unstable and ready to be unblocked. For future reference: * We generally need to full debdiff to know exactly what we will be approving. In this case, I assumed you need that change plus an upload to d/changelog only (hopefully sparing us from a round trip) * Assuming this is indeed the only change, it would have been faster and easier for both parties if you had uploaded it to sid in parallel with the unblock request. - I appreciate that you may prefer a "rather safe than sorry"- approach, which is greatly appreciated with potential risky changes. Thanks, ~Niels
Bug#928448: unblock: mmdebstrap/0.4.1-3
Control: tags -1 moreinfo confirmed Johannes 'josch' Schauer: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Hello release team! > > [...] > > I find especially support for old apt versions and derivative > distributions important. If you tell me to go ahead, then I would need: > > unblock mmdebstrap/0.4.1-3 > > All the patches I list in the following are attached to this mail as > part of a debdiff where I applied all of them. > > [...] > Hi, Please go ahead with the upload and remove the moreinfo tag when it is in unstable and ready to be unblocked. Thanks, ~Niels
Bug#928281: unblock: lemonldap-ng/2.0.2+ds-7 (pre-approval)
Control: tags -1 moreinfo confirmed Xavier Guimard: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package lemonldap-ng > > Hi all, > > upstream authors of lemonldap-ng have updated language translations. I > imported updated translation files in a patch. Do you think it is > opportune to update lemonldap-ng package to have better l10n support in > Buster? > > Cheers, > Xavier > > unblock lemonldap-ng/2.0.2+ds-7 > > [...] Please go ahead with the upload and remove the moreinfo tag when it is in unstable and ready to be unblocked. Thanks, ~Niels
Bug#926992: unblock: sia/1.3.0-1.1
Andreas Beckmann: > Control: reopen -1 > Control: retitle -1 unblock: sia/1.3.0-1.1~deb10u1 [t-p-u] > > On 2019-04-29 07:42, Niels Thykier wrote: >> Ok, can you prepare a t-p-u upload to fix this directly in testing then? > > What is the correct (or preferred) distribution for t-p-u uploads ? > "buster" or "testing-proposed-updates" ? Attached patch uses the latter. > > > Andreas > Either way should work. I think there is a slight preference for buster-proposed-updates because it automatically updates in case buster becomes stable before the upload is complete (but it has been a while since someone asked me). Please go ahead with the upload, btw. :) Thanks, ~Niels
Re: How to handle daemon-not-running bugs of debhelper compat level 11?
wf...@niif.hu: > On Wed, 27 Mar 2019 20:12:00 +0000 Niels Thykier wrote: > >> Related note (with my RT hat on): Please defer debhelper compat bumps >> for anything targeting buster as it is not considered a "minimal change". > > Dear Release Team, > > I recently realised that #887904 (dh_installsystemd will unmask services > *after* an attempt to start them) affects pacemaker (and probably every > other debhelper compat level 11 daemons with a native systemd unit). > The symptom: > > apt install pacemeker => pacemaker is running, good; > apt remove pacemaker => pacemaker is not running, good; > apt install pacemaker => pacemaker is still not running, NOT good; > service pacemaker start => pacemaker is running, good. > > I think this is a bug, although probably not a policy violation. What > should one do for buster? > 1. Don't care, > 2. try to fix this somehow on compat level 11 (how?), Another package had a similar issue and here I recommended the use of DH_COMPAT (and override targets) to selectively bump the compat level of dh_installinit and dh_installsystemd to compat 12. E.g. override_dh_installinit: DH_COMPAT=12 dh_installinit ... override_dh_installsystemd: DH_COMPAT=12 dh_installsystemd ... Note the exact runes needed depend on your existing compat level and package; the above runes are geared towards compat 11 but are untested. For compat 10 and earlier you want a similar but slightly different approach. I believe that is the (general) route/path of "least evil/problematic" for buster (without having looked at the concrete packaging at all). Thanks, ~Niels
Bug#926992: unblock: sia/1.3.0-1.1
Andreas Beckmann: > On 2019-04-18 13:18, Niels Thykier wrote: >> Andreas Beckmann: >>> This NMU adds 'missingok' to the logrotate config, fixing piuparts >>> unblock sia/1.3.0-1.1 >> Unblocked, thanks. > > This is stuck behind golang-golang-x-sys. > > Andreas > Ok, can you prepare a t-p-u upload to fix this directly in testing then? Thanks, ~Niels
Bug#928081: unblock: matrix-synapse/0.99.2-3.1
On Sat, 27 Apr 2019 12:30:03 -0400 Antoine Beaupre wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package matrix-synapse > > The package currently in buster generates gigabytes of logs which can > easily fill up disks on servers (RC bug #927057). > > The following patch fixes the problem, and I can upload the fix > if this is approved. > > unblock matrix-synapse/0.99.2-3.1 > > [...] Unblocked, thanks. ~Niels
Bug#928092: unblock: youtube-dl/2019.01.17-1.1
Control: tags -1 moreinfo confirmed Antoine Beaupre: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package youtube-dl > > youtube-dl, as often happens, has already lagged behind the youtube > interface and cannot download stuff from there at all (RC bug #927862) > > The attached patch (provided by carnil) fixes the issue. > > unblock youtube-dl/2019.01.17-1.1 > > [...] Please go ahead with the upload and remove the moreinfo tag once it is in unstable and ready to be unblocked. Thanks, ~Niels
Bug#928094: unblock (pre-approval): mutter/3.30.2-7
Control: tags -1 moreinfo confirmed Simon McVittie: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > While preparing gnome-shell/3.30.2-9 (see separate unblock request) I > thought I should also look into updating the closely-related mutter > package from the upstream gnome-3-30 stable branch. > >> [...] > > OK to upload? > > Thanks, > Simon > Please go ahead with the upload and remove the moreinfo tag once the upload is in unstable and ready to be unblocked. Thanks, ~Niels
Bug#928093: unblock (pre-approval): gnome-shell/3.30.2-9
Control: tags -1 moreinfo confirmed Simon McVittie: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Now that gnome-shell's RC bugs are (hopefully) dealt with, I'd like > to update gnome-shell with the remaining bug fixes from the upstream > gnome-3-30 branch, backported from 3.32.x development. > >> [...] > > Proposed diff attached, filtering out the translation update patches for > brevity. Is this (plus a `dch -r`) suitable for upload to unstable? > > Thanks, > smcv > Please go ahead with the upload and remove the moreinfo tag once the upload is in unstable and ready to be unblocked. Thanks, ~Niels
Bug#928090: unblock: ipywidgets/6.0.0-4
Control: tags -1 moreinfo confirmed Sergio Durigan Junior: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Hi there, > > I'd like to request the unblock of ipywidgets, please. The current > package in buster FTBFS due to a small JavaScript issue (RC bug #926802) > in the build system of the package.. The patch below fixes the problem; > I'm a member of the Python team, and can upload the fix if > approved/needed. > > Thanks, > Please go ahead with the upload and remove the moreinfo tag when it is in unstable and ready to be unblocked. Thanks, ~Niels
Bug#928081: unblock: matrix-synapse/0.99.2-3.1
Control: tags -1 moreinfo confirmed Antoine Beaupre: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package matrix-synapse > > The package currently in buster generates gigabytes of logs which can > easily fill up disks on servers (RC bug #927057). > > The following patch fixes the problem, and I can upload the fix > if this is approved. > > unblock matrix-synapse/0.99.2-3.1 > > [...] > Hi, The changes look good from an RT PoV. Please remove the moreinfo tag when it has been uploaded and is ready to be unblocked. Thanks, ~Niels
Bug#927958: [pre-a] unblock: utf8proc/2.3.0-1
Control: tags -1 moreinfo confirmed Mo Zhou: > Hi, > > Here are some incremental updates to 2.3.0-1 following the last mail: > > + * Patch: update unicode-data version strings to 12.1.0 > > Upstream code hard-coded unicode-data version in the code. I need to > patch those string literals. > > + * Patch: Upstream didn't bump minor version in build system and header. > > Upstream forgot to bump "MINOR" from 2 to 3 in the build system. > > + * Install the newly-added pkgconfig file. (Closes: #927260) > > a very simple pkg-config file. > > On Sat, Apr 27, 2019 at 02:38:44AM +, Mo Zhou wrote: >> control: tags -1 -moreinfo >> >> Hi, >> >> Debdiff has been attached. The patch is enormously large (3MB) but >> 99.9% of the content is automatically generated from unicode-data. >> See my extremely detailed comments to diffstat below: >> >> [...] Thanks for this. :) Please go ahead with the proposed changes and remove the moreinfo tag once it is in unstable and ready to be unblocked. Thanks, ~Niels
Bug#927850: unblock: htslib/1.9-11
Control: tags -1 moreinfo Andreas Tille: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package htslib > > > [...] > > > unblock htslib/1.9-11 > > [...] Hi, Please file a bug against ftp.debian.org requesting the removal of htslib on i386. Without this removal, htslib cannot migrate to testing regardless of whether we unblock it or not. Please include the bug id of that removal bug in a follow up and remove the moreinfo bug when the removal bug has been filed. Thanks, ~Niels
Bug#927912: unblock: gcalcli/4.0.4-2 (pre-approval)
Control: tags -1 moreinfo confirmed Unit 193: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Howdy, > > Pending approval, I'm uploading a version of gcalcli which contains an > upstream patch to fix the reliance on the Google shortening service. > > If a user invokes one of the subcommands with '--details url', the > application hits traceback issues as the service has been shut down. > > See https://github.com/insanum/gcalcli/issues/440 for more details of the > problem. > > > The changelog reads: > > gcalcli (4.0.4-2) unstable; urgency=medium > > * d/p/remove_url_shortening.patch: Remove the deprecated goo.gl service. > > -- Unit 193 Wed, 24 Apr 2019 19:46:16 -0400 > > > And debdiff: > > [...] > Please go ahead with the upload and remove the moreinfo tag when it is in unstable and ready to be unblocked. Thanks, ~Niels
Bug#927958: [pre-a] unblock: utf8proc/2.3.0-1
Control: tags -1 moreinfo Mo Zhou: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package utf8proc > > (explain the reason for the unblock here) > > I'm astonished that the unicode (11.* -> 12.*) transition happend at > such a deep freeze stage. utf8proc is tightly coupled with the > unicode-data version, and the new unicode-data version incured FTBFS: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927941 > > The simplest way to fix this bug is to bump utf8proc to 2.3.0 > > (include/attach the debdiff against the package in testing) > > According to upstream NEWs/changelog > https://github.com/JuliaStrings/utf8proc/commit/eb39b060e7e518941a912e1f51bae1cc6316f547 > And the commit history (97ef668 -> 454f601) > https://github.com/JuliaStrings/utf8proc/commits/master > The major change from 2.2.0 (testing) to 2.3.0 (not yet packaged) > is the support for unicode-data (= 12). There is no breaking change. > So I request an unblock for 2.3.0-1 > > unblock utf8proc/2.3.0-1 > > [...] > Please include a full debdiff of the changes. The link to a master branch with no clear marking of start/end commits makes it too time consuming for us to evaluate the request. Thanks, ~Niels
Bug#927980: unblock: librsvg/2.44.10-2.1 (pre-approval)
Control: tags -1 moreinfo confirmed Boyuan Yang: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-CC: pkg-gnome-maintain...@lists.alioth.debian.org > 927...@bugs.debian.org > > Hello all, > > I have prepared an NMU to fix bug https://bugs.debian.org/927886 . > This bug in librsvg caused deepin-image-viewer to crash on startup. > The patch is picked > from upstream git trunk. The full debdiff is pasted in this mail. > > I have confirmed that deepin-image-viewer will no longer crash with this > patch. > > The upload hasn't been made yet. Please let me know if it looks okay > to you and I'll upload the NMU later. > > -- > Thanks, > Boyuan Yang > > [...] Please go ahead with the upload and remove the moreinfo tag when the upload is in unstable and ready to be unblocked. Thanks, ~Niels
Bug#927901: unblock: lucene-solr/3.6.2+dfsg-19
Control: tags -1 moreinfo Markus Koschany: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package lucene-solr > > I made a mistake when I installed solr-permissions.conf into the wrong > /etc/systemd/system/ directory. This makes solr unusable because > tomcat can't write to /var/lib/solr. A user spotted the error and reported > it here: > > https://salsa.debian.org/java-team/lucene-solr/commit/ae53f09f37b18aa836640b256137a3a9e26e186f > > The only change is installing this file to > /etc/systemd/system/tomcat9.service.d now which makes it work again. > > Regards, > > Markus > > > unblock lucene-solr/3.6.2+dfsg-19 > > [...] > Hi, Thanks for working to improve buster. I suspect this change is missing an "rm_conffile" for this misplaced configuration file (everything in /etc is by default tagged as a conffile for anything built with debhelper). Could you please have a look at that and ensure this part is handled correctly? (otherwise, I think the changes look good) Thanks, ~Niels
Bug#927789: [pre-upload-approval] unblock: x2gobroker/0.0.4.1-1
Control: tags -1 moreinfo confirmed Mike Gabriel: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package x2gobroker > > [...] > > light+love, > Mike > > unblock x2gobroker/0.0.4.1-1 > > [...] Please go ahead with the upload and remove the moreinfo tag when it is in unstable and ready to be unblocked. Thanks, ~Niels
Bug#927816: unblock: shim-signed/1.30
Control: tags -1 moreinfo Steve McIntyre: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package shim-signed > > We've just got new signatures back from Microsoft to match our shim > binaries for amd64, i386 and arm64. I've fixed up the packaging a lot > to accommodate the new arches (previously we had amd64 only). > > We've made a lot of progress with shim, and we're nearing the end of > the process for Secure Boot in Buster. I'm asking for this unblock > today to cover most of what we need, with potentially a further > unblock for a new set of signed binaries with some shim bugfixes to > come. That'll depend on how long new signatures take to come. (Yay!). > > The main set of changes here are in version 1.29. > > [...] Hi, Thanks for the work on shim-signed. I am mostly happy with the changes, except for ... > diff -Nru shim-signed-1.28+nmu1/debian/control shim-signed-1.30/debian/control > --- shim-signed-1.28+nmu1/debian/control 2018-11-04 07:09:26.0 > + > +++ shim-signed-1.30/debian/control 2019-04-22 23:59:15.0 +0100 > @@ -1,15 +1,34 @@ > Source: shim-signed > Section: utils > Priority: optional > -Maintainer: Steve Langasek > -Build-Depends: debhelper (>= 9), shim, sbsigntool (>= 0.6-0ubuntu4), > po-debconf > -Standards-Version: 3.9.4 > +Maintainer: Debian EFI Team > +Uploaders: Steve McIntyre <93...@debian.org>, Steve Langasek > > +Build-Depends: debhelper (>= 9), > +# Need shim-unsigned version 15+1533136590.3beb971-5 so we can check the > +# signature on the right version of shim. Version -6 saw arm64 toolchain > +# changes that changed the binary. Ugh. :-( > + shim-unsigned (= 15+1533136590.3beb971-5), ^ Testing has -6, so shim-signed is B-D'ing on a non-existent package version. IOW it will not be buildable in buster and unblocking it (plus forcing it) would imply breaking the self-containedness of buster. Thanks, ~Niels
Bug#927797: unblock: debian-archive-keyring/2019.1
Package: release.debian.org Severity: normal Tags: d-i User: release.debian@packages.debian.org Usertags: unblock Please unblock package debian-archive-keyring, which includes the new signing keys for buster. I have taken the liberty of X-Debbugs-CC'ing Kibi for a d-i ack as well. """ debian-archive-keyring (2019.1) unstable; urgency=medium [ Adam D. Barratt ] * Ensure separated keyrings for Wheezy's keys are removed. Thanks to Sven Joachim. (Closes: #912214) [ Jonathan Wiltshire ] * Add my own key to the team-members keyring * Add Debian Stable Release key (10/buster) (ID: DCC9EFBF77E11517) (Closes: #917536) * Add Debian Archive Automatic Signing Key (10/buster) (ID: BCDDDC30D7C23CBBABEE) and Debian Security Archive Automatic Signing Key (10/buster) (ID: C5FF4DFAB270CAA96DFA) (Closes: #917535) * Refresh the signature over keyrings/debian-archive-keyring.gpg [ Niels Thykier ] * Add myself as uploader (Closes: #927765) -- Niels Thykier Tue, 23 Apr 2019 13:42:28 +0200 """ A diffstat: """ $ diffstat debian-archive-keyring.debdiff active-keys/add-buster-automatic | 179 +++ active-keys/add-buster-security-automatic | 179 +++ active-keys/add-buster-stable | 58 active-keys/index |3 active-keys/index.gpg | 21 + debian/changelog | 22 + debian/control|1 debian/debian-archive-keyring.maintscript |2 keyrings/debian-archive-keyring.gpg.asc | 21 + team-members/add-5394479DD3524C51 | 357 ++ team-members/index|1 team-members/index.gpg| 21 + 12 files changed, 841 insertions(+), 24 deletions(-) """ Note that the majority of the changes are due to keyring changes, which are base64 encoded and hench is included as a "textual" change rather than a binary file change. This inflates the diff size considerably. unblock debian-archive-keyring/2019.1 Thanks, ~Niels Base version: debian-archive-keyring_2018.1 from testing Target version: debian-archive-keyring_2019.1 from unstable Hints in place: ==> freeze # These udebs can be handled directly by britney # but are currently blocked at the d-i RM's request block-udeb debian-archive-keyring Excuses: Filter applied (not reflected in the diffstat): filterdiff -x **/*.po -x **/*.pot active-keys/add-buster-automatic | 179 +++ active-keys/add-buster-security-automatic | 179 +++ active-keys/add-buster-stable | 58 active-keys/index |3 active-keys/index.gpg | 21 + debian/changelog | 22 + debian/control|1 debian/debian-archive-keyring.maintscript |2 keyrings/debian-archive-keyring.gpg.asc | 21 + team-members/add-5394479DD3524C51 | 357 ++ team-members/index|1 team-members/index.gpg| 21 + 12 files changed, 841 insertions(+), 24 deletions(-) gpgv: unknown type of key resource 'trustedkeys.kbx' gpgv: keyblock resource '/home/nthykier/.gnupg/trustedkeys.kbx': General error gpgv: Signature made 2018-10-28T17:26:50 UTC gpgv:using RSA key F1FF5D0D7E002DF0FE55FB0CA65B78DBE67C7AAC gpgv:issuer "ni...@thykier.net" gpgv: Can't check signature: No public key dpkg-source: warning: failed to verify signature on /tmp/tmpodpid684/debian-archive-keyring_2018.1.dsc gpgv: unknown type of key resource 'trustedkeys.kbx' gpgv: keyblock resource '/home/nthykier/.gnupg/trustedkeys.kbx': General error gpgv: Signature made 2019-04-23T11:49:10 UTC gpgv:using RSA key F1FF5D0D7E002DF0FE55FB0CA65B78DBE67C7AAC gpgv: Can't check signature: No public key dpkg-source: warning: failed to verify signature on /tmp/tmpodpid684/debian-archive-keyring_2019.1.dsc diff -Nru debian-archive-keyring-2018.1/active-keys/add-buster-automatic debian-archive-keyring-2019.1/active-keys/add-buster-automatic --- debian-archive-keyring-2018.1/active-keys/add-buster-automatic 1970-01-01 00:00:00.0 + +++ debian-archive-keyring-2019.1/active-keys/add-buster-automatic 2019-04-23 11:40:11.0 + @@ -0,0 +1,179 @@ +Comment: add buster automatic key +Date: Mon, 22 Apr 2019 13:57:10 +0100 +Action: import +Data: + -BEGIN PGP PUBLIC KEY BLOCK- + + mQINBFyy5ecBEACxXGKUyi5dFjPhEFoz3IwKlVfDxySVg+hlhcUEO657UHf/7Ba5 + wr9eHxjlbpxetAymSNnptgh8oaJWcokr9UjeaTbKrYGpRra7Wd1W+f++9tF7BVvV + +AWBaltD5NDuq+eQ7kj72oeMa7KAr4702ZokLgiTsS9dPeDAodx3/jMuV9VxlJ7q + w07bAoUdzhlPBcII3MOCMfQmtwIg27/qqekeOn
Bug#927778: unblock: bind9/1:9.11.5.P4+dfsg-3
Package: release.debian.org
Severity: normal
Tags: d-i confirmed
User: release.debian@packages.debian.org
Usertags: unblock
Hi,
I am filing an unblock for bind9 as it has a fixed RC bug and
needs a d-i ack.
bind9 (1:9.11.5.P4+dfsg-3) unstable; urgency=medium
* More fixes to the AppArmor policy for Samba AD DLZ
- allow access to /dev/urandom
- allow locking for dns.keytab
- fix path to smb.conf
-- Bernhard Schmidt Mon, 22 Apr 2019 22:31:06 +0200
bind9 (1:9.11.5.P4+dfsg-2) unstable; urgency=medium
[ Ondřej Surý ]
* Update d/gbp.conf for Debian Buster
[ Bernhard Schmidt ]
* Cherry-Pick upstream commit to prevent dnssec-keymgr from immediately
expiring and deleting old DNSSEC keys when being run for the first
time (Closes: #923984)
* Update AppArmor policy for Samba AD DLZ
- Add changed default location for named.conf
- Allow read/mmap on some Samba libraries
Thanks to Steven Monai (Closes: #920530)
[ Andreas Beckmann ]
* bind9.preinst: cope with ancient conffile named.conf.options
(Closes: #905177)
-- Bernhard Schmidt Tue, 02 Apr 2019 21:12:50 +0200
unblock bind9/1:9.11.5.P4+dfsg-3
Thanks,
~Niels
Base version: bind9_1:9.11.5.P4+dfsg-1 from testing
Target version: bind9_1:9.11.5.P4+dfsg-3 from unstable
Hints in place:
==> nthykier
#2019-04-23
unblock bind9/1:9.11.5.P4+dfsg-3
==> freeze
# These udebs need to be put in one of the lists:
block-udeb bind9
Excuses:
bind9 (1:9.11.5.P4+dfsg-1 to 1:9.11.5.P4+dfsg-3)
Migration status: BLOCKED: Needs an approval (either due to a freeze, the
source suite or a manual hint)
Maintainer: Debian DNS Team
Too young, only 0 of 2 days old
Updating bind9 fixes old bugs: #905177
Piuparts tested OK - https://piuparts.debian.org/sid/source/b/bind9.html
Required age reduced by 3 days because of autopkgtest
Not touching package due to block-udeb request by freeze (please contact
the d-i release manager if an update is needed)
Not touching package due to block request by freeze (please contact
debian-release if update is needed)
Filter applied (not reflected in the diffstat):
filterdiff -x **/*.po -x **/*.pot
bind9.preinst | 10 +
changelog | 29 +++
extras/apparmor.d/usr.sbin.named| 11 +
gbp.conf|3
patches/keymgr-dont-immediately-delete.diff | 217
patches/series |1
6 files changed, 267 insertions(+), 4 deletions(-)
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/nthykier/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made 2019-02-22T17:47:49 UTC
gpgv:using RSA key D6E01EC516A5DFCEF71956D3775079E5B850BC93
gpgv:issuer "be...@debian.org"
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on
/tmp/tmplzeh50h3/bind9_9.11.5.P4+dfsg-1.dsc
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/nthykier/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made 2019-04-22T21:03:24 UTC
gpgv:using RSA key D6E01EC516A5DFCEF71956D3775079E5B850BC93
gpgv:issuer "be...@debian.org"
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on
/tmp/tmplzeh50h3/bind9_9.11.5.P4+dfsg-3.dsc
diff -Nru bind9-9.11.5.P4+dfsg/debian/bind9.preinst
bind9-9.11.5.P4+dfsg/debian/bind9.preinst
--- bind9-9.11.5.P4+dfsg/debian/bind9.preinst 2019-02-22 16:54:10.0
+
+++ bind9-9.11.5.P4+dfsg/debian/bind9.preinst 2019-04-22 20:31:06.0
+
@@ -20,7 +20,15 @@
theirs=$(md5sum /etc/bind/named.conf.options | sed 's/ .*$//')
mine=56919cbc0d819c9a303a8bdeb306b5f1
if [ "$mine" = "$theirs" ]; then
- mv /etc/bind/named.conf.options
/etc/bind/named.conf.options.dpkg-old
+ if [ -n "$(dpkg-query -f '${Conffiles}' -W bind9 | grep
/etc/bind/named.conf.options)" ]; then
+ # dpkg knows /etc/bind/named.conf.options as a conffile
(from squeeze or older)
+ # cannot move the outdated file aside to avoid dpkg
noticing deleted-by-local-admin
+ # therefore edit it in place to make it match the
to-be-installed version
+ cp -p /etc/bind/named.conf.options
/etc/bind/named.conf.options.dpkg-old
+ sed -i '26{/^$/d}; 23{/auth-nxdomain no;/d}'
/etc/bind/named.conf.options
+ else
+ mv /etc/bind/named.conf.options
/etc/bind/named.conf.options.dpkg-old
+ fi
fi
fi
;;
diff -Nru bind9-9.11.5.P4+dfsg/debian/changelog
bind9-9.11.5.P4+dfsg/debian/changelog
--- bind9-9.11.5.P4+dfsg/debian/changelog 2019-02-22 16:54:10.0
+
+++ bind9-9.11.5.P4+dfsg/debian/changelog
Bug#927777: unblock: alsa-utils/1.1.8-2
Package: release.debian.org Severity: normal Tags: d-i confirmed User: release.debian@packages.debian.org Usertags: unblock Hi, I am filing an unblock for alsa-utils as it has a fixed RC bug and needs a d-i ack. alsa-utils (1.1.8-2) unstable; urgency=medium * Introduce Fix-alsactl-to-restore-config.patch. Don't rely on undocumented /etc/alsa/state-daemon.conf to start alsa-state.service. alsa-restore.service now will have an error code 99 the first time it runs. But after an reload of the service or just a reboot both services will run smoothly. [closes: #925455] -- Elimar Riesebieter Sat, 30 Mar 2019 10:18:40 +0100 unblock alsa-utils/1.1.8-2 Thanks, ~Niels Base version: alsa-utils_1.1.8-1 from testing Target version: alsa-utils_1.1.8-2 from unstable Hints in place: ==> freeze # These udebs need to be put in one of the lists: block-udeb alsa-utils Excuses: alsa-utils (1.1.8-1 to 1.1.8-2) Migration status: BLOCKED: Needs an approval (either due to a freeze, the source suite or a manual hint) Maintainer: Debian ALSA Maintainers 13 days old (needed 5 days) Updating alsa-utils fixes old bugs: #925455 Piuparts tested OK - https://piuparts.debian.org/sid/source/a/alsa-utils.html Not touching package due to block-udeb request by freeze (please contact the d-i release manager if an update is needed) Not touching package due to block request by freeze (please contact debian-release if update is needed) Filter applied (not reflected in the diffstat): filterdiff -x **/*.po -x **/*.pot changelog | 10 ++ patches/Fix-alsactl-to-restore-config.patch | 46 patches/series |1 3 files changed, 57 insertions(+) gpgv: unknown type of key resource 'trustedkeys.kbx' gpgv: keyblock resource '/home/nthykier/.gnupg/trustedkeys.kbx': General error gpgv: Signature made 2019-02-11T12:43:26 UTC gpgv:using RSA key E8175486C02929837C286A1625502F6FCBE3CB04 gpgv:issuer "jo...@mallach.net" gpgv: Can't check signature: No public key dpkg-source: warning: failed to verify signature on /tmp/tmpy1szi6bf/alsa-utils_1.1.8-1.dsc gpgv: unknown type of key resource 'trustedkeys.kbx' gpgv: keyblock resource '/home/nthykier/.gnupg/trustedkeys.kbx': General error gpgv: Signature made 2019-04-09T16:08:42 UTC gpgv:using RSA key D1E1316E93A760A8104D85FABB3A68018649AA06 gpgv: Can't check signature: No public key dpkg-source: warning: failed to verify signature on /tmp/tmpy1szi6bf/alsa-utils_1.1.8-2.dsc diff -Nru alsa-utils-1.1.8/debian/changelog alsa-utils-1.1.8/debian/changelog --- alsa-utils-1.1.8/debian/changelog 2019-01-27 18:55:15.0 + +++ alsa-utils-1.1.8/debian/changelog 2019-03-30 09:18:40.0 + @@ -1,3 +1,13 @@ +alsa-utils (1.1.8-2) unstable; urgency=medium + + * Introduce Fix-alsactl-to-restore-config.patch. Don't rely on undocumented +/etc/alsa/state-daemon.conf to start alsa-state.service. alsa-restore.service +now will have an error code 99 the first time it runs. But after an reload of +the service or just a reboot both services will run smoothly. +[closes: #925455] + + -- Elimar Riesebieter Sat, 30 Mar 2019 10:18:40 +0100 + alsa-utils (1.1.8-1) unstable; urgency=medium * New upstream release. diff -Nru alsa-utils-1.1.8/debian/patches/Fix-alsactl-to-restore-config.patch alsa-utils-1.1.8/debian/patches/Fix-alsactl-to-restore-config.patch --- alsa-utils-1.1.8/debian/patches/Fix-alsactl-to-restore-config.patch 1970-01-01 00:00:00.0 + +++ alsa-utils-1.1.8/debian/patches/Fix-alsactl-to-restore-config.patch 2019-03-30 09:18:40.0 + @@ -0,0 +1,46 @@ +From 6198e81500938a1e0f5e9d8f58c4e45dec2ee6b3 Mon Sep 17 00:00:00 2001 +From: Elimar Riesebieter +Date: Sat, 30 Mar 2019 10:07:46 +0100 +Subject: [PATCH] Fix-alsactl-to-restore-config. + +--- + alsactl/alsa-restore.service.in | 2 +- + alsactl/alsa-state.service.in | 5 +++-- + 2 files changed, 4 insertions(+), 3 deletions(-) + +diff --git a/alsactl/alsa-restore.service.in b/alsactl/alsa-restore.service.in +index 38ffea7..74b9290 100644 +--- a/alsactl/alsa-restore.service.in b/alsactl/alsa-restore.service.in +@@ -8,7 +8,7 @@ Description=Save/Restore Sound Card State + Documentation=man:alsactl(1) + ConditionPathExists=!@daemonswitch@ + ConditionPathExistsGlob=/dev/snd/control* +-ConditionPathExists=@asoundrcfile@ ++After=alsa-state.service + + [Service] + Type=oneshot +diff --git a/alsactl/alsa-state.service.in b/alsactl/alsa-state.service.in +index a3c6e49..f631cc3 100644 +--- a/alsactl/alsa-state.service.in b/alsactl/alsa-state.service.in +@@ -1,4 +1,4 @@ +-# ++ + # Note that two different ALSA card state management schemes exist and they + # can be switched using a file exist check - /etc/alsa/state-daemon.conf . + # +@@ -6,7 +6,8 @@ + [Unit] + Description=Manage Sound Card Stat
Bug#927732: unblock: variety/0.7.1-2 (pre-approval)
Control: tags -1 moreinfo confirmed James Lu: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Dear Release Team, > > Please consider unblocking variety 0.7.1-2. I've backported a couple of > fixes from the newest upstream version, which fix a couple of subtle but > annoying bugs. The changelog is as follows: > > variety (0.7.1-2) unstable; urgency=medium > > * Backport bugfixes from Variety 0.7.2: > - fix-crash-on-help-version.patch: Don't forward --help or --version to > running Variety instances, as this causes it to crash. > - fix-spurious-error-when-analyzing-gifs.patch: Fix spurious > FileNotFoundError when analyzing GIFs inside a wallpaper folder > > -- James Lu Sun, 21 Apr 2019 19:10:58 -0700 > > The debdiff is attached. > > Best, > James > Hi James, Please go ahead with this upload and remove the moreinfo tag when it is in unstable and ready to be unblocked. Thanks, ~Niels
Bug#926888: unblock: wget/1.20.1-1.1
On Fri, 12 Apr 2019 07:54:00 + Niels Thykier wrote: > Control: tags -1 d-i confirmed > > Salvatore Bonaccorso: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > > > Hi, > > > > Please unblock package wget > > > > It fixes CVE-2019-5953, #926389 a buffer overflow vulnerability in the > > handling of Internationalized Resource Identifiers (IRI), it was > > adressed as well in DSA-4425-1 for stretch. > > > > Attached is the debdiff between 1.20.1-1 and 1.20.1-1.1. > > > > unblock wget/1.20.1-1.1 > > > > Regards, > > Salvatore > > > > Hi, > > OK from here; Cc'ing KiBi for a d-i ack. > > Thanks, > ~Niels > > Gentle ping on this unblock request for a CVE fix in wget. Thanks, ~Niels
Bug#927259: release.debian.org: unblock request: nheko
Control: tags -1 moreinfo confirmed Hubert Chathi: > Package: release.debian.org > Severity: normal > > Hello release team. > > I would like to upload a new version of nheko to fix #926671. It is an > "important" bug (though in reality, it could be argued that it is > "serious", as Matrix will be bumping the default room version soon, > which will cause the bug to manifest much more commonly, making the > program less usable). > > The fix is to apply a small patch from upstream. Attached is a debdiff. > > In addition to the above issue, I would like to also include fixes for > the following bugs, which are not included in the attached debdiff, but > are fairly trivial: > > - #926659 - incorrectly named file (debian/README.sources instead of > debian/README.source) -- has an obvious fix > - #926680 - a working directory is not properly cleaned up if the build > fails -- I would just add the working directory to the list of files > that are "rm -rf"-ed in override_dh_auto_clean. > > [...] > Hi, Please go ahead with the upload including the two extra changes you mentioned above and remove the moreinfo tag when it is in unstable and ready to be unblocked. For future reference: We generally prefer seeing the debdiff before approving the changes. Had the two extra changes not been obvious from your description, then it would have been necessary for me to ask you for the full debdiff. Please make it easier for us by always including the changes you want us to consider (modulo filterdiff of auto-generated files). Thanks, ~Niels
Bug#927434: unblock: network-manager-applet/1.8.20-1.1 (pre-approval)
Control: tags -1 confirmed moreinfo Boyuan Yang: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-CC: bi...@debian.org pkg-utopia-maintain...@lists.alioth.debian.org > > This is a pre-approval for NMU that would fix https://bugs.debian.org/926328 . > > The one-liner patch is taken from commits in upstream git trunk. > > I haven't make any upload yet. Michael, please let me know if this > patch looks okay for you. I can open a Merge Request for this NMU on > Salsa if necessary. > > The full debdiff is pasted here. > > -- > Thanks, > Boyuan Yang > > [...] > Hi, >From a release team PoV, the change looks fine. Please remove the moreinfo tag when the upload is in sid and ready to be unblocked. Thanks, ~Niels
Bug#927383: unblock: bitlbee/3.6-1.1
Control: tags -1 moreinfo Andreas Tille: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package bitlbee > > > * Non-maintainer upload. > * Apply patch to d/copyright provided by Jochen Sprickerhof > > > > unblock bitlbee/3.6-1.1 > > [...] > Hi, Relative to testing, this request also includes a new upstream version with a lot of unrelated changes, which is a risk we are not ready to take. If the incomplete d/copyright also applies to testing, then it will need a fix via testing-proposed-updates. The bug metadata does not have any found version, so it is not clear to me if the issue existing before the new upstream version in sid or that version introduced the issue. Thanks, ~Niels
Bug#926853: unblock: openssh/1:7.9p1-10
Control: tags -1 confirmed d-i
Colin Watson:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
>
> Please unblock openssh 1:7.9p1-10; as discussed recently on
> debian-devel, this reverts an upstream change in 7.8 that causes
> problems for certain iptables configurations as well as for VMware.
>
> unblock openssh/1:7.9p1-10
>
Hi,
Ok and unblocked from a release team PoV, but it needs a d-i ack due to
its udeb. CC'ing kibi for that part (and quoting the diff in full for him).
Thanks,
~Niels
> diff -Nru openssh-7.9p1/debian/.git-dpm openssh-7.9p1/debian/.git-dpm
> --- openssh-7.9p1/debian/.git-dpm 2019-03-01 10:57:53.0 +0100
> +++ openssh-7.9p1/debian/.git-dpm 2019-04-08 11:51:26.0 +0200
> @@ -1,6 +1,6 @@
> # see git-dpm(1) from git-dpm package
> -7a3fa37583d4abf128f7f4c6eb1e7ffc90115eab
> -7a3fa37583d4abf128f7f4c6eb1e7ffc90115eab
> +6b56cd57db9061296231f14d537f1ebaf25e8877
> +6b56cd57db9061296231f14d537f1ebaf25e8877
> 3d246f10429fc9a37b98eabef94fe8dc7c61002b
> 3d246f10429fc9a37b98eabef94fe8dc7c61002b
> openssh_7.9p1.orig.tar.gz
> diff -Nru openssh-7.9p1/debian/README.Debian
> openssh-7.9p1/debian/README.Debian
> --- openssh-7.9p1/debian/README.Debian2019-03-01 10:57:52.0
> +0100
> +++ openssh-7.9p1/debian/README.Debian2019-04-08 11:56:59.0
> +0200
> @@ -270,6 +270,26 @@
>
>https://bugs.launchpad.net/bugs/1674330
>
> +IPQoS defaults reverted to pre-7.8 values
> +-
> +
> +OpenSSH 7.8 changed the default IPQoS settings to use DSCP AF21 for
> +interactive traffic and CS1 for bulk. This caused some problems with other
> +software ("iptables -m tos" and VMware), so Debian's OpenSSH reverts this
> +change for the time being.
> +
> +This is *temporary*, and we expect to come back into sync with upstream
> +OpenSSH once those other issues have been fixed. If you want to restore the
> +upstream default, add this to ssh_config and sshd_config:
> +
> + IPQoS af21 cs1
> +
> +For further discussion, see:
> +
> + https://bugs.debian.org/923879
> + https://bugs.debian.org/926229
> + https://bugs.launchpad.net/1822370
> +
> --
> Matthew Vernon
> Colin Watson
> diff -Nru openssh-7.9p1/debian/changelog openssh-7.9p1/debian/changelog
> --- openssh-7.9p1/debian/changelog2019-03-01 13:23:36.0 +0100
> +++ openssh-7.9p1/debian/changelog2019-04-08 12:13:04.0 +0200
> @@ -1,3 +1,11 @@
> +openssh (1:7.9p1-10) unstable; urgency=medium
> +
> + * Temporarily revert IPQoS defaults to pre-7.8 values until issues with
> +"iptables -m tos" and VMware have been fixed (closes: #923879, #926229;
> +LP: #1822370).
> +
> + -- Colin Watson Mon, 08 Apr 2019 11:13:04 +0100
> +
> openssh (1:7.9p1-9) unstable; urgency=medium
>
>* Apply upstream patch to make scp handle shell-style brace expansions
> diff -Nru openssh-7.9p1/debian/patches/revert-ipqos-defaults.patch
> openssh-7.9p1/debian/patches/revert-ipqos-defaults.patch
> --- openssh-7.9p1/debian/patches/revert-ipqos-defaults.patch 1970-01-01
> 01:00:00.0 +0100
> +++ openssh-7.9p1/debian/patches/revert-ipqos-defaults.patch 2019-04-08
> 11:51:26.0 +0200
> @@ -0,0 +1,93 @@
> +From 6b56cd57db9061296231f14d537f1ebaf25e8877 Mon Sep 17 00:00:00 2001
> +From: Colin Watson
> +Date: Mon, 8 Apr 2019 10:46:29 +0100
> +Subject: Revert "upstream: Update default IPQoS in ssh(1), sshd(8) to DSCP
> + AF21 for"
> +
> +This reverts commit 5ee8448ad7c306f05a9f56769f95336a8269f379.
> +
> +The IPQoS default changes have some unfortunate interactions with
> +iptables (see https://bugs.debian.org/923880) and VMware, so I'm
> +temporarily reverting them until those have been fixed.
> +
> +Bug-Debian: https://bugs.debian.org/923879
> +Bug-Debian: https://bugs.debian.org/926229
> +Bug-Ubuntu: https://bugs.launchpad.net/1822370
> +Last-Update: 2019-04-08
> +
> +Patch-Name: revert-ipqos-defaults.patch
> +---
> + readconf.c| 4 ++--
> + servconf.c| 4 ++--
> + ssh_config.5 | 6 ++
> + sshd_config.5 | 6 ++
> + 4 files changed, 8 insertions(+), 12 deletions(-)
> +
> +diff --git a/readconf.c b/readconf.c
> +index 661b8bf40..6d046f063 100644
> +--- a/readconf.c
> b/readconf.c
> +@@ -2133,9 +2133,9 @@ fill_default_options(Options * options)
> + if (options->visual_host_key == -1)
> + options->visual_host_key = 0;
> + if (options->ip_qos_interactive == -1)
> +-options->ip_qos_interactive = IPTOS_DSCP_AF21;
> ++options->ip_qos_interactive = IPTOS_LOWDELAY;
> + if (options->ip_qos_bulk == -1)
> +-options->ip_qos_bulk = IPTOS_DSCP_CS1;
> ++options->ip_qos_bulk = IPTOS_THROUGHPUT;
> + if (options->request_tty == -1)
> + options->request_tty = REQUEST_TTY_AUTO;
> + if (options->proxy_use_fdpass == -1)
> +diff --git a/servconf.c b/servconf.c
> +index c5dd617ef..bf266914
Bug#927298: unblock: ebtables/2.0.10.4+snapshot20181205-3
Control: tags -1 moreinfo confirmed Alberto Molina Coballes: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package ebtables > > A serious bug was opened on ebtables and arptables regarding an issue > with usr merged systems. This patch solves this issue. > > The debdiff also includes a previous minor commit including salsa CI files, > if you > consider this must not be included, please let me know. > > unblock ebtables/2.0.10.4+snapshot20181205-3 > > Thanks > Please go ahead with the upload/changes as-is and remove the moreinfo tag when it is ready to be unblocked. Thanks, ~Niels
Bug#927299: unblock: arptables/0.0.4+snapshot20181021-4
Control: tags -1 moreinfo confirmed Alberto Molina Coballes: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package arptables > > A serious bug was opened on ebtables and arptables regarding an issue > with usr merged systems. This patch solves this issue. > > The debdiff also includes a previous minor commit including salsa CI files, > if you > consider this must not be included, please let me know. > > unblock arptables/0.0.4+snapshot20181021-4 > > Thanks > Please go ahead with the upload/changes as-is and remove the moreinfo tag when it is ready to be unblocked. Thanks, ~Niels
Bug#927199: unblock: gnome-shell/3.30.2-6
Control: tags -1 moreinfo intrigeri: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package gnome-shell. > > Changes are: > > 1. Vcs-Git, gbp.conf: point to the correct, Buster-specific, branches. > > 2. Avoid test failures on buildd environments where HOME, XDG_RUNTIME_DIR > might >be invalid. This allows the tests to run a bit further on s390x. The > package >still FTBFS there but as Simon McVittie wrote, "The remaining test failures >on s390x look to me more like a bug in mozjs60 or gjs than a bug in >gnome-shell" — which I guess is #927081. > > 3. Add missing French layouts to on screen keyboard (Closes: #926452) > >Due to a bug in the code that generates on screen keyboard layouts, the >French layout ends up being generated from the French-Canadian layout > (which >is qwerty rather than azerty). This is a regression compared to Stretch. > >Fixed by cherry-picking the relevant upstream (3.32.0) commit. > > 4. Fix on screen keyboard language's menu closing the keyboard (Closes: > #926453) > >GNOME Shell 3.30's on screen keyboard now offers a menu that allows > selecting >among the supported keyboard layouts. But moving the pointer over this menu >closes the keyboard. This is a regression from Stretch, where that menu did >not exist yet. > >Fixed by cherry-picking the relevant upstream (3.32.0) commits. > > unblock gnome-shell/3.30.2-6 > There is a bug in d/clean. The "debian/home" line is a directory and therefore needs a trailing slash (otherwise, dh_clean will refuse to remove it - see "man dh_clean"). Otherwise, it looks fine. Thanks, ~Niels
Bug#927183: [pre-approval] unblock: debiancontributors/0.7.8-1
Control: tags -1 moreinfo cionfirmed Daniele Tricoli: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Hello! > > This is a pre-approval to unblock package debiancontributors 0.7.8-1 > > debiancontributors is a package used internally by our infra team and this > upload would fix some simple but important bugs, in particular: > > https://salsa.debian.org/python-team/modules/python-debiancontributors/commit/51adfafa4ee8cb58fc4d651ec99b6f46a83f02d5 > > https://salsa.debian.org/python-team/modules/python-debiancontributors/commit/b41908ea65e6a550438f90339c29ea2a3feda718 > > The first one (workaround for #801506) is the most important one: > python-requests can't support (for now) 100-Continue response. > > The debdiff against the package in testing is attached. Thanks for considering > this pre-approval. > > unblock debiancontributors/0.7.8-1 > > [...] > Please go ahead with the upload and remove the moreinfo tag when the upload is ready to be unblocked. For future reference: Please avoid generic code-style rewrite/refactoring during freezes (and instead deploy it after the freeze). In the particular instance, it was manageable to review but most of the was "noise" due to that refactoring - this in turn increases the risk that the proposal is rejected. Thanks, ~Niels
Bug#927189: unblock: docker.io/18.09.1+dfsg1-5+b10
Control: tags -1 moreinfo confirmed Arnaud Rebillout: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package docker.io. > > unblock docker.io/18.09.1+dfsg1-5+b10 > > I'd like to fix #925224 [1] for buster. The fix is trivial, and allows > the docker's debootstrap script to work again when it queries > security.debian.org, by following redirections. Please see bug for > more details. > > I attached a source debdiff as mentioned in buster freeze policy [2]. > > Sorry for the inconvenience, > > Thanks! > > Arnaud > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925224 > [2] https://release.debian.org/buster/freeze_policy.html. > > [...] > Please go ahead with the upload and remove the moreinfo tag when it is ready to be unblocked. Thanks, ~Niels
Bug#927156: unblock: parted/3.2-25
Control: tags -1 confirmed d-i Colin Watson: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock parted 3.2-25: there was an arithmetic error in its > handling of extended partitions, which was often in practice masked by > higher-level tools but could be triggered in some circumstances such as > by gnome-disks, leading to disturbing results like apparently-vanishing > partitions. The patch is pretty clear if you look at a little more > context: one branch of an if/else block multiplied by the device's > sector size while the other didn't, which was obviously wrong. > > [...] > > unblock parted/3.2-25 > Approved from a RT PoV; CC'ing KiBi for a d-i review. Thanks, ~Niels
Bug#927111: unblock: wpa/2:2.7+git20190128+0c1e29f-4
Control: tags -1 d-i confirmed Andrej Shadura: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock the package wpa. > > This upload fixes a security vulnerability in WPA3-Personal and EAP (#926801): > > - CVE-2019-9494: SAE cache attack against ECC groups (VU#871675) > - CVE-2019-9495: EAP-pwd cache attack against ECC groups > - CVE-2019-9496: SAE confirm missing state validation > - CVE-2019-9497: EAP-pwd server not checking for reflection attack > - CVE-2019-9498: EAP-pwd server missing commit validation for scalar/element > - CVE-2019-9499: EAP-pwd peer missing commit validation for scalar/element > > For more details on the vulnerability itself, see: > - https://w1.fi/security/2019-1/ > - https://w1.fi/security/2019-2/ > - https://w1.fi/security/2019-3/ > - https://w1.fi/security/2019-4/ > > Since the patches are quite big, you can check them here: > - > https://salsa.debian.org/debian/wpa/tree/debian/master/debian/patches/2019-sae-eap > - > https://sources.debian.org/src/wpa/2:2.7+git20190128+0c1e29f-4/debian/patches/2019-sae-eap/ > > Erroneously not mentioned in the changelog, this upload also declares a > correct > build dependency on libnl-3-dev. > > unblock wpa/2:2.7+git20190128+0c1e29f-4 > Hi, Thanks for filing this unblock. From a RT PoV it looks fine and I have Cc'ed KiBi for a d-i ack before accepting it fully. Thanks, ~Niels
Please verify that buster related suites are functional
Hi Security team and backports team, According to the release team's checklist we have the following TODO for you: """ Check with security team and backports team that it is possible to build uploads for -security and -backports """ To our knowledge, the relevant suites have already been created (#917537) and ask that you kindly smoke test them to ensure they work as intended. * Please let us know when you have verified these relevant suites or if you have any issues with them. Thanks, ~Niels
Bug#925936: release.debian.org: Would v4l-utils 1.16.5 match unblocking criteria?
Control: tags -1 moreinfo confirmed
Gregor Jasny:
> Control: tags -1 - moreinfo
>
> Hello,
>
> A new patch turned up and I decided to only cherry-pick the three most
> important patches from the stable-1.16 tree.
>
> Debdiff is attached.
>
> If you agree on the changes I will upload via unstable.
>
> Thanks,
> Gregor
Hi Gregor,
Please go ahead with this patch and remove the moreinfo tag once it has
been fixed.
Please note that you may want to inform upstream of the following
possible bug:
"""
+- parms->fname = fname;
++ parms->fname = strdup(fname);
++ if (!parms->fname) {
++ dvb_logerr(_("fname calloc: %s"), strerror(errno));
++ return -errno;
++ }
++
"""
Please note that *any* call to a library function (e.g. strerror or _,
which I presume is gettext, or dvb_logerr which sounds like it will do
IO operations) may alter errno. I.e. the errno returned may no longer
be from the failing strdup.
AFAICT, this is a consistent issue through out the diff and therefore
not really a regression:
"""
+ if (xioctl(fd, FE_GET_PROPERTY, &dtv_prop) == -1) {
+ dvb_perror("FE_GET_PROPERTY");
+- dvb_v5_free(parms);
+ close(fd);
+ return -errno;
+ }
"""
Which is why I am ok with accepting it as it is. For reference, the
solution is to store "errno" in a local variable immediately after the
failing call.
Thanks,
~Niels
Bug#926556: unblock: yubikey-personalization/1.19.3-3
Control: tags -1 moreinfo confirmed Nicolas Braud-Santoni: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package yubikey-personalization > > In version 1.19.3-1, I introduced a bug w.r.t. udev rules handling, > resulting in users being unable to use the software (see #924787); > as such, I deemed the bug serious, and bumped its severity accordingly. > > The latest upload reverses that change, and split the udev rules to a new > binary > packages (libyubikey-udev) so other packages may Depend or Recommend it. > > > Best, > > nicoo > > unblock yubikey-personalization/1.19.3-3 > > [...] > Hi Nicolas, I cannot see these changes in unstable, so we cannot unblock them (nor do I see them NEW). Please upload this and remove the moreinfo tag once it is in unstable and ready for unblocking. Thanks, ~Niels
Bug#926876: unblock: chiark-utils/6.0.4
Control: tags -1 moreinfo confirmed Ian Jackson: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package chiark-utils > > chiark-utils is a portmanteau of different utiliies. I am proposing > to fix two bugs. Each bug is RC for the corresponding utility in the > sense that the utility is dangerous or useless without the fix. (The > bugs are not IMO RC for the package as a whole, although I think the > dangerous one is "important".) > > 1. fishdescriptor has a bug which makes it not work on amd64 and could > cause malfunctions or even UB in the target process. #926858 > > 2. sync-accounts uses an ancient deprecated perl syntax and is > entirely rejected by current versions of perl. #865985 > > Below is the source diff. Assuming the unblock is granted I will > finalise the changelog entry for 6.0.4 and do a dgit push-source > to do a source-only upload. > > (For my records: diff was generated from current master on chiark, ie > 0caba95b1c3f211fa3defcff017dde1374b3caa6) > > > unblock chiark-utils/6.0.4 > > [...] > Please go ahead with the upload and remove the moreinfo tag when it is ready to be unblocked. Thanks, ~Niels
Bug#926888: unblock: wget/1.20.1-1.1
Control: tags -1 d-i confirmed Salvatore Bonaccorso: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Hi, > > Please unblock package wget > > It fixes CVE-2019-5953, #926389 a buffer overflow vulnerability in the > handling of Internationalized Resource Identifiers (IRI), it was > adressed as well in DSA-4425-1 for stretch. > > Attached is the debdiff between 1.20.1-1 and 1.20.1-1.1. > > unblock wget/1.20.1-1.1 > > Regards, > Salvatore > Hi, OK from here; Cc'ing KiBi for a d-i ack. Thanks, ~Niels
Bug#926375: (pre-approve) unblock: python-fakeredis/1.0.3-1
Control: tags -1 moreinfo confirmed Ondrej Koblizek: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package python-fakeredis > > I would like to upload stable update of python-fakeredis (1.0.3) to sid which > fixes FTBFS #924851 and other minor bugs. > Actual python-fakeredis (1.0~rc1) testing version is not compatilbe with the > latest python-redis (3.2.1) because > https://github.com/jamesls/fakeredis/issues/235 > > I think it's better to have a stable rather than RC version with some Debian > patches in buster. > > Changes between RC and stable is minimal and they are all bug fixes. > python-fakeredis is leaf-package, so the risk is minimal. > > Kindly asking to pre-approve this migration. > > Thanks > Ondrej Koblizek > > debdiff follows: > > > [...] > > > unblock python-fakeredis/1.0.3-1 > > [...] Hi, Please go ahead with the python-fakeredis/1.0.3-1 upload. Advice for future unblock requests: The unblock request would have seem a lot less daunting if the upstream changelog had been pruned (it is over 70% of the entire debdiff) or if a diffstat had been included in the mail (before the debdiff obviously). If you prune a debdiff, please remember to state this and tell us how you did it (usually the filterdiff cmd-line will suffice). This will make it easier for us to determine how difficult/much time we need to spent on the review. This will in turn enable us to provide you with feedback faster much faster in cases like this. Thanks, ~Niels
Bug#926513: unblock: fswatch/1.14.0+repack-7
Control: tags -1 moreinfo Alf Gaida: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package fswatch > > Reason: Symbols reworked after compiler change. > Additional bumped Standards and switched to debhelper-compat. > > > unblock fswatch/1.14.0+repack-7 > > [...] Hi Alf, Thanks for working on improving buster. We are not accepting changes to debhelper compat levels at this point in the freeze. If you upload a -8 without that, then I am happy with unblocking these changes. Please remove the moreinfo tag once the -8 version is uploaded and ready for a final review. Thanks, ~Niels
Bug#926299: unblock: busybox/1:1.30.1-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock (X-CC'ed kibi + debian-boot). Hi kibi/d-i, The recent upload of busybox fixes the bug #925979 in busybox-udeb. Should we (RT) unblock it now or do you prefer waiting (as I understand it there is d-i release coming up). unblock busybox/1:1.30.1-4 Thanks, ~Niels
Re: gpac_0.7.1+dfsg1-1_amd64.changes is NEW
Thorsten Alteholz: > Hi Reinhard, > > On Tue, 2 Apr 2019, Reinhard Tartler wrote: >> Now about 6 weeks have passed since I've been uploading this package, and >> I do have a question: Is there anything wrong with this package? > > yes, you did an upload to unstable. At this time of the freeze and > without a notice from the maintainer/release team this is usually wrong. > >> I'm CC'ing the release team to inform them about this upload. > > Ok, so is this version suitable for buster? > > Thorsten > Note that gpac/0.5.2-426-gc5ad4e4+dfsg5-4.1 is currently in sid, recorded as fixing #892526, #902782 and #921969. Therefore, please hold gpac/0.7.1+dfsg1-1 in NEW for now until the sid version can migrate to testing. As for gpac/0.7.1+dfsg1-1, I cannot find a debdiff for it on the mailing list nor the BTS. Therefore, I have no clue whether it is suitable for buster. Thanks, ~Niels
Bug#925185: unblock pre-approval: sysstat/12.0.3-1 (actually 12.0.3-2)
Control: tags -1 confirmed moreinfo Robert Luberda: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please approve sysstat 12.0.3, which is upstream bugfix release, > for uploading to unstable and migrating to testing. > > [...] > > I uploaded systat 12.0.3-1 to experimental a few days ago with the > following changelog: > > sysstat (12.0.3-1) experimental; urgency=medium > > * New upstream stable version: > + sadf: Fix out of bound reads security issues (CVE-2018-19416 and > CVE-2018-19517, closes: #914384, #914553); > + sadf: Fix possible infinite loop; > + sar: Fortify remap_struct() function to prevent possible crashes on > reading binary datafiles generated by older versions of sysstat. > * systat.init.d: revert a change introduced in 11.5.5-1, as it caused > the start script to fail to execute the command that adds "Linux > Restart" > marker into statistics file on systems on which systemd is not used. > Thanks to Georgios Zarkadas for noticing this (closes: #924864). > * debian/rules: replace deprecated dh_systemd_start by dh_installsystemd, > as suggested by lintian; the former command wass ignored by debhelper > v11, Typo > what in turn resulted in the `--no-start' option being ignored, and the > restart markers were incorrectly added during package upgrades. > >-- Robert Luberda Sun, 17 Mar 2019 23:09:46 +0100 > > The debdiff against buster is attached. > > If you think this version would be OK for buster, then I can upload -2 > to unstable, with no other changes, except for Debian changelog entry. > > Otherwise please let me know what would you approve, and what I should do: > - backport patch [3] only (but I don't think this would be safer); > - backport both patches, i.e. [3], and [4] (but those are the biggest ones); > - something else. > > Regards, > robert > > > [...] Please go ahead with 12.0.3-1 for buster and remove the moreinfo tag when it is ready for unblocks. Thanks, ~Niels
Bug#926222: unblock: pbgenomicconsensus/2.3.2-2
Control: tags -1 moreinfo
Andreas Tille:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
>
> Please unblock package pbgenomicconsensus
>
>
> I admit the changes are more complex than I would have prefered them to
> be. The usage of the upstream Makefile inside the tests would have
> required to re-do the workaround for missing data for some tests as they
> were just done in debian/rules. Instead I moved the code from d/rules
> right into upstream makefile to keep the test consistent at package
> build time and in autopkgtest.
>
> Unfortunately further patches of the test suite are necessary to deal
> with several warnings bloating the output.
>
> Kind regards, Andreas.
>
>
> unblock pbgenomicconsensus/2.3.2-2
>
> [...]
>
Hi,
A possible reoccurring issue is that the changes to the Makefile
involves long shell sequences with ";" (i.e. "Ignore errors") without
use of "set -e". As an example is this:
> +--- a/Makefile
> b/Makefile
> +@@ -8,7 +8,12 @@ tests: unit-tests basic-tests
> +
> + unit-tests:
> + # Unit tests
> +- py.test --junit-xml=nosetests.xml tests/unit
> ++ # ignore tests requiring
> https://github.com/PacificBiosciences/PacBioTestData which is not packaged
> ++ TMPDIR=$$(mktemp -d /tmp/test_ignore_XX) ; \
> ++ mv tests/unit/test_tool_contract.py $${TMPDIR} ; \
> ++ py.test --junit-xml=nosetests.xml tests/unit ; \
> ++ mv $${TMPDIR}/* tests/unit ; \
> ++ rmdir $${TMPDIR}
> +
> + # Note: We need at least cram/0.7 for '--xunit-file'
> + # Note: The cram tests often need h5py.
AFAICT, if the py.test command fails the target might still succeed as
long as the final "rmdir" succeeds due to "; without set -e". Obviously,
it is not going to be any easier to correctly clean up *in case of* errors.
Similar issue appears here:
> +--- a/tests/cram/extra/plurality-fluidigm.t
> b/tests/cram/extra/plurality-fluidigm.t
> +@@ -7,7 +7,8 @@ Some tests of a "fluidigm amplicons" dat
> +
> + Set the QV threshold to 10.
> +
> +- $ variantCaller --algorithm=plurality -r $REFERENCE -q 10 -o variants.gff
> -o consensus.csv -o consensus.fastq $INPUT
> ++ $ variantCaller --algorithm=plurality -r $REFERENCE -q 10 -o variants.gff
> -o consensus.csv -o consensus.fastq $INPUT 2>&1 | tee | grep -v
> H5pyDeprecationWarning
> ++ [1]
> +
> + There are two true SNVs (and one diploid SNV that we miss right now).
> +
(ASSUMPTION: It is a command and run under "normal shell rules" and the
test actually checks the exit code rather than the out).
If the above assumption holds, this patch will hide the exit code of
variantCaller and replace it by the exit code of grep (a normal pipeline
*without* the "set -o pipefail"-bashism will have the exit code of the
last command in the pipeline).
If it is just code examples, then you can (mostly) disregard this remark.
Final remark:
> Test-Command:
> - cp -r Makefile tests $AUTOPKGTEST_TMP
> - && cd $AUTOPKGTEST_TMP
> - && make tests
> + make unit-tests || true # due to warnings caused by python-pbcore
> some non-zero value is returned despite all tests are passing - thus adding
> '|| true'
> Depends:
> @,
> python-nose,
> python-cram,
> make,
> + poa
> Restrictions: allow-stderr
If the autopktest cannot "fail" (both stderr and exit code is ignored),
then it should either not be run or at least be tagged as "superficial"
as a(n unconditional) "Success" is not really saying anything about
whether it worked or exploded in fire and flames.
Thanks,
~Niels
Bug#926246: unblock: kronosnet/1.8-1
Control: tags -1 confirmed moreinfo Ferenc Wágner: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package kronosnet > > Dear Release Team, > > The latest upstream release of kronosnet fixes a use-after-free and a > configuration error causing 100% CPU usage, both of which would be very > good to have in buster. Besides this, there's a flow change required by > FreeBSD (which returns EINVAL if the destination address is filled in > while sending over connected sockets) and some minor logging, test and > documentation fixes. Most of the latter does not affect the binary > packages, because the unit tests and the doxyxml tool is not shipped. > I'm the only user of this library (via corosync), so the change is also > very narrow-scoped. Unfortunately, the debdiff is hard to read due to > the copyright year updates across the board. Please consider digging > through it. :) I'm ready to upload kronosnet_1.8-1 if you agree. > > Thanks, > Feri. > > [...] > > unblock kronosnet/1.8-1 > Please go ahead and remove the moreinfo tag when it is ready to be unblocked. Thanks, ~Niels
Bug#926162: unblock: opensaml/3.0.1-1
Control: tags -1 moreinfo confirmed Ferenc Wágner: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package opensaml > > Dear Release Team, > > [...] > > If you're fine with this, I'm ready to upload opensaml/3.0.1-1 to > unstable. > > Thanks, > Feri. > > [...] > > unblock opensaml/3.0.1-1 > Please go ahead with the upload and remove the moreinfo tag when it is ready for unblocking. Thanks, ~Niels
