Bug#1069919: transition: kimageannotator

[Boyuan Yang]

Package: release.debian.org
Control: affects -1 + src:kimageannotator
X-Debbugs-Cc: kimageannota...@packages.debian.org couc...@debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: by...@debian.org
Severity: normal

I would like to initiate the following listed transitions together
since they are tightly bundled together:

* https://release.debian.org/transitions/html/auto-kimageannotator.html
* https://release.debian.org/transitions/html/auto-kcolorpicker.html

List of all affected packages:

Level 0:
* src:kcolorpicker
Level 1:
* src:kimageannotator
Level 2:
* src:ksnip
* src:gwenview

The basic rationale is the upstream renaming of shared libraries (for
dual Qt5/Qt6 support):

libkimageannotator0 => libkimageannotator-qt{5,6}-0
libkcolorpicker0 => libkcolorpicker-qt{5,6}-0

Since src:kcolorpicker, src:kimageannotator and src:ksnip have a
tight relationship, they will be updated in Sid together in this
transition. Rebuilds in Experimental for all involved packages were
prepared, performed and all passed.

Since I am the package maintainer (or team co-maintainer) of all four
packages, I will perform all-manual source-only uploads for all involved
packages (Experimental => Sid) bottom-up following the dependency chain
once the transition is approved.


Ben file:

(please reuse auto-kcolorpicker and auto-kimageannotator trackers.)


Thanks,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part

Processed: transition: kimageannotator

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:kimageannotator
Bug #1069919 [release.debian.org] transition: kimageannotator
Added indication that 1069919 affects src:kimageannotator

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

Processed: bts

[Debian Bug Tracking System]

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

> block 1054631 by 1068954
Bug #1054631 [libnvme1] random memory corruption with some NVMe devices
1054631 was not blocked by any bugs.
1054631 was not blocking any bugs.
Added blocking bug(s) of 1054631: 1068954
> thanks
Stopping processing here.

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

Re: Making trixie debootstrap-able again?

[Sebastian Ramacher]

Hi

we've been made aware on #d-release that my hints broke debootstrap. I
am working through the remaining packages that are relevant for
debootstrap, but it takes some time.

On 2024-04-26 18:35:59 +0200, Cyril Brulebois wrote:
> I'm not sure how we reached this situation but there are a bunch of
> packages in trixie that are not in a suitable state. To reproduce, a
> simple `debootstrap trixie /tmp/trixie` on amd64 is sufficient.
> 
> Note: I've limited my exploration to amd64, which kept me busy already…
> 
> An obvious first problem is coreutils, which picked a Pre-Depends on
> libssl3 (not the t64 one), which… disappeared from testing between the
> 2024-04-24 14:58:20 and 2024-04-24 20:51:02 (checked by looking at
> Packages.gz for amd64 via snapshot.debian.org).

The core problem is that deboostrap fails to understand versioned
Provides. libssl3t64 on amd64:

Package: libssl3t64
Source: openssl
Version: 3.2.1-3
Installed-Size: 7302
Maintainer: Debian OpenSSL Team 
Architecture: amd64
Replaces: libssl3
Provides: libssl3 (= 3.2.1-3)
Depends: libc6 (>= 2.34), libzstd1 (>= 1.5.5), zlib1g (>= 1:1.1.4)
Breaks: libssl3 (<< 3.2.1-3), openssh-client (<< 1:9.4p1), openssh-server (<< 
1:9.4p1), python3-m2crypto (<< 0.38.0-4)
Description-en: Secure Sockets Layer toolkit - shared libraries
 This package is part of the OpenSSL project's implementation of the SSL
 and TLS cryptographic protocols for secure communication over the
 Internet.
 .
 It provides the libssl and libcrypto shared libraries.
Description-md5: 88547c6206c7fbc4fcc7d09ce100d210
Multi-Arch: same
Homepage: https://www.openssl.org/
Section: libs
Priority: optional
Filename: pool/main/o/openssl/libssl3t64_3.2.1-3_amd64.deb
Size: 2243528
MD5sum: 8919d70ec8be690308f3970878113b1a
SHA256: 84bf4abab84da9c8a2bdd2b161ae02d4de78657fe77483bf7656d8a368344add

So that britney dropped libssl3 from testing on !armel !armhf is fine in
genaral, but britney does not account for deboostrap not supporting
versioned Provides. That's the same for all the other packages involved
in bootstraping.

> Again, I have absolutely no clue regarding the best course of action at
> this point. I can't even perform clean builds to check what a binNMU in
> testing would look like, as I can't debootstrap a clean environment (and
> therefore only tested rebuilds in an existing, devel-oriented, unclean
> trixie chroot).

I am currently looking into making coreutils and systemd (which needs
glib2.0) migrate. I hope to have it back in a debootstrapable-step after
the weekend. If you are aware of more apckages that need help, please
let us know.

Cheers
-- 
Sebastian Ramacher

Re: Making trixie debootstrap-able again?

[Cyril Brulebois]

Cyril Brulebois  (2024-04-26):
> Anyway, I wanted to see if suggesting (I wouldn't go as far as requesting
> because I'm really not sure this would be the right course of action, more
> details below) a new binNMU of coreutils within testing would be
> sufficient to make trixie debootstrap-able again, I built a modified
> repository, and try debootstrap against it, only to find more problems:
>  - util-linux binaries (e.g. fdisk) depend on libreadline8, which is gone.
>  - iproute2 depends on libtirpc3, which is gone.
> 
> I guess the reason is similar, the former I tracked down to the same block
> of hints as before:
> 
> # 2024-04-23; done 2024-04-25
> # help some t64 packages migrate
> […]
> force-hint readline/8.2-4
> 
> The latter I tracked down to thisone:
> 
> # 2024-04-23; done 2024-04-26
> # get t64 unstuck
> urgent libtirpc/1.3.4+ds-1.3
> force-hint libtirpc/1.3.4+ds-1.3
> 
> Again, I have absolutely no clue regarding the best course of action at
> this point. I can't even perform clean builds to check what a binNMU in
> testing would look like, as I can't debootstrap a clean environment (and
> therefore only tested rebuilds in an existing, devel-oriented, unclean
> trixie chroot).

Looks like I forgot to mention the final results: with the modified
repository stuffed with (unclean) rebuilds of coreutils, iproute2, and
util-linux, I'm able to debootstrap trixie again.

(I've hacked a repository together from scratch, based on the failed
debootstrap's apt cache, adding rebuilt packages, and injecting new
dependencies manually; I could redo that cleanly by forking trixie's
current Packages instead, but I'm not sure it's really worth the
efforts, esp. given rebuilt packages are “tainted” anyway.)


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


signature.asc
Description: PGP signature

Making trixie debootstrap-able again?

[Cyril Brulebois]

Hi,

I'm not sure how we reached this situation but there are a bunch of
packages in trixie that are not in a suitable state. To reproduce, a
simple `debootstrap trixie /tmp/trixie` on amd64 is sufficient.

Note: I've limited my exploration to amd64, which kept me busy already…

An obvious first problem is coreutils, which picked a Pre-Depends on
libssl3 (not the t64 one), which… disappeared from testing between the
2024-04-24 14:58:20 and 2024-04-24 20:51:02 (checked by looking at
Packages.gz for amd64 via snapshot.debian.org).

The coreutils binNMU is hardly new, as it appeared via unstable in
January, and was already in testing by April 1st (I didn't check earlier
than that). Therefore I'm quite baffled to see libssl3 happily disappear
from testing while we still have stuff that Pre-Depends on it?!

Checking britney, I suppose this is a result of the following hint:

# 2024-04-23; done 2024-04-25
# help some t64 packages migrate
[…]
force-hint openssl/3.2.1-3

Anyway, I wanted to see if suggesting (I wouldn't go as far as requesting
because I'm really not sure this would be the right course of action, more
details below) a new binNMU of coreutils within testing would be
sufficient to make trixie debootstrap-able again, I built a modified
repository, and try debootstrap against it, only to find more problems:
 - util-linux binaries (e.g. fdisk) depend on libreadline8, which is gone.
 - iproute2 depends on libtirpc3, which is gone.

I guess the reason is similar, the former I tracked down to the same block
of hints as before:

# 2024-04-23; done 2024-04-25
# help some t64 packages migrate
[…]
force-hint readline/8.2-4

The latter I tracked down to thisone:

# 2024-04-23; done 2024-04-26
# get t64 unstuck
urgent libtirpc/1.3.4+ds-1.3
force-hint libtirpc/1.3.4+ds-1.3


Again, I have absolutely no clue regarding the best course of action at
this point. I can't even perform clean builds to check what a binNMU in
testing would look like, as I can't debootstrap a clean environment (and
therefore only tested rebuilds in an existing, devel-oriented, unclean
trixie chroot).

Seeing how some packages, e.g. coreutils, have DEP-17 changes staged in
unstable (since 1.5+ month), I'm definitely not advocating for pushing
them into testing as a quick or easy fix for those issues.


I'm not sure whether you're keeping track of things that break when
force-hinting but if you were aware of the resulting breakages already,
some kind of heads-up would have been nice…


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


signature.asc
Description: PGP signature

Re: Y2038-safe replacements for utmp/wtmp and lastlog

[Luca Boccassi]

On Fri, 26 Apr 2024 at 12:30, Chris Hofstaedtler  wrote:
>
> Fellow Developers,
>
> you are probably aware of the time_t-64bit migration :-)
> However, this does not magically transition all data formats to 64bit
> times. One such instance is the set of utmp/wtmp and lastlog files.
>
> Thorsten Kukuk and others have been working on replacements for the
> existing file formats and interfaces [1]; these are called wtmpdb
> and lastlog2.
>
> Some parties have requested that we do something in Debian [2]. If
> we use Thorsten's work (and why not?), this likely means introducing
> new packages into the Priority: standard set, and changes to a few
> other packages, esp. those that handle user sessions.
>
> Thorsten's code introduces new PAM modules to manage the new files,
> so it should transparently work with most packages. Later, the
> old interfaces can probably be turned off. This seems like a good
> idea as a migration strategy to me.
> A bonus seems to be that installs not wanting these features can
> remove them - whereas today they are baked into everything.
>
>
> On the wiki [0] I have summarized what I know; a list of initial
> work items; and some open questions mostly concerned with upgrading.
>
> I invite you to read the wiki page and the background info, to
> identify gaps, to provide insights on feasability and further
> related comments.
> I'm hoping that we can build consensus on this plan.
>
> Please keep #1068017 in CC: when discussing substantial matters
> about this plan but drop it for only vaguely related sub-threads.
>
> Chris
>
>
> [0] https://wiki.debian.org/pam_lastlog2%20and%20wtmpdb
> [1] https://www.thkukuk.de/blog/Y2038_glibc_lastlog_64bit/
> [2] https://bugs.debian.org/1068017

Would be nice to drop things that are not used, but otherwise, option
A looks good and broadly similar to what other distros are doing, so
should be pretty safe. Thanks for taking care of this.

Bug#1069891: bookworm-pu: package ansible/7.7.0+dfsg-3+deb12u1

[Lee Garrett]

On Fri, 26 Apr 2024 15:05:00 +0200 Lee Garrett  wrote:

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ansi...@packages.debian.org, deb...@rocketjump.eu
Control: affects -1 + src:ansible

Hi,

I'm requesting to bump the version of the ansible package ("ansible-community
collection") to the last minor semantic version of the v7 series in bookworm.
This version has previously spent ~10 months in testing/unstable, so I'm fairly
confident that any potential regressions would have been caught (so far none).

[ Reason ]
This incorporates the latest bugfixes from the v7 series, which update all
modules in the collection. These contain updates to handle:
- distro releases that have been released since
- web API changes that ansible can run against
- various bugfixes
- deprecation warnings that will be useful for users before they upgrade to
  bookworm + 1

Most importantly due to semantic versioning, there is no user-visible change.
Any previous playbooks will continue to work without changes.

I intend to use the 7.7.0 release as a basis for security support until bookworm
LTS EOL.

[ Impact ]
(What is the impact for the user if the update isn't approved?)
If the update is not approved, users will likely report errors that have already
been fixed in the latest minor release, and I'd have to cherrypick those
changes, add roundtrip time to the process.

[ Tests ]
autopkgtests have been widely expanded from the previous 7.3.0 release, covering
more unit tests than before.

[ Risks ]
There is a small risk of regressions, but I believe the risk to be minimal as no
such regressions have been reported in the 10 months in testing/unstable.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
- upstream update to 7.7.0


Forgot to add the link with the high-level upstream changes:
https://salsa.debian.org/debian/ansible/-/blob/debian/bookworm-proposed/CHANGELOG-v7.rst


- fixes to the libvirt connection plugin that bit me
- updates to the package metadata
- widely expanded autopkgtests for more coverage

[ Other info ]
This is my first s-p-u process, let me know what I can do better for any
following s-p-u.

Re: Y2038-safe replacements for utmp/wtmp and lastlog

[Sam Hartman]

> "Chris" == Chris Hofstaedtler  writes:

Chris> Fellow Developers,
Chris> you are probably aware of the time_t-64bit migration :-)
Chris> However, this does not magically transition all data formats to 64bit
Chris> times. One such instance is the set of utmp/wtmp and lastlog files.

Chris> Thorsten Kukuk and others have been working on replacements for the
Chris> existing file formats and interfaces [1]; these are called wtmpdb
Chris> and lastlog2.

Relatedly, PAM upstream and apparently at least some aspects of Fedora
have been moving to logind to handle utmp functionality.
You will start to see the  first impacts of that in pam unstable.

--Sam

Processed: bookworm-pu: package ansible/7.7.0+dfsg-3+deb12u1

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:ansible
Bug #1069891 [release.debian.org] bookworm-pu: package 
ansible/7.7.0+dfsg-3+deb12u1
Added indication that 1069891 affects src:ansible

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

Y2038-safe replacements for utmp/wtmp and lastlog

[Chris Hofstaedtler]

Fellow Developers,

you are probably aware of the time_t-64bit migration :-)
However, this does not magically transition all data formats to 64bit
times. One such instance is the set of utmp/wtmp and lastlog files.

Thorsten Kukuk and others have been working on replacements for the
existing file formats and interfaces [1]; these are called wtmpdb
and lastlog2.

Some parties have requested that we do something in Debian [2]. If
we use Thorsten's work (and why not?), this likely means introducing
new packages into the Priority: standard set, and changes to a few
other packages, esp. those that handle user sessions.

Thorsten's code introduces new PAM modules to manage the new files,
so it should transparently work with most packages. Later, the
old interfaces can probably be turned off. This seems like a good
idea as a migration strategy to me.
A bonus seems to be that installs not wanting these features can
remove them - whereas today they are baked into everything.


On the wiki [0] I have summarized what I know; a list of initial
work items; and some open questions mostly concerned with upgrading.

I invite you to read the wiki page and the background info, to
identify gaps, to provide insights on feasability and further
related comments.
I'm hoping that we can build consensus on this plan.

Please keep #1068017 in CC: when discussing substantial matters
about this plan but drop it for only vaguely related sub-threads.

Chris


[0] https://wiki.debian.org/pam_lastlog2%20and%20wtmpdb
[1] https://www.thkukuk.de/blog/Y2038_glibc_lastlog_64bit/
[2] https://bugs.debian.org/1068017

Processed: bullseye-pu: package cpu/1.4.3-14~deb11u1

[Debian Bug Tracking System]

Processing control commands:

> block 1067439 with -1
Bug #1067439 {Done: Andreas Beckmann } [cpu] cpu: undefined 
symbol globalLdap in libcpu_ldap.so on Debian 12
1067439 was not blocked by any bugs.
1067439 was not blocking any bugs.
Added blocking bug(s) of 1067439: 1069880
> affects -1 + src:cpu
Bug #1069880 [release.debian.org] bullseye-pu: package cpu/1.4.3-14~deb11u1
Added indication that 1069880 affects src:cpu

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

Bug#1069880: bullseye-pu: package cpu/1.4.3-14~deb11u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
Control: block 1067439 with -1
Control: affects -1 + src:cpu

[ Reason ]
The last QA upload four years ago fixed a FTBFS (multiple definitions of
a global variable) by replacing that variable with an extern declaration
and zero definitions. This didn't result in a linker error (missing
symbol) because it happens in a plugin library and thus is only detected
at runtime when the plugin gets loaded (i.e. always).
So let's ship the plugin with *one* definition of the global variable
;-)

[ Impact ]
cpu stays unusable, but nobody noticed that for the last 4 years and two
stable releases ...

[ Tests ]
Added a smoketest autopkgtest that detects the current failure.

[ Risks ]
We can't make the current situation much worse ;-)

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable
  [x] the issue is verified as fixed in bookworm-pu

[ Changes ]
  * Actually provide a definition of globalLdap.  (Closes: #1067439)
  * Add smoke test.

[ Other info ]
n/a

Andreas
diff --git a/debian/changelog b/debian/changelog
index ec0f291..5487744 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,25 @@
+cpu (1.4.3-14~deb11u1) bullseye; urgency=medium
+
+  * QA upload.
+  * Rebuild for bullseye.
+
+ -- Andreas Beckmann   Fri, 26 Apr 2024 11:52:39 +0200
+
+cpu (1.4.3-14~deb12u1) bookworm; urgency=medium
+
+  * QA upload.
+  * Rebuild for bookworm.
+
+ -- Andreas Beckmann   Mon, 25 Mar 2024 21:37:56 +0100
+
+cpu (1.4.3-14) unstable; urgency=medium
+
+  * QA upload.
+  * Actually provide a definition of globalLdap.  (Closes: #1067439)
+  * Add smoke test.
+
+ -- Andreas Beckmann   Sat, 23 Mar 2024 14:39:06 +0100
+
 cpu (1.4.3-13) unstable; urgency=medium
 
   * QA upload.
diff --git a/debian/gbp.conf b/debian/gbp.conf
new file mode 100644
index 000..9048820
--- /dev/null
+++ b/debian/gbp.conf
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch = main
diff --git a/debian/patches/14_use-extern.patch 
b/debian/patches/14_use-extern.patch
index 774b581..26b0b19 100644
--- a/debian/patches/14_use-extern.patch
+++ b/debian/patches/14_use-extern.patch
@@ -1,10 +1,11 @@
 Description: Fix ftbfs with GCC-10
 
 Bug-Debian: https://bugs.debian.org/957106
+Bug-Debian: https://bugs.debian.org/1067439
 ---
 
 cpu-1.4.3.orig/src/include/plugins/ldap/ldap.h
-+++ cpu-1.4.3/src/include/plugins/ldap/ldap.h
+--- a/src/include/plugins/ldap/ldap.h
 b/src/include/plugins/ldap/ldap.h
 @@ -106,7 +106,7 @@ typedef struct CPU_ldap {
Parser * parse;
  } CPU_ldap;
@@ -14,3 +15,14 @@ Bug-Debian: https://bugs.debian.org/957106
  
  int parseCommand(int argc, char *argv[]);
  void printHelp(int op);
+--- a/src/plugins/ldap/ldap.c
 b/src/plugins/ldap/ldap.c
+@@ -26,6 +26,8 @@
+ #include 
+ #include "plugins/ldap/ldap.h"
+ 
++CPU_ldap * globalLdap;
++
+ int verbose;
+ int operation;
+ 
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..7633658
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,8 @@
+Test-Command: /usr/sbin/cpu || /usr/sbin/cpu 2>&1 | grep ^usage:
+Features: test-name=smoketest
+Depends:
+ cpu,
+Restrictions:
+ superficial,
+ needs-root,
+ allow-stderr,