This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------DbvUqeSx9r2Vbwesu25FcFRx
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGVsbG8gbGlzdCwNCg0KU2luY2UgdHdvIGRheXMgdGhlIGxpdmUgaW1hZ2VzIGJhc2VkIG9u IHNpZCBjYW4gYmUgZ2VuZXJhdGVkIGFnYWluIA0KKGh1cnJheSEpLCBub3cgdGhhdCBkZWJv b3RzdHJhcCBpcyBhYmxlIHRvIGdlbmVyYXRlIGEgYm9vdHN0cmFwIGFnYWluLg0KVGhlIHNt YWxsZXN0IGltYWdlIGlzIGdlbmVyYXRlZCBwcm9wZXJseSBub3csIGJlY2F1c2UgaXQgZG9l cyBub3QgaGF2ZSANCmFuIGluc3RhbGxlci4NCg0KRm9yIHRoZSBvdGhlciBpbWFnZXMsIHRo ZSBpbnN0YWxsZXIgaXMgY3VycmVudGx5IGZhaWxpbmcgdG8gYnVpbGQgZnJvbSANCnNvdXJj ZSwgYXMgc29tZSBkZXBlbmRlbmNpZXMgKGluIHRoZSB1ZGVicykgYXJlIHN0aWxsIG1pc3Np bmcgKGR1ZSB0byANCnRoZSB0NjQtdHJhbnNpdGlvbikuDQoNClRoZSBsYXRlc3QgbWVzc2Fn ZSAoZnJvbSBteSBsb2NhbCBidWlsZF9jZHJvbV9ndGsubG9nKSBpczoNCg0KVGhlIGZvbGxv d2luZyBwYWNrYWdlcyBoYXZlIHVubWV0IGRlcGVuZGVuY2llczoNCiAgbGliY2Fpcm8yLXVk ZWIgOiBEZXBlbmRzOiBsaWJwbmcxNi0xNnQ2NC11ZGViICg+PSAxLjYuMikgYnV0IGl0IGlz IG5vdCANCmluc3RhbGxhYmxlDQogIGxpYmZyZWV0eXBlNi11ZGViIDogRGVwZW5kczogbGli cG5nMTYtMTZ0NjQtdWRlYiAoPj0gMS42LjIpIGJ1dCBpdCBpcyANCm5vdCBpbnN0YWxsYWJs ZQ0KICBsaWJnZGstcGl4YnVmLTIuMC0wLXVkZWIgOiBEZXBlbmRzOiBsaWJwbmcxNi0xNnQ2 NC11ZGViICg+PSAxLjYuMikgYnV0IA0KaXQgaXMgbm90IGluc3RhbGxhYmxlDQogIGxpYmlu cHV0MTAtdWRlYiA6IERlcGVuZHM6IGxpYm10ZGV2MXQ2NCBidXQgaXQgaXMgbm90IGluc3Rh bGxhYmxlDQoNCk9uIG9wZW5RQSBJJ3ZlIGFkZGl0aW9uYWxseSBzZWVuIHRoYXQgZm9yIERl YmlhbiBFZHUsIHRoZSBpbnN0YWxsZXIgDQpmYWlscyB3aXRoIHRoZSBtZXNzYWdlIHRoYXQg bGliYWlvLjEuc28gaXMgbWlzc2luZywgc28gc29tZSB1ZGViIGlzIA0KcHJvYmFibHkgYWxz byByZXF1aXJpbmcgYW4gdXBkYXRlLg0KDQpXaXRoIGtpbmQgcmVnYXJkcywNClJvbGFuZCBD bG9idXMNCg==

--------------DbvUqeSx9r2Vbwesu25FcFRx--

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEUFVLM5Bdj7GSJEb+YsV8aqYUlb0FAmX52DkACgkQYsV8aqYU lb3Yeg//WN8csQjQUr/xOFYqiBuYwjMC+xq4VKb7jIzOrpaTrSm9FQGk6O1KtwXA jQI1OwR2x7pRenLTrczCGGixhFWUImjekQtCyskHcz2tyoza8l1804jVasv40SnF N+p2Uq9Eot2e2I7PTHJkMLGGkjvyPg4X2KwyxtQEK/A+aeav+h3fBCxz4L7Q9gi8 tZv9MF/PVX/kD5p13JItsU+8qB8teH3YhyFv40ezw340uzpZVVnXa0JCpE7ryDHc MIkZNhFkqAfXsFO9VSKT2grRgyrqPN0JljJd/J0VkS3eZc5eC9kCx98DqxFR+KzJ DHQVkrPZu6y8PMHhSbjU6tkT2WB5C45FjtrcemK3qWzuSVdxkvA5j5kHtpL0Ey0Z 1eP4p3Co8yk3qPZoaye0UpwamsFF0btbxbLfoE081vAXZesCJE+gFI3LaqiIYz57 GJQ22vChOS52+Y+jiNuo6YHQMMHdjiwVBSQieQFokYXkCwItuYFtOMm9L4JxxWbp RoryOxpgf81XQRMsy4lCsWVbS1k6uwd9TY7rY8D5DGGg/dihTv+D4S+TbjEhGgRf iaYfoPXLo3UBNQyhn8wjIn3JpLX/d9viIQlBqwc+c/GbNItnq2NWBwR5uwYH8NRT DO/rfLhjIVSVPa2b2lGhZEheOX8brxKePYH0CV3qQgk+dwA2yfQ=
=q572
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Roland Clobus <rclobus@rclobus.nl> (2024-03-19):

For the other images, the installer is currently failing to build from source, as some dependencies (in the udebs) are still missing (due to
the t64-transition).

The latest message (from my local build_cdrom_gtk.log) is:

The following packages have unmet dependencies:
libcairo2-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable
libfreetype6-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable
libgdk-pixbuf-2.0-0-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it
is not installable
libinput10-udeb : Depends: libmtdev1t64 but it is not installable

https://lists.debian.org/debian-boot/2024/03/msg00102.html

On openQA I've additionally seen that for Debian Edu, the installer fails with the message that libaio.1.so is missing, so some udeb is probably also requiring an update.

Do you have more details? That thing doesn't exist, but libaio.so.1
does (different suffix order).

In any case, there are no reasons to complicate the t64 transition with transitioning udebs, so I wouldn't be surprised if “images” (whatever
they are) built against old udebs would break if newer udebs are pulled
from the network.


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmX8SyYACgkQ/5FK8MKz VSCL3A/+KeosJn888ZCspmytkcU7rkoeRlH4m9cSLb5+3+aMWBvLh0s5GuK5b4dL DdsTV867s1ux+k7s/hwqFF0YPwwK/4HH3HsG2Aa0eFfUdUvabOVqx5n1JuvDhtjl kTJnrWFC3gUpq0ZD9p+lbN0Lbin46Qb/D8DqhMuuXXt8upiTnt9JVVHEwsCkXV8E 3DZANS9w1PhjXNyNFdZ4yjTFGyoLAvPVR1XMdADKYXIrjGdIaSYjPIdceXEOb/bs +T+EbFK+OSVgFpl6O/rNGAKpki6JwanidUTjos3Snx1kkIXTlL1XmruBFRhi/1Rq iPxkW2UNBhVm6/h8Q8UfooDQroyjxll0z9ho4piEJJD2HanllTxm240NT7PZy7tP WVQwkLuQXcwWNkXm2ckha9Xq5n3CV/yhA6W1yGZ8voH/UyZofMdG024rk3bda+jZ UjtglYgTd2O0DkzcsYQTmxVfE484WEUFuZsFRN9m6kmwE/k/Slj6bSDzrFh8jjc7 5GSvLGS6v6I7avx2UX//llvffLCZVgFOCW275qcxsi9didCA+bn+SWHozfsaIJSd 7ZvCaDT9m7gU8Div9JAG9ICqbTCmw96qx1LBzAL0bvhqW0GXuBeZVJk+J3jhnfxh REVJA0X9vUDXx1OBwDHqCRocKbPzfGLUXuAn2lkwbB1clq2tNZk=
=8BM1
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

Hi,

Roland Clobus <rclobus@rclobus.nl> (2024-03-21):

On 21/03/2024 15:58, Cyril Brulebois wrote:

[…]

The diagram shows nicely that the t64-transition is affecting the
installer, with currently 1 major bottleneck, libpng16-16t64-udeb: https://d-i.debian.org/dose/graph-unstable-amd64.png

Glad you like it, those have been quite useful a very long while back;
it's been a while since the last time we had such a huge archive-wide transition…

Do you have more details? That thing doesn't exist, but libaio.so.1
does (different suffix order).

My bad, I reversed the order when typing.

No worries, thanks for confirming.

I've done some basic triaging in the openQA comment: https://openqa.debian.net/tests/244163#comments

The installer fails here:
https://openqa.debian.net/tests/244163#step/grub/3

Some details are here (/var/log/syslog): https://openqa.debian.net/tests/244163#step/grub/35

Thanks, that's pvs from lvm2-udeb; for some reason libaio1-udeb got t64-transitioned, and without an lvm2 rebuild, its tools will want the
non-t64 version.

I'm a bit conflicted about what to do here. At the moment, libaio1-udeb
is the only udeb with t64 (at least according to the output of
`apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies
would be sufficient (and might happen at some point anyway).

For the sake of consistency, I think I'm tempted to suggest a revert of
the udeb part (it wasn't renamed so there's a contents vs. package name mismatch anyway).

In any case, there are no reasons to complicate the t64 transition with transitioning udebs, so I wouldn't be surprised if “images” (whatever they are) built against old udebs would break if newer udebs are pulled from the network.

The images I've spoken of are the daily-built Debian live ISO-images based
on sid. They are built by Jenkins https://jenkins.debian.net/view/live/

OK, but what I meant to say is that the failure mode I was alluding to
isn't specific to d-i daily builds, or debian-cd builds, or live builds;
that's something that can happen, and might do until things stabilize.


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmX8rHsACgkQ/5FK8MKz VSCMkBAAp2a206hOHKa8G6jre/mnCbMQmRLH7sNDPz8lxawEnCUBu1InbHs4xHrR UclHZBiZGulKyHoLKaBcw4Mvde/z87bg+aL382Vfg5CErLJ7Ilo/gvsTlGTvmwNy ucgobATBII/0sySF1uN+3adEnMSHz98AfmwuVpgUk3JOpKTQYFMSdyucpGHtJTu7 Rtoj+Ka/4+R3CKYw1ZnfFBAFiNFalRGlwxyoE7cjl49QACA7GTOT2FrvcrACcFYl SfHTWXdfKXnOxA2/al1pj1O7y+sQAxZs+VN+MMpGbOqwtNXqyr9ZtNmdwratAVM1 uwSHlgdH0qJXrvht+uTL+a0XfuFaKJi7Mljk7tyJW8yn1YXxtG5wkEPF9d7KXcdi l7GEE/K4uRK77brhMHEv/dCM8/JBfDqC4czlm3yMmej5JfJNBbuO3qLzc98vxkJb CfHghiUg7V6X9MzkBfTn2Gb7fC9/a3PseeocZIk0748Fl9E9RaQcjKPBqhcV6vX4 6LIDdTH5nIx6IuVUNL0PtyxuJaa/nh74qVPZYn/D4mO0P4yHQpBY3dBibsgMHw3E +NMUqSynesP/duzM4ua515uxWgXqVJgyBzcLmYo7rQqshMBuQPGGYV0rYwHXvLbT PTPDRe2vgyzrCDgXcZORv2yhzqT9p2i8H7PjGI7r1yBN09PsgR8=
=dF/x
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

Hi,

I realised that there might be a way to kludge around the current D-I
build failures, so I gave it a try and it seems to work:

https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/45

That creates dummy udebs with the missing names, where each depends upon
the matching udeb that actually exists. Dropping them into localudebs.

That's enough to get D-I to build in salsa pipelines, such that one gets
a mini-ISO to test.

It may be enough to get D-I and debian-cd back to the point where we can produce daily images etc. but I'm not completely sure about that bit
(perhaps the use of localudebs is enough to make debian-cd grumpy?)

Anyway, it's currently broken anyway, so perhaps it's worth giving it a
go, and then reverting the commit once the proper fixes become
available.

What do you think?

Cheers, Phil.
--
Philip Hands -- https://hands.com/~phil

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmYcMQ0ACgkQ0EujoAEl 1cDZaQ/7BNDPWqEsojcDR51REarX4AMUpmip3IJTRlBQ0Ne/1c++v6p8W2R3IcYw 0xsazE9y8cB0bgLCZNdMtZFC1XMlFdoJqZ6BC7hHRfvSoMu7Zm7UY5/qZb14eJUz 2Cgax50TeicibbWbTHwLUeizbWmcU1YlshixkldBoiCyedA4w0r9KsTEteVYnYEu in+d3zpnRy2gME9PnoiOGBgY6ezrIiB6qM6SyQrrqlVS9ANovPWHlVa3YABU11hs 6J79l4qHnuq5Vx4Q1dCSxZasOdxFr3/+OuJ8pslHr29FCIUKNkFgcvm2KxeeUaO1 otPI2GWF3cM+m4MsxM6PRX2J6ntf+6BcjiAe6wq+WTS+QnaGqDt4CBggFigZ99NJ /4TX2IVCQaOOmFsWEIoNKD084Hx+037uotLLxbOG76bMBHZOcH72O/tHANSzkwTd oZLLzns0dxhQYI1J5FriOPe1iyXRPsTlAsPELcWZ9tJmFJedWw0QWPaHvS0noCj/ FdEZF5ms4QsSlmk6gUFMWtvLQHUIwJPIsAET1u64ox+Vrl6RZGIPXvqnYjS/BlBM Q1Mbq9HrZX+txJTPnU7AMNKkTCyoo3D7VDcYS+BQUxxU3baxme8UaOUGkuFALNOT zaeUXrzBQf8svCTf8iSxQX8OcQgfkbAD/biG2tmhdLXVSqqnW8Y=pMnS
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gatewa

Philip Hands <phil@hands.com> (2024-04-14):

I realised that there might be a way to kludge around the current D-I
build failures, so I gave it a try and it seems to work:

https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/45

That creates dummy udebs with the missing names, where each depends upon
the matching udeb that actually exists. Dropping them into localudebs.

That's enough to get D-I to build in salsa pipelines, such that one gets
a mini-ISO to test.

It may be enough to get D-I and debian-cd back to the point where we can produce daily images etc. but I'm not completely sure about that bit
(perhaps the use of localudebs is enough to make debian-cd grumpy?)

Anyway, it's currently broken anyway, so perhaps it's worth giving it a
go, and then reverting the commit once the proper fixes become
available.

What do you think?

I'd rather see actual progress in getting packages fixed. So far I haven't
been chasing because I thought people would be busy rebuilding the world, in the right order, and patching things along, but I had hoped to get *some*
kind of feedback after filing those bug reports and putting people driving changes in the loop.


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmYcQgsACgkQ/5FK8MKz VSCvZQ//UiigHDm4mQ2xi6v3vo9C+BmVfoWKcLoGJ2dxdxMksuurSDoPeeNPyRfX CIKd2RHAecCVvstFcwCINyGxSX+kvNgLRnLBMqkxStCcd2hSd7ks4iBa1RDZuNkz p8ti0HJhiMObU6xWFcSeti5lo1EhSsHHVrQfQ0w4nBAABWzYnJaSUYnJ0UxTvIsg ZYDxboXr93ypL6i05OuVCAn1f716KfNcVpCgUBWlxNEJvWmIOJSUHUoVa5FMa1H7 fDk2LuEoOFuXdElb1U7XRqJ5mLXKkd6fULmgpf2NxE5G0ZhiRKpRuGvz5PcxXwL1 UdCRHV8OVuajnNW/0PmDtS+DLbjaaYKvObQgR0zqtUWDCB0NG4nUw+gZDzIfPccG JavhSX4mgGIE+SPvJ5VNOdUcyIDt7/RCJJX9R/cdpnYzRPem+D/1WMsKt/oYQOwO m9vnAZemkEAMavuUMWujodPB3tw3wFUnOgtAMaZ53+RRwdG2pPq3kXS8CTL3gBr3 opHZQ10+s0birvEOLjzg+wl2rZvBtKuN9jGfNyYDyK9lYcJWTVHxzzf+IUcs0WmG GrMxTEA5ZZL5xVKEP+0lKK7MzXb7ZDdq/y75PDy1hyuGqeiS2DlFsKRwbpGAomy5 371WDkpHZZ7Yj5z88WoNEpaKgH0w/+bbaWPllvQQaMFBSpEKfZ4=
=KZ+T
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

Philip Hands <phil@hands.com> (2024-04-15):

On the other hand, it's taken over a month so far. Rather than living in
hope for another month, I thought it might be worth removing this as a blocker (I've had to tell a couple of people that they'll need to wait
before they can do their salsa-CI tests :-/ )

I'm not suggesting living in hope, I'm suggesting to get the ball rolling.

The commit lists #1066070, which was a duplicate (because -ECOFFEE) of #1066069, which got fixed rather quickly. So what we would need are
rebuilds of the reverse dependencies (which I haven't checked right now
would be sufficient to get them fixed), which one could request on the
release team side.

Regarding #1066071, that needs a fix in the package first. Looking at
tracker, it's not migrating any time soon as far as I can see (due to regressions on 32-bit arms), and I'm not sure how fixing the udeb would interfere there. So one could start with an upload.


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmYczdYACgkQ/5FK8MKz VSDyqg/+P9XvZegS9J3XFPHeFWdxF7NCtiFOgJ9NOfptH8jFta87fws8N1lJudpf aHdRagVwHklP05imi5WTBfqmjlxRuF1JADuNoIQTIZUD80e5FFbK4sSZRAIiho1z R/P7mlvtZPSlaRnJvOtL8jxjQdV2Vn6GoLyI7ILs6fDhyzKNlgeQEDDGSskwTGp/ kCkB/g386r2nH9GRP8eCKcB7ERNYQR4Mcro0cFOEMYop21EbtMhRv5+rO2M++i/p 3qpp/1lqIITN+S1ZqPjVoYIlhighBvdt/Bka7RQB5ziV8kPiZci+lKUzFwAgfG0d FnOHC8kjxTkWNaH9embRrd5+FFdveXz/OLkUxYWnalxcrNHizbmeneDHw0CG2vC/ wvZ+//ha7ltzON8ZiDmSrKSXiFieCnGkIhLr1ITrHmDh4CPTNq4b3n+Y9st0/F7Q Z8XG8BRgfmBg4wXw3e4wmGxKaR6/Ahgy5p24mbXgP2F503epBHEhjXyCzlRMm+84 o3NVlBpa0DbuuIQDuCZ7bQ1RG/DHxZIKOHj55tn0wqTvwYx5tBOU59oEQ101+LoN n8Y1koWYX/qnJvJ8ag1VHgstUbE8wRFfOLU9Mj2FCwpqIc4sNSVH38U8mkryWBfi CqL3vlqQjqkj2I2hF5oMZJD8ual+3QYFdVxw4BakI2QkahrMtG0=
=eunB
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

Cyril Brulebois <kibi@debian.org> writes:

Philip Hands <phil@hands.com> (2024-04-14):

I realised that there might be a way to kludge around the current D-I
build failures, so I gave it a try and it seems to work:

https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/45

That creates dummy udebs with the missing names, where each depends upon
the matching udeb that actually exists. Dropping them into localudebs.

That's enough to get D-I to build in salsa pipelines, such that one gets
a mini-ISO to test.

It may be enough to get D-I and debian-cd back to the point where we can
produce daily images etc. but I'm not completely sure about that bit
(perhaps the use of localudebs is enough to make debian-cd grumpy?)

Anyway, it's currently broken anyway, so perhaps it's worth giving it a
go, and then reverting the commit once the proper fixes become
available.

What do you think?

I'd rather see actual progress in getting packages fixed. So far I haven't been chasing because I thought people would be busy rebuilding the world, in the right order, and patching things along, but I had hoped to get *some* kind of feedback after filing those bug reports and putting people driving changes in the loop.

I too had rather hoped that it would already have been fixed by now.

On the other hand, it's taken over a month so far. Rather than living in
hope for another month, I thought it might be worth removing this as a
blocker (I've had to tell a couple of people that they'll need to wait
before they can do their salsa-CI tests :-/ )

I can just tell branch2repo to use the 'philh' D-I repo in the mean
time, and that'll fix the salsa-CI side of things, but that doesn't help debian-cd or people's ability to build D-I locally.

Cheers, Phil.
--
Philip Hands -- https://hands.com/~phil

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmYcyGEACgkQ0EujoAEl 1cA/7hAAlKxEvoP8bWIajofehgGP7qvMU3DWZ2t2kIC2etdeRa4Z+Hs62PnVj0Ph JqGJCNClZSZPqCW8y4WGfzGEJ9rT8GuWUXBGkM1EIcQlenWYm+o0tf9Kq/lMzedq UIXbOx0kYz2Oryq+CHbKa5CSZVOwTSvEKWxCwp2A3u4XqJptHTh0ODPdC6bbJhcZ ICCXQEEcXiWpF+YQ9mJqBi+wrUKU6o1j+Gi3Fw2WATnez5eoGkbrJvvzkjGAMjHD R3uA9Ej0PiYoicJLYjECdQw+/bKlwEK4UMQiq+5BuwRvW7N905NH6M5+khZXEUvp NAe7Tt3RoNzHhlHYZWu6XUtjnuwwsb3wJtC/+F8JWuoa9UdY6Q+CacEV8UbwQg5H d98Epvd1UUP68puty8MIzKaZPN6hlX8krK5BkzGqWVnEnCnlbhYR4zUprq6mX8eV FjDLL3p5dXtWsEk6JxmWX0DlEzfpZxsXmsriz5WzkaKwMNCLIwGNfyAAOy0+nv7m M0OFu7/4mkiqowjbI0Yl+XIILAPUo2DqiJIBqGfMSSyv8w63Rkf6EpW1ZTxALwUn 5zfnWh7/1QjnNpI2AahaL9lI4z/G3vVTGL7Fmg4cC430sGxruauLf8XN/QY3e7n6 4MAC8BnIPX9rtrfPaer6sqBUG2S9JXOK4PxavfESrrx/49aowRw=6T+h
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gatewa

Cyril Brulebois <kibi@debian.org> writes:

Philip Hands <phil@hands.com> (2024-04-15):

On the other hand, it's taken over a month so far. Rather than living in
hope for another month, I thought it might be worth removing this as a
blocker (I've had to tell a couple of people that they'll need to wait
before they can do their salsa-CI tests :-/ )

I'm not suggesting living in hope, I'm suggesting to get the ball rolling.

The commit lists #1066070, which was a duplicate (because -ECOFFEE) of #1066069, which got fixed rather quickly. So what we would need are
rebuilds of the reverse dependencies (which I haven't checked right now
would be sufficient to get them fixed), which one could request on the release team side.

Oh, I seem to have managed to overlook the bit with you closing it.
Sorry about that. Anyway, that's encouraging.

If I can work out what needs prodding, and where to prod, I'll give it a
go.

Regarding #1066071, that needs a fix in the package first. Looking at tracker, it's not migrating any time soon as far as I can see (due to regressions on 32-bit arms), and I'm not sure how fixing the udeb would interfere there. So one could start with an upload.

I had looked at fixing that, but didn't immediately know in which
direction the mismatch should be resolved which convinced me that I
probably don't know enough about the background to be doing NMUs.

Which is what lead me to try working around it instead.

Cheers, Phil.
--
Philip Hands -- https://hands.com/~phil

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmYc1nIACgkQ0EujoAEl 1cDZHg//cKG+sHTM4jnVeVukPiSJj/V4AjD8CqW19B8RGTi+4qC8XI+hk1b/nSR8 ziQ7kXuIoJ2uBtjajvv1+6w4rzOBVwT/AY6ERJVgi6u4hCFk+1ELXj3m7VUy4ikj nBfpHtXta3axKtqjKfGvDeRL0Tw15saHtJ+Q3Rix0YYwtizIVkS6w/P8xa0QrzX6 rmnB7yN3qXRhDjDKKqJe9LkdVLW5PF1/+eWYsA+OHqbLrEuPirnEWkMJkOg1cJWt g/73tv/ZW7tJZHfH325Z0nF7hnOHSpfvwi45MsMN5iaVUIhjYCejljOUX+JeipE0 RYRsgF8swaRXwBUz5OMIcYQE+LJPvsTJ+6Ac24XPzn21JzlWL3q+B0fdMC+qJK07 OdpSsfEqVsNx5XoHaZicafothUSvzatIFAJBkUHSpx4RqdpMAdV0mtypls2EwOSc WFvJmZs48/oGGrKQPT4h3IkLb7kFIC87SQxy+kYjGp/y/KsI3+iD6gQb376wdb7H 5PG6zWu/rFqe9L87+VcWr54HiOcIaw6076KbjfMS3UJ7xdOWq5Yj8NPui+yRYK19 zBCJhg8fP/Sh/FOu9VpwaIxDyQITXHSAOgplm8HaSZnaCeuNc6mDzWny0J20pSLF ZU1baJQuhRtB2Bpq6kOv4es00Lb6/Hz9ue29QP3td/5IEW4dfcQ=kihz
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gatewa