XPost: linux.debian.kernel, linux.debian.maint.boot

Hey Salvatore!

On Fri, Sep 20, 2024 at 03:46:29PM +0200, Salvatore Bonaccorso wrote:

Hope you and family are doing better already now.

Thanks!

Just double-checking as well, given debian-installer moved to testing,
is it now fine to do other src:linux uploads to unstable or are we yet >waiting to move with other changes in?

I'm happy to wait, but I think we would like to to at least another
6.10.y upload to unstable, 6.11-1~exp1 was earlier uploaded to
experimental by Ben.

Apologies for the slight delay - doing test builds here showed up a
couple of debian-cd bugs that needed fixing. All done now, though -
please go ahead!

--
Steve McIntyre, Cambridge, UK. [email protected] "Every time you use Tcl, God kills a kitten." -- Malcolm Ray

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

XPost: linux.debian.kernel, linux.debian.maint.boot

Hi,

On Sun, Sep 22, 2024 at 10:16:11AM +0100, Steve McIntyre wrote:

Hey Salvatore!

On Fri, Sep 20, 2024 at 03:46:29PM +0200, Salvatore Bonaccorso wrote:

Hope you and family are doing better already now.

Thanks!

Just double-checking as well, given debian-installer moved to testing,
is it now fine to do other src:linux uploads to unstable or are we yet >waiting to move with other changes in?

I'm happy to wait, but I think we would like to to at least another
6.10.y upload to unstable, 6.11-1~exp1 was earlier uploaded to
experimental by Ben.

Apologies for the slight delay - doing test builds here showed up a
couple of debian-cd bugs that needed fixing. All done now, though -
please go ahead!

Thanks a lot, then I'm preparing the next upload.

Regards,
Salvatore

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

Hi Alastair

On 2024-08-21 09:16:08 +0200, Sebastian Ramacher wrote:

On 2024-08-15 10:51:26 +0100, Alastair McKinstry wrote:

On 15/08/2024 10:42, Sebastian Ramacher wrote:

On 2024-07-13 10:54:19 +0100, Alastair McKinstry wrote:

On 12/07/2024 22:56, Sebastian Ramacher wrote:

On 2024-07-08 11:40:37 +0100, Alastair McKinstry wrote:

On 08/07/2024 11:34, Sebastian Ramacher wrote:

Hi Alastair

On 2024-07-07 19:20:01 +0200, Sebastian Ramacher wrote:

Control: tags -1 confirmed

On 2024-02-26 06:40:41 +0000, Alastair McKinstry wrote:

Package: release.debian.org
Severity: normal
User: [email protected]
Usertags: transition
X-Debbugs-Cc: [email protected], [email protected]
Control: affects -1 + src:mpi-defaults

OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH.

Let's go ahead with this change. Please switch the 32 bit architectures
to mpich.

Thanks for the upload of mpi-defaults. A fix for #1028172 is needed
though to continue with this transition. I would appreciate if you could
take a look at that bug.

Thanks for highlighting it. I'm preparing a fix now.

Most of the binNMUs are now scheduled. Not that https://release.debian.org/transitions/html/mpi-defaults.html still lists quite a lot of packages. Some FTBFS, but others also depend on both mpi-defaults and openmpi and build with openmpi. I would appreciate
if you could take a look at those packages and file bugs where appropriate.

Cheers

Will do.  Thanks

Let's also start the openmpi 32 bit removal transition. The tracker is https://release.debian.org/transitions/html/openmpi-rm32.html.

Same request as above: please check the packages that are marked as bad on the tracker and file bugs to change to mpich or drop the 32 bit binaries as appropriate.

Cheers

Note that mpich got caught up in the gcc 14 transition and FTBFS (#1057292) I'm working on this as I write, (there is a patch from Adrian Bunk that fails to install for me, but I have it working now and am testing on amd64).

Thanks, this upload now made its way into testing.

Are there any news regarding the upload of openmpi removing 32 bit
support?

Cheers
--
Sebastian Ramacher

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

Hi Sebastian


On 04/10/2024 22:57, Sebastian Ramacher wrote:

Hi Alastair

On 2024-08-21 09:16:08 +0200, Sebastian Ramacher wrote:

On 2024-08-15 10:51:26 +0100, Alastair McKinstry wrote:

On 15/08/2024 10:42, Sebastian Ramacher wrote:

On 2024-07-13 10:54:19 +0100, Alastair McKinstry wrote:

On 12/07/2024 22:56, Sebastian Ramacher wrote:

On 2024-07-08 11:40:37 +0100, Alastair McKinstry wrote:

On 08/07/2024 11:34, Sebastian Ramacher wrote:

Hi Alastair

On 2024-07-07 19:20:01 +0200, Sebastian Ramacher wrote:

Control: tags -1 confirmed

On 2024-02-26 06:40:41 +0000, Alastair McKinstry wrote:

Package: release.debian.org
Severity: normal
User: [email protected]
Usertags: transition
X-Debbugs-Cc: [email protected], [email protected]
Control: affects -1 + src:mpi-defaults

OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH.

Let's go ahead with this change. Please switch the 32 bit architectures
to mpich.

Thanks for the upload of mpi-defaults. A fix for #1028172 is needed >>>>>>>> though to continue with this transition. I would appreciate if you could
take a look at that bug.

Thanks for highlighting it. I'm preparing a fix now.

Most of the binNMUs are now scheduled. Not that
https://release.debian.org/transitions/html/mpi-defaults.html still >>>>>> lists quite a lot of packages. Some FTBFS, but others also depend on >>>>>> both mpi-defaults and openmpi and build with openmpi. I would appreciate >>>>>> if you could take a look at those packages and file bugs where
appropriate.

Cheers

Will do.  Thanks

Let's also start the openmpi 32 bit removal transition. The tracker is >>>> https://release.debian.org/transitions/html/openmpi-rm32.html.

Same request as above: please check the packages that are marked as bad >>>> on the tracker and file bugs to change to mpich or drop the 32 bit
binaries as appropriate.

Cheers

Note that mpich got caught up in the gcc 14 transition and FTBFS (#1057292) >>> I'm working on this as I write, (there is a patch from Adrian Bunk that
fails to install for me, but I have it working now and am testing on amd64).

Thanks, this upload now made its way into testing.

Are there any news regarding the upload of openmpi removing 32 bit
support?

Cheers

I need to do more bug submissions on the transition but mpich is
present, and I can upload openmpi 5

(there is a bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078212 that I will
close on uploading 5.0.5). I will do so when the Release Team agrees.


Regards

Alastair

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

Hi Alastair

On 2024-10-07 10:44:52 +0100, Alastair McKinstry wrote:

Let's also start the openmpi 32 bit removal transition. The tracker is
https://release.debian.org/transitions/html/openmpi-rm32.html.

Same request as above: please check the packages that are marked as bad
on the tracker and file bugs to change to mpich or drop the 32 bit binaries as appropriate.

Cheers

Note that mpich got caught up in the gcc 14 transition and FTBFS (#1057292)
I'm working on this as I write, (there is a patch from Adrian Bunk that fails to install for me, but I have it working now and am testing on amd64).

Thanks, this upload now made its way into testing.

Are there any news regarding the upload of openmpi removing 32 bit
support?

Cheers

I need to do more bug submissions on the transition but mpich is present,
and I can upload openmpi 5

(there is a bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078212 that I will close on uploading 5.0.5). I will do so when the Release Team agrees.

ACK, from our side this is good to go.

Cheers
--
Sebastian Ramacher

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

Hi Sebastian

On 12/10/2024 12:36, Sebastian Ramacher wrote:

Hi Alastair

On 2024-10-07 10:44:52 +0100, Alastair McKinstry wrote:

Let's also start the openmpi 32 bit removal transition. The tracker is >>>>>> https://release.debian.org/transitions/html/openmpi-rm32.html.

Same request as above: please check the packages that are marked as bad >>>>>> on the tracker and file bugs to change to mpich or drop the 32 bit >>>>>> binaries as appropriate.

Cheers

Note that mpich got caught up in the gcc 14 transition and FTBFS (#1057292)
I'm working on this as I write, (there is a patch from Adrian Bunk that >>>>> fails to install for me, but I have it working now and am testing on amd64).

Thanks, this upload now made its way into testing.

Are there any news regarding the upload of openmpi removing 32 bit
support?

Cheers

I need to do more bug submissions on the transition but mpich is present,
and I can upload openmpi 5

(there is a bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078212
that I will close on uploading 5.0.5). I will do so when the Release Team
agrees.

ACK, from our side this is good to go.

Cheers

Ok this is uploaded and through britney, though I need to bring git up
to date on salsa.

I'll be submitting bugs on the remaining packages.

Thanks

Alastair

--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e: [email protected], im: @alastair:mckinstry.ie @[email protected]

Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff

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

On Mon, Oct 14, 2024 at 02:25:40PM +0100, Alastair McKinstry wrote:

...
Ok this is uploaded and through britney, though I need to bring git up to date on salsa.
...

Various packages (e.g. combblas, superlu-dist, trilinos) are linked with
the libmpi_cxx that was removed in openmpi 5.

A rebuild seems to fix it.

The clean solution would be renaming the library package
(e.g. libopenmpi40), and then a transition to rebuild all
reverse dependencies.

Thanks

Alastair

cu
Adrian

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

On 18/10/2024 21:52, Adrian Bunk wrote:

On Mon, Oct 14, 2024 at 02:25:40PM +0100, Alastair McKinstry wrote:

...
Ok this is uploaded and through britney, though I need to bring git up to
date on salsa.
...

Various packages (e.g. combblas, superlu-dist, trilinos) are linked with
the libmpi_cxx that was removed in openmpi 5.

A rebuild seems to fix it.

The clean solution would be renaming the library package
(e.g. libopenmpi40), and then a transition to rebuild all
reverse dependencies.

cu
Adrian

I'll prepare this now for debian/experimental. Is there an example of
good practice with breaks/replaces/provides when doing two transitions
in one release, ie libopenmpi3->libopenmpi3t64->libopenmpi40 ?


Thanks

Alastair

--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e: [email protected], im: @alastair:mckinstry.ie @[email protected]

Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff

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

To: [email protected] (Adrian Bunk)
Copy: [email protected]

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

SGksDQoNCk9uIDIxLTEwLTIwMjQgMDY6NTcsIEFsYXN0YWlyIE1jS2luc3RyeSB3cm90ZToN Cj4gSSdsbCBwcmVwYXJlIHRoaXMgbm93IGZvciBkZWJpYW4vZXhwZXJpbWVudGFsLiBJcyB0 aGVyZSBhbiBleGFtcGxlIG9mIA0KPiBnb29kIHByYWN0aWNlIHdpdGggYnJlYWtzL3JlcGxh Y2VzL3Byb3ZpZGVzIHdoZW4gZG9pbmcgdHdvIHRyYW5zaXRpb25zIA0KPiBpbiBvbmUgcmVs ZWFzZSwgaWUgbGlib3Blbm1waTMtPmxpYm9wZW5tcGkzdDY0LT5saWJvcGVubXBpNDAgPw0K DQpZb3UgY2FuJ3QgYWRkIGEgcHJvdmlkZXMsIG90aGVyd2lzZSB5b3Ugd291bGRuJ3QgbmVl ZCB0aGUgcmVuYW1lLg0KTm9ybWFsbHkgbGlicmFyeSBwYWNrYWdlcyBhcyBjby1pbnN0YWxs YWJsZSAodGhhdCdzIHdoeSB3ZSB3YW50IG5ldyANCmJpbmFyeSBwYWNrYWdlcyB3aXRoIFNP TkFNRSBtYXRjaGluZyBuYW1lcykgYW5kIHlvdSBkb24ndCBuZWVkIGFueSANCmJyZWFrcy9y ZXBsYWNlcy4NCg0KSGF2aW5nIHNhaWQgdGhhdCwgSSB0aGluayB5b3UgY2FuIGp1c3QgYWRk IGEgQnJlYWtzL1JlcGxhY2VzIG9uIA0KbGlib3Blbm1waTN0NjQgaW4gc2FtZSB3YXkgeW91 IGFscmVhZHkgaGF2ZSBpdCBmb3IgbGlib3Blbm1waTMuDQoNCkFuZCBsb29raW5nIGF0IHRo ZSBjb250ZW50IG9mIGxpYm9wZW5tcGkzdDY0LCBJJ20gd29uZGVyaW5nIGlmIHlvdSdyZSAN Cm5vdCB2aW9sYXRpbmcgUG9saWN5IDguMSBbMV0gKHRoZSBuYW1lcyBvZiB0aGUgZmlsZXMg c3VnZ2VzdCB0aGUgDQpsaWJyYXJpZXMgZG9uJ3QgaGF2ZSB0aGUgc2FtZSBTT05BTUUpOg0K IiIiDQpJZiB5b3UgaGF2ZSBzZXZlcmFsIHNoYXJlZCBsaWJyYXJpZXMgYnVpbHQgZnJvbSB0 aGUgc2FtZSBzb3VyY2UgdHJlZSwgDQp5b3UgbWF5IGx1bXAgdGhlbSBhbGwgdG9nZXRoZXIg aW50byBhIHNpbmdsZSBzaGFyZWQgbGlicmFyeSBwYWNrYWdlIA0KcHJvdmlkZWQgdGhhdCBh bGwgb2YgdGhlaXIgU09OQU1FcyB3aWxsIGFsd2F5cyBjaGFuZ2UgdG9nZXRoZXIuDQoiIiIN Cg0KUGF1bA0KDQpbMV0gDQpodHRwczovL3d3dy5kZWJpYW4ub3JnL2RvYy9kZWJpYW4tcG9s aWN5L2NoLXNoYXJlZGxpYnMuaHRtbCNydW4tdGltZS1zaGFyZWQtbGlicmFyaWVzDQo=

--------------6xjjotX0ZeX0N1BpwXSVsGtq--

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

wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmcV6U4FAwAAAAAACgkQnFyZ6wW9dQos cAf7BumMqu8cJklQzvgJNfrtW2QGSw6Cqv5Kk4Zhdr9MJWkVxmwzjSmaU7RWHnpNEAl93jKgB1Qa zd1oev15mLPVjbM2e5R6GUSLYv1Gua+elE7/ycN6a00rZre75JzV2JHcI4aAX/tQmHfTBScjHy1U vUBvU/NxFabs/HFqiWs8labhqSY6ncwsyBJk3TKbVWtrXVAcLfEJ6Tzs7IZRhHFTALrvf7nfQ4Bx CPTjMV7x2StgsCwTb0PefbeMvtQxXN43wGJmBdQtDjMntfq1feq3V0iW6kaiAZMB4kKKBnuu53+E kcaNE06NWbl2m56Lc4+s3zjMRsCqtoUjuOgCf+Zl0A==
=cIo7
-----END PGP SIGNATURE-----

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

Hi Hans,

On Sun, Aug 25, 2024 at 03:59:06PM +0200, Hans van Kranenburg wrote:

Hi Adam,

On 8/25/24 15:26, Adam D. Barratt wrote:

I noticed that there's a xen upload in the stable-new queue, which
claims to have been uploaded by you.

I'm afraid that we can't accept it currently, because it is a newer
version than is currently in unstable and testing:

xen | 4.17.3+10-g091466ba55-1~deb12u1 | stable | source xen | 4.17.3+10-g091466ba55-1~deb12u1 | stable-debug | source xen | 4.17.3+36-g54dacb5c02-1 | testing | source xen | 4.17.3+36-g54dacb5c02-1 | unstable | source xen | 4.17.3+36-g54dacb5c02-1 | unstable-debug | source xen | 4.17.5-1~deb12u1 | stable-new | source

Fair enough. I just read this after finishing the accompanying bts bug report, which also mentions that.

We're running into problems with 4.17.5-1 for unstable, which is most
likely related to compatibility issues with newer ocaml in unstable.
This is causing crashes while testing the results, which we did not
manage to resolve so far. The Bookworm build of it tests fine, however.

So, instead of doing nothing at all, we at least wanted to share what we
have now.

Were you able to work towards that, and have unstable upload so that
xen might be included in the next point release? Note that window is
closing soon, and point release is scheduled for 9th November.

Regards,
Salvatore

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

On Mon, Oct 21, 2024 at 07:40:29AM +0200, Paul Gevers wrote:

...
And looking at the content of libopenmpi3t64, I'm wondering if you're not violating Policy 8.1 [1] (the names of the files suggest the libraries don't have the same SONAME):
"""
If you have several shared libraries built from the same source tree, you
may lump them all together into a single shared library package provided
that all of their SONAMEs will always change together.
"""

Funnily that does not even cover the problem at hand,
which is dropping of one of the same-SONAME libraries.

You are thinking towards splitting libopenmpi into 9 library packages
(one package per library).

A relevant question would be whether they are independent, or whether
mixing libraries from different OpenMPI versions in one binary might
break.

If libmpi_cxx from OpenMPI 4 does not work with libmpi from OpenMPI 5,
then co-installability is anyway not an option and having them in one
package is the easiest solution.

Paul
...

cu
Adrian

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

This is a multi-part message in MIME format.
Hi


On 04/11/2024 09:06, Adrian Bunk wrote:

On Mon, Oct 21, 2024 at 07:40:29AM +0200, Paul Gevers wrote:

...
And looking at the content of libopenmpi3t64, I'm wondering if you're not
violating Policy 8.1 [1] (the names of the files suggest the libraries don't >> have the same SONAME):
"""
If you have several shared libraries built from the same source tree, you
may lump them all together into a single shared library package provided
that all of their SONAMEs will always change together.
"""

Funnily that does not even cover the problem at hand,
which is dropping of one of the same-SONAME libraries.

You are thinking towards splitting libopenmpi into 9 library packages
(one package per library).

A relevant question would be whether they are independent, or whether
mixing libraries from different OpenMPI versions in one binary might
break.

If I have a test build of openmpi5 (libnames changed to libopenmpi40) from OpenMPI 4 does not work with libmpi from OpenMPI 5,
then co-installability is anyway not an option and having them in one
package is the easiest solution.

I have a test build of openmpi5 (libnames changed to libopenmpi40) under
test at the moment to prepare for the libopenmpi40 transition.

All of the SONAMES and ABI/APIs are preserved, except for C++ and Java
which were not formally standardized I believe. This means that both
OpenMPI 4 and OpenMPI 5 are shipping identical libraries libmpi.so.40
and so will clash. I'd need to investigate further if libmpi_cxx.so
would cope working with OpenMPI 5+ , but at minimum we would need to
ship OpenMPI4 and 5 as separate source packages, with a complex
arrangement of OpenMPI 4 only shipping libmpi_cxx.so, which I'm not sure
would work.

Longer term, we need to add symbols to OpenMPI to avoid transitions.

Alastair

Paul
...

cu
Adrian

--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e:[email protected], im: @alastair:mckinstry.ie @[email protected]

Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 04/11/2024 09:06, Adrian Bunk wrote:<br>
</div>
<blockquote type="cite" cite="mid:ZyiOiTRcosGHywQ4@localhost">
<pre wrap="" class="moz-quote-pre">On Mon, Oct 21, 2024 at 07:40:29AM +0200, Paul Gevers wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">...
And looking at the content of libopenmpi3t64, I'm wondering if you're not violating Policy 8.1 [1] (the names of the files suggest the libraries don't have the same SONAME):
"""
If you have several shared libraries built from the same source tree, you
may lump them all together into a single shared library package provided
that all of their SONAMEs will always change together.
"""
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Funnily that does not even cover the problem at hand,
which is dropping of one of the same-SONAME libraries.

You are thinking towards splitting libopenmpi into 9 library packages
(one package per library).

A relevant question would be whether they are independent, or whether
mixing libraries from different OpenMPI versions in one binary might
break.

If I have a test build of openmpi5 (libnames changed to libopenmpi40) from OpenMPI 4 does not work with libmpi from OpenMPI 5,
then co-installability is anyway not an option and having them in one
package is the easiest solution.
</pre>
</blockquote>
<p>I have a test build of openmpi5 (libnames changed to
libopenmpi40) under test at the moment to prepare for the
libopenmpi40 transition.</p>
<p>All of the SONAMES and ABI/APIs are preserved, except for C++ and
Java which were not formally standardized I believe. This means
that both OpenMPI 4 and OpenMPI 5 are shipping identical libraries
libmpi.so.40 and so will clash. I'd need to investigate further if
libmpi_cxx.so would cope working with OpenMPI 5+ , but at minimum
we would need to ship OpenMPI4 and 5 as separate source packages,
with a complex arrangement of OpenMPI 4 only shipping
libmpi_cxx.so, which I'm not sure would work.</p>
<p><span style="white-space: pre-wrap">Longer term, we need to add symbols to OpenMPI to avoid transitions.</span></p>
<p><span style="white-space: pre-wrap">
</span></p>
<p><span style="white-space: pre-wrap">Alastair
</span></p>
<blockquote type="cite" cite="mid:ZyiOiTRcosGHywQ4@localhost">
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Paul
...
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
cu
Adrian

</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>, im: @alastair:mckinstry.ie @[email protected]

Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff</pre>
</body>
</html>

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

On Mon, Nov 04, 2024 at 09:29:43AM +0000, Alastair McKinstry wrote:

Hi

On 04/11/2024 09:06, Adrian Bunk wrote:

On Mon, Oct 21, 2024 at 07:40:29AM +0200, Paul Gevers wrote:

...
And looking at the content of libopenmpi3t64, I'm wondering if you're not violating Policy 8.1 [1] (the names of the files suggest the libraries don't
have the same SONAME):
"""
If you have several shared libraries built from the same source tree, you may lump them all together into a single shared library package provided that all of their SONAMEs will always change together.
"""

Funnily that does not even cover the problem at hand,
which is dropping of one of the same-SONAME libraries.

You are thinking towards splitting libopenmpi into 9 library packages
(one package per library).

A relevant question would be whether they are independent, or whether mixing libraries from different OpenMPI versions in one binary might
break.

If I have a test build of openmpi5 (libnames changed to libopenmpi40) from OpenMPI 4 does not work with libmpi from OpenMPI 5,
then co-installability is anyway not an option and having them in one package is the easiest solution.

I have a test build of openmpi5 (libnames changed to libopenmpi40) under
test at the moment to prepare for the libopenmpi40 transition.

All of the SONAMES and ABI/APIs are preserved, except for C++ and Java which were not formally standardized I believe. This means that both OpenMPI 4 and OpenMPI 5 are shipping identical libraries libmpi.so.40 and so will clash. I'd need to investigate further if libmpi_cxx.so would cope working with OpenMPI 5+ , but at minimum we would need to ship OpenMPI4 and 5 as separate source packages, with a complex arrangement of OpenMPI 4 only shipping libmpi_cxx.so, which I'm not sure would work.

Noone wants to ship both versions in a release.

My point/question was whether e.g. mixing libraries from OpenMPI 5 and
OpenMPI 6 in a binary would work.

If OpenMPI is a collection of libraries that are only guaranteed to work together when everything is the same version, then splitting would not
bring any benefits.

Longer term, we need to add symbols to OpenMPI to avoid transitions.

Symbols don't avoid transitions.

Alastair

cu
Adrian

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

This is a multi-part message in MIME format.
On 04/11/2024 10:01, Adrian Bunk wrote:

On Mon, Nov 04, 2024 at 09:29:43AM +0000, Alastair McKinstry wrote:

Hi


On 04/11/2024 09:06, Adrian Bunk wrote:
All of the SONAMES and ABI/APIs are preserved, except for C++ and Java which >> were not formally standardized I believe. This means that both OpenMPI 4 and >> OpenMPI 5 are shipping identical libraries libmpi.so.40 and so will clash. >> I'd need to investigate further if libmpi_cxx.so would cope working with
OpenMPI 5+ , but at minimum we would need to ship OpenMPI4 and 5 as separate >> source packages, with a complex arrangement of OpenMPI 4 only shipping
libmpi_cxx.so, which I'm not sure would work.

Noone wants to ship both versions in a release.

My point/question was whether e.g. mixing libraries from OpenMPI 5 and OpenMPI 6 in a binary would work.

If OpenMPI is a collection of libraries that are only guaranteed to work together when everything is the same version, then splitting would not
bring any benefits.

I really doubt mixing libraries from 5 and 6 would work.

Longer term, we need to add symbols to OpenMPI to avoid transitions.

Symbols don't avoid transitions.

Some transitions. They don't stop all,eg removing libraries and functionality.  But they've been relatively successful in eg glibc and
MPI itself is pretty conservative in removing stuff.

Alastair

cu
Adrian

--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e:[email protected], im: @alastair:mckinstry.ie @[email protected]

Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 04/11/2024 10:01, Adrian Bunk wrote:<br>
</div>
<blockquote type="cite" cite="mid:ZyibhBLwJ2XvobYG@localhost">
<pre wrap="" class="moz-quote-pre">On Mon, Nov 04, 2024 at 09:29:43AM +0000, Alastair McKinstry wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Hi


On 04/11/2024 09:06, Adrian Bunk wrote:
</pre>
<pre wrap="" class="moz-quote-pre">
All of the SONAMES and ABI/APIs are preserved, except for C++ and Java which were not formally standardized I believe. This means that both OpenMPI 4 and OpenMPI 5 are shipping identical libraries libmpi.so.40 and so will clash.
I'd need to investigate further if libmpi_cxx.so would cope working with OpenMPI 5+ , but at minimum we would need to ship OpenMPI4 and 5 as separate source packages, with a complex arrangement of OpenMPI 4 only shipping libmpi_cxx.so, which I'm not sure would work.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Noone wants to ship both versions in a release.

My point/question was whether e.g. mixing libraries from OpenMPI 5 and
OpenMPI 6 in a binary would work.

If OpenMPI is a collection of libraries that are only guaranteed to work together when everything is the same version, then splitting would not
bring any benefits.
</pre>
</blockquote>
<p>I really doubt mixing libraries from 5 and 6 would work.</p>
<blockquote type="cite" cite="mid:ZyibhBLwJ2XvobYG@localhost">
<pre wrap="" class="moz-quote-pre">
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Longer term, we need to add symbols to OpenMPI to avoid transitions.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Symbols don't avoid transitions.</pre>
</blockquote>
<p>Some transitions. They don't stop all,eg removing libraries and
functionality.  But they've been relatively successful in eg glibc
and MPI itself is pretty conservative in removing stuff.<span
style="white-space: pre-wrap">
</span></p>
<blockquote type="cite" cite="mid:ZyibhBLwJ2XvobYG@localhost">
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Alastair
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
cu
Adrian

</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>, im: @alastair:mckinstry.ie @[email protected]

Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff</pre>
</body>
</html>

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

XPost: linux.debian.ports.arm, linux.debian.security

On 2024-08-16 10:25, Emanuele Rocca wrote:

Martin, I think you and your employer were looking for ways to help the armhf/armel ports. This looks like a great one! :)

Noted ;-)

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

On Sun, 2024-08-25 at 15:59 +0200, Hans van Kranenburg wrote:

Hi Adam,

On 8/25/24 15:26, Adam D. Barratt wrote:

I noticed that there's a xen upload in the stable-new queue, which
claims to have been uploaded by you.

I'm afraid that we can't accept it currently, because it is a newer
version than is currently in unstable and testing:

[...]

Fair enough. I just read this after finishing the accompanying bts
bug report, which also mentions that.

We're running into problems with 4.17.5-1 for unstable, which is most
likely related to compatibility issues with newer ocaml in unstable.

We now have 4.19.1 in unstable, and after DSA 5836-1, both 4.17.5-
1~deb12u1 and 4.17.5+23-ga4e5191dc0-1 in stable-new. Should the former
be rejected in favour of the version from the DSA?

I'm tempted to leave the packages in stable-new in any case until the
new version manages to migrate to testing, just to avoid any potential
version skew issues as we're not far off the next point release.

Regards,

Adam

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

Hi,

On 28/12/2024 22:43, Adam D. Barratt wrote:

On Sun, 2024-08-25 at 15:59 +0200, Hans van Kranenburg wrote:

Hi Adam,

On 8/25/24 15:26, Adam D. Barratt wrote:

I noticed that there's a xen upload in the stable-new queue, which
claims to have been uploaded by you.

I'm afraid that we can't accept it currently, because it is a newer
version than is currently in unstable and testing:

[...]

Fair enough. I just read this after finishing the accompanying bts
bug report, which also mentions that.

We're running into problems with 4.17.5-1 for unstable, which is most
likely related to compatibility issues with newer ocaml in unstable.

We now have 4.19.1 in unstable, and after DSA 5836-1, both 4.17.5-
1~deb12u1 and 4.17.5+23-ga4e5191dc0-1 in stable-new. Should the former
be rejected in favour of the version from the DSA?

I'm tempted to leave the packages in stable-new in any case until the
new version manages to migrate to testing, just to avoid any potential

Sorry for the confusion.

Some people in the team had some struggles last year (*cough*).

We have 4.19.1-1 right now in sid, yay.

You can totally disregard and/or delete the 4.17.5-1~deb12u1 thing.

The 4.17.5+23-ga4e5191dc0-1 security update is the newer thing we want
instead.

Hans

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

On Sat, Dec 28, 2024 at 11:35:01PM +0100, Hans van Kranenburg wrote:

Hi,

On 28/12/2024 22:43, Adam D. Barratt wrote:

On Sun, 2024-08-25 at 15:59 +0200, Hans van Kranenburg wrote:

Hi Adam,

On 8/25/24 15:26, Adam D. Barratt wrote:

I noticed that there's a xen upload in the stable-new queue, which
claims to have been uploaded by you.

I'm afraid that we can't accept it currently, because it is a newer
version than is currently in unstable and testing:

[...]

Fair enough. I just read this after finishing the accompanying bts
bug report, which also mentions that.

We're running into problems with 4.17.5-1 for unstable, which is most
likely related to compatibility issues with newer ocaml in unstable.

We now have 4.19.1 in unstable, and after DSA 5836-1, both 4.17.5- 1~deb12u1 and 4.17.5+23-ga4e5191dc0-1 in stable-new. Should the former
be rejected in favour of the version from the DSA?

I'm tempted to leave the packages in stable-new in any case until the
new version manages to migrate to testing, just to avoid any potential

Sorry for the confusion.

Some people in the team had some struggles last year (*cough*).

We have 4.19.1-1 right now in sid, yay.

You can totally disregard and/or delete the 4.17.5-1~deb12u1 thing.

Rejected from p-u-new.

The 4.17.5+23-ga4e5191dc0-1 security update is the newer thing we want instead.

You need to get a higher version into testing too before we can accept the security update into stable. Because you dropped armhf you need that architecture cleaned up in sid, which means first fixing reverse
dependencies:

| # Broken Depends:
| kexec-tools: kexec-tools
| kexec-tools-udeb
| libvirt: libvirt-daemon-driver-xen
|
| # Broken Build-Depends:
| collectd: libxen-dev
| kexec-tools: libxen-dev
| libvirt: libxen-dev
| systemd: libxen-dev


--
Jonathan Wiltshire [email protected]
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

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

On Fri, Dec 22, 2023 at 09:54:45AM +0100, Moritz Muehlenhoff wrote:

One solution which has been discussed in the past is to import a full copy
of stable towards stable-security at the beginning of each release cycle,
but that is currently not possible since security-master is a Ganeti VM
and the disk requirements for a full archive copy would rather require
a baremetal host.

I don't think we are constrained by disk space here. I understand you
are talking about a full import here, rather than referencing data
elsewhere. We could make disk available for that.

But it'd be nicer if dak could do an overlay pool. I feel like people
might in general want to be able to do that. Replicating projectb onto
the VM would be one option - I think we'd not even need the data pool,
as all checksums are in the files table anyway. If we need to provide
a mirror to the VM, we can do that via NFS.

There's a security question here somewhere about importing untrusted
data from other places, but we are already ultimately trusting
ftp-master so I'm not sure it actually makes a different.

Kind regards
Philipp Kern

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