Copy: [email protected] (debian-release)

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

RGVhciBEU0EsDQoNCkFzIGlzIGN1c3RvbSBmb3IgdGhlIFJlbGVhc2UgVGVhbSwgSSdtIGFz a2luZyB5b3Ugd2hhdCB5b3VyIHBsYW5zIGFyZQ0Kd2l0aCByZXNwZWN0IHRvIHRlc3Rpbmcg dXBncmFkaW5nIERTQSBtYWludGFpbmVkIG1hY2hpbmVzIHRvIHRyaXhpZS4NCg0KSWYgbXkg aW5mb3JtYXRpb24gaXMgY29ycmVjdCwgaW4gdGhlIHBhc3QgeW91J2QgZmlyc3QgdXBncmFk ZSBhIG5vbg0KY3JpdGljYWwgbWFjaGluZSB0byBzZWUgaWYgdGhlcmUncyBhbnl0aGluZyBi cm9rZW4gaW4gdHJpeGllIHRoYXQNCnByZXZlbnRzIHlvdSBmcm9tIG1haW50YWluaW5nIHRo ZSBtYWNoaW5lcyBpbiBhIGRlY2VudCBtYW5uZXIuIFdoZW4NCnRoaW5ncyBsb29rIE9LLCBJ IHVuZGVyc3RhbmQgaXQncyBjdXN0b20gdG8gdXBncmFkZSBhdCBsZWFzdCBvbmUgYnVpbGRk DQpmb3IgZXZlcnkgcmVsZWFzZSBhcmNoaXRlY3R1cmUgdG8gc2VlIGlmIGFsbCBhcmNoaXRl Y3R1cmUgYnVpbGRkcyByZW1haW4NCndvcmtpbmcgYXMgdGhleSBzaG91bGQgb24gdHJpeGll Lg0KDQpJJ2QgbGlrZSB0byB3YXJuIHlvdSBvbiB0aGlzIGZyb250IGFscmVhZHkgd2l0aCBt eSBleHBlcmllbmNlIGZyb20gDQp1cGdyYWRpbmcgY2kuZC5uIG1hY2hpbmVzIHRoaXMgd2Vl ayAoc2VlIGJhY2tsb2cgb2YgI2QtZGV2ZWwgaWYgeW91IGhhdmUgDQppdCkuIER1ZSB0byBj aGFuZ2VzIGluIHN5c3RlbWQgdGhhdCByYWlzZSB0aGUgYW1vdW50IG9mIG9wZW4gZmlsZSAN CmRlc2NyaXB0b3JzIFsxXSwgc29tZSBidWlsZHMgYW5kIHRlc3RzIG1heSB0aW1lb3V0IG9y IHVzZSBhYnN1cmQgYW1vdW50IA0Kb2YgUkFNLCBlLmcuIFsyXS4gSSBoYWQgdG8gbGltaXQg ZnMubnJfb3BlbiBbM10gdG8gdGhlIGJvb2t3b3JtIHZhbHVlcyANCnRvIHByZXZlbnQgYmFk IGJlaGF2aW9yIHRha2luZyB0aGUgc2VydmljZSBkb3duLCBldmVuIGlmIHRoaW5ncyBhcmUg DQpmaXhlZCBpbiB1bnN0YWJsZS90cml4aWUuDQoNClBhdWwNCg0KWzFdIGh0dHBzOi8vbGlz dHMuZGViaWFuLm9yZy9kZWJpYW4tZGV2ZWwvMjAyNC8wNi9tc2cwMDA0MS5odG1sDQpbMl0g aHR0cHM6Ly9idWdzLmRlYmlhbi5vcmcvMTA3MzA0Ng0KWzNdIA0KaHR0cHM6Ly9zYWxzYS5k ZWJpYW4ub3JnL2NpLXRlYW0vZGViaWFuLWNpLWNvbmZpZy8tL2NvbW1pdC82MzJjYzFlNGFi NDZlZGI0OWIxYzRiZjNmNGU5ZTZhMGQ4Mzk0NDQyDQo=

--------------KDPCkRGfzeVheLW0H80ouEw6--

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

wsC7BAABCABvBYJoQ0IfCRCcXJnrBb11CkcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmeI4xEjN78SIXfNITaLjiInl5n/i67ogOMjlQVbT5WP NhYhBFi2bUhza+k7BS3mcpxcmesFvXUKAABm5wf/VKkfDhZvzjySZMKMjN22LsJi VxU7N2cuCrbYbjMaqLv0S6Q30nH+wfe9liw2Mh2Q5KYthw8qPReEhogv0xK8bVVU 6IvVoRnznkIRNKz4bnKcrjnC+wsRAF4sEV8UnHG04hKnvbwKyTqiBp+yDq44nS46 Wp0rrpduLKMD16+ykDgpPlMgAEm5lgKQBZucs0eIQlQ+9AvLrpVlrA9ZhOlA1P6a mdp0Om5FBozJvibNWBQF558p1FqMnKtH7+bjfsZ4tuDvU5R6ngohrn5ZAorKRbRy i1z8rrTqrIL5gFDfDzSUaIJslJS/iVSMk67FH8o8gpuWoG+fLm7kLsSFS0S1NQ==
=m0Ht
-----END PGP SIGNATURE-----

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

Hi,

On 6/6/25 9:31 PM, Paul Gevers wrote:

As is custom for the Release Team, I'm asking you what your plans are
with respect to testing upgrading DSA maintained machines to trixie.

If my information is correct, in the past you'd first upgrade a non
critical machine to see if there's anything broken in trixie that
prevents you from maintaining the machines in a decent manner. When
things look OK, I understand it's custom to upgrade at least one buildd
for every release architecture to see if all architecture buildds remain working as they should on trixie.

I'd like to warn you on this front already with my experience from
upgrading ci.d.n machines this week (see backlog of #d-devel if you have
it). Due to changes in systemd that raise the amount of open file
descriptors [1], some builds and tests may timeout or use absurd amount
of RAM, e.g. [2]. I had to limit fs.nr_open [3] to the bookworm values
to prevent bad behavior taking the service down, even if things are
fixed in unstable/trixie.

Current progress: arm-conova-01, x86-grnet-01, ppc64el-conova-01 are
upgraded. I did not touch s390x yet. riscv64 is all trixie anyway (and
physical machines). mips64el I cannot upgrade.

All of the upgraded hosts of these were VMs, we should still also try to upgrade physical hosts - but AFAICS for arm64 and ppc64el all physical
machines we have today are part of Ganeti clusters and it'd be unwise to upgrade them individually. For x86 I'm not that worried, but we could do
that.

So I think we ultimately would need to figure out if there's a working
Ganeti in trixie and go and upgrade single clusters. (Preferably
starting with an x86 cluster, so that we don't run into architecture
specific issues on top of that on arm64, or ppc64el (where we only have
single host clusters).

Kind regards
Philipp Kern

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

On 6/13/25 12:42 PM, Philipp Kern wrote:

On 6/6/25 9:31 PM, Paul Gevers wrote:

As is custom for the Release Team, I'm asking you what your plans are
with respect to testing upgrading DSA maintained machines to trixie.

If my information is correct, in the past you'd first upgrade a non
critical machine to see if there's anything broken in trixie that
prevents you from maintaining the machines in a decent manner. When
things look OK, I understand it's custom to upgrade at least one buildd
for every release architecture to see if all architecture buildds remain
working as they should on trixie.

I'd like to warn you on this front already with my experience from
upgrading ci.d.n machines this week (see backlog of #d-devel if you have
it). Due to changes in systemd that raise the amount of open file
descriptors [1], some builds and tests may timeout or use absurd amount
of RAM, e.g. [2]. I had to limit fs.nr_open [3] to the bookworm values
to prevent bad behavior taking the service down, even if things are
fixed in unstable/trixie.

Current progress: arm-conova-01, x86-grnet-01, ppc64el-conova-01 are upgraded. I did not touch s390x yet. riscv64 is all trixie anyway (and physical machines). mips64el I cannot upgrade.

All of the upgraded hosts of these were VMs, we should still also try to upgrade physical hosts - but AFAICS for arm64 and ppc64el all physical machines we have today are part of Ganeti clusters and it'd be unwise to upgrade them individually. For x86 I'm not that worried, but we could do that.

So I think we ultimately would need to figure out if there's a working
Ganeti in trixie and go and upgrade single clusters. (Preferably
starting with an x86 cluster, so that we don't run into architecture
specific issues on top of that on arm64, or ppc64el (where we only have single host clusters).

ppc64el was successful (prokofiev) with some snags hit in the process
that were easy to resolve. That leaves one of the ARM clusters and
potentially one of the x86 clusters.

Kind regards
Philipp Kern

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