Bug#1082798: marked as done (unblock: rust-sequoia-keystore-tpm/0.1.0-2)
Control: reopen -1 On 26-09-2024 17:03, Debian Bug Tracking System wrote: Your message dated Thu, 26 Sep 2024 17:02:15 +0200 with message-id <408fa13d-0016-4df3-a1c8-ff6fca76b...@debian.org> and subject line Re: Bug#1082798: unblock: rust-sequoia-keystore-tpm/0.1.0-2 has caused the Debian Bug report #1082798, regarding unblock: rust-sequoia-keystore-tpm/0.1.0-2 to be marked as done. While I expected I would fix the bug when I started replying, I came across the misunderstanding of the Breaks, so this bug isn't fixed yet. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1080439: [SPAM] Bug#1080439: transition: exiv2 0.28.x
Hi, On 25-09-2024 18:26, Andreas Metzler wrote: Afaiui every rdep would need to be ready for migration to testing at the same time. Which probably has not never been the case, e.g. currently geeqie is too young. Nevertheless I suspect that transition is too big to be happen without help/force. I've added a hint. Let's hope that the next few hours no new package appears. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#969633: transition: json-simple
Hi, On Sun, 20 Sep 2020 19:33:49 +0200 Gilles Filippini wrote: Emilio Pozuelo Monfort a écrit le 20/09/2020 à 18:50 : > On 06/09/2020 13:38, Gilles Filippini wrote: >> Upstream removed an API that was deprecated long ago and introduced a >> few backward incompatible changes. > > Then it needs a SONAME bump. There is no such thing in java. I asked the question on the debian-java list whether to change the binary package's name and it was answered that it should be avoidable [1]. I eventually chose not to change it because there are few reverse dependencies. As you don't have a way to know what 3rd party packages exist that rely on json-simple's binaries, the most robust solution is to rename the binary like we do in c-library transitions when SONAME's are bumped. We don't get the benefit of smooth-transitions, but it avoids most silent breakage. Do I assume correctly that the reverse build dependencies' binaries get the right package name to depend on during the build, or are they hard-coded and would need manual updating? If it's manual, how would the reverse build dependencies' binaries get the right versioned dependency? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1074180: php8.4 mass rebuild
Hi Athos, On 18-09-2024 22:52, Paul Gevers wrote: Well, we'd first need to add your repo to the ci.d.n infrastructure. I'll do that tomorrow. I notice that you have a new archive for (probably) each rebuild. It might be less hassle in the use of ci.d.n if you can maintain a canonical URL for your latest rebuild, e.g. a softlink from ~athos-ribeiro/rebuilds/latest to ~athos-ribeiro/rebuilds/php8.4-beta now. I've added php8.4-beta to the list of supported external repos. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1074180: php8.4 mass rebuild
Hi Athos, On 18-09-2024 22:47, Athos Ribeiro wrote: On Mon, Aug 26, 2024 at 08:40:31PM +0200, Paul Gevers wrote: I suppose I would need to also push php8.4 and php-defaults to that repository so autopkgtest would pick those up, right? Or is it possible to pick those from experimental? You can request from multiple additional archives, so yes, it's possible to pick those from experimental. This was also recently discussed in bug 1073983 that mentioned scripts by glondu to do the scheduling. If you're interested, that bug had more discussion so is probably a good read. I will go through that and will request those autopkgtests for the new rebuild I performed for PHP 8.4 beta available in experimental. Well, we'd first need to add your repo to the ci.d.n infrastructure. I'll do that tomorrow. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1080521: transition: Removing gjs and GNOME Shell from armel
Hi On 06-09-2024 17:32, Paul Gevers wrote: I also think that the faux-packages list is/can be architecture specific, so it's probably trivial to fix but adding all architectures but armel. I have made the constraints arch specific and dropped armel from the list. Looking at the current britney2 log I see that the task-pkgs-are-installable-faux is in the list for gwenview/ except for armel, so that seems to work as intended. Given [1] we should probably do the same for i386 very soon too. Paul [1] https://lists.debian.org/msgid-search/918d41dda41dff06c9f14fb3dd4111d85492316c.ca...@decadent.org.uk OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1081362: unblock: libdata-validate-domain-perl/0.15-1
Hi, On 11-09-2024 08:17, EiPiFun wrote: The only thing I want to confirm is that will tests be performed again if lintian is upgraded? Failing tests are retried after 1 day once the results come in. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1081274: ftp.debian.org: snapper-gui wrongly removed from testing
Control: retitle -1 reverse dependencies can get autoremoved too early Control: tags -1 wontfix Hi, On Tue, 10 Sep 2024 14:24:30 +0530 Ritesh Raj Sarraf wrote: Yesterday, I got a report that snapper-gui is removed from Debian testing. The reason for removal is Debiang bug: 1073699, which is for the snapper package. snapper is still in the archive while snapper-gui has been removed. snapper has an RC bug and hence it's listed for autoremoval. All reverse dependencies of packages listed for autoremoval get also listed for autoremoval. Packages listed for autoremoval get early warnings, so it shouldn't come as a surprise that your package is removed. There's no mechanism in place to guarantee this will be done in lockstep. While it seems unfair that snapper isn't removed at the same time as snapper-gui, that's a hard to solve problem because we're using our migration software to do the autoremoval via removal hints and that process isn't designed to handle removal hints in a block. So while it's technically possible to fix this issue, I don't think anybody will spend their time on this problem any time soon. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1080521: transition: Removing gjs and GNOME Shell from armel
Hi, On 06-09-2024 15:16, Simon McVittie wrote: When we discussed this in 2022, Paul Gevers said that the release team could probably disable this check and allow task-gnome-desktop to be uninstallable on armel... I recall that we currently can't build d-i on armel anymore because there are not kernel udeb. I think we effectively said we're done with the installer on armel and hence we don't need to care about task-gnome-desktop on armel as much. I also think that the faux-packages list is/can be architecture specific, so it's probably trivial to fix but adding all architectures but armel. Let me do some checking if I got the details above correct. I'm convinced we should be able to deal with this on the Release Team side of this. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1080021: trixie-pu: package chromium/128.0.6613.113-1~deb13u1
Control: tags -1 cconfirmed Hi Andres, On 29-08-2024 18:32, Andres Salomon wrote: As we discussed on IRC, Saturday's bookworm point release would be made easier if chromium in trixie were up-to-date with what's in bookworm. Given that chromium also has an additional 23 CVEs and 128 is already in pretty good shape, let's do another tpu. The packaging changes between 127.0.6533.119-1 in sid and 127.0.6533.119-1~deb13u1 remain the same as in past tpus (eg, #1076396). See attached. Please go ahead and upload and lets check tomorrow evening where we stand before hinting it in. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hi, On 28-08-2024 13:58, Steve McIntyre wrote: Apologies for the delayed response - busy weekend here... Totally understood. :) But the autopkgtest of python-django-storages fails [1]. This *appears* to me as a test problem we can accept, but maybe you or the python-django-storages maintainers can confirm? That does very much look like a test with broken assumptions, I'll be honest. Ah, I see... I can see that Josh Schneier (the upstream for django-storages) is the person responsible for the CVE against django in the first place - he spotted the issue and reported it. In https://github.com/jschneier/django-storages/commit/330966293a74f2dabda18fa2e4a221952bf010a9 there's a fix on his side to cope with the django change. It looks like we'll want that change backporting into python-django-storages. I can try to do that too if you like, but I appreciate we're getting very tight on time before the weekend. :-/ I'm not SRM, just trying to help out with the autopkgtest infrastructure and results. I'm predicting that SRM might not want a fixed python-django-storages this late, so I think it would help if you can advise the SRM: do you think the regression is less bad than leaving the CVE's unfixed or the other way around? I.e. accept the regression, or keep the fixed python-django out until the next point release (with a fixed python-django-storages). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue
Hi, On 21-08-2024 19:44, Aurelien Jarno wrote: It also means that at least gettext will need to get reboostrapped on all architectures. Indeed the new libxml2-dev won't be co-installable with debhelper, which is a build-dependency of gettext: - libxml2-dev will depend on libxml2n - debhelper will still depend (through debhelper) on libxml2 What are the plans with regard to that? Note that I haven't check further in the (build)-dependency tree. On IRC aurel32 suggested to add a "Provides: libxml2" during the transition to provide a smooth-update path, which is now implemented in the version in experimental. I understand that will work around the problem raised above. I believe that in general we're OK with going this route. I leave the actual planning to pochu, Sebastinas and ginggs as they handle most regular transitions. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1074180: php8.4 mass rebuild
Hi Athos, On 26-08-2024 19:58, Athos Ribeiro wrote: I performed a first mass rebuild for all php8.2 and php-defaults reverse-dependencies. The results are available at: http://people.ubuntu.com/~athos-ribeiro/rebuilds/php8.4-alpha/ Are you aware that we at ci.d.n offer support for these kind of rebuild archives as external sources to schedule autopkgtests against? See the bottom of [1]. This was also recently discussed in bug 1073983 that mentioned scripts by glondu to do the scheduling. If you're interested, that bug had more discussion so is probably a good read. Paul [1] https://salsa.debian.org/ci-team/debian-ci-config/-/blob/master/cookbooks/debci/templates/extra_apt_sources_list.yaml.erb?ref_type=heads OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1079515: bullseye-pu: package rustc-web/1.78.0+dfsg1-2~deb11u1
Hi Emilio, On 24-08-2024 12:29, Emilio Pozuelo Monfort wrote: Uploaded. The package fails its own autopkgtest. Did something go wrong? 63s autopkgtest [22:00:29]: test create-and-build-crate: [--- 63s Created binary (application) `hello` package 63s error: no such subcommand: `add` 63s 63sDid you mean `doc`? 63s autopkgtest [22:00:29]: test create-and-build-crate: ---] Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hi Steve and python-django-storages maintainers, On 23-08-2024 13:24, Steve McIntyre wrote: I've backported a lump of upstream CVE fixes for django to the version in bookworm. Chris Lamb has reviewed and approved the changes as one of the existing maintainers. The standard test suite all passes as expected. But the autopkgtest of python-django-storages fails [1]. This *appears* to me as a test problem we can accept, but maybe you or the python-django-storages maintainers can confirm? Paul [1] https://release.debian.org/proposed-updates/stable.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1079353: bookworm-pu: package cacti/1.2.24+ds1-1+deb12u3
Hi Bastien, On 24-08-2024 15:18, Bastien Roucariès wrote: Le samedi 24 août 2024, 11:03:38 UTC Paul Gevers a écrit : I'm wondering if you may have hardened cacti and that if fails on that now. If this is to be expected, the string can be added to the "ignore" lines. I'm not an SRM, so I wonder how much time you still have. It might be better to have cacti in bookworm now, albeit with a broken test. Can we have a stuff like on elts with a special queue that need dcut migrate ? cacti has already been accepted into proposed-updates. The tests are run to inform everyone of issues, to enable actions if needed. It's not nice and trivial (IIUC) but if a package has issues, SRM can choose to skip it when the point release is cut. Alternatively they can ignore the failure and nothing special needs to happen in that case. Is that what you're asking (I'm not sure I understood your question correctly)? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1078937: bookworm-pu: package openssl/3.0.14-1~deb12u1
Hi Sebastian, On Sat, 17 Aug 2024 23:25:28 +0200 Sebastian Andrzej Siewior wrote: This is a stable release update of openssl provided upstream. Besides regular fixes it addresses three CVEs which are clasified as minor and therefore not yet fixed. After this update one CVE remains open which has been clasified as low by upstream and requires more than one patch address it and I decided to delayed it until 3.0.15 is released. I am not aware of any fallout at this point. Some flaky autopkgtests are failing [1], but nodejs regresses on all architectures. It *seems* to me that's acceptable, one failure mode is changed for another, but hopefully you or nodejs maintainers can confirm, the regression is harmless (doesn't indicate a real issue with the update). Paul [1] https://release.debian.org/proposed-updates/stable.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1079353: bookworm-pu: package cacti/1.2.24+ds1-1+deb12u3
Hi, On 24-08-2024 10:31, Bastien Roucariès wrote: Could you reject the time of investigation ? I'm wondering if you may have hardened cacti and that if fails on that now. If this is to be expected, the string can be added to the "ignore" lines. I'm not an SRM, so I wonder how much time you still have. It might be better to have cacti in bookworm now, albeit with a broken test. Paul 104s Unexpected output in /var/log/cacti/cacti.log: 104s 2024-08-24 06:02:11 - AUTOM8 Attempted SQL Injection found in Tree Automation for the field variable. 104s 2024-08-24 06:02:12 - AUTOM8 Attempted SQL Injection found in Tree Automation for the field variable. 104s 2024-08-24 06:02:12 - AUTOM8 Attempted SQL Injection found in Tree Automation for the field variable. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1079353: bookworm-pu: package cacti/1.2.24+ds1-1+deb12u3
Hi, On 22-08-2024 17:38, Bastien Roucariès wrote: [ Tests ] Automated test and manual test of the application by myself and others, including users. Did you run the autopkgtest? It now fails on the ci.d.n infrastructure on all architectures. (Unfortunately, cacti has a rather large artifacts file, so the logs are rotated a bit aggressive. I've retrigged the amd64 job to get new logs.) Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1078945: trixie-pu: package chromium/127.0.6533.119-1~deb13u1
Control: tags -1 confirmed Hi Andres, On 18-08-2024 09:27, Andres Salomon wrote: Chromium is still blocked from migrating by libxml2, and trixie's version has racked up 37 CVEs. Now that the sid version builds for all 5 architectures, it's time for another tpu. The packaging changes between 127.0.6533.119-1 in sid and 127.0.6533.119-1~deb13u1 are attached. Same changes as in #1076396. Please go ahead. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue
Hi, [Disclaimer: I'm not the most experienced person on transitions in the team, so I'd like for Graham, Emilio and/or Sebastian to check if they agree with me.] Thanks for working on this. On 17-08-2024 05:58, Aron Xu wrote: After some research, I prefer making a t64-like transition for libxml2 for the following reasons: I'm a bit curious in how far you think this looks like a t64-like transition as apposed to a regular c-library transition. Is it because the libraries will not be co-installable, you don't bump SONAME and just rename the binary package name? Even with all the work that went into the t64 transition, we're starting to see hidden bugs [0] (although I think this can happen with any transition). - Upstream is not prepared to bump the SONAME to something like libxml3. Given the long history of this function library, determining which APIs should be public and which should be private is challenging. That's why earlier I proposed a Debian specific SONAME, "in between" 2 and 3. Upstream (I think) even suggested that [1]. - The potential for breaking locally built software is minimal. Although abi-compliance-checker raises many issues, most of them are not used in the real world. Isn't the fact that we *caught* an issue in Debian the proof that it's not just academic? - This approach is significantly easier and safer. I'm hesitant because we have well established procedures to handle ABI breakage with SONAME bumps and how to handle them in Debian. Can you elaborate on the easier and safer parts? Because I mostly see risks to deviate from established paths as the corner cases on them are less known. I've prepared a preliminary debdiff and tested locally. What do you think? Also just curious, why the letter n? Paul [0] https://lists.debian.org/msgid-search/Zr57AYhXiL3oi8_d@per [1] https://gitlab.gnome.org/GNOME/libxml2/-/issues/751#note_2157870 (second to last paragraph) OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073983: transition: ocaml
Hi On 16-08-2024 06:31, julien.pu...@gmail.com wrote: The OCaml compiler has two compilation modes: native and vm. The new version disabled the native mode on 32bits architectures. Some packages that were ok with the last version aren't anymore. Hope that makes things clearer, Partially. My (not explicitly asked) question remains: what needs to be done with those packages? Fix them in this transition? RC bugs filed and removal from testing? Removal for those architectures only (are bugs filed already, the release team can't remove architecture specific packages)? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073983: transition: ocaml
Hi On 13-08-2024 08:03, Stéphane Glondu wrote: Howevever, many of them are related to the fact that i386 and armhf are no longer native (ocaml 5 dropped support for native compilation on 32-bit architectures), hence the corresponding uninstallability or autopkgtest issues for coq-related packages are irrelevant. Is britney smart enough to cope with this? If the excuses report an autopkgtest failure, britney2 didn't do what you were hoping. ocaml builds on all architectures, so how should I understand your statement? Are these non-installability and autopkgtest issues all for source packages that build arch:all binaries? Than that needs a hint from our side. Do any of these source packages build arch specific binaries on those architectures that no longer work, than those need to be removed from unstable (reportbug ftp.debian.org). Maybe I don't understand what you meant exactly (sorry for not having read the full backlog). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: RFC: dropping armel from Debian for the upcoming release
Hi, On 15-08-2024 20:35, Martin wrote: What would be the best way, esp. for people outside of Debian, to always know about such problems? And not only read about it, when it's already solved? Ideally bug affecting specific architectures should have the right usertags. I believe in this case the bug had it: https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-...@lists.debian.org Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Request for clarification on RC-ness of DEP17 bugs
Control: reopen -1 Hi Thorsten, The Release Team considers packages that ship files in /usr-merged aliased locations RC buggy. We have put our trust in Helmut to come up with the right solutions during the preparation for trixie, so I'm asking you to either convince him of a better approach, or apply the patches he proposes. Paul Release Team member OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue
Hi Aron, On 14-07-2024 07:37, Paul Gevers wrote: On 28-06-2024 5:44 a.m., Aron Xu wrote: Would like to know if such steps would help resolve the issue better: - revert to a previous version which does not have API/ABI breakage - apply/port security patches on a best effort basis - help upstream to check and fix API/ABI changes I think all three would help, where the first one is the quickest one to get things moving again. Given the severity of the security issue mentioned in the changelog I think you could even consider ignoring item number two for now, but maybe you mean going forward. Or do you have any recommendations? There is the option to do a Debian specific SONAME bump, but if the break was not intended and might get reverted that's probably a bad idea. And if the changes are here to stay, upstream should bump SONAME themselves. While the upstream bug about the soname breakage seems to have halted, can we please get some resolution in Debian please? The fact that libxml2 can't migrate as-is is hurting more and more (particularly the creation of a useful testing for riscv64). If upstream is really reluctant to bump SONAME when they should, maybe you should prepare for a maintenance scheme to do that in Debian when needed. Ideally the scheme should be designed such that when upstream bumps SONAME, you can follow them again. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1071970: pcre3 should not be part of trixie
Hi, On 06-08-2024 23:33, Bastian Germann wrote: I am including a patch to drop the libpcre3-udeb. Please consider applying so that the package can be autoremoved. Please don't do that until you have approval from d-i. I included them in the mail chain. If the udeb is used by d-i, that needs to be resolved first. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1077958: nmu: rust-async-broadcast_0.7.1-1
Hi, On 06-08-2024 06:39, Paul Gevers wrote: On 06-08-2024 04:21, Reinhard Tartler wrote: So I think I managed to find the right combination of packages. Basically, we need all of - rust-async-channel - rust-async-process - rust-event-listener - rust-async-broadcast to migrate together. Because they break each other, or merely because the test fail? Wait, I think I now understand what you tried to say earlier (sorry, it's very exciting at $dayjob and I'm not always as sharp at home as I normally am). Apparently librust-async-io stopped providing librust-async-io-2+default-dev (and others), or something along those lines. I think we're running into limitations of britney2 here where it isn't aware of how to deal with situations where only one package Provides something else during the excuses phase. It's already for a long time on my todo list, but alas. Under the assumption that the above assessment above is correct, the packages will migrate together because otherwise they become not-installable and the second phase of britney2 protects against that. Let me schedule the tests. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1077958: nmu: rust-async-broadcast_0.7.1-1
Hi, On 06-08-2024 04:21, Reinhard Tartler wrote: So I think I managed to find the right combination of packages. Basically, we need all of - rust-async-channel - rust-async-process - rust-event-listener - rust-async-broadcast to migrate together. Because they break each other, or merely because the test fail? When triggering with all of these four sources from unstable, I end up with a successful autopkgtest: Ack, thanks. How to convey that to britney/debci? Depending on the answer above, I'll need to manually trigger those jobs, just like you did, but then with britney2 credentials. Is that something that could be added as a hint by the release team, or does that require adding what Breaks to what package exactly? Well, to answer that last question the people that know the software need to figure out which package Breaks which package. I can't say from this distance, because I can't distinguish package breakage from test breakage. I suddenly realize that rust packages are special in Debain. Do the involved packages actually do anything besides providing source? Can other packages actually break due to packages that provide source? I recall rust packages are mostly meant to be used to build Debian packages, and not intended to be used by users. Am I correct in that understanding? Than, what happens if package A would migrate and package B not: would it mean FTBFS in testing of reverse Build-Depends package C until B migrates too? In the latter case, I think package A should have a versioned Breaks on package B in testing. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1052119: autopkgtest in experimental: sometimes just fails for rust libraries with "crate directory not found"
Hi, On 05-08-2024 15:46, Simon McVittie wrote: To avoid this, I think it would have to grow a new command-line option to tell it something like: "pin all binary packages from src:rust-async-executor to source version 1.12.0-3, at a high priority". I thought we were doing that *until* the fallback lifts all pinning. Rest assured that in the past I worked [1, 2] to prevent the fallback, because I consider it wrong, but it helped in quite some cases where the outcome is acceptable in the end. The price was that if it still fails, it more confusing to figure out. I have good hopes that the version 3 solver of apt is going to improve things, I'm not sure if it would have helped in this case. But maybe it will enable us to disable the fallback again. Paul [1] https://salsa.debian.org/ci-team/autopkgtest/-/commit/d83497c0 [2] https://lists.debian.org/deity/2018/06/msg00034.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1077958: nmu: rust-async-broadcast_0.7.1-1
Hi On 05-08-2024 14:03, Reinhard Tartler wrote: I need some help to understand how skipped tests lead to delaying the package migration to testing. My naive understanding is that this flag would rather allow issues to go through to testing? What skipping means isn't up to autopkgtest to determine, but up to the consumers of the test results. For migration to testing, that britney2 that's owned by the Release Team. We, the Release Team, want britney2 to prevent migration: a) the autopkgtest of a package doesn't fail in testing, but the test fails with $something from unstable (regression). That $something should be blocked. b) the test is new to testing, but it fails (weird definition of regression). My question is basically: what needs to be done so that https://tracker.debian.org/pkg/rust-event-listener <https://tracker.debian.org/pkg/rust-event-listener> can actually migrate testing? Good question. It seems that britney2 did schedule some combination "correctly", but not all. That is probably due to the order in which packages were uploaded. I.e. if a package needs some other package, britney2 will schedule the test for both triggers and if it passes, it counts for both. However, if the dependent-on package is later updated again, britney2 doesn't see the relation and will not schedule the combination. If the test than fails, the package is blocked. If there would be a versioned Breaks (not sure if the package is really broken, or merely the test, then a Breaks is a bit overkill), than britney2 would again trigger the combination. Does this help to tell the right answer? If this is only a test issue, and not really a versioned Breaks missing, I'm willing to manually trigger the right test combination. But then people need to hold off with uploading, otherwise the results might come too late. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1077958: nmu: rust-async-broadcast_0.7.1-1
Hi, On 05-08-2024 04:25, Jeremy Bícha wrote: Some Rust autopkgtests take a very long time to complete which is especially noticeable on riscv64 which I think may be the slowest autopkgtest infrastructure. That's why the test timeout on riscv64 is double that of other architectures: https://salsa.debian.org/ci-team/debian-ci-config/-/blob/master/config/production/nodes.d/riscv64.yaml?ref_type=heads#L11 Some rust autopkgtests have additional trouble because 1. No riscv64 packages are in Testing yet This is indeed a problem, largely because of 2. 2. The Debian Rust team sets skip-not-installable by default. That means the migration-reference autopkgtest will always show as neutral since the dependencies are uninstallable when migration-reference is the only trigger. I think skip-not-installable by default is bad for other reasons but I think this situation makes it worse. I regret I added skip-not-installable to autopkgtest. It does more harm than it helps. See for instance https://ci.debian.net/packages/r/rust-gtk4/testing/riscv64/ which passes once in a while. But I don't believe riscv64 is delaying the rust-zbus transition. Until yesterday at least rust-libseccomp was blocking a lot. I was hoping that once that migrated (happend yesterday) new tests would have more chance of succes, as it seems that several tests pass in a pure unstable environment. So this hints at missing *versioned* dependencies. But maybe it will resolve itself by time ordering. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1077845: release.debian.org: Should non-free-firmware require being built on buildd?
Hi, On 04-08-2024 13:22, Adrian Bunk wrote: The question would be whether you want to enforce it in Britney, which basically implies that Autobuild: should default to yes in non-free-firmware. I see this as a rephrasing of the discussion, so I can only agree that that's the question. You could ask on debian-devel whether there are any potential use cases in non-free-firmware where this might be problematic. With main we also just decided to do it, with the possibility to have packages hinted through. I'm don't see how it could be problematic, unless you mean that asking for an exception is problematic already. I already made a mental note to announce this when we deploy it, so it doesn't come as a surprise for those following announcements. But maybe you're having a different angle in mind? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1077845: release.debian.org: Should non-free-firmware require being built on buildd?
Hi, On 04-08-2024 09:31, Niels Thykier wrote: That leaves us with 3/15 and the question whether we want to commit for future firmware. I don't think we need to commit, just express a very strong desire to build on buildds when possible, and be practical if we can't. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1077845: release.debian.org: Should non-free-firmware require being built on buildd?
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 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1077803: transition: recode
Hi On 02-08-2024 22:30, Santiago Vila wrote: While we are at it, is the wording of this item ok? [MTL]: Bumps all blocking bugs to RC. Bug #1077768 is non-blocking because package is not in testing, but now the affected package will FTBFS, so the bug also needs to be raised to RC, which I will do after recode is built for all archs. I think the wording is OK, but you're free to change it if you can improve it (it's a Wiki after all). I think the wording doesn't exclude bumping non-blocking bugs to RC. Indeed, FTBFS in unstable only is RC even if it doesn't impact the transition. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1077803: transition: recode
Hi, On 02-08-2024 19:53, Santiago Vila wrote: - How are binNMUs handled? Is the maintainer (me in this case) in charge of requesting them (at appropriate times), or maybe there is some automated procedure to trigger them? It's documented on the wiki (linked from the transition page): https://wiki.debian.org/Teams/ReleaseTeam/Transitions (under "How transitions work in general") TL;DR: the RT takes care. - The only package which FTBFS (ui-utilcpp, filed as #1077768) is not currently in testing. Does this mean that in this case the FTBFS bug should not block the transition bug? Correct. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1077714: release.debian.org: Have the auto-remover emails include details on how managet the RC bugs
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 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1077314: unblock: pytest-jupyter/0.9.1-2
Hi Julian, On 28-07-2024 11:10, Julian Gilbey wrote: It's failing the autopkgtest on riscv64 quite badly. It's a new package, and I have no idea where in the toolchain the problem lies; given that pytest also fails on this architecture, it's probably not pytest-jupyter itself that is problematic. It's also quite probable that all of the newer versions of the jupyter suite will also fail on riscv64 because of the same reason, but we'll find out... We prefer you handle this inside your package. There are multiple options I can think of: * Add a "Architecture: !riscv64" stanza to the test (you don't get useful logs) * Add a "skippable" restriction and exit 77 on riscv64 instead of the regular exit code if non zero (you get logs to examine) * I assume the tests use a python testing framework, you could mark the individual failing tests as skipped (you get to catch regressions) Will I need to request unblocks for riscv64 for each of the other Jupyter packages separately if they also fail the autopkgtests on riscv64 once I have uploaded them? For every source package that isn't already in testing with autopkgtests running, failing tests will block indeed. Currently only existing failures that failed since the start are non RC issues. Failures on amd64 and arm64 are already RC [1]. Regressions are RC too. Paul [1] https://release.debian.org/testing/rc_policy.txt 6a. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072036: release.debian.org: Transition for gsl-2.8 / libgsl28
Hi, On 25-07-2024 13:22, Dirk Eddelbuettel wrote: I have built it, but in haste and error left the source-only flag from a recent upload to NEW on so I have to wait for the queue to purge before I can re-upload the corrected source-only batch. Worst case I make a -3. -2 is in the archive now, you'll need a -3. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073983: transition: ocaml
Hi, On 21-07-2024 1:14 p.m., Adrian Bunk wrote: The proper solution would be that release team tooling automatically schedules rebuilds and autopkgtests with the rebuilt packages for transitions prepared in experimental. But even with experimental that isn't always possible because there might be newer versions there already than we're interested into testing. We'd need an archive per "transition", i.e. bikesheds. every (re)upload of an auto-* transition package should start a CI run that does everything you are currently asking people to do manually. That's close to what I was saying, except we currently lack the place and tooling to do that. That was *exactly* what I was hinting at. Don't assume that tooling would be the only issue, and that all DDs would have hardware capable of doing rebuilds. Some DDs might have more RAM than others have diskspace. My laptop is rather bare. I know exactly what you're talking about: 4GB RAM, 100 GB disk. Many DDs appear to have desktops/laptops that are badly equipped for rebuilds involving larger packages. Like mine. Trying to build larger C++ sources with less than 4 GB RAM per virtual core can be a horrible experience. I'm not even trying, I hardly ever build on my system and off-load most builds to debomatic for that reason. Luckily I don't maintain much packages. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073983: transition: ocaml
Hi Stéphane, On 21-07-2024 6:40 a.m., Stéphane Glondu wrote: I've scheduled tests of all OCaml packages that provide tests (there are 86 of them). I did not specify any priority, I hope that's fine. That's fine for now. I guess you submitted via pasting the json you created in the self-service. You get priority 10 that way by default. Did you we the service also has an API [1] you can use? The json for it is similar and it has a priority parameter. (@terceiro: does the self-service have an undocumented priority parameter, or is it really absent)? It did allow me to spot a regression in camlzip, which I've already fixed. Great. I also noticed that opam's tests were broken, [...] I will fix that > on the way. Also great. This tests only packages that have been rebuilt and have a "testsuite" field, and pins all build-dependencies that have been rebuilt. Of course the cool thing you can do (and why I pointed you at britney2) is that you can also test for reverse (test) dependencies and check that *they* still work with the rebuild packages. Due to the way we do rebuilds in the archive (binNMU instead of NMU) we don't do those tests there (bug #944458), so it currently has added value if you could already check. To be clear, I'm not asking you to do it, I'm making you aware of these things, such that you can take it along if you so wish. Paul PS: one other idea I'm having. There are multiple teams doing these kind of rebuilds and archive creation; does each have their own tools and does it their own way, I guess so? Has anybody ever tried to have the teams join forces? ruby, perl, python and ocaml I already know of. (I fear I'm hearing PPA/bicksheds/debusine resonating in my question). [1] https://ci.debian.net/api/doc OpenPGP_signature.asc Description: OpenPGP digital signature
Re: libdisplay-info nano-transition soname 1->2
Hi Marc, On 20-07-2024 7:32 a.m., Marc Dequènes (duck) wrote: (I'm not sure why you request the list of affected package since ben does a much better job and the list could have changed in the meantime, but anyway here it is) Given that you didn't use the current recommend way to ask for a transition in a bug report (e.g. $(reportbug release.debian.org) to get the right usertags), I wonder where the "you request the list" is based on. Hmm, reading the documentation [1] I see it mentioned there, did you use [1]? I'll improve the text, but I'm wondering if there's other places. To avoid getting this request lost and to have the request fit into the work flow, can you please file a transition bug with . Paul [1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1076396: trixie-pu: package chromium/126.0.6478.126-1~deb13u1
Control: tags -1 confirmed Hi Andres, On 15-07-2024 7:13 p.m., Andres Salomon wrote: Chromium has been blocked from migrating to testing by libxml2 for roughly two months now. There are 38 CVEs that have been fixed between the version currently in trixie (125.0.6422.60-1) and the version in sid (126.0.6478.126-1). Several folks have asked for an updated version via tpu, so here we go again. The packaging changes between 126.0.6478.126-1 in sid and 126.0.6478.126-1~deb13u1 are attached. Please go ahead. I had to look up what that patch did that you enabled as it was already part of the source. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1076396: trixie-pu: package chromium/126.0.6478.126-1~deb13u1
Control: tags -1 confirmed Hi Andres, On 15-07-2024 7:13 p.m., Andres Salomon wrote: Chromium has been blocked from migrating to testing by libxml2 for roughly two months now. There are 38 CVEs that have been fixed between the version currently in trixie (125.0.6422.60-1) and the version in sid (126.0.6478.126-1). Several folks have asked for an updated version via tpu, so here we go again. The packaging changes between 126.0.6478.126-1 in sid and 126.0.6478.126-1~deb13u1 are attached. Please go ahead. I had to look up what that patch did that you enabled as it was already part of the source. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue
Hi Aron, On 28-06-2024 5:44 a.m., Aron Xu wrote: Would like to know if such steps would help resolve the issue better: - revert to a previous version which does not have API/ABI breakage - apply/port security patches on a best effort basis - help upstream to check and fix API/ABI changes I think all three would help, where the first one is the quickest one to get things moving again. Given the severity of the security issue mentioned in the changelog I think you could even consider ignoring item number two for now, but maybe you mean going forward. Or do you have any recommendations? There is the option to do a Debian specific SONAME bump, but if the break was not intended and might get reverted that's probably a bad idea. And if the changes are here to stay, upstream should bump SONAME themselves. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072920: release.debian.org: force-skiptest debusine/0.3.2/riscv64
Hi, On 13-07-2024 12:45 p.m., Jochen Sprickerhof wrote: The latest test failures look like timeout problems and we can still address them later. Why not do that now? Then we don't need to give you an exception without a good reason. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: yojson/botch blockage
Hi, On 20-06-2024 11:23 a.m., Paul Gevers wrote: The test for botch was done with the trigger of yojson of the time and valid for that too. britney2 will retry tests after 5 days (IIRC), so even without manual hint this should resolve itself in some time. Somehow the retry hasn't been triggered yet, so I manually scheduled to combination. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050237:
Hi, On 18-06-2024 7:33 p.m., t...@envs.net wrote: hello? 46 was already released, testing is still on 44 is there anything i can help with to port the new version to testing? This bug has a "blocking" bug tagged. You could try and help fixing that bug as a starter? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: yojson/botch blockage
Hi, On 19-06-2024 4:01 p.m., Stéphane Glondu wrote: It seems yojson/2.2.1-2 is blocked because of a failure of botch/0.24-3 test suite. But this has been fixed in botch/0.24-4 which won't migrate because it depends on yojson/2.2.1-2... It looks like some manual hint is needed here? I suspect (didn't check all details) that it's because the latest version of yojson was uploaded after the latest version of botch was uploaded. The test for botch was done with the trigger of yojson of the time and valid for that too. britney2 will retry tests after 5 days (IIRC), so even without manual hint this should resolve itself in some time. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061075: release.debian.org: Cross compilation of kernel modules for arm64 on bookworm is broken
Control: tags -1 moreinfo Hi, On Wed, 17 Jan 2024 15:10:55 +0100 Felix Moessbauer wrote: Package: release.debian.org Severity: normal The following dependencies need to be installed to cross compile a kernel module on debian bookworm, arm64: build-essential:amd64 crossbuild-essential-arm64:amd64 linux-headers-arm64 Currently, these have conflicting dependencies around gcc or binutils: | The following packages have unmet dependencies: | g++-12 : Depends: gcc-12 (= 12.2.0-14) but it is not installable | cpp : Depends: cpp-12 (>= 12.2.0-1~) but it is not installable | g++ : Depends: gcc-12 (>= 12.2.0-1~) but it is not installable | gcc : Depends: gcc-12 (>= 12.2.0-1~) but it is not installable | dpkg-dev : Depends: binutils but it is not installable | gcc-12-aarch64-linux-gnu : Depends: binutils-aarch64-linux-gnu (>= 2.40) What kind of action do you expect from the Release Team with regard to this bug report? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072920: release.debian.org: force-skiptest debusine/0.3.2/riscv64
Hi, On 10-06-2024 1:30 p.m., Colin Watson wrote: Would you please consider skipping debusine's autopkgtests on riscv64 (I think the hint in the subject line is correct, but I certainly wouldn't swear to it)? armel and armhf are having issues too (they were disabled due to time_t but I enabled them again recently). I fixed most of the issues in debusine 0.3.2, but the remaining failure happens persistently on ci.debian.net and refuses to reproduce for me in an emulated local environment. It doesn't appear that the package is terribly broken on riscv64 in general, and so I don't think this needs to block its migration to testing. ci.d.n maintainer hat on: I can give you access to a testbed where the test just ran if that would help you. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi, On 06-06-2024 8:54 a.m., Helmut Grohne wrote: I think this is fine. Doing final checks then uploading it all. For the record, the set of base-files, bash, dash, glibc and util-linux migrated yesterday in the 16:00 UTC britney2 run after some hinting from the Release Team side (me). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072813: release.debian.org: Help doris migrate to testing
Hi, On 09-06-2024 9:25 a.m., Antonio Valentino wrote: The main problem with non-amd64 architecture is that I do not have easy > access to them, I'm only DM. Ack I think that in the past we had binaries for other platforms but it was quite a pain. I just reread the section of the devref about autobuilding and contrib [1]. I understand it again. If it is not a big issue on your side I would prefer to keep amd64 only. Ack, will do. Paul [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#source-and-binary-uploads OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072813: release.debian.org: Help doris migrate to testing
Hi, On 08-06-2024 11:17 a.m., Antonio Valentino wrote: Could you please clarify if there is something on my side that I should do to allow doris to migrate? You could bootstrap doris on other architectures too, such that it's not only available on amd64 and this check of the migration tooling wouldn't block the package. It's a hint you might have not thought about doing it. If bootstrapping doris on non-amd64 isn't trivial, we can add a hint to ignore the installability on arm64. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067064: transition: petsc hypre
Hi On 20-05-2024 11:26 a.m., Drew Parsons wrote: Something weird happened with the slepc upload (3.20.2+dfsg1-1). See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071469 Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1070706: gtk4 udeb has unsatisfiable dependencies
Hi, On 07-05-2024 7:49 p.m., Simon McVittie wrote: The version in testing, 4.12.5+ds-3, has the same dependencies, so this is not a regression. Is it? It seems that the version in unstable depends on libpng16-16t64-udeb where the version in testing depends on libpng16-16-udeb. The later exists, the former not. Is this requirement newly enforced by britney? No. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1070708: unblock: rust-chrono/0.4.38-2
Hi, On 07-05-2024 5:55 p.m., plugwash wrote: Can you figure out what is going wrong and either fix it or override the tests? As noted on IRC, it's unclear what caused this. I retriggered the test and it's now picked up. For those watching, britney2 would have done this by itself too after 5 days: https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/autopkgtest.py?ref_type=heads#L138 Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1070040: bookworm-pu: package dm-writeboost/???
Hi, On 30-04-2024 8:54 a.m., Andreas Beckmann wrote: Can you point me to the code that evaluates dpkg's Testsuite-Triggers to schedule these tests? Maybe it's possible to convert dpkg's Testsuite field to a (hardcoded) list of additional triggers ... I think you mean this: https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/utils.py?ref_type=heads#L609 Or probably more something like this one: https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/autopkgtest.py?ref_type=heads#L615 and where it's used. Having said that, I'm not a great fan of teaching britney2 about autodep8 internal details. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1070040: bookworm-pu: package dm-writeboost/???
Hi, On 30-04-2024 12:43 a.m., Andreas Beckmann wrote: Testsuite: autopkgtest-pkg-dkms Right. I was talking about Testsuite-Triggers in the sources file generated by dpkg. Unfortunately the automation one gets with autodep8 doesn't extend that far and the triggers you are interested in are missing. Currently in unstable dm-writeboost has: Testsuite-Triggers: dkms, dmsetup, stress-ng (The dependencies for the first test contain unreleased changes that will try to fix the isolation-machine test, so you might see fewer deps on the package currently in the archive.) That will fix the problem at hand. Perhaps you can spot what's wrong with this setup s.t. it does not trigger as intended. I hope it's clear now. Related, for future reference, we also have the hint-testsuite-triggers [1] restriction in autopkgtest. Paul [1] https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1070040: bookworm-pu: package dm-writeboost/???
Hi Andreas, On 29-04-2024 10:52 a.m., Andreas Beckmann wrote: These failures could show up as autopkgtest failures in bookworm-pu. Are they flagged somewhere in your tooling s.t. they don't go unnoticed? As I hinted at in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069600#25, once there's an *test* dependency relation with linux, this will be tested. Current regressions can be seen here: https://release.debian.org/proposed-updates/stable.html, look for "c-i". Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Status of the t64 transition
Hello, On Thu, 2024-04-18 at 21:22 +0200, Sebastian Ramacher wrote: > Finally, packages that need rebuilds but currently have open FTBFS (RC + > ftbfs tag) bugs: > (...) > virtualjaguar I already have a tentative patch and will fix the package within the next days. I am also preparing to fix two other bugs, one being missing SDL-2 support and the other the FTBFS after rebuild from the same source unpack. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: R 4.4.0 coming April 24
Hi Dirk, On 18-04-2024 4:41 a.m., Dirk Eddelbuettel wrote: I uploaded a first beta release r-base_4.3.3.20240409-1 to 'experimental' a week ago, I just followed up with a rc release r-base_4.3.3.20240416-1. Thanks for preparing in experimental, as that triggers some QA. Given these non-changes, I do not think we need a formal transition. If the release teams thinks otherwise, please let me know, ideally before April 24. https://qa.debian.org/excuses.php?experimental=1&package=r-base shows there are 5 reverse (test) dependencies who's autopkgtest fail with the latest r-base in experimental. You'll want to discuss with the maintainers of those packages what that means for either r-base or their packages (ideally by filing bug reports to track the discussion). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068719: RM: ruby-arel/9.0.0-2 -- RoQA; obsolete, integrated into ruby-activerecord, incompatible with ruby-activerecord 6.1.x
tags -1 bookworm On 09-04-2024 7:23 p.m., Andreas Beckmann wrote: Please remove the obsolete ruby-arel from bookworm. I'm tagging it as such, so it shows up in the SRM tooling. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [sylpheed:37255] Re: Debian 12 released with two RC bugs in Sylpheed
On Sun, 7 Apr 2024 15:18:57 +0200 José Luis González wrote: > I found the report now. It's #1036799. Yes, it looks like a temporary server issue. And you're sending via gmail now. But again, what do you expect a package maintainer to do? It's upstream where bugs get fixed. Your subject is wrong, your two RC bugs are not RC bugs; in fact, they both seem to be describing the same behaviour, and you are requesting that the behaviour be different. i.e. they are feature requests. The more I consider your complaints about the Debian maintainer, the less they seem to hold water. with regards Paul
Re: [sylpheed:37253] Debian 12 released with two RC bugs in Sylpheed
On Sun, 7 Apr 2024 13:26:49 +0200 José Luis González wrote: > Debian 12 was released with two Release Critical bugs I filed on May > 20th 2023 (#1036424 and #1036388) on Sylpheed about issues that I > found on stable, and remain, with Debian 12 released later on June 10th > 2023. Those are not "Release Critical bugs". > I want to know why Debian 12 was released with those two Sylpheed RC > bags, report the incident to you all, know what to do with the > maintainer and kindly request that someone better at the job takes over > Sylpheed maintainance, or otherwise I will become a Debian developer > and package it myself. The upstream mailing list is not the place for this Debian discussion. On the one hand you "kindly request" and on the other your hurl unwarranted insults on a public list about the long-term Debian maintainer. Maybe Debian will overlook your behaviour and accept you as a developer, I don't know. with regards Paul
Re: grub 2.12-2 and 2.12-2~deb13u1 unstable/testing security updates [CVE-2024-2312]
Hi, On 05-04-2024 9:36 p.m., Julian Andres Klode wrote: Dear ftp and release teams, please ensure that the testing-proposed-updates upload lands and that the signed uploads are processed accordingly. I don't know how to handle the signing with the proposed-updates, but I'm sure you can coordinate that :) I saw the signed binaries coming in. I've added a hint. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068345: trixie-pu: package chromium/123.0.6312.105-1~deb13u1
Hi Andres, On 04-04-2024 9:56 a.m., Paul Gevers wrote: I have $(reschedule --days=0)-ed your upload to DELAYED. I'll do a final check when that lands before unblocking. The upload seems to be not a pure changelog only change. The tpu upload has a debian/patches/system/ffmpeg.patch that's not in unstable. Was that a mistake or care to elaborate? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068345: trixie-pu: package chromium/123.0.6312.105-1~deb13u1
Control: tags -1 confirmed Hi, On 03-04-2024 10:31 p.m., Andres Salomon wrote: I'd like to go ahead and upload 123.0.6312.105-1~deb13u1 to trixie. I have $(reschedule --days=0)-ed your upload to DELAYED. I'll do a final check when that lands before unblocking. Thanks for you patience. Please feel invited to request this path sooner next time when the unstable status delays security fixes landing in testing for more than several days. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: What to do with d-i on armel?
Hi, On 03-03-2024 9:01 p.m., Cyril Brulebois wrote: Maybe have it marked Not-For-Us on armel, also requesting the binary to be dropped there? And maybe poke the ftp team to have installer-armel/ cleaned up? Those actions sound appropriate to me, but I don't know the inner details well enough to see if there are traps set out. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Updating extrepo-offline-data in Debian Stable
Hi zigo, Disclaimer: I'm not acting as SRM, the final call is with team members that do. On 07-03-2024 12:28 a.m., Thomas Goirand wrote: So IMO, it'd make a lot of sense to be able to update the extrepo-offline-data package in Stable, so that Stable (currently bookworm) would get the latest up-to-date repository list data. That seems reasonable to me as long as it's data only. Having said that and not knowing if it doesn't already do that, if extrepro would update a cache when online, it's offline option could also be refreshed at a convenience moment without the need for an up-to-date package in stable. I hope it's needless to say that I don't mean that this mechanisme should replace the data package, merely complement it. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064427: [Britney] blocks a binNMU if a binary takeover of that package is in progress
/me is drinking coffee now *and* looking at test bug-709460 On 29-02-2024 8:43 a.m., Paul Gevers wrote: but I exposed it in the bug-709460 test case while trying to enable britney to check architecture-independent packages. Currently the behavior is masked in that case because britney skips the -doc package due to it being arch-indep. If this _is_ expected behavior, bug-709460 is currently passing erroneously. From you bug report title I was expecting that britney2 currently *didn't* migrate the binNMU's of src:pkga (or in the test case llvm-3.2-arch). However, ignoring arch:all binaries actually achieves that binaries from src:pkga are *eligible* for migration *despite* some of their (wrongly assigned) arch:all binaries should not. I think that's the behavior that we want (unless the failure to support arch:all binNMU's in the infrastructure is solely caused by this implementation detail in britney2). Did you interpret the final result of bug-709460 wrong or do I not understand what you tried to tell us? So, rethinking and if I understand correctly, this bug is about arch:any takeovers, whereas bug 709460 was about arch:all takeovers: src:pkga is newer in source-suite than in target-suite src:pkga builds bin:takeover arch:$any src:pkga has been binNMU-ed src:pkgb is in source-suite only src:pkgb builds bin:takeover arch:$any (higher version than from src:pkga) Yes, ideally the binNMU of src:pkga migrates, but I'm not sure it's worth the effort. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064427: [Britney] blocks a binNMU if a binary takeover of that package is in progress
grr, sent too soon (do I need coffee?) On 29-02-2024 8:33 a.m., Paul Gevers wrote: Hi, On 21-02-2024 10:53 p.m., Dalton Durst wrote: This condition only occurs when both source packages are considerable for migration. If both source packages provide both binaries, pkgb is found to supersede pkga, so pkga is not considered for migration. If pkgb passes all policy, it will migrate and pkga will probably be forgotten about (even though it considers pkgb its own cruft). This may be expected behavior, Expected behavior in the sense that once src:pkgb migrates, it's OK to forget about bin:takeover from src:pkga. I think *ideally* britney2 would migrate the binNMU from src:pkga while src:pkgb is blocked, but I think it's a niche case that is acceptable to not support. What would be bad is if bin:takeover from src:pkgb migrates without src:pkgb (bug 709460). > but I exposed it in the bug-709460 test case while trying to enable britney to check architecture-independent packages. Currently the behavior is masked in that case because britney skips the -doc package due to it being arch-indep. If this _is_ expected behavior, bug-709460 is currently passing erroneously. Which means that, if we fix bug 1064428 with your proposal to just skip the check, we need to add other code to prevent reintroduction of bug 709460. Either properly migrating bin:takeover from src:pkga, or by blocking bin:takeover altogether (this bug). Depending on required complexity [1], I don't think it's bad if we would end up wontfix-ing this bug (#1064427) I forgot it's important here to reason about arch:all vs arch:$any. In case bin:takeover is arch:all there will not be an binNMU of it, so there's no version of it that needs to migrate as long as src:pkgb is blocked. [1] I haven't inspected the code yet, but keeping track of all binary versions and reason about them instead of just taking the highest version seems like a large paradigm shift in britney2 (but I could be wrong). This still holds though. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064427: [Britney] blocks a binNMU if a binary takeover of that package is in progress
Hi, On 21-02-2024 10:53 p.m., Dalton Durst wrote: This condition only occurs when both source packages are considerable for migration. If both source packages provide both binaries, pkgb is found to supersede pkga, so pkga is not considered for migration. If pkgb passes all policy, it will migrate and pkga will probably be forgotten about (even though it considers pkgb its own cruft). This may be expected behavior, Expected behavior in the sense that once src:pkgb migrates, it's OK to forget about bin:takeover from src:pkga. I think *ideally* britney2 would migrate the binNMU from src:pkga while src:pkgb is blocked, but I think it's a niche case that is acceptable to not support. What would be bad is if bin:takeover from src:pkgb migrates without src:pkgb (bug 709460). but I exposed it in the bug-709460 test case while trying to enable britney to check architecture-independent packages. Currently the behavior is masked in that case because britney skips the -doc package due to it being arch-indep. If this _is_ expected behavior, bug-709460 is currently passing erroneously. Which means that, if we fix bug 1064428 with your proposal to just skip the check, we need to add other code to prevent reintroduction of bug 709460. Either properly migrating bin:takeover from src:pkga, or by blocking bin:takeover altogether (this bug). Depending on required complexity [1], I don't think it's bad if we would end up wontfix-ing this bug (#1064427) Paul [1] I haven't inspected the code yet, but keeping track of all binary versions and reason about them instead of just taking the highest version seems like a large paradigm shift in britney2 (but I could be wrong). OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064635: nmu: normaliz_3.10.1+ds-5
Control: tags -1 moreinfo Hi Jerome, On 25-02-2024 11:39, Jerome Benoit wrote: the upload of e-antic 2.0.2+ds-1 came with a shift of its SONAME from 1 to 3, This is a normal library transition. Why didn't you coordinate it with the Release Team as usual before the upload? and autopkgtest spots a build issue with the package normaliz: Build issue? "32s autopkgtest [15:05:58]: build not needed" So I guess you mean an install issue. Do you have any idea why? (I'm seeing a "Conflicts: libeantic-dev" in bin:libeantic-dev which looks weird to me (it may be right, I just don't immediately understand the use case). Might it be that apt gets confused?) rebuilding the package against libeantic3 causes not problem (and solve the issue). Sure, it's on our radar: https://release.debian.org/transitions/html/auto-e-antic.html Why didn't you also request the polymake rebuild? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064428: [Britney] does not migrate new arch:all packages after initial migration of same source
Hi Dalton, Good to have this discussion. I'll add a few remarks on behavior in Debian in this e-mail. On 21-02-2024 23:50, Dalton Durst wrote: test-src migrated after its amd64 and i386 binaries appeared. It also has architecture-independent binaries that miraculously only showed up after migration was complete (maybe someone hinted through the package too early). Well, if somebody hinted a package to testing that's supposed to have an arch:all build, than they can keep the pieces ;) (or in other words, it should be on their radar and they could deal with it). Not saying that that's ok, but the hint is obviously wrong in that case. If the package were binNMU'd, though, britney would migrate everything including the arch:all package if it passed checks. In Debian, binNMU-ing a arch:all package is known to not work. I don't know if this bug is the reason why it doesn't work, but I've been taught this when I joined the Release Team. I think I tried once by accident (or ignorance) and the binNMU didn't work. This behavior instability might be undesirable. But there _might_ be more infrastructure problems than britney2. The code which skips arch:all packages dates all the way back to britney2's original import[1], so it's not clear if it's still load-bearing. In the old days, an arch:all package was never build on a buildd, but uploaded by the uploader (together with the source). It's very possible that that fact is related to the original intent. Should britney be given the ability to test arch:all packages in ExcuseFinder by removing the block of code? If not, should it at least give a REJECTED_CANNOT_DETERMINE_IF_PERMANENT output to help an archive admin figure out what's going on? I am currently working an a change to britney2 that (based on Package-List entries in the Sources) will prevent migration of sources which build arch:all binaries. That will also work around bug #915948 (in dak) and fix bug #887060 (in britney2 for Sources build from source.changes files). From our conversation on IRC I take it that that wouldn't solve *your* case as you're using aptly and apparently that builds the Sources (with or without a Package-List) from what's in the archive so it would still run into this issue. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057180: Info received (bullseye-pu: package mariadb-10.5 1:10.5.23-0+deb11u1)
Hi, On 18-01-2024 05:50, Otto Kekäläinen wrote: Hi oldstable release managers, (I'm not one of them). I got email after my upload 11 days ago that 10.5.23 was accepted in oldstable-proposed-updates but I don't see any updates under 'News' at https://tracker.debian.org/pkg/mariadb-10.5 yet. Is the update progressing automatically somewhere? Neither https://release.debian.org/proposed-updates/oldstable.html refers it as being accepted nor does rmadison know about it (except in NEW): paul@mulciber ~ $ rmadison mariadb-10.5 mariadb-10.5 | 1:10.5.21-0+deb11u1 | oldstable | source mariadb-10.5 | 1:10.5.21-0+deb11u1 | oldstable-debug | source mariadb-10.5 | 1:10.5.23-0+deb11u1 | oldstable-new | source I also can't find the mail you refer to in my Trash folder. Nor can I find an comments file in elbrus@coccia:/home/release/www/proposed-updates/bullseye_comments Can you share the mail you are talking about? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060367: release.debian.org: RFC: Transitions check for dupload?
Hi On 14-01-2024 18:46, Guillem Jover wrote: I think that would be great, I guess the message from the hook could give some very basic and generic guidance, and point to this page for more in-depth explanation of what to do, what else to check etc. But in any case an initial version sounds good, as that can always be tuned, or extended/improved later on. :) Initial version. Please consider the name too, moving now is easier than later: https://wiki.debian.org/Teams/ReleaseTeam/TransitionUploadHook Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060367: release.debian.org: RFC: Transitions check for dupload?
Hi, On 14-01-2024 17:43, Guillem Jover wrote: https://wiki.debian.org/Teams/ReleaseTeam/Transitions but it looks like that one is targeted more to maintainers that start or drive the transitions instead of someone that might upload a package which is part or affected by that transition? Indeed. I had the same idea when I replied earlier, but I think we'd need a new (wiki) page for this. If we happen to agree here, I'm fine with creating an initial version. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060367: release.debian.org: RFC: Transitions check for dupload?
Hi Guillem On 10-01-2024 02:23, Guillem Jover wrote: I've had for a while a new hook for dupload that adds a transitions check for Debian hosts, for sourceful uploads targeting unstable (to avoid disrupting buildd or porter uploads, or uninteresting suites). I've just finished polishing it, and the main lingering question I've had all along has been whether you think this would actually be useful and/or desired at all, see below. The hook is currently using https://release.debian.org/transitions/export/packages.yaml, and prompting in case that source package is part of any ongoing transition. Cool. I wondered also whether checking https://ftp-master.debian.org/transitions.yaml would be useful, but I'm not sure whether that is or has ever been used? It still works, but it's hardly used. I do have some vague ideas to use it again in the future, but that's not going to happen soon I guess. So I guess my questions would be whether you think this is helpful or useful at all? Yes, I do. If so, whether the criteria is adequate or it needs to be changed? Whether this should be a prompt, or maybe only an info or warning? And any other comment or suggestion you might have! I'm mostly wondering if the information shown is enough to help people. I'm actually surprised how many people don't know how transitions work. What is your opinion on the length of the text you could provide? Maybe a link to a wiki page with more info particularly for this case? Maybe Sebastian can comment on how often he sees interfering uploads to judge if it should be a warning or a prompt. If you make this only a warning, what are the options of the uploader, canceling? Paul PS: if you're happy with this, should we file wish list bugs against dput and dput-ng too? OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Ability to further support 32bit architectures
Hello Dimitri, On Thu, 2024-01-11 at 09:48 +, Dimitri John Ledkov wrote: > Separately, I wish we had cross-builders available, and cross-build > i386/armhf kernels from amd64/arm64 and thus having access to 64-bit > compiler. Helmut Grohne is actually working towards cross-builders and I think there is a chance we might see these in the foreseeable future. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Ability to further support 32bit architectures
Hi! On Thu, 2024-01-11 at 10:25 +0100, Bastian Blank wrote: > Linux 6.7 fails to build on at least i386 and armhf. Even it now > manages to make the compiler fail to allocate memory: > > cc1: out of memory allocating 135266296 bytes after a total of 235675648 > > bytes > > Right now both fail on the same driver, so a short team workaround would > be to disable it. But we need a long term fix, and quickly. The long term fix would be fixing this driver so a single compilation unit doesn't take several gigabytes of RAM. > As it is now, we will not be able to provide a kernel for maybe all > 32bit architectures for Trixie. I don't think that this would be a reasonable decision. We're preparing to switch 32-bit architectures over to time64_t. Disabling 32-bit kernel builds would make this whole work moot. FWIW, both m68k and powerpc are not affected by this bug, the powerpc build fails because of a packaging problem. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
Hi Simon On 06-01-2024 12:48, Simon McVittie wrote: On Sat, 06 Jan 2024 at 10:16:28 +0100, Paul Gevers wrote: If an explicit dependency on steam-libs:i386 would be valid, I'd be happy to use that, and remove the steam-libs-i386 binary package as redundant. We're not there yet, so please hold your horses. Although I tend to think we should allow this too for the use cases you describe. So unless it's really the intent of a (source) package or small (source) package set to be meant to be used in a multi architecture environment I think we should demand that dependencies are not be exclusively fulfilled by packages from another architecture (:any is OK, :$arch is not). So indeed, each should require manual review. While writing this that *could* mean that britney2 grows support for cross-architecture dependencies while still blocking them if not forced. packages being blocked for useful use cases (that we could hint through, but that britney2 would consider non-installable, so not protected from then on) and ... I think this bug report is one of only a couple over the years that requested anything on this front I specifically ment these sentences in the broader discussion we started having. This bug #1059929 involving gobject-introspection_1.78.1-9 is different from things like steam-installer and nss-mdns: Ack. I consider that just a bug in britney2: if apt, dpkg and dose3 allow this, so should britney2. My previous message was about the more generic case (including :$arch qualifiers instead of only :any (this bug being about :any on virtual packages)). in the steam-installer case I had to ask the release team (a while ago) to apply some force to work around a known limitation in britney2, but in the gobject-introspection case, my hope is that it can be resolved (possibly by a bug fix in britney2, or possibly by changing gobject-introspection) without forcing the installability check to be ignored. Absolutely. Thanks for being elaborate in your reply, it matches what I was thinking. (I wasn't aware of the other examples though). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
Hi, On 06-01-2024 08:21, Johannes Schauer Marin Rodrigues wrote: I think it's a bit more complicated than that. Currently, the tool creates 8624 package relationships. If I remember correctly, britney is unable to analyze cross-architecture relationships? At least by lack of implementation. But thinking about pure cross-architecture relations (I mean those that are *only* satisfied using multiple architectures) a bit, what is it that we'd want at the archive level? I guess there are exceptions we could accept like from src:steam-installer (which doesn't use :i386 or :amd64 at the moment if I'm correct) or src:wine (which only uses it in alternatives and IIUC could equally well use :any), but do we really want to allow pure cross-architecture relations in general? I don't think so. What kind of complexity would that add for architecture qualification and efforts to remove an architecture from the archive later on? (steam-installer if it were using architecture qualifiers now would probably be handled somewhat because it could be accepted once manually and then afterwards it's accepted by britney2 because the non-installability doesn't go up). In that case that number goes down to 2352. One could reduce that number even further and only check those cases where apt, dpkg and dose3 agree on a solution but that would then rather be a documentation of the status quo than a list of the intended ground truth. Maybe it would make sense to analyze the archive and only add those cases that currently exist as real package relationships? As far as I can tell (I checked testing/main/source, testing/main/(amd64|i386) and testing/contrib/(amd64|i386) for (:i386|:amd64)) there is no package that does this for Depends or Build-Depends (excluding alternatives in src:wine and src:build-essential). So I think we can reduce it to :any in Depends and :any and :native in Build-Depends. Not sure how far your number goes down then. What the tool never received since its inception was somebody to look over these cases and write down what the ground-truth actually is supposed to look like. For the britney tests you likely want some kind of ground-truth and I fear that tool can give you the status quo but not necessarily the truth as intended by the spec. Ack. If that is fine for you, do you still want to add thousands of test-cases? Or do you want to hand-pick them? It depends on the route we take and what we envision as useful cases to support. What I want to avoid is two things, highest prio first: 1) something that we don't want to migrate migrates (I think the current *lack* of support achieves that mostly already) albeit *maybe* my current fix for this bug is going to change that unintentionally in the wrong direction. 2) (lots of) packages being blocked for useful use cases (that we could hint through, but that britney2 would consider non-installable, so not protected from then on) I think this bug report is one of only a couple over the years that requested anything on this front (I think all were from Simon), so I wonder how many (legitimate) use cases there are that people would want to use and don't because of lack of support on our side. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
Control: tags -1 pending Hi, On 03-01-2024 20:40, Paul Gevers wrote: On 03-01-2024 20:22, Simon McVittie wrote: I think all of those are correct? I think that if apt allows you to install it, chances are that it's a britney2 bug. I'll try to debug it tomorrow. I have a first proposal for a fix in https://salsa.debian.org/release-team/britney2/-/merge_requests/89 Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Steve, On 05-01-2024 17:36, Rene Engelhard wrote: Also a problem is that experimental also might already contain totally unrelated updates like new upstream versions... I share this worry. Have you thought about how to handle the cases where you don't have experimental to upload to? How big is this problem? Another worry, how will you provide the required changes to the maintainers of the packages? Via BTS? For those working on salsa: MR? Both? Something else? Obviously we should not end in the situation that a new upload goes back to the old name (or are the ftp-masters so keen on this transition that that won't happen? But what about newer versions with the old name already in experimental, conform the former worry?). I've seen NMU's being ignored by subsequent uploads by the maintainer, even when they fixed RC issues which were then reintroduced. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
Hi, Thanks for reaching out. On 05-01-2024 07:45, Johannes Schauer Marin Rodrigues wrote: It would generate the following two stubs (shortened here for brevity): Package: pkga Version: 1 Architecture: amd64 Depends: pkgc:any Multi-Arch: no Package: pkgb Version: 1 Architecture: amd64 Provides: pkgc Multi-Arch: allowed For britney2, the Sources stanza would also be needed; then we could use this to generate britney2 testcases. I created 10 of those yesterday by hand [1]. The simplest for of tests is a tree with var/data/unstable/Sources # i386 is the default archive of the testsuite, which can be overruled # if that makes sense var/data/unstable/Packages_i386 var/data/testing/Sources (may be empty) var/data/testing/Packages_i386 expected expected is in Heidi format (if I understand correctly) of what britney2 will allow to be in testing after the run, it will only migrate packages that are installable. Would it make sense to you to generate a branch in that archive with a bunch of tests that you know the answer too? Paul [1] https://salsa.debian.org/debian/britney2-tests/-/commit/5ab98de685e15a654227e9b188a48e44857f9d11 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059898: unblock: steam-installer/1:1.0.0.78~ds-4
Hi Simon, On 03-01-2024 10:34, Simon McVittie wrote: In the HTML output, under "Additional info" (which if I understand correctly is meant to be for notes that do not affect migration), That's the idea, yes. it says: - Additional info: - uninstallable on arch amd64, not running autopkgtest there - uninstallable on arch i386, not running autopkgtest there I recently (some weeks/months ago) enhanced britney2 to take the results of the InstallabilityPolicy into account before scheduling autopkgtests, to prevent failures due to "can't install". By the looks of it, the passing of data goes wrong, because I wouldn't expect this autopkgtest info *without* a negative verdict from the InstallabilityPolicy. Obviously it's not the task of the AutopkgtestPolicy to prevent migration due to non-installability. but in the YAML output, I see that actually this might be the reason why it isn't migrating: autopkgtest: verdict: REJECTED_TEMPORARILY ... reason: - autopkgtest I find this confusing, because steam-installer doesn't have any autopkgtest coverage at all. Well, the AutopkgtestPolicy also schedules tests for reverse dependencies and this check happens *before* britney even calculated those. The steam-installer:amd64 contrib binary package is uninstallable if you don't have an i386 foreign architecture added, because Valve's proprietary code has hard dependencies on both amd64 and i386 libraries. Hmm, interesting. Probably my new code doesn't deal with this possibility at all, while apparently the InstallabilityPolicy is smarter. Is this perhaps what the migration software is unhappy about? But I thought we could have uninstallable packages as long as they are not a regression? Well, I suspect this is in new code. It probably just doesn't support this corner case (because I wasn't aware of it and I might have made wrong assumptions). Similarly, the steam:i386 contrib binary package is uninstallable unless you are actually on an amd64 system. Ack. The other binary packages (in main) should be installable on their appropriate architectures with no special measures. The AutopkgtestPolicy looks at the joined installability of all binaries on an arch. Thanks for letting us know. I prefer to keep the status quo for a day such that I can debug this tomorrow. I hope to add a hint at the end of the day (if I don't forget, feel free to ping me if I do). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
Hi Simon, On 03-01-2024 20:22, Simon McVittie wrote: I think all of those are correct? I think that if apt allows you to install it, chances are that it's a britney2 bug. I'll try to debug it tomorrow. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Unblocking spring
HI, On 23-12-2023 23:09, Jonathan Wiltshire wrote: On Sat, Dec 23, 2023 at 04:01:39PM +0100, Markus Koschany wrote: I was told to contact you in order to unblock src:spring for testing. At the moment tracker.debian.org shows that: "spring-javaai/arm64 has unsatisfiable dependency". This is a bit confusing because spring builds only binary packages for arch all, i386 and amd64. I don't see any real issues that would prevent the migration to testing. Thanks in advance and happy holidays. spring-javaai is arch:all though, and depends on spring. And is only a problem on arm64 because we only ensure installability on amd64 and arm64 for arch:all packages (unless hinted). The full (relevant bit) of the migration excuse is: depends: arch_all_not_installable: - armel - armhf - ppc64el - s390x verdict: REJECTED_PERMANENTLY This is probably a red herring, as the problem is arm64 which isn't listed. This field is used in the DependsPolicy (IIRC) to communicate to the AutopkgtestPolicy that the tests should be run because the arch:all packages aren't installable (and that's allowed on those arches). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059226: release.debian.org: Help doris migrate to testing
Control: retitle -1 britney2 wrong installability block in autopkgtest Hi Bas, On 21-12-2023 14:06, Bas Couwenberg wrote: doris (5.0.3~beta+dfsg-17) is not migrating to testing, the excuses suggest this is due to superficial autopkgtests: https://qa.debian.org/excuses.php?package=doris No, I think the problem is: uninstallable on arch arm64, not running autopkgtest there which I think is a bug in britney2 as this isn't a regression and britney2 shouldn't block on it. I've hinted doris but I'll leave this bug open for us to fix the issue. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi On 18-12-2023 10:07, Andreas Tille wrote: https://tracker.debian.org/pkg/r-bioc-megadepth d/tests/control has Architecture: !s390x Why is it considered failing on s390x anyway? The log has this at the end: 127s run-unit-testSKIP Test declares architecture as not supported: s390x 127s run-unit-testSKIP Test declares architecture as not supported: s390x 127s pkg-r-autopkgtestFAIL non-zero exit status 1 pkg-r-autopkgtest comes from autodep8. You didn't tell autodep8 that you wanted s390x to be excluded also from that test. https://tracker.debian.org/pkg/r-bioc-scater While this is an Architecture:all package it Depends from r-bioc-densvis which exists only on amd64 and arm64 due to the Build-Depends: r-bioc-basiklisk. Thus tests on other architectures are failing since r-bioc-densvis is not installable. What solution do you suggest in this case? Well, mark the test as amd64 and arm64 only? Were this due to Depends (and thus the package not installable) the test would *automatically* not be scheduled if I'm correct, but it works differently for test dependencies. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1057755: Qt WebEngine Security Support In Stable
Hi Soren, On 14-12-2023 08:45, Soren Stoutner wrote: How do you recommend we change that? I think you're having the right discussion. I'm not a Stable Release Manager so I don't feel authoritative about stable. However, in my *personal* opinion and reflected in a proposal [1] I'm driving (about changes during the freeze, so targeting unstable and testing), we could be accepting more new upstream release *if* upstream release processes and criteria align with our stability criteria. In nearly all cases I expect that to mean a stable branch with strict documented rules and QA processes to guard quality. Paul [1] https://salsa.debian.org/elbrus/memos/-/blob/main/vetted-upstream-stable-versions.md OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1057755: Qt WebEngine Security Support In Stable
Hi Soren, On 14-12-2023 04:49, Soren Stoutner wrote: Currently there is no real security support for Qt WebEngine in stable, which is an oversight that might surprise many Debian users. It's explicitly documented in the release notes: https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#limited-security-support so I wouldn't call it an oversight. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi, On 13-12-2023 17:08, Andreas Tille wrote: Not built on buildd: arch all binaries uploaded by tille, a new source-only upload is needed to allow migration I do not understand this line. What exact package needs a source-only upload? You uploaded binaries together with the source. Because this is an arch:all binary we can't binNMU in a meaningful way and we don't accept uploader built binaries in testing anymore. Currently the only way to solve this is by doing a source-only (so, no binaries) upload (of r-bioc-biocgenerics). Remember, all r-bioc-* packages need to migrate together, so all of your uploads need to be ready before r-bioc-biocgenerics can migrate. I checked only the first few "Migrates after" links from [1], and found at least these packages still show autopkgtest regressions [2][3][4][5][6]. Thank you for these links. Could you please explain how I can obtain these myself? Is there any page I could look at for some kind of summary? I read in Graham's message that he started at [1] and just clicked the links. I don't think there's a great web site yet ([tracker] comes close), except udd has all the information which can be queried and *all* excuses can be viewed too [excuses] (or processed [yaml]). [2] https://tracker.debian.org/pkg/r-bioc-beachmat This shows: autopkgtest for r-bioc-biocsingular/1.16.0+ds-1: amd64: Regression or new test... but that version of r-bioc-biocsingular is in testing and bound to fail. Version 1.18.0+ds matches to BioC API 3.18. I wonder if it might be that britney2 doesn't notice that if it needs to take r-bioc-biocgenerics from unstable to run a test, that r-api-bioc-3.17 is no longer provided and hence also the test needs to come from unstable. Obviously there's room for improvement there, but the amount of code to determine the set of pinned packages from unstable is already rather long. [britney2] I admit I have no idea what to do. If the migration issues are caused by running tests against versions in testing which can't pass something is broken. They *should* be scheduled with the test from unstable, as the binaries depend on r-api-bioc-3.17 which will no longer be available when r-bioc-biocgenerics is used from unstable. Please let me know if I can do something to fix the situation, but for the moment I have no idea what to do. Patches for britney2 please ;). I'll try to do some manual triggering of tests tonight/tomorrow, but after a quick glance, that might be too much to handle manually. Paul [1] https://tracker.debian.org/pkg/r-bioc-biocgenerics [tracker] https://tracker.debian.org/teams/r-pkg-team/ the piece below Packages with test failures: if it goes from passing in testing to fail in unstable there is potentially a problem [excuses] https://release.debian.org/britney/update_excuses.html [yaml] https://release.debian.org/britney/excuses.yaml.gz [britney2] https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/autopkgtest.py#L622 until line 743 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: maintainer built binary package in stable release, still (Re: Bug#1054401: bookworm-pu: package nagios-plugins-contrib/42.20230308+deb12u1)
Hi, On 07-12-2023 12:20, Adrian Bunk wrote: On Thu, Dec 07, 2023 at 11:18:42AM +0100, Paul Gevers wrote: I hope that in several hours, https://release.debian.org/britney/excuses_s-p-u.html will have the answer. it should find packages like jtreg6 that are scheduled for the next point release, but it won't find packages like gmp that went into bullseye 2 years ago. Ack. Indeed it spots: cacti, fastdds, freetype, grub-efi-amd64-signed, grub-efi-arm64-signed, grub-efi-ia32-signed, jtreg6, llvm-toolchain-16, node-babel7, node-browserify-sign and slurm-wlm. A bunch of them have arch:all binaries. Stopping further regression on this is good, but for the ~ February point releases we have to discuss whether binNMUs+NMUs for packages that slipped through in the past should be done for bookworm (and bullseye). I would agree with this, but I'm not an SRM. A bunch of these are security uploads. We need to discuss this with the security team too (in CC now). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: maintainer built binary package in stable release, still (Re: Bug#1054401: bookworm-pu: package nagios-plugins-contrib/42.20230308+deb12u1)
Hi, On 07-12-2023 10:48, Adrian Bunk wrote: unfortunately not, I noticed nagios-plugins-contrib on the buildds and checked a few of the results after looking for "amd64" and "all" in the subjects of recent months at [1]. I hope that in several hours, https://release.debian.org/britney/excuses_s-p-u.html will have the answer. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: maintainer built binary package in stable release, still (Re: Bug#1054401: bookworm-pu: package nagios-plugins-contrib/42.20230308+deb12u1)
Hi, On 04-12-2023 18:59, Holger Levsen wrote: There are other packages with the same issue in bookworm, but these either involve binary-all packages and/or were in previous point releases. do you have a list of these? or better yet, a command to assemble that list? It might be useful if SRM tooling catches this issue, similar to what britney does for testing. absolutly. The britney2 runner for pu (that triggers the autopkgtest runs and exposes the results) could be taught to also do that check and expose it in the excuses. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi, On 03-12-2023 11:46, Graham Inggs wrote: This seems to be due to the restructuring of src:pandoc [1]. src:haskell-pandoc [2] recently cleared NEW into unstable, and the updated src:pandoc has not been uploaded yet. This is probably a good example for why new packages should be uploaded to experimental first, instead of directly to unstable. And it also means that r-bioc-biocgenerics is now blocked on the haskell transition. Lovely. Good thing that pandoc is supposed to be the last piece in that several months long transition. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#622947: per-maintainer insights into migrations and transitions
Control: reopen 622947 Control: reassign 622947 tracker.debian.org Hi pabs, On 01-12-2023 04:10, Paul Wise wrote: On Thu, 2023-11-30 at 14:14 +0100, Paul Gevers wrote: The tracker has been doing this for years now. distro-tracker doesn't have per-maintainer pages at all But it could and I think it's the right place. Similar to how it does that for teams: https://tracker.debian.org/teams/debian-accessibility/ I agree that transitions are missing in that overview. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
