Re: Understanding what is blocking spamassassin 4.0.0 testing migration

[Andreas Metzler]

On 2022-12-29 "Adam D. Barratt"  wrote:
> On Thu, 2022-12-29 at 07:21 +0100, Andreas Metzler wrote:
[...]
> > removing spamassassin/4.0.0~rc4-1/amd64 from testing makes claws-
[...]

> That's due to the arch:all build failing, which means there is no
> "spamassassin" binary package in unstable currently when combined with
> dak's feature of hiding arch:all packages that don't correspond to the
> version of arch-dep packages. See #915948 for further details on
> similar issues.

> Looking at previous build failures, it looks like the arch:all build
> has issues with IPv6-only buildds. I've given it back, so let's see
> what happens.

Thank you (and Paul) for the explanation. I did not get that "removing
spamassassin" was talking about the binary. The retried build succeeded.
:-)

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Understanding what is blocking spamassassin 4.0.0 testing migration

[Paul Gevers]

Hi Andreas,

On 29-12-2022 07:21, Andreas Metzler wrote:

I do not understand why spamassassin 4.0.0 does not prpagate to testing.
Tracker/excuses https://qa.debian.org/excuses.php?package=spamassassin
says:
Issues preventing migration:
[...]
 removing spamassassin/4.0.0~rc4-1/amd64 from testing makes 
claws-mail-spamassassin/4.1.1-2/amd64 uninstallable
 removing spamassassin/4.0.0~rc4-1/amd64 from testing makes 
evolution-plugin-spamassassin/3.46.2-1/amd64 uninstallable
[ list of more spamassassin rdeps which would be uninstallable if ]


Note that it only talks about "removing" instead of "upgrading". Which
obviously cannot work.


Well, the arch:all package didn't build yet, so if the source would 
migrate, it would be effectively removing the binary. (It seems like the 
while I'm typing this message, somebody hit the rebuild retry.)



https://release.debian.org/britney/update_output.txt does not mention
spamassassin at all. It also seems very short, not like a full run with
less than 1000 lines.


If the first phase of britney (the policy phase) already blocks an item, 
the second phase doesn't see it, so that's expected. See the docs [1].


Paul

[1] https://release.debian.org/doc/britney/short-intro-to-migrations.html


OpenPGP_signature
Description: OpenPGP digital signature

Re: Understanding what is blocking spamassassin 4.0.0 testing migration

[Adam D. Barratt]

Hi,

On Thu, 2022-12-29 at 07:21 +0100, Andreas Metzler wrote:
> I do not understand why spamassassin 4.0.0 does not prpagate to
> testing.
> Tracker/excuses 
> https://qa.debian.org/excuses.php?package=spamassassin
> says:
> Issues preventing migration:
> [...]
> removing spamassassin/4.0.0~rc4-1/amd64 from testing makes claws-
> mail-spamassassin/4.1.1-2/amd64 uninstallable
> removing spamassassin/4.0.0~rc4-1/amd64 from testing makes
> evolution-plugin-spamassassin/3.46.2-1/amd64 uninstallable
> [ list of more spamassassin rdeps which would be uninstallable if ]
> 
> 
> Note that it only talks about "removing" instead of "upgrading".
> Which
> obviously cannot work.
> 

That's due to the arch:all build failing, which means there is no
"spamassassin" binary package in unstable currently when combined with
dak's feature of hiding arch:all packages that don't correspond to the
version of arch-dep packages. See #915948 for further details on
similar issues.

Looking at previous build failures, it looks like the arch:all build
has issues with IPv6-only buildds. I've given it back, so let's see
what happens.

Regards,

Adam

Understanding what is blocking spamassassin 4.0.0 testing migration

[Andreas Metzler]

Hello,

I do not understand why spamassassin 4.0.0 does not prpagate to testing.
Tracker/excuses https://qa.debian.org/excuses.php?package=spamassassin
says:
Issues preventing migration:
[...]
removing spamassassin/4.0.0~rc4-1/amd64 from testing makes 
claws-mail-spamassassin/4.1.1-2/amd64 uninstallable
removing spamassassin/4.0.0~rc4-1/amd64 from testing makes 
evolution-plugin-spamassassin/3.46.2-1/amd64 uninstallable
[ list of more spamassassin rdeps which would be uninstallable if ]


Note that it only talks about "removing" instead of "upgrading". Which
obviously cannot work.

https://release.debian.org/britney/update_output.txt does not mention
spamassassin at all. It also seems very short, not like a full run with
less than 1000 lines.

TIA, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1027258: bullseye-pu: package golang-github-containers-psgo/1.5.2-2~deb11u1

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: golang-github-containers-p...@packages.debian.org, 
siret...@tauware.de, siret...@gmail.com, Vignesh Raman 
vignesh.ra...@collabora.com
Control: affects -1 + src:golang-github-containers-psgo


[ Reason ]

Backport for CVE-2022-1227, taken from 
https://github.com/containers/psgo/pull/92

This prevents an exploit when running 'podman top'

[ Impact ]


[ Tests ]
No new test is added. The code change is rather small and straight-forward to
review. It required small changes to apply to this older version.

[ Risks ]
I determined that the code change and adaptions to version 1.5.2 is easier to
review than updating containers-psgo to upstream version 1.7.2, which would
be closer to how upstream or Fedora/RedHat would recommend to address this 
issue.

[ 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 ]

diff --git a/debian/changelog b/debian/changelog
index a1f0d96..0448fdf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+golang-github-containers-psgo (1.5.2-2~deb11u1) bullseye; urgency=medium
+
+  * CVE-2022-1227: do not join the process user namespace
+
+ -- Reinhard Tartler   Wed, 28 Dec 2022 21:21:57 -0500
+
 golang-github-containers-psgo (1.5.2-1) unstable; urgency=medium

   * Team upload
diff --git a/debian/control b/debian/control
index 5a52891..ba4c8e5 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends:
  dh-golang,
 Build-Depends-Indep:
  golang-any,
+ golang-github-containers-storage-dev (>= 1.24.8+dfsg1-2~deb11u1),
  golang-github-opencontainers-runc-dev,
  golang-github-pkg-errors-dev,
  golang-github-sirupsen-logrus-dev,
diff --git a/debian/patches/CVE-2022-1227.patch 
b/debian/patches/CVE-2022-1227.patch
new file mode 100644
index 000..991a7c5
--- /dev/null
+++ b/debian/patches/CVE-2022-1227.patch
@@ -0,0 +1,279 @@
+commit 3ae3044916481f5c001f64a9d26110b878a676e0 (github/v1.7.1-fedora)
+Author: Aleksa Sarai 
+Date:   Wed Jan 12 01:01:30 2022 +1100
+
+internal: proc: do not join the process user namespace
+
+The only reason we joined the process user namespace was to map a
+handful of fields into the same usernamepsace as that process. This
+procedure can be implemented entirely in Go without having to run code
+inside the container.
+
+In addition, since psgo is used inside "podman top", we were actually
+executing the nsenter binary *from the container* without all of the
+container's security profiles applied. At the very least this would
+allow a container process to return bad data to psgo (possibly confusing
+management scripts using psgo) and at the very worst it would allow the
+container process to escalate privileges by getting podman to execute
+code without all of the container security profiles applied.
+
+Fixes: CVE-2022-1227
+
+Signed-off-by: Aleksa Sarai 
+Backported-by: Valentin Rothberg 
+Signed-off-by: Valentin Rothberg 
+
+Index: golang-github-containers-psgo/internal/proc/ns.go
+===
+--- golang-github-containers-psgo.orig/internal/proc/ns.go
 golang-github-containers-psgo/internal/proc/ns.go
+@@ -21,14 +21,9 @@ import (
+   "os"
+
+   "github.com/pkg/errors"
++  "github.com/containers/storage/pkg/idtools"
+ )
+
+-type IDMap struct {
+-  ContainerID int
+-  HostID  int
+-  Sizeint
+-}
+-
+ // ParsePIDNamespace returns the content of /proc/$pid/ns/pid.
+ func ParsePIDNamespace(pid string) (string, error) {
+   pidNS, err := os.Readlink(fmt.Sprintf("/proc/%s/ns/pid", pid))
+@@ -48,14 +43,14 @@ func ParseUserNamespace(pid string) (str
+ }
+
+ // ReadMappings reads the user namespace mappings at the specified path
+-func ReadMappings(path string) ([]IDMap, error) {
++func ReadMappings(path string) ([]idtools.IDMap, error) {
+   file, err := os.Open(path)
+   if err != nil {
+   return nil, errors.Wrapf(err, "cannot open %s", path)
+   }
+   defer file.Close()
+
+-  mappings := []IDMap{}
++  var mappings []idtools.IDMap
+
+   buf := bufio.NewReader(file)
+   for {
+@@ -70,10 +65,10 @@ func ReadMappings(path string) ([]IDMap,
+   return mappings, nil
+   }
+
+-  containerID, hostID, size := 0, 0, 0
++  var containerID, hostID, size int
+   if _, err := fmt.Sscanf(string(line), "%d %d %d", , 
, ); err != nil {
+   return nil, errors.Wrapf(err, "cannot parse %s", 
string(line))
+   }
+-  mappings = append(mappings, IDMap{ContainerID: containerID, 
HostID: hostID, Size: size})
++  mappings 

Processed: bullseye-pu: package golang-github-containers-psgo/1.5.2-2~deb11u1

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:golang-github-containers-psgo
Bug #1027258 [release.debian.org] bullseye-pu: package 
golang-github-containers-psgo/1.5.2-2~deb11u1
Added indication that 1027258 affects src:golang-github-containers-psgo

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

Bug#1027257: bullseye-pu: package golang-github-containers-storage/1.24.8+dfsg1-2~deb11u1

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: golang-github-containers-stor...@packages.debian.org, 
siret...@tauware.de, siret...@gmail.com, Vignesh Raman 
vignesh.ra...@collabora.com
Control: affects -1 + src:golang-github-containers-storage


[ Reason ]
In order to fix CVE-2022-1227, an update to golang-github-containers-psgo
is needed, more specifically, https://github.com/containers/psgo/pull/92

That patch introduces a dependency on golang-github-containers-storage, and uses
the helper functions RawTo{Container,Host} which are introduced with this patch.

[ Impact ]

[ Tests ]
No new tests are added. The patch was taken from upstream and required
little modificaiton to apply.

[ Risks ]
The code changes adds a helper function that isn't used otherwise yet.

[ 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 ]
diff --git a/debian/changelog b/debian/changelog
index 837efeeb1..640a90134 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+golang-github-containers-storage (1.24.8+dfsg1-2~deb11u1) bullseye; 
urgency=medium
+
+  [ Vignesh Raman ]
+  * prereq to fix CVE-2022-1227: pkg: idtools: export RawTo{Container,Host}
+
+ -- Reinhard Tartler   Wed, 28 Dec 2022 21:39:17 -0500
+
 golang-github-containers-storage (1.24.8+dfsg1-1) unstable; urgency=medium

   * New upstream release, focused on targetted bugfixes for podman 3.0
diff --git a/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch 
b/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch
new file mode 100644
index 0..d00cbd0e9
--- /dev/null
+++ b/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch
@@ -0,0 +1,111 @@
+From 3da85a122411a57b5a65dc243ae56f89d7fd2564 Mon Sep 17 00:00:00 2001
+From: Aleksa Sarai 
+Date: Wed, 12 Jan 2022 12:56:56 +1100
+Subject: [PATCH 1/4] pkg: idtools: export RawTo{Container,Host}
+
+While the IDMapping methods are preferable for most users, sometimes it
+is necessary to map a single ID using a given mapping. In particular
+this is needed for psgo to be able to map the user and group entries in
+/proc/$pid/status using the user namespace of the target process.
+
+Required to resolve CVE-2022-1227.
+
+Signed-off-by: Aleksa Sarai 
+Backported-by: Valentin Rothberg 
+---
+ pkg/idtools/idtools.go | 36 ++--
+ 1 file changed, 22 insertions(+), 14 deletions(-)
+
+diff --git a/pkg/idtools/idtools.go b/pkg/idtools/idtools.go
+index 83bc8c34f..d3d56066e 100644
+--- a/pkg/idtools/idtools.go
 b/pkg/idtools/idtools.go
+@@ -82,7 +82,7 @@ func GetRootUIDGID(uidMap, gidMap []IDMap) (int, int, error) 
{
+   if len(uidMap) == 1 && uidMap[0].Size == 1 {
+   uid = uidMap[0].HostID
+   } else {
+-  uid, err = toHost(0, uidMap)
++  uid, err = RawToHost(0, uidMap)
+   if err != nil {
+   return -1, -1, err
+   }
+@@ -90,7 +90,7 @@ func GetRootUIDGID(uidMap, gidMap []IDMap) (int, int, error) 
{
+   if len(gidMap) == 1 && gidMap[0].Size == 1 {
+   gid = gidMap[0].HostID
+   } else {
+-  gid, err = toHost(0, gidMap)
++  gid, err = RawToHost(0, gidMap)
+   if err != nil {
+   return -1, -1, err
+   }
+@@ -98,10 +98,14 @@ func GetRootUIDGID(uidMap, gidMap []IDMap) (int, int, 
error) {
+   return uid, gid, nil
+ }
+
+-// toContainer takes an id mapping, and uses it to translate a
+-// host ID to the remapped ID. If no map is provided, then the translation
+-// assumes a 1-to-1 mapping and returns the passed in id
+-func toContainer(hostID int, idMap []IDMap) (int, error) {
++// RawToContainer takes an id mapping, and uses it to translate a host ID to
++// the remapped ID. If no map is provided, then the translation assumes a
++// 1-to-1 mapping and returns the passed in id.
++//
++// If you wish to map a (uid,gid) combination you should use the corresponding
++// IDMappings methods, which ensure that you are mapping the correct ID 
against
++// the correct mapping.
++func RawToContainer(hostID int, idMap []IDMap) (int, error) {
+   if idMap == nil {
+   return hostID, nil
+   }
+@@ -114,10 +118,14 @@ func toContainer(hostID int, idMap []IDMap) (int, error) 
{
+   return -1, fmt.Errorf("Host ID %d cannot be mapped to a container ID", 
hostID)
+ }
+
+-// toHost takes an id mapping and a remapped ID, and translates the
+-// ID to the mapped host ID. If no map is provided, then the translation
+-// assumes a 1-to-1 mapping and returns the passed in id #
+-func toHost(contID int, idMap []IDMap) (int, error) {
++// RawToHost takes an id mapping and a remapped ID, and translates the ID to

Processed: bullseye-pu: package golang-github-containers-storage/1.24.8+dfsg1-2~deb11u1

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:golang-github-containers-storage
Bug #1027257 [release.debian.org] bullseye-pu: package 
golang-github-containers-storage/1.24.8+dfsg1-2~deb11u1
Added indication that 1027257 affects src:golang-github-containers-storage

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

Bug#1027044: transition: numpy 1.24.x

[Sandro Tosi]

> > There are handful more errors in the form of:
> >
> >   * ValueError: setting an array element with a sequence. The
> > requested array has an inhomogeneous shape after 1 dimensions. The
> > detected shape was (2,) + inhomogeneous part.
> >   * Too many indices for array: array is 0-dimensional, but 1 were indexed
> >
> > which will need to be looked at in more details, likely by individual
> > projects upstream.
>
> The sooner these bugs are filed, the better.

bugs have been filed:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-python%40lists.debian.org=numpy1.24


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1026119: transition: matplotlib

[Sandro Tosi]

> thanks! matplotlib/3.6.2-3 has been accepted in unstable

bugs have been filed:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-python%40lists.debian.org=matplotlib3.6

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1026890: marked as done (transition: ruby3.0-rm)

[Debian Bug Tracking System]

Your message dated Wed, 28 Dec 2022 23:46:51 +0100
with message-id 
and subject line Re: Bug#1026890: transition: ruby3.0-rm
has caused the Debian Bug report #1026890,
regarding transition: ruby3.0-rm
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.)


-- 
1026890: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026890
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: ruby-defau...@packages.debian.org
Control: affects -1 + src:ruby-defaults

Please create a tracker for removing ruby3.0 as a supported version.

Ben file (based on ruby2.7-rm from the transition-data repository):

title = "ruby3.0-rm";
is_affected = (.depends ~ "ruby3.0" | .depends ~ "libruby3.0") & !.source ~ 
/^(ruby3.0)$/;
is_good = false;
is_bad = .depends ~ "ruby3.0" | .depends ~ "libruby3.0";


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
On 2022-12-23 16:36:33 +0100, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> Control: forwarded -1 
> https://release.debian.org/transitions/html/ruby3.0-rm.html
> 
> Hi Antonio
> 
> On 2022-12-23 10:47:59 -0300, Antonio Terceiro wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: ruby-defau...@packages.debian.org
> > Control: affects -1 + src:ruby-defaults
> > 
> > Please create a tracker for removing ruby3.0 as a supported version.
> 
> Tracker created. Please go ahead.

ruby-defaults migrated. Let's consider this one done.

Cheers
-- 
Sebastian Ramacher--- End Message ---

Bug#1022573: transition: procps

[Paul Gevers]

Hi Craig,

With procps migrated to testing, dose [1] is reporting two more packages 
that weren't on our radar: open-vm-tools and guymager. Can you have a 
look and help the maintainer with migrating to the new version of 
procps? open-vm-tools has a new version in unstable that's now unable to 
migrate.


Paul

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026964: transition: wxwidgets3.2

[Sebastian Ramacher]

On 2022-12-28 12:15:29 -0500, Scott Talbert wrote:
> On Tue, 27 Dec 2022, Scott Talbert wrote:
> 
> > On Tue, 27 Dec 2022, Sebastian Ramacher wrote:
> > 
> > > On 2022-12-27 08:59:19 -0500, Scott Talbert wrote:
> > > > On Tue, 27 Dec 2022, Sebastian Ramacher wrote:
> > > > 
> > > > > > Rebuild wxwidgets3.2 rdeps due to wxwidgets ABI change, due to
> > > > > > rebuilding with GLX support instead of EGL support. See bug 
> > > > > > #1024147.
> > > > > > Updated wxwidgets3.2 package has been uploaded to experimental.
> > > > > 
> > > > > Please go ahead.
> > > > 
> > > > Do I just re-upload to unstable now?
> > > 
> > > Yes, and we will then schedule the rebuilds.
> > 
> > Done, thanks!
> 
> As best as I can tell, slic3r-prusa might have been missed in the binNMU
> list?

It was skipped due to #1025827.

Cheers
-- 
Sebastian Ramacher

Bug#1026964: transition: wxwidgets3.2

[Scott Talbert]

On Tue, 27 Dec 2022, Scott Talbert wrote:


On Tue, 27 Dec 2022, Sebastian Ramacher wrote:


On 2022-12-27 08:59:19 -0500, Scott Talbert wrote:

On Tue, 27 Dec 2022, Sebastian Ramacher wrote:


Rebuild wxwidgets3.2 rdeps due to wxwidgets ABI change, due to
rebuilding with GLX support instead of EGL support. See bug #1024147.
Updated wxwidgets3.2 package has been uploaded to experimental.


Please go ahead.


Do I just re-upload to unstable now?


Yes, and we will then schedule the rebuilds.


Done, thanks!


As best as I can tell, slic3r-prusa might have been missed in the binNMU 
list?


Regards,
Scott

Bug#1008495: marked as done (transition: tinyobjloader)

[Debian Bug Tracking System]

Your message dated Wed, 28 Dec 2022 17:34:30 +0100
with message-id 
and subject line Re: Bug#1008495: transition: tinyobjloader
has caused the Debian Bug report #1008495,
regarding transition: tinyobjloader
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.)


-- 
1008495: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008495
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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,

I'd like to transition tinyobjloader for its new soname. Technically,
this is a simple transition, the reverse dependencies build fine.
However, the transition is unusual as it is not an official release, so
allow me to explain my reasons.

The initial upload was with 2.0.0~rc5 around April 2020, because it was
required by Open3D at that time. Upstream assured me that a final 2.0
release would be happening in early 2021. Some development occurred
(which broke ABI backwards compatibility) and some bugs were fixed,
among them CVE-2020-28589; however, the final release never
materialized. Now, almost two years later, I find myself with an
"in-between" ABI version that is no longer .so.1 but likely not
.so.2 yet (the TODO still includes some "API polishing").

It is impossible to predict when upstream will find the time to finish
the 2.0 release, and I would like to have the bugfixes in Debian at some
point. Given that this is only a minor package with few reverse depends,
I felt it was fine to have this "in-between" transition now and the
proper one with .so.2 whenever the final release happens. Let me know
what you think.


Cheers
Timo

PS. https://release.debian.org/transitions/html/auto-tinyobjloader.html
looks good

-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmJAnnYACgkQ+C8H+466
LVk67AwAo6qohyBPGDq36lxSFbEW/E6qZHNWBr239hVMGNT63DzhvRqRO4KOdt9C
xoQYSRrFXP5oQRKXh6EosmHK/uHxVNAH1IG8xyWpe7pdD6QvzKhnVGpZiKQviGEe
iixw92dqWx0R72fuBUzojqeAT1v680t+upshDYm0SlrJWZGym5emJUBs+6LRcx5o
F6l9z3teuIacHeUyt/L1J9aoWHS9GKmFyoIgZMYWFMC+D0t03osvUuikDawc3v6P
JGrDpDU9pDpLIPUwcT9R/YP8vYq12PfTJnKgWDjCCk5vOADdYbOCgpbu7GkqZFcQ
eQBpS45aULq539W+oKpuaeMtXPMkZvFkBExdlvnVmyQ5fX4V16wRyrTci7C+vrwA
VXG4TaUF2MBmO6pNnbjCASzblz7A2IJiEdMWeXjej7XA5ZZZ7bGjJe8WcTHpXG9n
yRmP7AjJvEtID6oQbTRkJeqpz8sVxyfvqLYMjqECA/pzyX2lCtXOI/Qv16g6wHyk
pWesoHlP
=rcmR
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---
On 2022-12-18 14:14:13 +0100, Timo Röhling wrote:
> Hi Sebastian,
> 
> * Sebastian Ramacher  [2022-12-18 13:07]:
> > 
> > Sorry, this transition was completely missed. Please go ahead.
> > 
> Thanks. I'm going to push rc10 through exp/NEW first, which has been
> released in the mean time.

With open3d rebuilt in testing, the old binaries got removed. Closing.

Cheers
-- 
Sebastian Ramacher--- End Message ---

Bug#1026867: marked as done (transition: youtube-dl)

[Debian Bug Tracking System]

Your message dated Wed, 28 Dec 2022 12:57:45 +0100
with message-id 
and subject line Re: Bug#1026867: transition: youtube-dl
has caused the Debian Bug report #1026867,
regarding transition: youtube-dl
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.)


-- 
1026867: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026867
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: 994...@bugs.debian.org, debian-de...@lists.debian.org

Hi,

Youtube-dl has mostly stopped development other than basic maintenance, and
development has resumed with the yt-dlp project (which is already in debian)
as documented in .

For the bookworm release, we intend to drop the youtube-dl upstream code 
from
the archive, with an empty transition package that will simply depend on 
yt-dlp

and a NEWS entry informing users of the change. We considered attempting a
seamless transition that provided a wrapper python module for the youtube_dl
library and the /usr/bin/youtube-dl executable, but there are complications
(such slightly different behavior between the two programs even when using
yt-dlp's provided '--compat-options youtube-dl' argument, and programs 
that are
aware of both yt-dlp and youtube-dl that will get confused if we pretend 
that
youtube-dl is yt-dlp). Rather than risk the potential to introduce 
silent bugs

into user setups, we prefer to simply inform users of the change and require
them to manually verify their setups with yt-dlp.

I filed 13 bugs with packages that have reverse dependencies on youtube-dl
(ignoring those packages that depend on yt-dlp|youtube-dl); half have 
already
been fixed. I plan to bump the severity on remaining bugs once the 
youtube-dl
transition package is uploaded to sid (for those packages that actually 
break

without a youtube-dl script/library).

Depends on youtube-dl:
ytcc: #1024212
youtubedl-gui: #1024214 (done)
mkchromecast: #1024216

Recommends youtube-dl:
lollypop: #1024217 (done)
celluloid: #1024222
lives: #1024229
libmpv1: #1026866

Suggests youtube-dl:
git-annex: #1024226 (done)
gpodder: #1024227 (done)
liquidsoap: #1024228 (done)
ytfzf: #1024230 (done)
acetoneiso: #1024231
python3-moviepy: #1024232

There are no library or ABI concerns with this transition, this is mostly
to get a transition slot and to track the transition.

Ben file:

title = "youtube-dl";
is_affected = .build-depends ~ /youtube-dl/ | .depends ~ /youtube-dl/;
is_good = .build-depends ~ /yt-dlp/ | .depends ~ /yt-dlp/;
is_bad = .build-depends ~ /youtube-dl/ | .depends ~ /youtube-dl/;

I can NMU where necessary for the remaining bugs, once the transition is
underway.

Thanks,
Andres
--- End Message ---
--- Begin Message ---
On 2022-12-27 22:54:17 -0500, Andres Salomon wrote:
> 
> 
> On Fri, Dec 23 2022 at 10:55:28 AM +0100, Sebastian Ramacher
>  wrote:
> > Control: tags -1 moreinfo
> > 
> > Hi Andres
> > 
> > On 2022-12-22 15:23:37 -0500, Andres Salomon wrote:
> > >  Package: release.debian.org
> > >  Severity: normal
> > >  User: release.debian@packages.debian.org
> > > 
> > >  Usertags: transition
> > >  X-Debbugs-Cc: 994...@bugs.debian.org
> > > , debian-de...@lists.debian.org
> > > 
> > > 
> > >  Hi,
> > > 
> > >  Youtube-dl has mostly stopped development other than basic
> > > maintenance, and
> > >  development has resumed with the yt-dlp project (which is already
> > > in debian)
> > >  as documented in <>.
> > > 
> > >  For the bookworm release, we intend to drop the youtube-dl upstream
> > > code
> > >  from
> > >  the archive, with an empty transition package that will simply
> > > depend on
> > >  yt-dlp
> > >  and a NEWS entry informing users of the change. We considered
> > > attempting a
> > >  seamless transition that provided a wrapper python module for the
> > > youtube_dl
> > >  library and the /usr/bin/youtube-dl executable, but there are
> > > complications
> > >  (such slightly different behavior between the two programs even
> > > when using
> > >  yt-dlp's provided '--compat-options youtube-dl' argument, and
> > > programs that
> > >  are
> > >  aware of both yt-dlp and youtube-dl that will get confused if we
> > > pretend
> > >  that
> > >  youtube-dl is yt-dlp). Rather than risk the potential to introduce
> > > silent
> > >  bugs
> > >  into user setups, we prefer to simply 

Bug#1026392: transition: gnat-12

[Sebastian Ramacher]

On 2022-12-26 17:37:30 +0100, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> Control: forwarded -1 https://release.debian.org/transitions/html/gnat-12.html
> 
> Hi Nicolas
> 
> On 2022-12-23 14:19:36 +0100, Nicolas Boulenguez wrote:
> > > libgnatcoll-db succesfully built on mipsel in the meantime.
> > 
> > Yes, I have uploaded a fixed version.
> > 
> > > > - are removed from testing because of #1020018,
> > > > - are updated in experimental, but now
> > > >   fail to build on a supported architecture.
> > > > I intend to
> > > > - fill RC bugs against them in order to prevent their migration from
> > > >   unstable to to testing.
> > > Against libgmpada and libnatcoll-db or are there also others?
> > 
> > This only applies to libgmpada and bug #1026828.
> 
> Okay, then please go ahead with the transition.

Please note that autopkgtests of dh-ada-library fail:
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dh-ada-library/29759654/log.gz

Cheers

> 
> > > > - reupload them from experimental to unstable with the other packages
> > > >   as part of the transition
> > > >   (so that the versions depending on gnat-11 disappear from unstable)
> > > >   (and so that RC-buggy but mostly usable versions are available)
> > > > - try to fix the issues after the transition is completed
> > 
> > > Given the upcoming freeze, I'd suggest fixing those as soon as possible.
> > 
> > I fear I don’t know what to do for libgmpada.  The build fails
> > reproductibly on buildds but succeeds on the i386 porterbox.
> 
> Architecture-specific removal could be an option. In any case, if
> libgmpada should be part of bookworm, it needs to migrate to testing
> before the start of the soft freeze in February.
> 
> Cheers
> -- 
> Sebastian Ramacher
> 

-- 
Sebastian Ramacher

Bug#1024893: libcifpp: Requesting transition slot

[Sebastian Ramacher]

Control: tags -1 confirmed

Hi Maarten

On 2022-11-27 16:37:34 +0100, Maarten L. Hekkelman wrote:
> Source: libcifpp
> Severity: normal
> 
> Dear Maintainer,
> 
> libcifpp and libpdb-redo are both in experimental. I've prepared the 
> packages depending on them and am now requesting a time slot to take
> the following transition steps.

Assuming that the test builds against the new versions were successful,
please go ahead.

Cheers
-- 
Sebastian Ramacher

Processed: Re: Bug#1024893: libcifpp: Requesting transition slot

[Debian Bug Tracking System]

Processing control commands:

> tags -1 confirmed
Bug #1024893 [release.debian.org] transition: libcifpp
Added tag(s) confirmed.

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

Processed: Re: Bug#1027127: transition: zxing-cpp

[Debian Bug Tracking System]

Processing control commands:

> block -1 by 1025863
Bug #1027127 [release.debian.org] transition: zxing-cpp
1027127 was not blocked by any bugs.
1027127 was not blocking any bugs.
Added blocking bug(s) of 1027127: 1025863

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

Bug#1027127: transition: zxing-cpp

[Sebastian Ramacher]

Control: block -1 by 1025863

Hi Jochen

On 2022-12-28 08:41:25 +0100, Johannes Schauer Marin Rodrigues wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: zxing-...@packages.debian.org
> Control: affects -1 + src:zxing-cpp
> 
> Hi,
> 
> the gstreamer 1.22 release as well as mediastreamer2 5.2 need zxing-cpp
> version 1.4. Currently there is 1.2 in unstable and 1.4 in experimental.
> Boyuan Yang, the maintainer of zxing-cpp told me to take care of this
> transition as they lack the time right now to to so themselves.
> 
> I have rebuilt the reverse dependencies of libzxing-dev as listed here:
> 
> https://release.debian.org/transitions/html/auto-zxing-cpp.html
> 
> The one that FTBFS is libreoffice for which I submitted a bug here that
> is already fixed in unstable:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027048
> 
> Is it too late before the freeze to do this?

It's not too late, but we need to finish the qtbase-opensource-src
transition first.

Cheers
-- 
Sebastian Ramacher

Bug#1025056: transition: numerical library transition: hypre / petsc / slepc / sundials

[Anton Gladky]

Hi Sebastian,

sundials is already in NEW, fixing two RC bugs.
Dyssol will be uploaded shortly.

Regards

Anton

Am Di., 27. Dez. 2022 um 12:23 Uhr schrieb Sebastian Ramacher
:
>
> Hi Drew, hi Anton
>
> On 2022-12-19 21:52:10 +0100, Sebastian Ramacher wrote:
> > Hi Drew
> >
> > On 2022-12-19 18:14:53 +0100, Drew Parsons wrote:
> > > The hypre/petsc part of this transition is complete.
> > >
> > > The sundials part is waiting for dyssol to be patched.  Anton is preparing
> > > this.
> >
> > sundials will also need fixes for #1026330 and #1026352.
>
> Any news regarding sundials?
>
> Cheers
>
> >
> > Cheers
> >
> > >
> > > Drew
> > >
> > >
> > > On 2022-11-29 23:34, Sebastian Ramacher wrote:
> > > > Control: tags -1 confirmed
> > > >
> > > > Hi Drew
> > > >
> > > > On 2022-11-29 12:16:55 +0100, Drew Parsons wrote:
> > > > > Package: release.debian.org
> > > > > Severity: normal
> > > > > User: release.debian@packages.debian.org
> > > > > Usertags: transition
> > > > > X-Debbugs-Cc: Anton Gladky 
> > > > >
> > > > > We'd like to update the numerical library stack in time for the new
> > > > > stable release.
> > > > >
> > > > > Affected libraries are
> > > > >
> > > > > hypre2.25.0 -> 2.26.0
> > > > > petsc/slepc3.17 -> 3.18
> > > > > sundials  5.8.0 -> 6.4.1
> > > > >
> > > > > Autotransitions are already generated:
> > > > > https://release.debian.org/transitions/html/auto-hypre.html
> > > > > https://release.debian.org/transitions/html/auto-petsc.html
> > > > > https://release.debian.org/transitions/html/auto-slepc.html
> > > > > https://release.debian.org/transitions/html/auto-sundials.html
> > > > >
> > > > > Most of the dependent packages are under our control
> > > > > (Debian Science Team), octave is the main one outside our team.
> > > > >
> > > > > Updates have built fine in experimental and dependent
> > > > > packages are building successfully against them.
> > > > >
> > > > > Anton Gladky will upload the sundials update.
> > > >
> > > > Please go ahead
> > > >
> > > > Cheers
> > >
> >
> > --
> > Sebastian Ramacher
> >
>
> --
> Sebastian Ramacher