Re: Re-planning for 12.6
Just one thing could you please pull all world wide repos so the repos that are new are there and defunct repositories don’t appear. My repositories have been registered repositories for years and newer been in one release Mike Hosken Sent via my iPhone > On 3 Apr 2024, at 08:40, Jonathan Wiltshire wrote: > > On Mon, Apr 01, 2024 at 01:07:27PM +0100, Adam D. Barratt wrote: >> April 13th >> April 20th >> April 27th > > At current progress I expect to be available for the SRM side 13th or 27th. > We're in a good position to freeze this weekend to make the 13th, if others > are available then. > > The 20th is a no for me. > >> May 4th >> May 11th > > Currently OK for me. > > Though as soon as we're heading into the middle of May we might as well > wait for the next cadence in June. > > -- > Jonathan Wiltshire j...@debian.org > Debian Developer http://people.debian.org/~jmw > > 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 > ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1 >
NEW changes in oldstable-new
Processing changes file: gnutls28_3.7.1-5+deb11u5_all-buildd.changes ACCEPT Processing changes file: gnutls28_3.7.1-5+deb11u5_mips64el-buildd.changes ACCEPT Processing changes file: gnutls28_3.7.1-5+deb11u5_mipsel-buildd.changes ACCEPT Processing changes file: gross_1.0.2-4.1~deb11u1_mips64el-buildd.changes ACCEPT Processing changes file: gross_1.0.2-4.1~deb11u1_mipsel-buildd.changes ACCEPT
Re: Re-planning for 12.6
On Mon, Apr 01, 2024 at 01:07:27PM +0100, Adam Barratt wrote: >Hi, > >As we had to postpone 12.6, let's look at alternative dates. > >April 13th >- Not great for me for personal reasons, mhy previously said no. I >could probably do if need be Works for me. >April 20th >- Doesn't work for me; I'm away from the Tuesday before until late on >the Friday Works for me. >April 27th >- Doesn't work for me; I have a pre-existing appointment which means >I'll be AFK much of the day Works for me. >May 4th >- Apparently doesn't work for me; long weekend in the UK > Works for me. >May 11th >- Should work for me Nope, already booked for that Saturday. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
NEW changes in oldstable-new
Processing changes file: gnutls28_3.7.1-5+deb11u5_amd64-buildd.changes ACCEPT Processing changes file: gnutls28_3.7.1-5+deb11u5_arm64-buildd.changes ACCEPT Processing changes file: gnutls28_3.7.1-5+deb11u5_armel-buildd.changes ACCEPT Processing changes file: gnutls28_3.7.1-5+deb11u5_armhf-buildd.changes ACCEPT Processing changes file: gnutls28_3.7.1-5+deb11u5_i386-buildd.changes ACCEPT Processing changes file: gnutls28_3.7.1-5+deb11u5_ppc64el-buildd.changes ACCEPT Processing changes file: gnutls28_3.7.1-5+deb11u5_s390x-buildd.changes ACCEPT Processing changes file: gross_1.0.2-4.1~deb11u1_s390x-buildd.changes ACCEPT
NEW changes in oldstable-new
Processing changes file: gross_1.0.2-4.1~deb11u1_amd64-buildd.changes ACCEPT Processing changes file: gross_1.0.2-4.1~deb11u1_arm64-buildd.changes ACCEPT Processing changes file: gross_1.0.2-4.1~deb11u1_armel-buildd.changes ACCEPT Processing changes file: gross_1.0.2-4.1~deb11u1_armhf-buildd.changes ACCEPT Processing changes file: gross_1.0.2-4.1~deb11u1_i386-buildd.changes ACCEPT Processing changes file: gross_1.0.2-4.1~deb11u1_ppc64el-buildd.changes ACCEPT
NEW changes in oldstable-new
Processing changes file: amavisd-new_2.11.1-6_amd64.changes REJECT Processing changes file: gnutls28_3.7.1-5+deb11u5_multi.changes ACCEPT Processing changes file: gross_1.0.2-4.1~deb11u1_source.changes ACCEPT Processing changes file: mediawiki_1.35.13-1+deb11u2_source.changes ACCEPT Processing changes file: mediawiki_1.35.13-1+deb11u2_all-buildd.changes ACCEPT Processing changes file: py7zr_0.11.3+dfsg-1+deb11u1_source.changes ACCEPT Processing changes file: py7zr_0.11.3+dfsg-1+deb11u1_all-buildd.changes ACCEPT Processing changes file: py7zr_0.11.3+dfsg-1+deb11u1_amd64-buildd.changes ACCEPT Processing changes file: py7zr_0.11.3+dfsg-1+deb11u1_arm64-buildd.changes ACCEPT Processing changes file: py7zr_0.11.3+dfsg-1+deb11u1_armel-buildd.changes ACCEPT Processing changes file: py7zr_0.11.3+dfsg-1+deb11u1_armhf-buildd.changes ACCEPT Processing changes file: py7zr_0.11.3+dfsg-1+deb11u1_i386-buildd.changes ACCEPT Processing changes file: py7zr_0.11.3+dfsg-1+deb11u1_mips64el-buildd.changes ACCEPT Processing changes file: py7zr_0.11.3+dfsg-1+deb11u1_mipsel-buildd.changes ACCEPT Processing changes file: py7zr_0.11.3+dfsg-1+deb11u1_ppc64el-buildd.changes ACCEPT Processing changes file: py7zr_0.11.3+dfsg-1+deb11u1_s390x-buildd.changes ACCEPT Processing changes file: samba_4.13.13+dfsg-1~deb11u6_source.changes ACCEPT Processing changes file: samba_4.13.13+dfsg-1~deb11u6_all-buildd.changes ACCEPT Processing changes file: samba_4.13.13+dfsg-1~deb11u6_amd64-buildd.changes ACCEPT Processing changes file: samba_4.13.13+dfsg-1~deb11u6_arm64-buildd.changes ACCEPT Processing changes file: samba_4.13.13+dfsg-1~deb11u6_armel-buildd.changes ACCEPT Processing changes file: samba_4.13.13+dfsg-1~deb11u6_armhf-buildd.changes ACCEPT Processing changes file: samba_4.13.13+dfsg-1~deb11u6_i386-buildd.changes ACCEPT Processing changes file: samba_4.13.13+dfsg-1~deb11u6_mips64el-buildd.changes ACCEPT Processing changes file: samba_4.13.13+dfsg-1~deb11u6_mipsel-buildd.changes ACCEPT Processing changes file: samba_4.13.13+dfsg-1~deb11u6_ppc64el-buildd.changes ACCEPT Processing changes file: samba_4.13.13+dfsg-1~deb11u6_s390x-buildd.changes ACCEPT Processing changes file: util-linux_2.36.1-8+deb11u2_source.changes ACCEPT Processing changes file: util-linux_2.36.1-8+deb11u2_all-buildd.changes ACCEPT Processing changes file: util-linux_2.36.1-8+deb11u2_amd64-buildd.changes ACCEPT Processing changes file: util-linux_2.36.1-8+deb11u2_arm64-buildd.changes ACCEPT Processing changes file: util-linux_2.36.1-8+deb11u2_armel-buildd.changes ACCEPT Processing changes file: util-linux_2.36.1-8+deb11u2_armhf-buildd.changes ACCEPT Processing changes file: util-linux_2.36.1-8+deb11u2_i386-buildd.changes ACCEPT Processing changes file: util-linux_2.36.1-8+deb11u2_mips64el-buildd.changes ACCEPT Processing changes file: util-linux_2.36.1-8+deb11u2_mipsel-buildd.changes ACCEPT Processing changes file: util-linux_2.36.1-8+deb11u2_ppc64el-buildd.changes ACCEPT Processing changes file: util-linux_2.36.1-8+deb11u2_s390x-buildd.changes ACCEPT
Bug#1064810: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
On 2024-04-02 07:13:38 +0100, Alastair McKinstry wrote: > > On 01/04/2024 23:25, Sebastian Ramacher wrote: > > > There is a transition to openmpi-5 / mpi-defaults which is stalled by the > > > t64 transition. > > > > > > It drops 32-bit support from OpenMPI. > > > > > > Because of this, I don't think the solution is to port 32-bit atomics for > > > armel/armhf, as it will be removed in a few weeks/months. > > > > > > While we didn't want the transitions to be done simultaneously, it might > > > be > > > the best answer. > > > > > > > > > What does the release team think? > > Adding another transition on top will just delay the time_t transition > > even more. So if we can avoid that, I'd prefer to not do this transition > > now. Unfortunately, uploads such as the one of pmix that no dropped > > support for 32 bit architectures (#1068211) are not really helpful. > > > > Also, #1064810 has no information on test builds with the new > > mpi-defaults on a 32 bit architecture. So has this transition been > > tested? > > > > Cheers > > OpenMPI 5 drops 32-bit support, but otherwise does not change the API/ABI. > So it is technically not a transition, but breaks 32-bit builds. Doesn't make it better. This is not the time to do that without tests builds and bugs filed. > The solution is changing mpi-defaults to MPICH for 32-bit archs. MPICH > builds on all archs, but testing all dependencies of the change has not been > tested, and I don't know how you would do that - setting up eg ratt to > rebuild all on 32-bit archs (as everything on 64-bit will not have changed.) Beside the easy part of chaning mpi-defaults, I count 30 something packages that have explicit build dependencies on libopenmpi-dev. None of those packages has bugs filed to change to mpich on 32 bit architectures. To be honest, I don't see these two changes (changing mpi-defaults to mpich on 32 bit; breaking 32 bit build of openmpi) to be ready. It'd be preferable to reinstate a 32-bit compatible pmix and fix openmpi on 32 bit until the time_t transition is done. Cheers -- Sebastian Ramacher
Processed: gnutls28 3.7.1-5+deb11u5 flagged for acceptance
Processing commands for cont...@bugs.debian.org: > package release.debian.org Limiting to bugs with field 'package' containing at least one of 'release.debian.org' Limit currently set to 'package':'release.debian.org' > tags 1061190 = bullseye pending Bug #1061190 [release.debian.org] bullseye-pu: package gnutls28/3.7.1-5+deb11u5 Added tag(s) pending; removed tag(s) confirmed. > thanks Stopping processing here. Please contact me if you need assistance. -- 1061190: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061190 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1068034: gross 1.0.2-4.1~deb11u1 flagged for acceptance
package release.debian.org tags 1068034 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: gross Version: 1.0.2-4.1~deb11u1 Explanation: fix stack-based buffer overflow [CVE-2023-52159]
Processed: gross 1.0.2-4.1~deb11u1 flagged for acceptance
Processing commands for cont...@bugs.debian.org: > package release.debian.org Limiting to bugs with field 'package' containing at least one of 'release.debian.org' Limit currently set to 'package':'release.debian.org' > tags 1068034 = bullseye pending Bug #1068034 [release.debian.org] bullseye-pu: package gross/1.0.2-4.1~deb11u1 Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 1068034: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068034 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1061190: gnutls28 3.7.1-5+deb11u5 flagged for acceptance
package release.debian.org tags 1061190 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: gnutls28 Version: 3.7.1-5+deb11u5 Explanation: fix assertion failure verifying a certificate chain with a cycle of cross signatures [CVE-2024-0567]; fix timing side-channel attack inside RSA-PSK key exchange [CVE-2024-0553]
Bug#1067953: transition: flint
Control: tags -1 confirmed On 2024-03-29 12:46:50 +, Torrance, Douglas wrote: > Package: release.debian.org > Control: affects -1 + src:flint > X-Debbugs-Cc: fl...@packages.debian.org > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: dtorra...@piedmont.edu > Severity: normal > > Dear Release Team, > > I would like to request a transition slot for flint. The recent upstream > release 3.1.0 introduced the new soversion flint 19. A new binary package, > libflint19, was introduced in the source package flint 3.1.2-1~exp1, which > cleared the NEW queue on March 28 and is now in experimental. > > flint 3.1.1-1 already exists in unstable, which ships libflint.so.19 in > the libflint18t64 binary package. However, flint 3.0.1-3.1 had been > previously uploaded for the t64 transition, shipping libflint.so.18 in > the same binary package. This is RC bug #1067226 and has resulted in > several other RC bugs in reverse dependencies. Please go ahead so that reverse dpeendencies can actually build again. > An auto-flint tracker already exists for the t64 transition, but it doesn't > take the new libflint19 package into account. (Although perhaps this will > update automatically at some point?) > > binNMU's should be sufficient for each of flint's reverse dependencies: > > * e-antic > * gyoto > * macaulay2 > * msolve > * normaliz > * polymake > * singular Please perform test builds or track the rebuilds for build failures. Cheers > > Ben file: > > title = "flint"; > is_affected = (.build-depends ~ /\blibflint-dev\b/) | (.depends ~ > /\blibflint(?:18|18t64|19)\b/); > is_good = .depends ~ /\blibflint19\b/; > is_bad = .depends ~ /\blibflint18(?:t64)?\b/; > > Thank you! -- Sebastian Ramacher
Processed: Re: Bug#1067953: transition: flint
Processing control commands: > tags -1 confirmed Bug #1067953 [release.debian.org] transition: flint Added tag(s) confirmed. -- 1067953: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067953 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Re-planning for 12.6
On Mon, Apr 01, 2024 at 01:07:27PM +0100, Adam D. Barratt wrote: > April 13th > April 20th > April 27th At current progress I expect to be available for the SRM side 13th or 27th. We're in a good position to freeze this weekend to make the 13th, if others are available then. The 20th is a no for me. > May 4th > May 11th Currently OK for me. Though as soon as we're heading into the middle of May we might as well wait for the next cadence in June. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Processed: Re: Bug#1068016: bookworm-pu: package node-babel7/7.20.15+ds1+~cs214.269.168-3+deb12u2
Processing control commands: > tag -1 - confirmed + moreinfo Bug #1068016 [release.debian.org] bookworm-pu: package node-babel7/7.20.15+ds1+~cs214.269.168-3+deb12u2 Removed tag(s) confirmed. Bug #1068016 [release.debian.org] bookworm-pu: package node-babel7/7.20.15+ds1+~cs214.269.168-3+deb12u2 Added tag(s) moreinfo. > block -1 with 1063530 Bug #1068016 [release.debian.org] bookworm-pu: package node-babel7/7.20.15+ds1+~cs214.269.168-3+deb12u2 1068016 was not blocked by any bugs. 1068016 was blocking: 1037234 Added blocking bug(s) of 1068016: 1063530 -- 1068016: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068016 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1068016: bookworm-pu: package node-babel7/7.20.15+ds1+~cs214.269.168-3+deb12u2
Control: tag -1 - confirmed + moreinfo Control: block -1 with 1063530 On 29/03/2024 18.08, Adam D. Barratt wrote: On Fri, 2024-03-29 at 17:41 +0100, Andreas Beckmann wrote: To smoothen some upgrade paths from buster -> bullseye -> bookworm we need to add some Breaks+Replaces against obsolete packages. node-babel7 currently FTBFS due to nodejs 18.19 in bookworm (+security), that seems to require a fix in node-undici first (#1063530) and probably a followup fix from node-babel7 7.20.15+ds1+~cs214.269.168-6, so maybe we should just rebuild the sid version as 7.20.15+ds1+~cs214.269.168-6~deb12u1 Andreas
Re: Re-planning for 12.6
Hi, On Mon, 01, Apr, 2024 at 01:07:27PM +0100, Adam D. Barratt spoke thus.. > April 13th > - Not great for me for personal reasons, mhy previously said no. I > could probably do if need be 13th is completely out for me. > May 11th > - Should work for me Looks like it'll work at present. Thanks, Mark -- Mark Hymers signature.asc Description: PGP signature
Processed: affects 1068242, block 1039583 with 1068242, block 1039612 with 1068242
Processing commands for cont...@bugs.debian.org:
> affects 1068242 + src:libtool
Bug #1068242 [release.debian.org] bookworm-pu: package libtool/2.4.7-7~deb12u1
Added indication that 1068242 affects src:libtool
> block 1039583 with 1068242
Bug #1039583 {Done: Alastair McKinstry } [libltdl-dev]
libltdl-dev: missing Breaks+Replaces: libltdl3-dev
1039583 was not blocked by any bugs.
1039583 was not blocking any bugs.
Added blocking bug(s) of 1039583: 1068242
> block 1039612 with 1068242
Bug #1039612 {Done: Alastair McKinstry } [libtool]
libtool: Incorrect check for += operator causes func_append to fail
1039612 was not blocked by any bugs.
1039612 was not blocking any bugs.
Added blocking bug(s) of 1039612: 1068242
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
1039583: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039583
1039612: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039612
1068242: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068242
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1068242: bookworm-pu: package libtool/2.4.7-7~deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Alastair McKinstry
[ Reason ]
I'd like to rebuild libtool from sid in order to fix two RC bugs:
* missing Conflicts against an obsolete (now virtual) package name
causing file conflicts on some upgrade paths of systems initially
installed while the obsolete package was still a real package
* incorrect detection of the += feature causing problems for packages
using it
[ Impact ]
Some upgrade paths not working (mostly triggered by QA tools).
Operator += not working.
[ Tests ]
Manual piuparts upgrade tests of the affected upgrade paths.
Both changes have been in sid since July without followup issues.
[ Risks ]
In case of regression, we could revert each of the two fixes
separately.
[ Checklist ]
[*] *all* changes are documented in the d/changelog
[*] I reviewed all changes and I approve them
[*] attach debdiff against the package in (old)stable
[*] the issue is verified as fixed in unstable
[ Changes ]
+libtool (2.4.7-7~deb12u1) bookworm; urgency=medium
+
+ * Non-maintainer upload.
+ * Rebuild for bookworm.
+ * Reinstate obsolete Breaks, Provides.
+
+ -- Andreas Beckmann Thu, 28 Mar 2024 13:23:40 +0100
+
+libtool (2.4.7-7) unstable; urgency=medium
+
+ * Remove obsole Breaks: for oldstable , Provides: libltdl7-dev
+ * Replace Breaks: libltdl3-dev with Conflicts: libltdl3-dev.
+Thanks Andreas Beckmann. Closes: #1041229
+
+ -- Alastair McKinstry Mon, 17 Jul 2023 16:03:58 +0100
+
+libtool (2.4.7-6) unstable; urgency=medium
+
+ * Incorrect check for += operator causes func_append to fail
+Patch from Ernesto Alfonso. Closes: #1039612
+ * Standards-Version: 4.6.2
+ * Add Breaks/Replaces on libtldl3-dev. Closes: #1039583
+
+ -- Alastair McKinstry Sat, 15 Jul 2023 09:09:39 +0100
changelog | 25
control |4 +
patches/0090-shell-op.patch | 126
patches/series |1
4 files changed, 155 insertions(+), 1 deletion(-)
[ Other info ]
This is a rebuild of the package from sid with the removal of some
obsolete Breaks/Replaces reverted to minimize the diff from stable.
There is an unneeded and useless (because misspelled) Replaces being
added. I'm not fixing (i.e. dropping) that because it's harmless and I
do not want to deviate from sid too much.
Andreas
diff -Nru libtool-2.4.7/debian/changelog libtool-2.4.7/debian/changelog
--- libtool-2.4.7/debian/changelog 2022-11-23 12:34:12.0 +0100
+++ libtool-2.4.7/debian/changelog 2024-03-28 13:23:40.0 +0100
@@ -1,3 +1,28 @@
+libtool (2.4.7-7~deb12u1) bookworm; urgency=medium
+
+ * Non-maintainer upload.
+ * Rebuild for bookworm.
+ * Reinstate obsolete Breaks, Provides.
+
+ -- Andreas Beckmann Thu, 28 Mar 2024 13:23:40 +0100
+
+libtool (2.4.7-7) unstable; urgency=medium
+
+ * Remove obsole Breaks: for oldstable , Provides: libltdl7-dev
+ * Replace Breaks: libltdl3-dev with Conflicts: libltdl3-dev.
+Thanks Andreas Beckmann. Closes: #1041229
+
+ -- Alastair McKinstry Mon, 17 Jul 2023 16:03:58 +0100
+
+libtool (2.4.7-6) unstable; urgency=medium
+
+ * Incorrect check for += operator causes func_append to fail
+Patch from Ernesto Alfonso. Closes: #1039612
+ * Standards-Version: 4.6.2
+ * Add Breaks/Replaces on libtldl3-dev. Closes: #1039583
+
+ -- Alastair McKinstry Sat, 15 Jul 2023 09:09:39 +0100
+
libtool (2.4.7-5) unstable; urgency=medium
* Standards-Version: 4.6.1
diff -Nru libtool-2.4.7/debian/control libtool-2.4.7/debian/control
--- libtool-2.4.7/debian/control2022-11-23 12:34:12.0 +0100
+++ libtool-2.4.7/debian/control2024-03-28 13:23:32.0 +0100
@@ -13,7 +13,7 @@
Section: devel
Priority: optional
Maintainer: Alastair McKinstry
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
Rules-Requires-Root: no
Homepage: https://www.gnu.org/software/libtool/
Vcs-Browser: https://salsa.debian.org:/mckinstry/libtool.git
@@ -96,6 +96,8 @@
Section: libdevel
Suggests: libtool-doc
Provides: libltdl3-dev, libltdl7-dev
+Conflicts: libltdl3-dev
+Replaces: libbtldl3-dev
Recommends: libtool
Depends: libltdl7 (= ${binary:Version}), ${misc:Depends}, ${automake}
Description: System independent dlopen wrapper for GNU libtool (headers)
diff -Nru libtool-2.4.7/debian/patches/0090-shell-op.patch
libtool-2.4.7/debian/patches/0090-shell-op.patch
--- libtool-2.4.7/debian/patches/0090-shell-op.patch1970-01-01
01:00:00.0 +0100
+++ libtool-2.4.7/debian/patches/0090-shell-op.patch2023-07-17
17:03:58.0 +0200
@@ -0,0 +1,126 @@
+Author: Ernesto Alfonso
+Description: Incorrect check for += operator causes func_append to fail
+Bug-Origin: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039612
+Forwarded: no
+Last-Updated: 2023-07-15
+
+--- a/bootstrap
b/bootstrap
+@@ -227,7 +227,7 @@
+
+ # Source
Bug#1066965: bookworm-pu: package newlib/3.3.0-2
Btw, what is the timeline for approval or rejection for this security upload proposal? -- Happy hacking Petter Reinholdtsen
Bug#1055857: patch still valid? (opm-common: test failure on ppc64el with -O3)
Hi,
Concerning the patch: It seems like -O2 is the default in Debian now anyway.
Will the patch still work as it is?
I did some investigations on platti.debian.org. I have no idea what the problem
is. My hunch is that compiler optimization breaks the code here. If I add a
simple print statement like this then the test passes:
(sid_ppc64el-dchroot)blattms@platti:~/opm-common$ git diff
opm/output/data/InterRegFlow.hpp
diff --git a/opm/output/data/InterRegFlow.hpp b/opm/output/data/InterRegFlow.hpp
index 0e1dadcc4..7e2aeabbe 100644
--- a/opm/output/data/InterRegFlow.hpp
+++ b/opm/output/data/InterRegFlow.hpp
@@ -29,7 +29,7 @@
#include
#include
#include
-
+#include
namespace Opm { namespace data {
/// Intermediary Protocol to Linearise Per-Connection Flow Rates Into Subrange.
@@ -271,7 +271,7 @@ namespace Opm { namespace data {
using sz_t = decltype(InterRegFlow::bufferSize());
const auto& [begin, end] = this->elements_;
-
+std::cout<<"distance=";//<< std::distance(begin, end);// << " size="<<
InterRegFlow::bufferSize()<(std::distance(begin, end))
== InterRegFlow::bufferSize();
}
(sid_ppc64el-dchroot)blattms@platti:~/opm-common$
Best,
Markus
Bug#1055857: marked as done (transition: opm-common)
Your message dated Tue, 2 Apr 2024 10:04:51 +0200 with message-id and subject line transition: opm-common not needed anymore has caused the Debian Bug report #1055857, regarding transition: opm-common to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1055857: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055857 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-scie...@lists.debian.org Dear Debian release team, A new upstream release of OPM is available. To ease migration to testing I am requesting a mini-transition. Uploading to unstable would probably work even without a transition, but I would like to play it safe. This should only affect the OPM source packages opm-common, opm-grid, opm- models, opm-simulators and opm-upscaling. I have already uploaded new versions to experimental that seemed to have built without any issues, see [1]. (please explain about the transition: impacted packages, reason, ... for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) Ben file: title = "libopm-common-2023"; is_affected = .depends ~ "libopm-common-2023.04" | .depends ~ "libopm- common-2023.10"; is_good = .depends ~ "libopm-common-2023.10"; is_bad = .depends ~ "libopm-common-2023.04"; Thanks a lot. Kind regards, Markus [1] https://qa.debian.org/developer.php?login=markus%40dr-blatt.de --- End Message --- --- Begin Message --- Hi, this bug has resolved itself. There has been a team-upload to sid and binary packages of opm-common etc. are removed from testing anyway. Best, Markus--- End Message ---
Bug#1064810: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
On 01/04/2024 23:25, Sebastian Ramacher wrote: There is a transition to openmpi-5 / mpi-defaults which is stalled by the t64 transition. It drops 32-bit support from OpenMPI. Because of this, I don't think the solution is to port 32-bit atomics for armel/armhf, as it will be removed in a few weeks/months. While we didn't want the transitions to be done simultaneously, it might be the best answer. What does the release team think? Adding another transition on top will just delay the time_t transition even more. So if we can avoid that, I'd prefer to not do this transition now. Unfortunately, uploads such as the one of pmix that no dropped support for 32 bit architectures (#1068211) are not really helpful. Also, #1064810 has no information on test builds with the new mpi-defaults on a 32 bit architecture. So has this transition been tested? Cheers OpenMPI 5 drops 32-bit support, but otherwise does not change the API/ABI. So it is technically not a transition, but breaks 32-bit builds. The solution is changing mpi-defaults to MPICH for 32-bit archs. MPICH builds on all archs, but testing all dependencies of the change has not been tested, and I don't know how you would do that - setting up eg ratt to rebuild all on 32-bit archs (as everything on 64-bit will not have changed.) I'm sorry I missed the dropped 32-bit support for pmix; I tested on 64-bit platforms only. Regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e:alast...@mckinstry.ie, im: @alastair:mckinstry.ie
