Bug#1072813: release.debian.org: Help doris migrate to testing

[Paul Gevers]

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

[Paul Gevers]

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

[Paul Gevers]

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

[Paul Gevers]

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

[Paul Gevers]

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/???

[Paul Gevers]

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/???

[Paul Gevers]

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/???

[Paul Gevers]

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: R 4.4.0 coming April 24

[Paul Gevers]

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=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

[Paul Gevers]

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: grub 2.12-2 and 2.12-2~deb13u1 unstable/testing security updates [CVE-2024-2312]

[Paul Gevers]

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

[Paul Gevers]

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

[Paul Gevers]

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?

[Paul Gevers]

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

[Paul Gevers]

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

[Paul Gevers]

/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

[Paul Gevers]

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

[Paul Gevers]

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

[Paul Gevers]

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

[Paul Gevers]

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)

[Paul Gevers]

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?

[Paul Gevers]

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?

[Paul Gevers]

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?

[Paul Gevers]

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

Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency

[Paul Gevers]

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

[Paul Gevers]

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

[Paul Gevers]

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

[Paul Gevers]

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

[Paul Gevers]

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

[Paul Gevers]

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

[Paul Gevers]

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

[Paul Gevers]

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

[Paul Gevers]

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))

[Paul Gevers]

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

[Paul Gevers]

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

[Paul Gevers]

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))

[Paul Gevers]

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)

[Paul Gevers]

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)

[Paul Gevers]

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)

[Paul Gevers]

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)

[Paul Gevers]

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

[Paul Gevers]

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

Bug#636342: release.debian.org: provide a dd-list in the transition tracker

[Paul Gevers]

Control: reassign -1 ben

Hi,

On Tue, 02 Aug 2011 13:54:23 +0200 Yves-Alexis Perez  
wrote:

Package: release.debian.org
Severity: wishlist



looking at the libnotify transition, I can see that I'm involved in
quite some packages, but as there are a lot of packages in total, it can
be easy to miss one. I thought it could be nice to have a dd-list (or
similar) of the relevant packaqes, so one could quickly see if he needs
to take action or not. Usually there are transition bugs against
packages when the maintainer needs to do something. But for the cases
where the maintainer has to refrain himself to upload something, having an
idea of who's concerned can be useful.


The binary that provides our transition tracker is ben, reassigning.


Another idea would be to send mail to maintainers when transition is set
up in the tracker.


Hmm, most trackers are (auto) set up months before the transition starts.


I'm not sure if it's hard or not and if it's really worth the work, but
I was asked to report it more formally than on #debian-release so here
we are :)


At the time, ben didn't even exist (at least not in the archive) ...

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#796476: ftp.debian.org: valid-until for stable

[Paul Gevers]

Hi,

On Thu, 19 May 2016 10:03:49 +0200 Julien Cristau  
wrote:

On Sat, Aug 22, 2015 at 01:28:22 +0200, Raphael Geissert wrote:
> Nowadays the Release files for the *stable releases do not have a
> Valid-Until field.
> >From a security POV, this could allow a replay attack to be performed
> on the main stable repositories, which could prevent a user from
> getting some security updates.
> 
> Would it be possible to have such a valid-until field with a duration

> of, say, four months?
> Given the trend of doing point updates every few months, the date
> could be renewed only at point release time.



I think it would have to be 6 months, at which point I don't see that it
buys you much in the way of security, and it breaks archive.debian.org
further.  So I'm not wild about that idea.


So, shall be close (wontfix) this bug report? Or have insights changed 
in those 7 years in between?


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054657: Transition issue for r-cran-rstanarm (Was: Bug#1055922: rmatrix: ABI change in Matrix 1.6-2)

[Paul Gevers]

Hi,

On 28-11-2023 10:10, Andreas Tille wrote:

I have no idea why r-cran-seurat is not profiting from reduced waiting
time for the transition.


Because its tests fail on armel. The reduction of waiting time is only 
for tests that run successfully on all architectures where they are 
triggered (as in, where at least some of the binaries build by the 
source are installable). As the failure isn't a regression, the 
migration isn't blocked, though.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055600: transition: suitesparse-7.3

[Paul Gevers]

Hi,

On 26-11-2023 18:20, Sébastien Villemot wrote:

The only remaining issue is an autopkgtest failure of octave in
testing, reported as #1056392.

I’ve argued there that this issue only affects partial upgrades, and
that I’m not sure how to fix it (if fixing is needed at all). Please
advise.


Although I'm not 100% sure, I think that cases like this are 
imperfections in our upgrade system. I believe that we started to care 
much more about partial upgrades since we started using autopkgtest, but 
I don't think we have the means (apart for always tightening relations 
and giving up much of the flexibility we so much appreciate) to fix skew 
in a mechanical way (particularly in transitions and our use of 
binNMUs), hence I think it's OK to occasionally let this happen currently.


I have rescheduled the failing tests with octave from unstable, which 
should automatically resolve the migration blocker. (There are several 
conditions where britney2 already does this trick automatically and 
where potential broken partial upgrades are not prevented either, so 
this is matching status quo).


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054657: transition: r-bioc-biocgenerics

[Paul Gevers]

Hi Andreas,

On Wed, 22 Nov 2023 20:46:17 +0100 Andreas Tille  wrote:

Control: tags -1 - moreinfo

r-bioc-sparsearray is accepted in unstable.


Well, Graham wrote "remove the 'moreinfo' tag once SparseArray has 
cleared NEW, and rmatrix has migrated."

 ^^^
Note the "and".

We're currently handling that, but rmatrix was blocked by r-cran-seurat, 
which, IIUC, is in that state because you updated r-cran-seuratobject 
three weeks ago.


We're still waiting for the migration of rmatrix to succeed.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055891: transition: gdal

[Paul Gevers]

Hi Bas,

On 22-11-2023 14:59, Sebastiaan Couwenberg wrote:

On 11/22/23 14:47, Paul Gevers wrote:
To prevent that manual labor, I can drop the autopkgtest from 
libgdal-grass as it just hinders testing migration.


That's not a solution to the problem I'm trying to address, that will 
just hide it again.


The version mismatches it detects (like #1006446) are less likely since 
grass got fixed (in 8.2.0-3).


Good.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055891: transition: gdal

[Paul Gevers]

Hi,

On 20-11-2023 12:54, Adrian Bunk wrote:

It is a case where a binary tries to load the new soversion of the
library and plugins for the old soversion of the library.


And, do we (as project) already have established processes where this is 
expressed correctly in package dependencies? Can that be done 
automatically (for packages that are likely to need it)?


I mean, in the ideal situation, this class of issues is prevented by 
proper package relations, but I also want to avoid manual labor that's a 
PITA to maintain and prone to wrong in the future.


Paul
PS: I'll schedule the tests shortly


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055891: transition: gdal

[Paul Gevers]

Hi,

On 19-11-2023 09:06, Sebastiaan Couwenberg wrote:

britney only schedules:

  gdal/3.8.0+dfsg-1
  src:gdal from unstable

Likely because there is no new version for the libgdal-grass source 
package, only a binNMU.


Well, because there's no relation that tells britney this combination is 
no good.


libgdal-grass (1:1.0.2-6+b1) has these dependencies to reflect the tight 
coupling:


  grass831 (provided by grass-core)
  libgdal34 (>= 3.8.0)


It *might* [1] be missing the upper limit (or some binary of gdal 
missing a breaks relation)? In other words, yes, libgdal-grass from 
unstable will pull in the right (current) version, but libgdal-grass (or 
other binary from libgdal-grass) in testing doesn't know it's broken 
with the version of src:gdal from unstable.


grass-core in testing depends on the old libgdal33, hence the need to 
also get grass and libgdal-grass from unstable when running autopkgtest 
with gdal from unstable.


Why? (In other words, what breaks exactly?) Is this a case where some 
binaries load the old library and others load the new one leading to 
symbol clashes?


Paul
[1] and maybe not, the autopkgtest, binNMU and transitions situation 
isn't britney's strongest side


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055891: transition: gdal

[Paul Gevers]

Hi

On 19-11-2023 07:32, Sebastiaan Couwenberg wrote:
For the libgdal-grass autopkgtest to pass it needs to pull gdal, grass, 
and libgdal-grass from unstable due to the tight coupling.


If it doesn't happen automatically and there is a tight coupling, where 
is the tight coupling missing in the package relations?


Paul
PS: I didn't check the situation, merely commented on the words in the 
e-mail that confused me.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug#1053686: pandoc: cannot fulfill the build dependencies

[Paul Gevers]

Hi,

On Thu, 12 Oct 2023 06:36:05 +0200 Jonas Smedegaard  wrote:

Quoting Scott Talbert (2023-10-12 02:33:45)
> It looks like pandoc can be updated to v3.0.1 and be compatible with the 
> dependencies that are in unstable currently (LTS 21).  Can you please let 
> us know if there are any dependencies still missing?



I will look at it soon - probably this upcoming weekend.


Is there any progress with fixing this bug? It seems that this issue is 
one of the last blocking issues in the haskell transition. src:pandoc is 
a key package, we can't easily remove it from testing to "fix" the blockage.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054657: transition: r-bioc-biocgenerics

[Paul Gevers]

Hi,

On 10-11-2023 11:56, Andreas Tille wrote:

The only new dependency we need is SparseArray.  However, we cannot
upload the package to new since it needs r-bioc-s4arrays (>= 1.1.6) for
building it.  In other words: We need to start the transition before we
can package SparseArray.


You're totally free use experimental for that to get SparseArray through 
NEW. I assume you don't need 100% of the transition, but only a 
(hopefully tiny) bit. So you could upload the newer version of 
r-bioc-biocgenerics and reverse depending packages up to where you need 
it to build SparseArray.


Alternatively, you can send packages to NEW that you build with locally 
newer versions (however you create them). Once accepted, the buildds 
will only build the non-uploaded archs once the right version becomes 
available. In other words, uploads to NEW don't require all their build 
dependencies already (at the right version) in Debian. We need to 
rebuild that package anyways to make it eligible for migration, so an 
(maybe from your perspective) early upload is not more waste of time 
with the current archive settings, but of course the preparation in 
experimental is a bit more work from your side. However, that's what we 
request in nearly all transitions: prepare as much as possible *before* 
we actually start the transition.


On 09-11-2023 14:59, Charles Plessy wrote:

But if this is important for you we can
surely write ack messages faster.
I'm convinced it would help. Having said that, that doesn't need to be 
long proza, mostly a sign "we're on top of this and that". (Which 
doesn't mean you have to work 24/7 to fix it, of course you are also a 
volunteer). When we know what's on your radar, we can also more 
effectively point at potential gaps that we may spot.



This is what I feel when I see the new request from your team coming
at the last minute and not as a debriefing of the previous
transition.
I'm sorry to hear that it felt like a new request. I think for us it 
felt more like "lets treat this more like we do other transitions". And 
yes, maybe we should do debriefings once in a while, but we are not 
accustomed to do that and I believe that in the cases that would benefit 
most from a debriefing those involved rather want to move on.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054657: transition: r-bioc-biocgenerics

[Paul Gevers]

Hi Andreas,

On 07-11-2023 18:01, Andreas Tille wrote:

You did not yet answered the question I asked twice whether we can find
a compromise by simply removing packages with missing new dependencies
from testing.  I consider this a compromise which I would really love to
discuss honestly.


I'll try to give at least one answer to this question and also add some 
other remarks after that.


The first and foremost reason why we're not enthusiastic about 
defaulting to removal of packages from testing is that that's a 
disservice to our users of testing. Yes, we (auto)remove packages from 
testing, but we mostly do that to remove RC buggy packages that aren't 
fixed in time. Removal out of the blue is rare. For the current 
transition, if we remove packages from testing because they are not 
ready and the transition migrates, these removed packages will suddenly 
cause systems where any of these packages is installed to hold back a 
lot of related packages and the user will have to figure out which one 
is causing the situation, why and how to solve it for their personal 
situation. (Were we to remove packages in other situations, still 
installed packages may suddenly fail to run without a proper bug report 
explaining the situation. In this case that's prevented by the 
r-api-bioc relation.)


Apart from the reasons already mentioned by Sebastian, another reason 
why at least I am not looking forward to an r-bioc-biocgenerics 
transition is that I have the *feeling* (which might be unjust, but then 
consider past interactions) that we often need to tell you about issues 
and how to solve them. If the r-bioc team were to actively monitor the 
situation and respond to failures and other problems (you might be 
already doing this, it might just be a visibility problem) then it would 
be easier on us even if a transition last a bit. As Sebastian said, for 
most other transitions the period that requires quite some attention 
from us is shorter, which means less pushing and popping from stack, and 
thus a lower mental load. We're doing quite a lot of transitions, longer 
lasting ones are never nice.


Several other ecosystems, e.g. perl, python and ruby, do preparation 
outside of the Debian archive and often have some idea (or know quite 
well) of what to expect during the transition. It's that pro-activeness 
that makes a difference to us; it *sounds* much better than "let's start 
and find out how much work it is". Maybe it's just the tone, but we're 
all humans.


I realize that the current tools and way of working in the r-bioc 
ecosystem isn't yet geared towards our ideal mode of operation. If you 
could try and work towards that, that would be appreciated.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: rust-grep-regex REMOVED from testing

[Paul Gevers]

Hi,

On 07-11-2023 16:54, Peter Green wrote:

  Previous version: 0.1.11-1
  Current version:  (not in testing)
  Hint: 
    # 2023-11-04
    # blocks lots of packages from migrating
    # 1053431


Assuming your goal was to allow rust-regex and friends to
migrate to testing, you will also want to set removal
hints for rust-matchers and rust-loom.


Thanks, that was indeed my intent. But after several iterations (and dak 
not being able to help me find the set) I gave up at it looked like it 
would be solved around 16 November 2023. So, this message was useful.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug#1054898: piuparts.d.o: overhaul merged-/usr configuration to match the majority of installed systems

[Paul Gevers]

Hi,

On 28-10-2023 17:10, Nicolas Dandrimont wrote:

In short, I think we've made a mistake by having piuparts use unmerged-/usr
chroots during the bookworm development cycle, and I'd like to fix that now.


Well, if I recall correctly one of the worries during the bookworm 
development cycle was a class of bugs that would break on 
un-merged-/usr, but not on merged-/usr. Hence, we *choose* to have 
piuparts test with the former. I don't think *yet* that that was a mistake.



As far as I can tell, to guard testing migration, the release team is
comparing the results of piuparts running on the package in trixie, with
the results of piuparts running on the package in sid. I'm not sure that
upgrades (that is, testing2sid) are involved, so, as long as the chroots
are consistent between the trixie tests and the sid tests, these exports
should keep making sense for the release team.


Indeed, britney2 only looks at the pure sid and pure testing results.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Lots of buggy packages propagated to trixie today (?)

[Paul Gevers]

Hi,

On 22-10-2023 21:57, Adam D. Barratt wrote:

On Sun, 2023-10-22 at 21:12 +0200, Paul Gevers wrote:

Hi,

On 22-10-2023 15:58, Sebastian Ramacher wrote:

Adding owner to the loop: Don, any idea what caused the RC bugs
export
to miss all the non-pseudo package RC bugs? Would it be possible to
fail
the export in such a case instead of providing partial RC bug data?


2023-10-10

[20:28:26]  why, o why did this migrate to testing despite an
RC
bug https://tracker.debian.org/pkg/libcleri
[20:28:39]  I know the package and the bug
[20:29:03]  seems like britney got confused yesterday
[20:29:55]  same for gitaly

It seems to have occurred more than once. So yes, we need a stronger
guard against this.



FWIW I'm not spotting any obviously wrongly-sized bugscan files around
then, looking on buxtehude.


Right, all files on 2023-10-09 and 2023-10-10 mention #1020507, so 
*that* case wasn't caused by loss of info on the bts side. I'll check 
later if the bts misrepresented the bug before britney migrated the 
package, but it's bed time now.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Lots of buggy packages propagated to trixie today (?)

[Paul Gevers]

Hi,

On 22-10-2023 15:58, Sebastian Ramacher wrote:

Adding owner to the loop: Don, any idea what caused the RC bugs export
to miss all the non-pseudo package RC bugs? Would it be possible to fail
the export in such a case instead of providing partial RC bug data?


2023-10-10

[20:28:26]  why, o why did this migrate to testing despite an RC 
bug https://tracker.debian.org/pkg/libcleri

[20:28:39]  I know the package and the bug
[20:29:03]  seems like britney got confused yesterday
[20:29:55]  same for gitaly

It seems to have occurred more than once. So yes, we need a stronger 
guard against this.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

status of ghc / haskell transition

[Paul Gevers]

Dear Haskell maintainers,

Since August 26, ghc has a version in unstable that triggered a haskell 
transition [1] and that hasn't been able to migrate to testing [2].


From a bystander view as a Release Manager, the situation looks a bit 
stalled. So I'd like to know if there is any progress and/or if there 
are plans to unlock the current situation. Can you enlighten us, what's 
the plan?


Do you need help from us?

Paul

[1] https://release.debian.org/transitions/html/haskell.html
[2] https://qa.debian.org/excuses.php?package=ghc


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: severity of bugs that FTBFS because of missing B-D

[Paul Gevers]

Hi josch,

[Talking mostly as a fellow DD, just a tiny bit with Release Team member 
hat on].


On 11-10-2023 13:31, Johannes Schauer Marin Rodrigues wrote:

There exist RC
bugs that the release team deems RC even though they do not directly violate
policy and vice-versa.


I would hope that this is only one direction. Policy describes practice 
and is always (by definition) behind. So, unless the policy needs 
updating for something that we (as a project) learned to accept, I would 
hope that all policy violations are RC by default. Indeed, the Release 
Team is delegated to make non-policy violations RC bugs. The RT *tries* 
to state them in the rc_policy [1], where non-policy issues are marked 
with "Ref: RT".



I'm going this route because *if* those bugs get classified as RC by the
release team, then there are different mechanisms available to fix them, like
NMUs in case the maintainer is unresponsive.


I claim that a bug doesn't need to be RC to be acceptable for NMU 
fixing. The dev ref has a chapter on it [2], nowhere it says that bugs 
have to be RC. It even suggests how to use the DELAYED queue for non-RC 
bugs.



The patch for each of these bugs
is very minimal, so fixing them is usually as simple as adding the missing B-D.


I'd say, prepare NMU's for all of them, let the bug report know you've 
done so and upload to DELAYED 10.



I am aware that this annoys people. I do not like to annoy people. But this is
a problem that annoys me (and others). So right now we are in a situation where
there are two ways forward: doing nothing and changing things. For each of
these two ways there are people in favour of it and people against it. So
independent of what the outcome is, *somebody* will be annoyed. Who is there to
choose who should be the one annoyed in the end? Quite evidently there is no
way out of this that annoys nobody. What would you do?


My *expectation* is that if you follow the NMU process as outlined in 
the dev ref, you'll not receive as much friction as you would get with 
(even approved) severity serious bugs.


Paul

[1] https://release.debian.org/testing/rc_policy.txt
[2] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-and-how-to-do-an-nmu


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: signing and releasing grub2 testing-proposed-updates

[Paul Gevers]

Hi,

On 11-10-2023 13:19, Julian Andres Klode wrote:

I think grub2 has migrated now either way, so the grub-efi-* ones can
migrate?


To be safe, I only added the hint for grub yesterday evening. I've 
hinted grub-efi-* now.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: signing and releasing grub2 testing-proposed-updates

[Paul Gevers]

Hi,

On 10-10-2023 21:00, Julian Andres Klode wrote:

That's bug #983912 and I can't tell you what to do, but yes, generally
grub2 should go before grub-efi-*.


During the migration run, would it just not accept grub-efi-* in the 
first run and would it accept it in the next run when grub2 has already 
migrated? In other words, can I add the unblock already or does the 
reject mean something more severe than I would expect?


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: signing and releasing grub2 testing-proposed-updates

[Paul Gevers]

Hi,

On 10-10-2023 18:59, Julian Andres Klode wrote:

It seems the binaries built but I guess someone needs to poke the
signing bits and once they are built they can all be released 


I was hoping to compare the package in tpu to the version in pu, but 
apparently that version is still stuck in stable-new and not available 
to me on respighi.



(
grub2 needs to go before grub-efi-* here too I suppose, due to a
dak limitation in built-using queue handling).


Please elaborate. If we hint it through it the same britney migration 
run, do things fail? Or do you mean grub-efi-* shouldn't go *before* grub2?


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053641: transition: libavif

[Paul Gevers]

Hi Mathieu,

On 08-10-2023 09:46, Mathieu Malaterre wrote:

(3) Wait till a sane jpeg-xl 0.8 upload (with transition) is ready, and entangle
jpeg-xl transition with libavif transition.


#1051131 has been fixed yesterday. I'll go ahead and do the 0.8 upload
this week.


Please wait with that until Sebastian approves. We normally don't want 
transitions to be entangled. An upload to experimental is fine of course 
to clear the NEW queue.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052357: RM: openbox-menu/0.8.0+hg20161009-3.1

[Paul Gevers]

Control: reassign -1 ftp.debian.org

On 20-09-2023 21:55, Mateusz Łukasik wrote:

Package: release.debian.org
Dear release team, I would like to request the removal of the openbox-menu
package (which I maintain) from repository.


This is handled by the ftp masters, hence reassigning. (We only handle 
testing, stable and oldstable).


This solution stopped being developed in 2016, temporarily came back to 
life in 2021, but the code was available in a different place as before. 
Repositoryhas currently been archived by the developer. The biggest 
problem is based on gtk2, see #967668, the package has already been 
removed from testing (see #1029201).


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug#1050256: autopkgtest fails on debci

[Paul Gevers]

Hi all,

On 09-09-2023 13:06, Paul Gevers wrote:
All ci.d.n workers (except riscv64) now run the kernel from 
bookworm-backports. systemd passes it's autopkgtest again in unstable, 
testing and stable.


We're having issues [1] with the (backports and) unstable kernel on our 
main amd64 host, so we reverted back to the stable kernel for amd64.


Paul

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052130


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug#1050256: autopkgtest fails on debci

[Paul Gevers]

Hi,

On 03-09-2023 10:50, Paul Gevers wrote:
I have manually upgraded the s390x host and 
rebooted, so that can serve as a test arch.


All ci.d.n workers (except riscv64) now run the kernel from 
bookworm-backports. systemd passes it's autopkgtest again in unstable, 
testing and stable.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Release Team concern about mips64el buildd status

[Paul Gevers]

Dear mips64el porters,

Recently it came to the attention [1, 2] of the release team that some
buildds for mips64el are still running Debian buster and the others
still bullseye with issues preventing upgrade to bookworm. In our
judgement this is unacceptable and would we have been aware of this at
the beginning of this year, it would most likely have prevented
mips*el being a supported release architecture in bookworm. DSA
already requires support in stable, and we'll be discussing adding
this to the Release Team's requirements too.

Please work together with DSA to improve the situation. Without decent
progress, mips64el will not be part of the next Debian release
(trixie).

On behalf of the Release Team,
Paul

[1] https://lists.debian.org/debian-release/2023/08/msg00516.html
[2] https://lists.debian.org/debian-mips/2023/07/msg00052.html
[3] https://dsa.debian.org/ports/hardware-requirements/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Releasing linux/6.1.52-1 bookworm-security update without armel build, Image size problems

[Paul Gevers]

Hi Salvatore,

On 09-09-2023 10:15, Salvatore Bonaccorso wrote:

but should have been support for armel been
dropped earlier and should we do it for trixie


The kernel for armel went over some hardware limits before (I was 
affected with my NAS, where I couldn't upgrade the kernel to bullseye as 
documented in the release notes [1]). Is the current situation reaching 
the limit for all armel devices, or "just" for some and are the others 
probably fine for some years to come?


If we're now reaching the final limit and if it was foreseeable that we 
would reach that limit, then yes it would have made sense to drop armel 
*before* the bookworm release, but alas. If the kernel team can't 
support the kernel on armel, than armel shouldn't be a release 
architecture for trixie. If it's only some devices, than we "just" need 
to communicate that clearly.


I don't have a clear advice for the current situation in security and 
the next point release, let's hope you can stretch the situation a bit 
longer. I recall that the kernel package has safety checks in place and 
refuses to *try* to install the kernel if it doesn't fit on the 
hardware. That means that you don't cripple the hardware of affected 
people, but "merely" can't give them security support? I guess it would 
be possible (as long as support lasts; no LTS support) for effected 
systems to run the security supported bullseye kernel.


Paul

[1] 
https://www.debian.org/releases/bullseye/armel/release-notes/ch-information.en.html#no-longer-supported-hardware


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

[Paul Gevers]

Hi Helmut,

On 04/09/2023 22.33, Helmut Grohne wrote:

If you
disagree with this and do not want to get involved, please just close
this transition request.


Given the impact (size) of this transition, I'd like to also see Graham, 
Cyril (for d-i) and Sebastian acknowledge this request.


I agree with it.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug#1050256: autopkgtest fails on debci

[Paul Gevers]

Hi,

On 03-09-2023 02:56, Michael Biebl wrote:
My main concern is to "stop the bleeding" quickly, so to speak, 
especially/mainly for debci.


I agree with you, but also consider that with this issue being there 
since ~ April 2023 we don't need to rush.



I guess we have three options here:
a/ upgrade the kernels to the one from backports as suggested by Antonio
b/ disable apparmor confinement for lxc on debci via some debci specific 
configuration
c/ disable apparmor confinement for lxc in bookworm via a stable upload 
of the lxc package


That said, I would be fine with a/ and b/ as well, as this would buy us 
time to investigate this issue without being under the pressure of 
causing debci failures.


What I fear a bit, is that if we do either of the three, Debian infra is 
not affected anymore which removes some incentive to find the root cause.


Those debci failures are hard to debug and I would like to avoid having 
individual maintainers waste time on it.


a, b, or c means that Debian maintainers don't need to dive into it 
anymore, but who knows which downstream project (volunteers or paid 
alike) will need to look into the problem in the future if we don't fix 
it inside packaging?


Do the debci maintainers  / lxc maintainers / release team have any 
preference regarding a/, b/ and c/ ?


One part of me likes the ci.d.n infrastructure to run stable as an 
example of "eat your own dogfood". Another part of me agrees with 
Antonio that it makes sense if it would run a backports kernel to be as 
close as possible to testing as we can reasonably (maintenance wise) can 
get. Because we have a known issue at hand, the balance goes to 
backports for me. If Antonio doesn't beat me to it, I'll get to it 
(although I don't know yet how to do that in our configuration [1] and 
exclude riscv64 too). I have manually upgraded the s390x host and 
rebooted, so that can serve as a test arch.


Paul

[1] https://salsa.debian.org/ci-team/debian-ci-config


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050974: binNMU: Rebuild against curl without NSS support

[Paul Gevers]

Hi,

On 01-09-2023 14:25, Samuel Henrique wrote:

These packages have a build dependency on the virtual package
"libcurl4-dev", which is satisfiable by any variant of the curl
binaries (openssl, gnutls, nss).


Policy 7.5 [1] says that "To specify which of a set of real packages 
should be the default to satisfy a particular dependency on a virtual 
package, list the real package as an alternative before the virtual 
one." It's best practice to specify which real package should be used to 
avoid apt choosing it on the buildd. We had variation because of 
temporary non-installability in the past (IIRC), it's better to wait 
with building.


I must admit I though the requirement was stronger and you *had to* 
specify a real package before a virtual build dependency.


Paul

[1] 
https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: How important are empty directories?

[Paul Gevers]

Hi Helmut,

On 24-08-2023 17:46, Helmut Grohne wrote:

In this mail,
I'm concerned with P6, i.e. loss of empty directories. 


[...]


This inconsistency is detected e.g. by
piuparts, which may fail. This is how Andreas Beckmann originally
discovered this problem class.


Ack.


As a result, I've started filing patches for this problem class.
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helmutg%40debian.org=dep17p6


Thanks.


In the majority of cases, such empty directories are more of a bug than
a feature and we can simply delete them. In some cases, they really are
used though.


Can you elaborate? My imagination might be limited, but all I could come 
up with is that maintainer scripts expect a directory to be there and 
try to write to it without checking (is that also the case for the issue 
that you referred to in [1] mentioned by Jochen?). I *think* that if a 
package needs the directory to installs a file into, the directory will 
be created (or will dpkg fail as it assumes the directory already exists)?



When they are used, we need to do something about that
deletion and I've submitted e.g.
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/208 where
I got negative feedback on the need to address this.


Which has been fixed nevertheless.

I agree that *only* pleasing piuparts is not the best time spent by 
maintainers, *if* that's really the only problem we're solving. I guess 
we're having a hard time with this check to find a real life problem. I 
*think* that https://bugs.debian.org/1050606 (linked from that MR) 
points at an example of this problem, right? So that's at least one.



So how important is it to have these empty directories? I concur with
Michael on the aspect that their loss rarely poses a practical issue. It
can make piuparts fail however and when it does, the failing package
tends to not be the one that is able to fix the failure. So in effect,
keeping these bugs would cause latent migration blockers. For this
reason, I was assuming the bug class to be release critical. Do you
concur?


If everybody agrees that the only place where this causes real life 
issues is piuparts, than I rather have piuparts ignore this problem. 
After we're fully canonized, are we safe again and could we turn the 
check on again? Looking at that example bug above though, I'm not sure 
we can only see this class of problems in piuparts.



If we want it to not be release critical, I think we'd have to augment
piuparts in a way that it ignores such directory loss.


Ack. Piuparts is a tool to detect problems. While technically correct, 
we can ignore classes of problems if that serves us better than fixing them.



On the flip side, systemd has been the last package for me to file a
patch where this issue has practical consequences already. All others
have been filed already. Beyond these, there are five more cases on the
horizon that likely need to be mitigated when we lift the moratorium.


With patches ready?


So while the mitigation is ugly, the low number of affected packages and
the temporary nature of the mitigation made me conclude that doing this
is a reasonable trade-off. Do you agree?

Another example for the ugliness is #1050412.


Will the next time that pkgconf-bin is installed (reinstall or upgrade) 
recreate the directory again (without your patch)? Or will the directory 
be lost forever?


I'm not totally sure you got the answer to the question you raised, but 
I'm also not totally sure what you wanted to hear.


Paul

[1] https://lists.debian.org/debian-devel/2023/05/msg00325.html (udev)


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050403: RM: flycheck/32~git.20200527.9c435db3-4

[Paul Gevers]

Control: tags -1 moreinfo

On 24-08-2023 08:37, Sean Whitton wrote:

flycheck is getting in the way of the Emacs 28->29 transition.  There is
#1050350 from the team.  Could the removal from testing be sped up, please?
I think it could go right now.  Thanks.


How about the dependencies?

Paul

elbrus@coccia:~$ dak rm --no-action -RB --suite testing flycheck
Will remove the following packages from testing:

elpa-flycheck | 32~git.20200527.9c435db3-4 | all
flycheck-doc | 32~git.20200527.9c435db3-4 | all

Maintainer: Debian Emacsen Team 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
emacs-lsp-ui: elpa-lsp-ui
flycheck-package: elpa-flycheck-package
rtags: elpa-flycheck-rtags

Dependency problem found.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050405: unblock: sbcl/2:2.3.7-2

[Paul Gevers]

Hi Sean,

On 24-08-2023 08:31, Sean Whitton wrote:

The only remaining issue britney shows is that its autopkgtest fails on
ppc64el.  It's a relatively harmless failure however, to my understanding.
Upstream do not seem interested in fixing it for the time being.


But why don't you disable the test on ppc64el than as maintainer? (Hint: 
the autopkgtest spec has an Architecture field that understands negated 
architectures).


Our RC policy says that we consider *regressed* autopkgtest RC on all 
release architectures (and ever failing autopkgtests on amd64 and arm64 
too) [1].


Paul

[1] https://release.debian.org/testing/rc_policy.txt section 6


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050223: RM: r-cran-rgdal/1.6-7+dfsg-1

[Paul Gevers]

Control: tags -1 moreinfo

Hi Andreas,

On 22-08-2023 12:08, Andreas Tille wrote:

as per upstream

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049438#31

rgdal will run out of upstream support soon.  Since the package created
failures with newer upstream versions of other packages (see bug
#1049438) it should be removed from testing.


Two questions/remarks:
1) why only testing, doesn't it make more sense to remove it from 
unstable (hint: reassign to ftp.debian.org) If you only need it from 
testing, reopening 1049438 is a reasonably fast way to achieve that.
2) as you mentioned in 1049438, the reverse (test) depends should be 
fixed first. Please remove the moreinfo tag once that has happened.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1040925: bookworm-pu: package ca-certificates-java/20230103+x

[Paul Gevers]

Hi Jonathan,

On 18-08-2023 18:48, Jonathan Wiltshire wrote:

I'm therefore inclined to make a stable update sooner than the point
release. How does this text sound?

| ca-certificates-java, a package to update the cacerts JKS keystore used
| for many java runtimes, may fail to install alongside OpenJDK because
| of a circular dependency. This is a regression in Debian 11 and 12.


The regression is that the problem seems to occur more frequently. I'm 
not convinced it's an actual regression as the circular dependency 
problem is known from *before* the bullseye release.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: src:utop: fails to migrate to testing for too long: blocked by ocaml-logs rebuild

[Paul Gevers]

Hi,

On 11-08-2023 08:34, Stéphane Glondu wrote:

On Thu, 10 Aug 2023 21:44:23 +0200 Paul Gevers  wrote:
One current blocker is xmlrpc-light, which I mistakenly uploaded with 
urgency low 2 days ago, which therefore should not migrate before 8 days 
from now.


It seems the connection is hidden. It would be nice if you could show 
how that works.


I am wondering: Couldn't the required age for xmlrpc-light be lowered? 
Or should I upload a new package with a higher urgency?


I have added an age hint and dropped required age to 5.

Paul

Re: Bug#1042978: Tests invalid package upgrades

[Paul Gevers]

Control: reassign -1 release.debian.org

Hi Ben,

On 03-08-2023 18:01, Ben Hutchings wrote:

ci.debian.net must therefore also test updating the binaries from all
these source packages together, not just those built from linux.


But ci.debian.net just does what it's been asked to do by the client, in 
this case britney. So, if anything it's britney2 that needs to be 
changed to support this. But, britney2 tries to deduce what needs to be 
tested together from the package relations. Normally, what you're seeing 
here is the result of a test where the signed packages haven't been 
build yet. britney retries tests after 24 hours and normally it retries 
with linux-signed-* in the list of pinned packages as you can see in the 
dkms history. The question that now arises is why it doesn't do that now.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

DSA for jupyter-core in oldstable triggers nbconvert autopkgtest

[Paul Gevers]

Hi nbconvert maintainers,

DSA 5422 [1] seems to be triggering an autopkgtest regression in 
nbconvert. Looking at the name of the test, this could be a serious 
problem for nbconvert users on oldstable. Can you please investigate and 
let us know if you need to fix nbconvert in the next point release update?


From the log [2]:
109s === FAILURES 
===
109s _ TestNbConvertApp.test_default_config 
_

109s
109s self = testMethod=test_default_config>

109s
109s def test_default_config(self):
109s """
109s Does the default config work?
109s """
109s with self.create_temp_cwd(['notebook*.ipynb', 
'jupyter_nbconvert_config.py']):

109s >   self.nbconvert('--log-level 0')
109s
109s 
/usr/lib/python3/dist-packages/nbconvert/tests/test_nbconvertapp.py:227:
109s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _

109s
109s self = testMethod=test_default_config>
109s parameters = ['--log-level', '0'], ignore_return_code = False, 
stdin = None

109s
109s def nbconvert(self, parameters, ignore_return_code=False, 
stdin=None):

109s """
109s Run nbconvert as a shell command, listening for both Errors and
109s non-zero return codes. Returns the tuple (stdout, stderr) of
109s output produced during the nbconvert run.
109s
109s Parameters
109s --
109s parameters : str, list(str)
109s List of parameters to pass to IPython.
109s ignore_return_code : optional bool (default False)
109s Throw an OSError if the return code
109s """
109s cmd = [sys.executable, '-m', 'nbconvert']
109s if sys.platform == 'win32':
109s if isinstance(parameters, string_types):
109s cmd = ' '.join(cmd) + ' ' + parameters
109s else:
109s cmd = ' '.join(cmd + parameters)
109s else:
109s if isinstance(parameters, string_types):
109s parameters = shlex.split(parameters)
109s cmd += parameters
109s p = Popen(cmd, stdout=PIPE, stderr=PIPE, stdin=PIPE)
109s stdout, stderr = p.communicate(input=stdin)
109s if not (p.returncode == 0 or ignore_return_code):
109s >   raise OSError(bytes_to_str(stderr))
109s E   OSError
109s
109s /usr/lib/python3/dist-packages/nbconvert/tests/base.py:162: OSError

Paul

[1] https://security-tracker.debian.org/tracker/DSA-5422
[2] 
https://ci.debian.net/data/autopkgtest/oldstable/amd64/n/nbconvert/36344377/log.gz


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)

[Paul Gevers]

Hi Andreas,

On 29-07-2023 21:52, Andreas Tille wrote:

IT can't be uploaded since the new version will not build due to the
missing dependencies that need to clear new.


As I understand it, you don't need to wait with *uploading*, the 
buildd's will just wait building until the build dependencies cleared 
NEW. So, just upload and forget about it (unless you're worried about 
"using" the version number already, but that was not your argument).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)

[Paul Gevers]

Hi Andreas,

On 29-07-2023 12:51, Andreas Tille wrote:

all r-bioc-* packages except

r-bioc-bitseq

which is not maintained upstream and should probably be removed (as in
the last transition) and

r-bioc-scater
r-bioc-deseq
r-bioc-isoformswitchanalyzer

are uploaded.  The latter three have new dependencies which are uploaded
to new.  Since all four exceptions are in sid only we could consider the
transition done and the majority of r-bioc-* packages can migrate to
testing.  We can wait for new processing for those three remaining
packages which does not really affect all other r-bioc-* packages.


Well, I didn't check everything yet (hint is at [1]) but at least the 
autopkgtest regression in r-bioc-rhdf5filters (see [2] to find that in 
unstable it fails too) should really be solved. For several of the other 
packages, you see that the right versioned (test) dependencies aren't 
declared, so the test pass in unstable, but fails to pull in the right 
dependencies when tested in the migration scenario. Also, but that's 
more my fault than yours, there are a bunch of packages in testing that 
fail their tests there because their *test* dependencies aren't in 
testing. Those should be pulled in by the migration scenario, but I hope 
none of the three packages mentioned above are needed for other tests, 
because then the tests will keep failing until NEW is cleared.


> If you agree it might make sense to not touch r-bioc-* packages to let
> the testing migration happen.

Well, any fix for triggered autopkgtest failure due to the lack of the 
right constraints (versioned (test) dependencies and/or breaks) might 
actually help speed up the process, because it will need less hand-holding.


Paul

PS: I'm not seeing the uploads of r-bioc-isoformswitchanalyzer and 
r-bioc-scater yet


[1] https://people.debian.org/~elbrus/ci/regressions.html (grey is only 
in unstable)

[2] https://ci.debian.net/packages/r/r-bioc-rhdf5filters/


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040498: transition: r-bioc-biocgenerics

[Paul Gevers]

Control: tags -1 confirmed

Hi Andreas,

On 06-07-2023 20:55, Andreas Tille wrote:

BioConductor has released version 3.17 when we were in Freeze.  Once we
have settled the r-base graphics API transition I would like to start the
BioConductor transition bumping r-api-bioc-3.16 to r-api-bioc-3.17.


Please go ahead.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Paul Gevers]

Hi,

On 12-07-2023 16:02, Dirk Eddelbuettel wrote:

I can add the Breaks as a 'best of the worse alternative'. And, I presume, I
can remove the existing four-year breaks? [1]


Yes, you only need to carry the Breaks until in the next release. So 
every Breaks that's present in the r-base package in bookworm can be 
removed from the r-base package in unstable.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Paul Gevers]

Hi Dirk,

On 11-07-2023 02:43, Dirk Eddelbuettel wrote:

I still have hopes that we can let technical excellence rule and not require
blunt instruments such as forced recompilation.


I'm totally on board for technical excellence, although I think we have 
different things in mind when we say that.


In Debian, with more QA than we ever had before, we're finding a class 
of issues that often went unnoticed years ago. One of these things is 
that partial upgrades can leave you in a bad state. So more and more we 
see that packages "have to" add Breaks to tell apt that when you want to 
upgrade package X, you also have to upgrade package Y if you happen to 
have that installed. As package Y can not tell that, package X has to 
add the Breaks on the broken version of Y. As an example, see the list 
of Breaks in libc6 [1]. While partial upgrades aren't officially 
supported, we rely on them nevertheless (even if only for QA (piuparts, 
autopkgtest)), and as a Release Team member I consider that class of 
fixes technical excellence: ensuring as best as we can that the user 
that upgrades a package keeps a working system.


While a rebuild of everything combined with bumping the "api" would 
achieve that, I'm much more in favor of targeted Breaks, like we have 
been discussing here. It's typically more work, but it's more correct.


For the future, with the recent change in dh-r, r-base will be much less 
impacted by this "problem" as the new uploads of reverse dependencies 
can migrate *before* r-base, and hence this class of issues will 
disappear once that happens (autopkgtest failures are retried after a 
day). So unless somebody investigates the issues in time, the retry will 
pass after the migration and the issue will no longer block r-base. I 
can live with that, but I find it a shame nevertheless.


So, what do you say: technical excellence and you add the Breaks? Or we 
let this slip in? I prefer the former, I can live with the latter.


Paul

[1] https://tracker.debian.org/media/packages/g/glibc/control-2.37-5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Paul Gevers]

Hi Dirk,

On 09-07-2023 21:09, Dirk Eddelbuettel wrote:

So this is where R 4.3.[01] will possibly break with some older packages.
But the fix is simple because when R 4.3.0 came out all packages at CRAN
complied. We need to have current packages that correspond to the R 4.3.0
standard.

(If one were super picky one could call this an ABI/API change and reason for
forcing _all_ packages to be rebuild. I never advocated for that but I am
getting tired of this process. But we need to throw that bomb at some point
just say 'fsck it' and rebuild _all_ packages. Feels like overkill but so is
wasting weeks on this.


Reading this a second time, I think your proposal is to acknowledge that 
r-base sometimes introduces unanticipated changes, and if we want to be 
on the safe side, we should rebuild everything when the minor version 
bumps. I guess that's more or less (I'm not sure how different r is in 
that respect) what other interpretation based languages like python, 
ruby, php and perl are doing too. r-base already has a "handle" for 
that: r-api-*. We *could* decide to just bump that on every minor bump 
of r-base and that would mean a transition every time that happens 
(mostly like those other languages except ruby, python and php also have 
a "defaults" package to explicitly switch from one version to the next), 
but at least our tools would help there. Apart from the potential 
overkill, the major (current) drawback is that for arch:all binaries, we 
still need source-full uploads as binNMU's don't work for them.


Is that what you are proposing? (For next time maybe?)

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Paul Gevers]

Hi,

On 09-07-2023 21:09, Dirk Eddelbuettel wrote:

| I don't understand this then. For several packages we're seeing failures
| in testing even if we only use r-base from unstable and everything else
| from testing to run the test. They pass with a rebuild r-cran-fnn and/or
| a rebuild and updated r-cran-ps, and/or r-cran-tibble. (Sorry, in my
| previous message I think I added r-cran-dplyr by mistake, misremembered).

It would be useful to break this down into concrete reproducible examples.


Several in the set that I explicitly tested:
r-cran-stars (needs r-cran-tibble and r-cran-interval)
r-cran-spacetime (needs r-cran-interval)
r-cran-uwot (needs r-cran-fnn)
r-cran-xopen (needs r-cran-ps)


So this is where R 4.3.[01] will possibly break with some older packages.
But the fix is simple because when R 4.3.0 came out all packages at CRAN
complied. We need to have current packages that correspond to the R 4.3.0
standard.


And Andreas already ensured (nearly) everything is rebuild by now, so 
that part is done. To be clear, I think I understand it when you say 
this is not caused by r-base, but rather by those packages that need 
rebuilding with the new r-base. However, to ensure those packages are 
upgraded alongside r-base, r-base needs to force that. And that's why 
there is the Breaks.


I think the list is now:
r-cran-cairo (<= 1.6-0-1)
r-cran-fnn (<= 1.1.3.1-1)
r-cran-magick (<= 2.7.3+dfsg-3)
r-cran-ps (<= 1.7.2-1)
r-cran-ragg (<= 1.2.5-1)
r-cran-svglite (<= 2.1.1-1)
r-cran-tibble (<= 3.1.8+dfsg-1)
r-cran-tikzdevice (<= 0.12.4-1)
r-cran-vdiffr (<= 1.0.5-1)


they built with. My point is that the accept-vs-break comes from the package,
not from R.)


Sure, but the package in testing and stable can't (easily) tell that 
anymore in their relationships as they are already shipped, so packages 
moving into testing should solve it. I think only r-base is in the 
position to add the right Breaks.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Paul Gevers]

Hi Dirk,

Thanks.

On 09-07-2023 18:41, Dirk Eddelbuettel wrote:

On 9 July 2023 at 17:40, Paul Gevers wrote:
| Did we already discuss that r-cran-ps also seems to be impacted by the
| r-base change of the symbols thingy, as can be seen in r-cran-xopen [1].

Correct me if I am wrong but the "symbols thingy" was not a change in R 4.2.*
to R 4.3.*. It was a change by some packages opting into different behavior.


I don't understand this then. For several packages we're seeing failures 
in testing even if we only use r-base from unstable and everything else 
from testing to run the test. They pass with a rebuild r-cran-fnn and/or 
a rebuild and updated r-cran-ps, and/or r-cran-tibble. (Sorry, in my 
previous message I think I added r-cran-dplyr by mistake, misremembered).



|   33s  10. ps:::not_null(.Call("psll_connections", p))

Tis would be a bug in r-cran-ps and I think a Breaks may be warranted.


Ok, let's remember this.


Given
that ps always had 'native symbols', maybe testthat changed?


But I think (I would need to check for the autopkgtest fallback) in none 
of the tests, the version of testthat in testing changed between passing 
and failing tests. Would testthat embed something during the build of 
the binaries (from the name, I would assume not)?



| Same for r-cran-fnn, which impacts r-cran-uwof [2].
|
| I think what we should do is add a versioned Breaks in r-base on
| , r-cran-ps, r-cran-tibble,
| r-cran-dplyr, r-cran-fnn. I think that's the right thing to do for

I think it would be best to work out to corresponding package pairings and
apply the Breaks to them. If we can.


Sure, lets add the Breaks to the place where it belongs.


For spacetime and stars I suspect (based on past experience) possible
interaction from the underlying graphics libraries.


Good to hear, didn't check yet, but will shortly (geospatial).


If I am not mistaken all of these were already in the Excuses list before we
made addition of the r-graphics-engine-* tag (which was taken care of for R
4.3.* already, having it may help if another change happens like that).


Sure, I'd hope the r-graphics-engine-* Provides only reduced issue, so 
I'm currently considering them to be different. But I might be proven 
wrong easily.



Unfortunately I find
the reports a little hard to read and am hence not very efficient at
pinpointing underlying causes. Above you pointed eg at [2] for uwot, I see no
error in there :-/


Well, that log has two tests. The first second one passes, the first one 
has:

 51s > library(testthat)
 51s > library(uwot)
 51s Loading required package: Matrix
 53s >
 53s > test_check("uwot")
 53s Error in FNN::get.knn(X, k) : DLL requires the use of native symbols
 53s Calls: test_check ... eval -> create_data -> find_nn -> FNN_nn -> 


 53s Execution halted


Obviously, I too want my package r-base in testing and I will help. But I
feel that pinning a large Breaks list on it seems a little inefficient /
unfair if the package was not causing the change. We can do if there is (as
we r-graphics-engine-*) an overwhelming feel "that we must".


I want the Breaks in the right location. If we locate a more logical 
location than r-base, that's where it should go. At least the packages 
involved in the r-graphics-engine would do nice, as it's really the 
change in r-base that broke them (will not be needed anymore after the 
release of trixie as now we have the Provides): r-cran-cairo, 
r-cran-magick, r-cran-ragg, r-cran-svglite, r-cran-tikzdevice and 
r-cran-vdiffr.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Paul Gevers]

Hi,

On 09-07-2023 16:20, Andreas Tille wrote:

I'm working my through the list and the ppc64el ci workers have a bit of
backlog; we're getting somewhere, but I'm think I'm still also seeing
different failure modes than the graphics engine, tibble and dplyr.


I admit the only chance I personally see to clarify this question is to
open an issue at the tibble git repository[1].  May be we also need
something like an r-cran-tibble-api?


Did we already discuss that r-cran-ps also seems to be impacted by the 
r-base change of the symbols thingy, as can be seen in r-cran-xopen [1]. 
In unstable r-cran-xopen works. If I take r-cran-ps, r-cran-xopen and 
r-base from unstable and test in testing, r-cran-xopen works. If I only 
take r-base and r-cran-ps from unstable and test in testing, 
r-cran-xopen works. Can somebody with R understanding confirm?


 33s Error in `not_null(.Call("psll_connections", p))`: DLL requires 
the use of native symbols

 33s Backtrace:
 33s   1. testthat::test_that(...)
 33sat test.R:4:0
 33s   2. testthat:::test_code(desc, code, env = parent.frame(), 
reporter = reporter)

 33s   3. reporter$start_test(context = reporter$.context, test = test)
 33s   4. testthat:::o_apply(self$reporters, "start_test", context, test)
 33s   5. base::lapply(objects, f)
 33s   6. testthat (local) FUN(X[[i]], ...)
 33s   7. x$start_test(...)
 33s   8. ps::ps_connections(ps_handle())
 33s   9. ps:::psl_connections(p)
 33s  10. ps:::not_null(.Call("psll_connections", p))

Same for r-cran-fnn, which impacts r-cran-uwof [2].

I think what we should do is add a versioned Breaks in r-base on 
, r-cran-ps, r-cran-tibble, 
r-cran-dplyr, r-cran-fnn. I think that's the right thing to do for 
bookworm to trixie upgrades (and current trixie to trixie with the new 
r-base). Has anyone see other packages throwing that "DLL requires the 
use of native symbols" error? I spotted the ones below [3, 4, 5, 6], but 
I haven't identified which package brings in the issue. I first thought 
it would be from the package itself, but for some (r-cran-spacetime and 
r-cran-stars) their versions in unstable fail their own testsuite in 
testing. Would it hint at the same problem for the packages, or just for 
their tests? I suspect the former, then they should also need to be 
added to the Breaks list.


Paul

[1] 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-xopen/35575366/log.gz
[2] 
https://ci.debian.net/data/autopkgtest/testing/i386/r/r-cran-uwot/35590669/log.gz
[3] 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-intervals/35575046/log.gz
[4] 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-maldiquant/35575320/log.gz
[5] 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-spacetime/35575371/log.gz
[6] 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-stars/35583884/log.gz


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Paul Gevers]

Hi,

On 06-07-2023 21:18, Andreas Tille wrote:

Am Thu, Jul 06, 2023 at 08:28:45PM +0200 schrieb Paul Gevers:

On 06-07-2023 19:08, Paul Gevers wrote:
I'm seeing in several tests where things seem to work when r-cran-tibble



from unstable is involved and fail if the version from unstable is used;

  

Are you sure there is no typo in your sentence?  At least I fail to
understand.  I assume the latter "unstable" should be "testing", right?


Indeed, I think the pattern is that if we test in testing, with r-cran 
from unstable and r-cran-tibble from testing it fails, but with r-cran 
from unstable and r-cran-tibble from unstable, it works.


I'm working my through the list and the ppc64el ci workers have a bit 
of backlog; we're getting somewhere, but I'm think I'm still also seeing 
different failure modes than the graphics engine, tibble and dplyr.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)

[Paul Gevers]

Hi,

On 06-07-2023 19:08, Paul Gevers wrote:
Yes, we'll take care of that where it looks sane to do so (examples of 
that are r-cran-epi); I'll manually schedule the "combined" tests, such 
that they disappear from the excuses if they then pass.


I'm seeing in several tests where things seem to work when r-cran-tibble 
from unstable is involved and fail if the version from unstable is used; 
e.g. here: https://ci.debian.net/packages/r/r-cran-rsample/testing/amd64/


Is there something special about r-cran-tibble? It didn't grow a 
dependency on r-graphics-engine according to 
https://buildd.debian.org/status/fetch.php?pkg=r-cran-tibble=amd64=3.2.1%2Bdfsg-2=1688629916=0 
so it doesn't seem to be involved in that part of the discussion.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)

[Paul Gevers]

Hi Andreas,

On 06-07-2023 16:44, Andreas Tille wrote:

Am Thu, Jul 06, 2023 at 09:56:31AM +0200 schrieb Andreas Tille:
Is there any chance to fix this via
hinting by release team or should I rather add some "artificial" versioned
Depends just to enable the whole set of r-cran-* packages to testing.


Yes, we'll take care of that where it looks sane to do so (examples of 
that are r-cran-epi); I'll manually schedule the "combined" tests, such 
that they disappear from the excuses if they then pass.



Alternatively it would probably OK to remove all
RC buggy r-bioc-* packages from testing since we need to upload new
versions of these packages anyway in the pending BioC transition (I'll
file an according bug report soon).


If you're OK to temporarily remove r-bioc-*, than I think it's the 
fastest and easiest way out, albeit not the prettiest.


Please all involved, hold any uploads in the r-* world until we get 
r-base migrated unless it's needed (and we acked it).


Paul

PS: in a private discussion I had today, we noticed that r-* packages 
often (always?) have a dependency on r-base-core with a lower limited 
version equal to the r-base-core that was used during the build. With 
the appropriate API in Provides of r-base-core, this should no longer be 
necessary and ease migrations in the future. We should probably file a 
bug against dh-r (I guess) to fix that dependency. Or did we conclude 
that wrong?


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040001: transition: r-base

[Paul Gevers]

Hi Dirk,

On 01-07-2023 16:47, Dirk Eddelbuettel wrote:

So per upstream ("R Core" for short), this is clearly on the package
side. There is no ABI/API incompatibility: R offers graphics functions new
functionality, to use it one needs a rebuild _if a package decides to stop
and die on mismatch_.

I so filed three bug reports last weekend against three such packages
requesting a simple rebuild as that is in fact all it takes. (And
missed one that was added.)  These were quickly rebuilt.


While this may be true, in Debian we require that such packages express 
this relation. I understand that that's what we achieve with the 
proposal of Andreas. "Just rebuilding" is often the wrong solution (in 
Debian) if it doesn't express the relation properly.



So let me know what you think.  If the release team thinks we must rebuild
across 1100 r-* packages (of which likely 400-500 are Architecture: any)
then I will of course work with you.


I recognize that at this moment we might not need it to straighten 
things out, because of all the new version uploads, but I believe it's 
the right solution for the future, as this seems to be a recurring topic.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040001: transition: r-base

[Paul Gevers]

Hi Andreas,

On 30-06-2023 21:35, Andreas Tille wrote:

I'm not sure that we are in the right status to ask for a transition bug


Anytime is good to ask for a transition, particularly when the 
transition is already ongoing.



   https://lists.debian.org/debian-r/2023/06/msg00025.html
 In the end of this mail three options are listed which I simply
 repeat here for your comfort:

1. implement the r-graphics-api-*
   This might be a bit complex since for the moment I do not know
   any means how to detect the packages that need this dependency
   (and how we can implement this into dh-update-R)  So this might
   become technically complex in the first case

2. Just do a full r-api transition
   This would work but affects more packages than strictly
   necessary.  My gut feeling says we will be able to finish this
   earlier than 1. despite technically not perfect

3. Blindly ignore the fact that we need a transition and follow
   the hackish workaround by using random versioned Depends as
   suggested by Nilesh for r-cran-epi.



While I would love to hear the opinion of the release team what kind of
transition (1. or 2.) should be prefered (if this is possible now at all
since the affected package r-base 4.3.1 is in the archive since some
time and also the most urgent packages are rebuild manually) or whether
we need to fight manually through this mess (option 3.)  I confirm that
I agree with Johannes Ranke to prefer option 1. and do it "right" to be
safe for the next time.


I don't think it should surprise anyone that we prefer it to be done 
right. Our preference is for option 1. However, if you can't get the 
pieces for that option in place in a reasonable time (say, a week or 
two, take some time to try), then we prefer to get *this* transition out 
of the way by means of option 2. I don't think it's in anybodies 
interest to waste time on option 3.



Sorry that this transition bug is that complex.  I would have loved if
it would went more coordinated but unfortunately that's not in my hands
and I simply try to reassemble the pieces.


Thanks for communicating with us, much appreciated.

I'll try to set a placeholder transition tracker up soon; for now, by 
lack of something better, will reflect option 2. We can update that once 
we have the pieces for option 1.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#803633: britney-tests-live-data/live-2012-05-09 fails randomly

[Paul Gevers]

Hi,

On 26-01-2023 17:45, Paul Gevers wrote:
On Sun, 01 Nov 2015 10:42:49 +0100 Emilio Pozuelo Monfort 
 wrote:

If run in a loop, live-2012-05-09 will eventually fail with:

AssertionError: NUNINST OUT OF SYNC


This issue was fixed in 2016 with this commit: 
https://salsa.debian.org/release-team/britney2/-/commit/2fd6c59460c0e78bb50a34938dbc05637abf27b2



Currently I'm seeing it also/instead being unreproducible.


This remains. I have now 10 different possible end states of britney. 
I'm trying to add sorted() to a bunch of for loops on sets. It seems I'm 
able to make it more deterministic, but I'm not there yet.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039870: release.debian.org: Help eccodes migrate to testing

[Paul Gevers]

Hi,

On 29-06-2023 06:35, Bas Couwenberg wrote:

Please help to remove these old binaries to unblock the testing migration of 
eccodes and its rdeps.


I think we just need patience. The britney2 run of 4:00 UTC removed 
eccodes-python and that still (is now?) needs to be propagated to the 
mirrors. Once that happens, I expect britney2 to figure it out.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Re: Bug#1038853: usrmerge: clean up the unused empty biarch directories

[Paul Gevers]

Hi Marco,

On 22-06-2023 17:41, Marco d'Itri wrote:

Release managers, I would like to upload to 12.1 a new package to fix
this (and other minor issues).


Please file a proper proposed-updates bug report as our workflow relies 
on them.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1038115: transition: gdal

[Paul Gevers]

Hi,

On 23-06-2023 08:49, Sebastiaan Couwenberg wrote:
To make the libgdal-grass autopkgtest pass it needs both gdal and 
libgdal-grass from unstable.


I'll schedule it.

I've scheduled jobs for this, but it seems britney ignores tests it 
hasn't scheduled itself.


That's mostly correct as any authenticated user can re-triggering runs 
done by britney and those also count.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Re: rust-base64 migration dependency adjustment

[Paul Gevers]

Hi Ian,

On 21-06-2023 02:30, Ian Jackson wrote:

Therefore I am tagging this bug trixie-ignore to avoid getting
autoremoval warnings etc.


As the rust-base64 migration seems to be just waiting (AFAIK at this 
moment) on rust-ruma-common autopkgtest-ing on ppc64el, I agree that 
this is OK.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Re: gcc-11: generate bad code for matplotlib with -O1/-O2 on mips64el

[Paul Gevers]

Hi YunQiang, mips porters,

On 28-04-2023 15:51, YunQiang Su wrote:

Paul Gevers  于2023年4月27日周四 04:26写道：

On Fri, 24 Feb 2023 23:10:29 + James Addison  wrote:

Hi Frederic: I'm linking a forwarded GCC GNU bug report that I _think_ is the
upstream report matching this bug.  I found it from a related GitHub issue[1]
for matplotlib.

The GCC bug reporter has done some work to create a minimal reproducer case.
Could you check whether the issue reported there is the same one as here?  (I
will do eventually, but am not familiar with C and do not have mips hardware
available so it may take some time)

[1] - https://github.com/matplotlib/matplotlib/issues/21789


We're you ever made aware of this bug in gcc-11 and gcc-12? Maybe a bit
of your help is appropriate.



Sorry about that I forget this bug...
I will dig it.


Did anything happen here? Lagging progress (reporting) on bugs like this 
isn't great for architectures in the the architecture qualification.


Paul


OpenPGP_signature
Description: OpenPGP digital signature