Processed: tagging 1059535

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 1059535 + confirmed
Bug #1059535 [release.debian.org] transition: abseil
Ignoring request to alter tags of bug #1059535 to the same tags previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1059535: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059535
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1064810: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'

[Sebastian Ramacher]

On 2024-04-01 12:05:30 +0100, Alastair McKinstry wrote:
> 
> On 23/03/2024 01:58, Thorsten Glaser wrote:
> > Andrey Rakhmatullin dixit:
> > 
> > > OPAL_THREAD_ADD_FETCH64 is defined under #if OPAL_HAVE_ATOMIC_MATH_64
> > > And I assume this arch doesn't have 64-bit atomics.
> > No native ones, yes.
> > 
> > I *think* either libatomic or libatomic_ops(?) make them
> > available, but very slowly, using a syscall to guarantee
> > atomicity (those systems are normally uniprocessor) on
> > m68k.
> > 
> > If possible, avoiding them would be preferrable. (For
> > example, in some cases, like reading a 64-bit timestamp,
> > if the writing direction is known and stable, reading
> > twice then comparing is a possible alternative at least
> > for some architectures (e.g. I know BSD code for sparc
> > does it that way).
> > 
> > I guess you’ll have to ask the porters of 32-bit arches
> > with no native 64-bit atomics for details.
> > 
> > Though I had thought GCC’s builtin atomics use the
> > aforementioned kernel-based workaround from that library
> > these days?
> 
> 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
-- 
Sebastian Ramacher

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: linux-signed-arm64_6.1.82+1_arm64-buildd.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: linux-signed-amd64_6.1.82+1_amd64-buildd.changes
  ACCEPT
Processing changes file: linux-signed-i386_6.1.82+1_i386-buildd.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: linux-signed-amd64_6.1.82+1_source.changes
  ACCEPT
Processing changes file: linux-signed-arm64_6.1.82+1_source.changes
  ACCEPT
Processing changes file: linux-signed-i386_6.1.82+1_source.changes
  ACCEPT
Processing changes file: mediawiki_1.39.7-1~deb12u1_source.changes
  ACCEPT
Processing changes file: mediawiki_1.39.7-1~deb12u1_all-buildd.changes
  ACCEPT
Processing changes file: util-linux_2.38.1-5+deb12u1_source.changes
  ACCEPT
Processing changes file: util-linux_2.38.1-5+deb12u1_all-buildd.changes
  ACCEPT
Processing changes file: util-linux_2.38.1-5+deb12u1_amd64-buildd.changes
  ACCEPT
Processing changes file: util-linux_2.38.1-5+deb12u1_arm64-buildd.changes
  ACCEPT
Processing changes file: util-linux_2.38.1-5+deb12u1_armel-buildd.changes
  ACCEPT
Processing changes file: util-linux_2.38.1-5+deb12u1_armhf-buildd.changes
  ACCEPT
Processing changes file: util-linux_2.38.1-5+deb12u1_i386-buildd.changes
  ACCEPT
Processing changes file: util-linux_2.38.1-5+deb12u1_mips64el-buildd.changes
  ACCEPT
Processing changes file: util-linux_2.38.1-5+deb12u1_mipsel-buildd.changes
  ACCEPT
Processing changes file: util-linux_2.38.1-5+deb12u1_ppc64el-buildd.changes
  ACCEPT
Processing changes file: util-linux_2.38.1-5+deb12u1_s390x-buildd.changes
  ACCEPT

Re: Re-planning for 12.6

[Cyril Brulebois]

Hi,

Adam D. Barratt  (2024-04-01):
> As we had to postpone 12.6, let's look at alternative dates.

I should be able to make anything work.
 

Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1059535: transition: abseil

[Sebastian Ramacher]

On 2024-04-01 10:39:08 -0400, Benjamin Barenblat wrote:
> On Monday, April  1, 2024, at  2:57 PM +0200, Sebastian Ramacher wrote:
> > Could you please re-add the build dependency on dpkg-dev (>= 1.22.5) to
> > ensure that the build with the new armel/armhf ABI only migrates when
> > the time_t transition is ready to advance?
> 
> Yes! I am going to wait for the current upload (20230802.1-3) to finish
> building on RISC-V, just to make sure the FTBFS is fixed. (It’s already
> 11 hours in; it can’t take too much longer.) Once that’s done, I’ll
> upload a new 20230802.1-4 with a Build-Depends: dpkg-dev (>= 1.22.5).
> (If you’d prefer that I preempt the current build and upload
> 20230802.1-4 right now, just let me know.)

Sounds good. Let's wait for -3 to finish building on riscv64.

Cheers
-- 
Sebastian Ramacher

Re: Re-planning for 12.6

[Andy Simpkins]

On 01/04/2024 13:07, Adam D. 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

April 20th
- Doesn't work for me; I'm away from the Tuesday before until late on
the Friday

April 27th
- Doesn't work for me; I have a pre-existing appointment which means
I'll be AFK much of the day

May 4th
- Apparently doesn't work for me; long weekend in the UK

May 11th
- Should work for me

Regards,

Adam



Hi all,

May the 11th is fine for me.  Sorry we will not get an Isy as she will 
be deep into her exams by then. But we'll be ok, given this is just 12.6 
(and not a double release)



/Andy

Bug#1059535: transition: abseil

[Benjamin Barenblat]

On Monday, April  1, 2024, at  2:57 PM +0200, Sebastian Ramacher wrote:
> Could you please re-add the build dependency on dpkg-dev (>= 1.22.5) to
> ensure that the build with the new armel/armhf ABI only migrates when
> the time_t transition is ready to advance?

Yes! I am going to wait for the current upload (20230802.1-3) to finish
building on RISC-V, just to make sure the FTBFS is fixed. (It’s already
11 hours in; it can’t take too much longer.) Once that’s done, I’ll
upload a new 20230802.1-4 with a Build-Depends: dpkg-dev (>= 1.22.5).
(If you’d prefer that I preempt the current build and upload
20230802.1-4 right now, just let me know.)

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: gpaste_43.1-3+deb12u1_mips64el-buildd.changes
  ACCEPT
Processing changes file: gross_1.0.2-4.1~deb12u1_mips64el-buildd.changes
  ACCEPT
Processing changes file: libpod_4.3.1+ds1-8+deb12u1_mips64el-buildd.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: gpaste_43.1-3+deb12u1_mipsel-buildd.changes
  ACCEPT
Processing changes file: gross_1.0.2-4.1~deb12u1_mipsel-buildd.changes
  ACCEPT
Processing changes file: libpod_4.3.1+ds1-8+deb12u1_mipsel-buildd.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: libpod_4.3.1+ds1-8+deb12u1_amd64-buildd.changes
  ACCEPT
Processing changes file: libpod_4.3.1+ds1-8+deb12u1_arm64-buildd.changes
  ACCEPT
Processing changes file: libpod_4.3.1+ds1-8+deb12u1_armel-buildd.changes
  ACCEPT
Processing changes file: libpod_4.3.1+ds1-8+deb12u1_armhf-buildd.changes
  ACCEPT
Processing changes file: libpod_4.3.1+ds1-8+deb12u1_i386-buildd.changes
  ACCEPT

Bug#1059535: transition: abseil

[Sebastian Ramacher]

On 2024-03-29 17:27:58 -0400, Benjamin Barenblat wrote:
> On Friday, March 29, 2024, at  1:02 PM +0100, Sebastian Ramacher wrote:
> > Since the version in unstable fails to build on armel and armhf and
> > blocks the time_t transition, but the version in experimental builds
> > fine, let's do this transition now.
> >
> > With the upload to unstable, please check the FTBFS issue on risc64,
> > though.
> 
> Sounds good. I never did get around to uploading 20240116 to
> experimental. I’ll upload 20230802 to unstable this weekend, and I’ll
> come back for 20240116 later.

Thanks! Could you please re-add the build dependency on dpkg-dev (>=
1.22.5) to ensure that the build with the new armel/armhf ABI only
migrates when the time_t transition is ready to advance?

Cheers
-- 
Sebastian Ramacher

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: gpaste_43.1-3+deb12u1_all-buildd.changes
  ACCEPT
Processing changes file: gpaste_43.1-3+deb12u1_amd64-buildd.changes
  ACCEPT
Processing changes file: gpaste_43.1-3+deb12u1_arm64-buildd.changes
  ACCEPT
Processing changes file: gpaste_43.1-3+deb12u1_armel-buildd.changes
  ACCEPT
Processing changes file: gpaste_43.1-3+deb12u1_armhf-buildd.changes
  ACCEPT
Processing changes file: gpaste_43.1-3+deb12u1_i386-buildd.changes
  ACCEPT
Processing changes file: gpaste_43.1-3+deb12u1_ppc64el-buildd.changes
  ACCEPT
Processing changes file: gpaste_43.1-3+deb12u1_s390x-buildd.changes
  ACCEPT
Processing changes file: gross_1.0.2-4.1~deb12u1_amd64-buildd.changes
  ACCEPT
Processing changes file: gross_1.0.2-4.1~deb12u1_arm64-buildd.changes
  ACCEPT
Processing changes file: gross_1.0.2-4.1~deb12u1_armel-buildd.changes
  ACCEPT
Processing changes file: gross_1.0.2-4.1~deb12u1_armhf-buildd.changes
  ACCEPT
Processing changes file: gross_1.0.2-4.1~deb12u1_i386-buildd.changes
  ACCEPT
Processing changes file: gross_1.0.2-4.1~deb12u1_ppc64el-buildd.changes
  ACCEPT
Processing changes file: gross_1.0.2-4.1~deb12u1_s390x-buildd.changes
  ACCEPT
Processing changes file: libpod_4.3.1+ds1-8+deb12u1_ppc64el-buildd.changes
  ACCEPT
Processing changes file: libpod_4.3.1+ds1-8+deb12u1_s390x-buildd.changes
  ACCEPT

Re-planning for 12.6

[Adam D. Barratt]

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

April 20th
- Doesn't work for me; I'm away from the Tuesday before until late on
the Friday

April 27th
- Doesn't work for me; I have a pre-existing appointment which means
I'll be AFK much of the day

May 4th
- Apparently doesn't work for me; long weekend in the UK

May 11th
- Should work for me

Regards,

Adam

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: gpaste_43.1-3+deb12u1_source.changes
  ACCEPT
Processing changes file: gross_1.0.2-4.1~deb12u1_source.changes
  ACCEPT
Processing changes file: libpod_4.3.1+ds1-8+deb12u1_source.changes
  ACCEPT

Processed: Re: Bug#1068084: bookworm-pu: package intel-microcode/3.20240312.1~deb12u1

[Debian Bug Tracking System]

Processing control commands:

> tag -1 confirmed
Bug #1068084 [release.debian.org] bookworm-pu: package 
intel-microcode/3.20240312.1~deb12u1
Added tag(s) confirmed.

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

Bug#1068084: bookworm-pu: package intel-microcode/3.20240312.1~deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sat, Mar 30, 2024 at 07:47:05AM -0300, Henrique de Moraes Holschuh wrote:
> As requested by the security team, I would like to bring the microcode
> update level for Intel processors in Bullseye and Bookworm to match what
> we have in Sid and Trixie.  This is the bug report for Bookworm, a
> separate one will be filled for Bullseye.

Please go ahead.

Thanks,

-- 
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: libpod 4.3.1+ds1-8+deb12u1 flagged for acceptance

[Debian Bug Tracking System]

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 1066096 = bookworm pending
Bug #1066096 [release.debian.org] bookworm-pu: package 
libpod/4.3.1+ds1-8+deb12u1
Added tag(s) pending; removed tag(s) confirmed.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1066096: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066096
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: gross 1.0.2-4.1~deb12u1 flagged for acceptance

[Debian Bug Tracking System]

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 1068033 = bookworm pending
Bug #1068033 [release.debian.org] bookworm-pu: package gross/1.0.2-4.1~deb12u1
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1068033: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068033
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: gpaste 43.1-3+deb12u1 flagged for acceptance

[Debian Bug Tracking System]

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 1067980 = bookworm pending
Bug #1067980 [release.debian.org] bookworm-pu: package gpaste/43.1-3+deb12u1
Added tag(s) pending; removed tag(s) confirmed.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1067980: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067980
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1068033: gross 1.0.2-4.1~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1068033 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: gross
Version: 1.0.2-4.1~deb12u1

Explanation: fix stack-based buffer overflow [CVE-2023-52159]

Bug#1067980: gpaste 43.1-3+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1067980 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: gpaste
Version: 43.1-3+deb12u1

Explanation: fix conflict with older libpgpaste6

Bug#1066096: libpod 4.3.1+ds1-8+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1066096 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: libpod
Version: 4.3.1+ds1-8+deb12u1

Explanation: handle removed containers properly

Re: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'

[Alastair McKinstry]

On 23/03/2024 01:58, Thorsten Glaser wrote:

Andrey Rakhmatullin dixit:


OPAL_THREAD_ADD_FETCH64 is defined under #if OPAL_HAVE_ATOMIC_MATH_64
And I assume this arch doesn't have 64-bit atomics.

No native ones, yes.

I *think* either libatomic or libatomic_ops(?) make them
available, but very slowly, using a syscall to guarantee
atomicity (those systems are normally uniprocessor) on
m68k.

If possible, avoiding them would be preferrable. (For
example, in some cases, like reading a 64-bit timestamp,
if the writing direction is known and stable, reading
twice then comparing is a possible alternative at least
for some architectures (e.g. I know BSD code for sparc
does it that way).

I guess you’ll have to ask the porters of 32-bit arches
with no native 64-bit atomics for details.

Though I had thought GCC’s builtin atomics use the
aforementioned kernel-based workaround from that library
these days?


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?



bye,
//mirabilos


--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e:alast...@mckinstry.ie, im: @alastair:mckinstry.ie

Re: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'

[Andrey Rakhmatullin]

On Mon, Apr 01, 2024 at 12:05:30PM +0100, Alastair McKinstry 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.
It may have been somewhat easier for armel/armhf bootstrapping/rebuilding
if MPI stuff was dropped there early, but that's already finished
successfully so it doesn't matter.
Note that openmpi built successfuly on all release architectures so this
bug doesn't apply to them anyway.

-- 
WBR, wRAR


signature.asc
Description: PGP signature