Processed: transition: benchmark

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:benchmark
Bug #1059961 [release.debian.org] transition: benchmark
Added indication that 1059961 affects src:benchmark

-- 
1059961: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059961
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1059961: transition: benchmark

[Anton Gladky]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: benchm...@packages.debian.org
Control: affects -1 + src:benchmark

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,

please schedule a tiny benchmark transition.

Thanks!

Ben file:

title = "benchmark";
is_affected = .depends ~ "libbenchmark1debian" | .depends ~ "libbenchmark1.8.3";
is_good = .depends ~ "libbenchmark1.8.3";
is_bad = .depends ~ "libbenchmark1debian";




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAmWWWMARHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wb6uA/9FuLjNjbEHrnfYhaMJPlFjc1d7xSOv5MJ
SsQJP8RRQP3KpSuP2U3B66b1itzRSOCMb+OiDIK9nigUPjM79l/E8WlVtZ6mLTBp
9PAoe391wPmJ4th3MzGQCOwCam/eXgy1xLa7/l6BgfBDRiOCygokFB1Pu3Af8IJq
34fsyPX2mbFoGjA+oqQcCLDPDmkWWYvo6iuMvP9tC3nGWojzAJlj4BS0Kds4ulsQ
NQ78W28wNfwqGSyfegHYN/8krkxWZI+OVXD/4eaW4qs+lfsMabdfCaiomA5dZZb8
N3UaPZdXwDRVw00btwW2lB/FN4smWd7V9gOprVzwwU8VfG9NGWGZ1DTrLQCjDQgj
/FGVFgTnp29xZSE1Z9FGJJh0BwJJLgM77x3+cDf8SHVwLiWO8DS51Y4P4xLTXSS6
9fvjea5XfquhDfSLsXpXFt6wFrnjrAImj/v1OWp9negPSRWyKycNzf4ePgIqhvw6
rQV6+VTVFGpB7DggoHqHmFEi8JV6SC44f5USpcHd5mMvHczGIgfuzho69xSoKx4U
CmdGtVEbEGsnxqylqFYHkfUz6B2Euper193JXAX5GQ/2DzrJe5TNsXStGvRBy+PS
TNSLeZMMkMofNE+1VjiffqQgmRSdFzqCmX6gmd3Zs6ZA20iNUjdcNPxKW9BAslbh
TndgQAtpDV4=
=EugD
-END PGP SIGNATURE-

Re: Planning for 12.5/11.9

[Luna Jernberg]

Hey!

10th or 17th works for me the 17th the best

Den tors 28 dec. 2023 kl 03:41 skrev Cyril Brulebois :
>
> Steve McIntyre  (2023-12-26):
> > Any of those *should* be OK for me.
>
> Ditto.
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant

Bug#1059898: unblock: steam-installer/1:1.0.0.78~ds-4

[Simon McVittie]

On Wed, 03 Jan 2024 at 20:51:46 +0100, Paul Gevers wrote:
> Thanks for letting us know. I prefer to keep the status quo for a day such
> that I can debug this tomorrow.

That's absolutely fine, this particular migration is not urgent and can
remain stuck for another few days or weeks if necessary.

It will only become urgent if it gets flagged as "out-of-sync for too
long", or if its udev rules become a blocker for the transition to
all-files-in-/usr.

smcv

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

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

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: britney
X-Debbugs-Cc: gobject-introspect...@packages.debian.org, 
debian-cr...@lists.debian.org

gobject-introspection in experimental has this in
https://release.debian.org/britney/pseudo-excuses-experimental.html#gobject-introspection:

gobject-introspection (1.78.1-6 to 1.78.1-9)

Migration status for gobject-introspection (1.78.1-6 to 1.78.1-9): BLOCKED: 
Rejected/violates migration policy/introduces a regression
Issues preventing migration:
gobject-introspection/amd64 has unsatisfiable dependency
gobject-introspection/arm64 has unsatisfiable dependency
Additional info:
uninstallable on arch amd64, not running autopkgtest there
uninstallable on arch arm64, not running autopkgtest there

The gobject-introspection binary package *is* installable, and in fact
I have it installed locally. Taking the amd64 version as an example,
it depends on:

- binutils-x86-64-linux-gnu:any, a real Multi-Arch: allowed package

- gcc-x86-64-linux-gnu, a virtual package provided by gcc:amd64

- gobject-introspection-bin | qemu-user | qemu-user-static, where
  g-i-bin is a Multi-Arch: allowed package from the same source

- gobject-introspection-little-endian:any, a virtual package provided
  by g-i-bin, which is Multi-Arch: allowed
  (experimentally, apt and dpkg both seem to be happy to assume that
  this makes the gobject-introspection-little-endian virtual package
  behave as though it was also Multi-Arch: allowed)

- pkgconf, a real package

- python3:any, a real Multi-Arch: allowed package

I think all of those are correct?

Or do I need to make gobject-introspection-bin Multi-Arch: foreign,
drop the :any from gobject-introspection-little-endian:any, and
replace the gobject-introspection-bin | qemu-user | qemu-user-static
dependency by python3 | qemu-user | qemu-user-static or similar?

My goal here is that you can install gobject-introspection:amd64 on an
amd64 machine, or on any other little-endian machine that will be able to
cross-compile amd64 binaries and then run them by explicitly invoking them
via qemu-user, as discussed with Helmut Grohne at the recent Cambridge
miniDebconf. (It has to be little-endian because g-ir-inspect and similar
tools don't currently support byte-swapping fields in binary typelibs.)

Thanks,
smcv

Re: /usr-move: Do we support upgrades without apt?

[Wouter Verhelst]

On Wed, Jan 03, 2024 at 04:43:45PM +0100, Helmut Grohne wrote:
> On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote:
> > We can restore lost files in a postinst. For this to work, we must
> > duplicate (e.g. hard link) affected files in the data.tar.
> > Example: #1057220 (systemd-sysv upgrade file loss)
> > Note that this approach is not policy compliant for essential packages
> > as they must work when unpacked and this is relevant for gzip being
> > diverted by zutils for instance.
> 
> We'll be doing this anyway. It is implemented in systemd-sysv.postinst
> and proposed in the gzip patch above. Yes, we are technically violating
> policy for gzip then, but I don't really see a technical way not to
> violate policy. I expect that we do not consider fixing this (unfixable)
> policy violation release-critical.

I agree that this is the best way forward.

Presumably the reason for this requirement in policy is that without it,
debootstrap cannot function. That is, debootstrap first unpacks all
Essential packages, without running any preinst or postinst scripts, and
*then* runs all the maintainer scripts. If an Essential package would
not function without its maintainer scripts being run, then debootstrap
could fail halfway through.

Running debootstrap cannot trigger the issue, because it does not
involve upgrades; and I do not believe that apt will special-case
Essential packages other than that it refuses to remove them unless
the user enters The Phrase[1], so we can consider that if it's something
that would work for a regular package, it will work for an Essential
one, too.

Perhaps if the above assumptions are correct, policy should be updated
such that the requirement is relaxed to only apply for initial
installation?

[1] At least, I think it logically *should* not do so, but then I'm not
an apt developer and thus I may not know all the corner cases.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1041982: Speeding up Symfony 6 transition? [Was: Upcoming transitions (Symfony, PHPUnit, etc.)]

[David Prévot]

control: block -1 with 1051989
control: severity 1051989 important
control: severity 1051988 important

Le Sun, Sep 17, 2023 at 07:57:03PM +0530, David Prévot a écrit :
> […] roughly, the
> following end user packages (families) are not yet ready.
> 
> civicrm (#1051988)
> kanboard (#1051989 and php-pimple)
> Laravel (#1051985 and #1039731, and php-faker)
> shaarli (#1039733 and php-slim, php-pimple)
> 
> civicrm is not in stable […] Robin already explicitly
> agreed that can be Laravel can be removed again from testing until a new
> upstream version is packaged.
> 
> I don’t know if there are strong opinions about kanboard and shaarli,
> Joseph and James CCed.

kanboard has been removed from testing in the mean time (due to
#1051989).

> […] it may already be time to raise the severity of the
> blocking bugs.

I’m in favour of raising the severity of bugs blocking this transition
to RC level ASAP: Symfony 6 has been in experimental for a while now,
and it’s the targeted version for Trixie anyway (6.4 is likely to be the
latest LTS version available before the Freeze, while 5.4 will be EOL
soon after Trixie gets released).

https://symfony.com/releases#symfony-releases-calendar

> Athos may try to rebuild packages also depending on recent version of
> php-symfony-contracts, php-psr-cache, php-psr-container and php-psr-log
> in order to figure out if more package are affected by this transition.

That would still be very much welcome if time permits, but IMHO not a
blocker (we used to handle such transition without involving the release
team nor as much build testing than already done for this transition.
Thanks to all people involved, the current state makes us in a better
position to move forward).

Regards,

taffit


signature.asc
Description: PGP signature

Processed: Speeding up Symfony 6 transition? [Was: Upcoming transitions (Symfony, PHPUnit, etc.)]

[Debian Bug Tracking System]

Processing control commands:

> block -1 with 1051989
Bug #1041982 [release.debian.org] transition: symfony 6
1041982 was blocked by: 1051988 1051985 1039733 1039732 1039734 1039735 1039731
1041982 was not blocking any bugs.
Added blocking bug(s) of 1041982: 1051989
> severity 1051989 important
Bug #1051989 [kanboard] kanboard: FTBFS with php-psr-log >= 3, needed for the 
symfony 6 transition
Severity set to 'important' from 'normal'
> severity 1051988 important
Bug #1051988 [civicrm-common] civicrm-common: Not compatible with symfony 6
Severity set to 'important' from 'normal'

-- 
1041982: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041982
1051988: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051988
1051989: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051989
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: /usr-move: Do we support upgrades without apt?

[Helmut Grohne]

Thanks for the feedback. Given the replies, I consider that most people
expect upgrades to be performed with apt (or some apt-using tool).
Upgrades using dpkg (directly) are at least partially unsupported. In
more detail:

On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote:
> ## Options (combinations possible)
> 
> When mitigating P3, we can avoid the mutual conflicts. For molly-guard
> that has been more involved, but it seems manageable. For other
> packages (that do not need to access diverted files), it becomes
> simpler.

We'll be doing this. It is implemented in molly-guard and submitted for
gzip #1059533 / zutils #1059534. Hence, upgrades with apt-dependent
tools will not experience the failure mode.

> We can restore lost files in a postinst. For this to work, we must
> duplicate (e.g. hard link) affected files in the data.tar.
> Example: #1057220 (systemd-sysv upgrade file loss)
> Note that this approach is not policy compliant for essential packages
> as they must work when unpacked and this is relevant for gzip being
> diverted by zutils for instance.

We'll be doing this anyway. It is implemented in systemd-sysv.postinst
and proposed in the gzip patch above. Yes, we are technically violating
policy for gzip then, but I don't really see a technical way not to
violate policy. I expect that we do not consider fixing this (unfixable)
policy violation release-critical.

> We can introduce "barrier" packages (one or more) and have them enforce
> conflicting packages removed before the conflictor being unpacked
> (thanks Julian).

We'll keep this as an option for later, but avoid implementing it now.

> We can - and this is the crux of the matter - argue that upgrading with
> bare dpkg is unsupported and you get to keep the pieces if you do so
> anyway.

release-notes already recommend upgrading with apt. In addition we'll:
 * Extend release-notes to do advise something like `dpkg --verify` post
   upgrade.
 * Mitigate file loss in postinst (such that it becomes temporary).

If you have any objections to these choices, please tell.

Helmut

Bug#1059898: unblock: steam-installer/1:1.0.0.78~ds-4

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: steam-instal...@packages.debian.org, debian...@lists.debian.org
Control: affects -1 + src:steam-installer

steam-installer doesn't seem to be migrating, and its excuses page
presents an empty list of reasons why not.

In the HTML output, under "Additional info" (which if I understand
correctly is meant to be for notes that do not affect migration), it
says:

- Additional info:
- uninstallable on arch amd64, not running autopkgtest there
- uninstallable on arch i386, not running autopkgtest there

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.

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

Similarly, the steam:i386 contrib binary package is uninstallable unless
you are actually on an amd64 system.

The other binary packages (in main) should be installable on their
appropriate architectures with no special measures.

Thanks,
smcv

Processed: unblock: steam-installer/1:1.0.0.78~ds-4

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:steam-installer
Bug #1059898 [release.debian.org] unblock: steam-installer/1:1.0.0.78~ds-4
Added indication that 1059898 affects src:steam-installer

-- 
1059898: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059898
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems