NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: cups_2.4.2-3+deb12u4_mipsel-buildd.changes
  ACCEPT

NEW changes in oldstable-new

[Debian FTP Masters]

Processing changes file: cups_2.3.3op2-3+deb11u6_arm64-buildd.changes
  ACCEPT
Processing changes file: cups_2.3.3op2-3+deb11u6_armel-buildd.changes
  ACCEPT
Processing changes file: cups_2.3.3op2-3+deb11u6_armhf-buildd.changes
  ACCEPT
Processing changes file: cups_2.3.3op2-3+deb11u6_mips64el-buildd.changes
  ACCEPT
Processing changes file: cups_2.3.3op2-3+deb11u6_mipsel-buildd.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: cups_2.4.2-3+deb12u4_armel-buildd.changes
  ACCEPT
Processing changes file: cups_2.4.2-3+deb12u4_armhf-buildd.changes
  ACCEPT
Processing changes file: cups_2.4.2-3+deb12u4_mips64el-buildd.changes
  ACCEPT
Processing changes file: cups_2.4.2-3+deb12u4_ppc64el-buildd.changes
  ACCEPT

NEW changes in oldstable-new

[Debian FTP Masters]

Processing changes file: cups_2.3.3op2-3+deb11u6_all-buildd.changes
  ACCEPT
Processing changes file: cups_2.3.3op2-3+deb11u6_amd64-buildd.changes
  ACCEPT
Processing changes file: cups_2.3.3op2-3+deb11u6_i386-buildd.changes
  ACCEPT
Processing changes file: cups_2.3.3op2-3+deb11u6_ppc64el-buildd.changes
  ACCEPT
Processing changes file: cups_2.3.3op2-3+deb11u6_s390x-buildd.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: cups_2.4.2-3+deb12u4_all-buildd.changes
  ACCEPT
Processing changes file: cups_2.4.2-3+deb12u4_amd64-buildd.changes
  ACCEPT
Processing changes file: cups_2.4.2-3+deb12u4_arm64-buildd.changes
  ACCEPT
Processing changes file: cups_2.4.2-3+deb12u4_i386-buildd.changes
  ACCEPT
Processing changes file: cups_2.4.2-3+deb12u4_s390x-buildd.changes
  ACCEPT

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

[Bastian Blank]

Hi

On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
> Those happen fairly often for urgent security updates.

We could encode that in the upstream version.  Aka to have
co-installable packages for security updates we do:

- 6.6.1-1
- 6.6.1+1-1
- 6.6.1+2-1

This allows for easy semantic, aka we only care for package names about
the upstream part of the version, which then needs to follow a certain
syntax.

Regards,
Bastian

-- 
A Vulcan can no sooner be disloyal than he can exist without breathing.
-- Kirk, "The Menagerie", stardate 3012.4

Bug#1053532: bookworm-pu: package arctica-greeter/0.99.3.0-1+deb12u2

[Mike Gabriel]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: arctica-gree...@packages.debian.org
Control: affects -1 + src:arctica-greeter

This is a follow-up upload of artica-greeter, +deb12u1 has already been
accepted for the next bookworm point release, but here comes another one
(explanation see below).

I have attached two debdiffs, one against arctica-greeter in bookworm,
one against arctica-greeter in bookworm-pu.

[ Reason ]
During the preparation of the Debian Edu 12 artwork I encountered a
problem with the logo positioning code in Arctica Greeter.

The previous code version would make assumptions of the logo height and
in the past we always used logo images of a certain pixel height.

However, the Debian 12 logo and the Debian Edu 12 logo differ in height
by design and the Debian Edu 12 would lap very far towards the bottom
border of the screen. Really not beautiful.

With Arctica Greeter upstream hat on I developed a patch that now allows
logos of any height with Arctica Greeter. This patch is shipped in
another bookworm-pu upload.

[ Impact ]
This is a change that makes Arctica Greeter in Debian Edu 12 more
beautiful. (We use Arctica Greeter for the MATE variant of Debian Edu).

If it does not get accepted, it won't leave anything in a broken or so,
it is merely an aesthetic fix.

[ Tests ]
Manual tests on a Debian bookworm and Debian Edu bookworm system.

[ Risks ]
Regression in arctica-greeter. Minimal.

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

+  * debian/patches:
++ Add 0008_better-positioning-of-logo.patch. Move logo in bottom-left
+  corner one grid-size count away from the border.

Patch cherry-picked from upstream PR:
https://github.com/ArcticaProject/arctica-greeter/pull/87

[ Other info ]
None.
diff -Nru 
arctica-greeter-0.99.3.0/debian/30_arctica-greeter-theme-debian.gschema.override
 
arctica-greeter-0.99.3.0/debian/30_arctica-greeter-theme-debian.gschema.override
--- 
arctica-greeter-0.99.3.0/debian/30_arctica-greeter-theme-debian.gschema.override
2023-03-01 19:35:03.0 +0100
+++ 
arctica-greeter-0.99.3.0/debian/30_arctica-greeter-theme-debian.gschema.override
2023-08-24 07:40:47.0 +0200
@@ -1,5 +1,5 @@
 [org.ArcticaProject.arctica-greeter]
-background='/usr/share/desktop-base/emerald-theme/login/background-nologo.svg'
+background='/usr/share/desktop-base/active-theme/login/background-nologo.svg'
 background-color='#032F3D'
 togglebox-button-bgcolor='#032F3D'
 togglebox-button-bordercolor='#032F3D'
diff -Nru arctica-greeter-0.99.3.0/debian/changelog 
arctica-greeter-0.99.3.0/debian/changelog
--- arctica-greeter-0.99.3.0/debian/changelog   2023-03-01 21:21:03.0 
+0100
+++ arctica-greeter-0.99.3.0/debian/changelog   2023-10-05 20:48:16.0 
+0200
@@ -1,3 +1,30 @@
+arctica-greeter (0.99.3.0-1+deb12u2) bookworm; urgency=medium
+
+  * debian/patches:
++ Add 0008_better-positioning-of-logo.patch. Move logo in bottom-left
+  corner one grid-size count away from the border.
+
+ -- Mike Gabriel   Thu, 05 Oct 2023 20:48:16 +0200
+
+arctica-greeter (0.99.3.0-1+deb12u1) bookworm; urgency=medium
+
+  * debian/patches:
++ [a11y] Add patches 0001 and 0002. Support configuring the onscreen
+  keyboard theme via ArcticaGreeter's gsettings.
++ [a11y, i18n]  Use 'Compact' OSK layout (instead of Small) which include
+  special keys such as German Umlauts, etc.
++ Add 0004-src-session-list.vala-Treat-gnome-xorg-as-GNOME-and-.patch. Show
+  correct icon for GNOME/X.Org session in session chooser list.
++ Add patches 0005, 0006 and 0007. Make PAM messages (esp. on login 
failure,
+  password expiry, etc.) be displayed fully and in readable colors.
+  * debian/30_arctica-greeter-theme-debian.gschema.override:
++ Use active theme rather then emerald (although the button color scheme
+  is designed for emerald). This allows the user/admin to adjust the
+  background image of Arctica Greeter via the alternative system in
+  desktop-base.
+
+ -- Mike Gabriel   Thu, 24 Aug 2023 19:58:57 +0200
+
 arctica-greeter (0.99.3.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
arctica-greeter-0.99.3.0/debian/patches/0001-data-org.ArcticaProject.arctica-greeter.gschema.xml-.patch
 
arctica-greeter-0.99.3.0/debian/patches/0001-data-org.ArcticaProject.arctica-greeter.gschema.xml-.patch
--- 
arctica-greeter-0.99.3.0/debian/patches/0001-data-org.ArcticaProject.arctica-greeter.gschema.xml-.patch
 1970-01-01 01:00:00.0 +0100
+++ 
arctica-greeter-0.99.3.0/debian/patches/0001-data-org.ArcticaProject.arctica-greeter.gschema.xml-.patch
 2023-08-24 07:40:06.0 +0200
@@ -0,0 +1,27 @@
+From 

Processed: bookworm-pu: package arctica-greeter/0.99.3.0-1+deb12u2

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:arctica-greeter
Bug #1053532 [release.debian.org] bookworm-pu: package 
arctica-greeter/0.99.3.0-1+deb12u2
Added indication that 1053532 affects src:arctica-greeter

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

NEW changes in oldstable-new

[Debian FTP Masters]

Processing changes file: cups_2.3.3op2-3+deb11u6_source.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: cups_2.4.2-3+deb12u4_source.changes
  ACCEPT

Processed: cups 2.4.2-3+deb12u4 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 1053523 = bookworm pending
Bug #1053523 [release.debian.org] bookworm-pu: cups/2.4.2-3+deb12u4
Added tag(s) pending.
> thanks
Stopping processing here.

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

Processed: cups 2.3.3op2-3+deb11u6 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 1053522 = bullseye pending
Bug #1053522 [release.debian.org] bullseye-pu: cups/2.3.3op2-3+deb11u6
Added tag(s) pending.
> thanks
Stopping processing here.

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

Bug#1053523: cups 2.4.2-3+deb12u4 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1053523 = 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: cups
Version: 2.4.2-3+deb12u4

Explanation: remove debian/NEWS again to avoid too much information when the 
server isn't installed; fix typo in config filename

Bug#1053522: cups 2.3.3op2-3+deb11u6 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1053522 = 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: cups
Version: 2.3.3op2-3+deb11u6

Explanation: remove debian/NEWS again to avoid too much information when the 
server isn't installed; fix typo in config filename

Bug#1053523: bookworm-pu: cups/2.4.2-3+deb12u4

[Thorsten Alteholz]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu


After uploading the fix for CVE-2023-4504 and CVE-2023-32360 to Buster I 
got some complaints:

 - the mentioned filename of the cupsd configuration contained a typo
   and several users were unsure what to do now ...
 - ... especially as the contents of debian/NEWS was also shown on
   computers where only cups client was installed.

So this upload fixes the typo and removes debian/NEWS again, so that the 
text is only shown when cups-daemon will be updated.


I know it is rather late for this, but maybe this makes things easier for 
our users.


  Thorsten
diff -Nru cups-2.4.2/debian/changelog cups-2.4.2/debian/changelog
--- cups-2.4.2/debian/changelog 2023-09-29 21:20:27.0 +0200
+++ cups-2.4.2/debian/changelog 2023-10-05 16:35:27.0 +0200
@@ -1,3 +1,11 @@
+cups (2.4.2-3+deb12u4) bookworm; urgency=medium
+
+  * remove debian/NEWS again to avoid too much information when only
+the client part is installed
+  * fix typo in config filename
+
+ -- Thorsten Alteholz   Thu, 05 Oct 2023 16:35:27 +0200
+
 cups (2.4.2-3+deb12u3) bookworm; urgency=medium
 
   * move debian/NEWS.Debian to debian/NEWS
diff -Nru cups-2.4.2/debian/cups-daemon.NEWS cups-2.4.2/debian/cups-daemon.NEWS
--- cups-2.4.2/debian/cups-daemon.NEWS  2023-09-29 21:20:27.0 +0200
+++ cups-2.4.2/debian/cups-daemon.NEWS  2023-10-05 16:35:27.0 +0200
@@ -4,7 +4,7 @@
   unauthorized users to fetch documents over local or remote networks.
   Since this is a configuration fix, it might be that it does not reach you if 
you
   are updating 'cups-daemon' (rather than doing a fresh installation).
-  Please double check your /etc/cups/cupds.conf file, whether it limits the 
access
+  Please double check your /etc/cups/cupsd.conf file, whether it limits the 
access
   to CUPS-Get-Document with something like the following
   >  
   >AuthType Default
diff -Nru cups-2.4.2/debian/NEWS cups-2.4.2/debian/NEWS
--- cups-2.4.2/debian/NEWS  2023-09-29 21:20:27.0 +0200
+++ cups-2.4.2/debian/NEWS  1970-01-01 01:00:00.0 +0100
@@ -1,16 +0,0 @@
-cups (2.4.2-3+deb12u3) bookworm; urgency=medium
-
-  This release addresses a security issue (CVE-2023-32360) which allows
-  unauthorized users to fetch documents over local or remote networks.
-  Since this is a configuration fix, it might be that it does not reach you if 
you
-  are updating 'cups-daemon' (rather than doing a fresh installation).
-  Please double check your /etc/cups/cupds.conf file, whether it limits the 
access
-  to CUPS-Get-Document with something like the following
-  >  
-  >AuthType Default
-  >Require user @OWNER @SYSTEM
-  >Order deny,allow
-  >   
-  (The important line is the 'AuthType Default' in this section)
-
- -- Thorsten Alteholz   Tue, 19 Sep 2023 21:20:27 +0200

Bug#1053522: bullseye-pu: cups/2.3.3op2-3+deb11u6

[Thorsten Alteholz]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu


After uploading the fix for CVE-2023-4504 and CVE-2023-32360 to Buster I
got some complaints:
 - the mentioned filename of the cupsd configuration contained a typo
   and several users were unsure what to do now ...
 - ... especially as the contents of debian/NEWS was also shown on
   computers where only cups client was installed.

So this upload fixes the typo and removes debian/NEWS again, so that the
text is only shown when cups-daemon will be updated.

I know it is rather late for this, but maybe this makes things easier for
our users.

  Thorsten
diff -Nru cups-2.3.3op2/debian/changelog cups-2.3.3op2/debian/changelog
--- cups-2.3.3op2/debian/changelog  2023-09-29 21:20:27.0 +0200
+++ cups-2.3.3op2/debian/changelog  2023-10-05 16:35:27.0 +0200
@@ -1,3 +1,11 @@
+cups (2.3.3op2-3+deb11u6) bullseye; urgency=medium
+
+  * remove debian/NEWS again to avoid too much information when only
+the client part is installed
+  * fix typo in config filename
+
+ -- Thorsten Alteholz   Thu, 05 Oct 2023 16:35:27 +0200
+
 cups (2.3.3op2-3+deb11u5) bullseye; urgency=medium
 
   * move debian/NEWS.Debian to debian/NEWS
diff -Nru cups-2.3.3op2/debian/cups-daemon.NEWS 
cups-2.3.3op2/debian/cups-daemon.NEWS
--- cups-2.3.3op2/debian/cups-daemon.NEWS   2023-09-29 21:20:27.0 
+0200
+++ cups-2.3.3op2/debian/cups-daemon.NEWS   2023-10-05 16:35:27.0 
+0200
@@ -4,7 +4,7 @@
   unauthorized users to fetch documents over local or remote networks.
   Since this is a configuration fix, it might be that it does not reach you if 
you
   are updating 'cups-daemon' (rather than doing a fresh installation).
-  Please double check your /etc/cups/cupds.conf file, whether it limits the 
access
+  Please double check your /etc/cups/cupsd.conf file, whether it limits the 
access
   to CUPS-Get-Document with something like the following
   >  
   >AuthType Default
diff -Nru cups-2.3.3op2/debian/NEWS cups-2.3.3op2/debian/NEWS
--- cups-2.3.3op2/debian/NEWS   2023-09-29 21:20:27.0 +0200
+++ cups-2.3.3op2/debian/NEWS   1970-01-01 01:00:00.0 +0100
@@ -1,16 +0,0 @@
-cups (2.3.3op2-3+deb11u5) bullseye; urgency=medium
-
-  This release addresses a security issue (CVE-2023-32360) which allows
-  unauthorized users to fetch documents over local or remote networks.
-  Since this is a configuration fix, it might be that it does not reach you if 
you
-  are updating 'cups-daemon' (rather than doing a fresh installation).
-  Please double check your /etc/cups/cupds.conf file, whether it limits the 
access
-  to CUPS-Get-Document with something like the following
-  >  
-  >AuthType Default
-  >Require user @OWNER @SYSTEM
-  >Order deny,allow
-  >   
-  (The important line is the 'AuthType Default' in this section)
-
- -- Thorsten Alteholz   Tue, 19 Sep 2023 21:20:27 +0200

Re: Upcoming changes to Debian Linux kernel packages

[Russ Allbery]

Sam Hartman  writes:

> B) They might already have headers installed.  Imagine someone who
> installs headers at the same time they install the kernel.  Unless they
> managed to upgrade the same version of their kernel without also
> upgrading their headers, they will still have headers.  They can still
> build modules against that kernel, either because they installed a new
> dkms package, or because one of their dkms packages upgraded.

I am also really confused by this discussion and don't entirely understand
the motivation for the proposed change to kernel headers, but isn't the
situation Sam describes above the normal way Linux kernel headers work and
have worked for years?  Kernels come with headers matching the same
version, if you want headers for external modules you install both
packages at the same time via one mechanism or another, and you only
remove the kernel and headers when you're pretty sure you will never use
that kernel again.

When I was using external modules heavily, I routinely kept three or four
old kernels and their corresponding headers installed at the same time so
that I could easily downgrade if I ran into regressions without having to
track down old packages that may have been removed from the archive.  This
feels like a normal and somewhat obvious Debian systems administration
thing to do to me.

I realize in the new signing regime every new kernel would have a separate
headers package (as opposed to today where the kernel and headers are
updated in place with the same package name if there is no ABI change),
but to me this doesn't feel like a significant difference for users.  I
haven't been paying close attention, so maybe I'm wrong, but I feel like
most kernel package updates have been ABI updates anyway, particularly in
stable.

-- 
Russ Allbery (r...@debian.org)  

Re: Upcoming changes to Debian Linux kernel packages

[Sam Hartman]

> "Bastian" == Bastian Blank  writes:

Bastian> The same as now: nowhere, because those packages have been
Bastian> removed from the archive already.

Bastian> And sadly you did not answer the question why a second
Bastian> degree error must not be worse then a worked around first
Bastian> degree error?

I'll admit that I find that phrasing difficult enough that I had to read
it a couple of times and I'm still not sure I've got it.

Let me see if I understand what you are saying.

1)  kernel headers will be removed from the archive.  So people complain
if they have an old kernel and wish to get kernel headers for it, but
those headers have been removed.

2) If the kernel header version changes but the kernel header package
name does not change  (version changed but not uname -r in the new
scheme?), you can have what you think is the right kernel headers but
they do not work with the binaries you have installed.

3) you can run into trouble between testing and backports.

I think that's what you mean by the first-level error.
If not, I'm still confused.

In the second level error case you are talking about is:

1) there is a regression in the kernel

2) someone needs kernel headers for an old kernel they want to downgrade
to.

I don't actually see how this is a second level error.
It appears to be a different first-level error (a regression), and  the
downgrade appears to follow naturally from that.

You point out that someone may not be able to get kernel headers for the
downgraded kernel.

a) They might.  In the window between a new kernel being introduced into
unstable and the same kernel being introduced into testing  there is an
old kernel available with kernel headers.
Similarly if someone needs to downgrade as far as stable, there is a
kernel with headers available in stable.

B) They might already have headers installed.  Imagine someone who
installs headers at the same time they install the kernel.
Unless they managed to upgrade the same version of their kernel without
also upgrading their headers, they will still have headers.
They can still build modules against that kernel, either because they
installed a new dkms package, or because one of their dkms packages
upgraded.

I think what you are saying is that

1) the current system is fragile: sometimes you want a kernel headers
that is not available and sometimes you have version skew between the
kernel headers and kernel even though you have both installed.

2) In your system, fewer things are possible, but the combination that
is possible is more likely to work.

And I think people's response is that
they care enough about some of the things you are breaking that they are
willing to accept the fragility.


Bastian> -- Each kiss is as the first.  -- Miramanee, Kirk's wife,
Bastian> "The Paradise Syndrome", stardate 4842.6

Bug#1028489: transition: boost1.81

[Adrian Bunk]

On Wed, Oct 04, 2023 at 03:23:46PM -0400, David James wrote:
> Hi Anton,
> 
> Is there anything I can do to help this transition along? I wish to
> package software that does not build on 1.74, but does on 1.81 and 1.82.
> If there's anyway I can assist with bumping boost-defaults to 1.81 or 1.82
> I would be happy to help.

Note that as a workaround you could temporarily use a non-default boost 
by build depending on libboost-foo1.81-dev instead of libboost-foo-dev,
and then later switch to libboost-foo-dev (>= 1.81) [1] after the 
defaults change.

> Regards,
> 
> David James

cu
Adrian

[1]   Build-Depends: libboost-foo-dev (>= 1.81) | libboost-foo1.81-dev
would then (*after* the defaults change) be an alternative option to 
make the package easily backportable since boost1.81 is already in
bookworm and even bullseye-backports

Bug#1052252: marked as done (transition: grantlee5)

[Debian Bug Tracking System]

Your message dated Thu, 5 Oct 2023 13:45:32 +0200
with message-id 
and subject line Re: Bug#1052252: transition: grantlee5
has caused the Debian Bug report #1052252,
regarding transition: grantlee5
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.)


-- 
1052252: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052252
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: grantl...@packages.debian.org, 
pkg-kde-t...@alioth-lists.debian.net
Control: affects -1 + src:grantlee5

Hi,

grantlee (packaged in Debian in src:grantlee5) is a library (two
libraries, in practice) that has a stable API/ABI. The new release
5.3.x, currently in experimental, is generally usable by users
built with the old version.

The only gotcha is that plugins for it are installed and loaded from
paths with the major and minor version in it, i.e.
  ../plugins/grantlee/./
This means that, after the upgrade to a new minor series, the plugins
installed after building with the old version are not used anymore;
usually software using grantlee and shipping plugins for it follows
the grantlee version, so a simple rebuild is enough to fix the issue.

Since I wanted to avoid uploading the new version and have to manually
track external plugins and breaking users that rely on those plugins,
I created a new simple dh_grantlee helper to track the dependency on
the version the plugins were built for, adding the provide for it in
one of the two grantlee libraries as "grantlee5-templates-MAJOR-MINOR".
This is already in place in unstable starting from grantlee5 5.2.0-5,
and the 4 sources that install plugins for it were already changed to
use dh_grantlee, and thus now properly track their plugin dependency.

Hence, I'd like to request a transition slot for uploading grantlee5
5.3.x to unstable, rebuilding the few dependencies needed:
- kcalutils
- kdevelop
- libkf5grantleetheme
- skrooge

They all build fine with the new grantlee; I have the new version of
kdevelop ready in experimental, and I can upload that rather than
rebuilding the current version in unstable.

Ben file:

title = "grantlee5";
is_affected = .depends ~ "grantlee5-templates-5-2" | .depends ~ 
"grantlee5-templates-5-3";
is_good = .depends ~ "grantlee5-templates-5-3";
is_bad = .depends ~ "grantlee5-templates-5-2";

Thanks,
-- 
Pino
--- End Message ---
--- Begin Message ---
On 2023-09-28 00:04:18 +0200, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> Control: forwarded -1 
> https://release.debian.org/transitions/html/grantlee5-3.html
> 
> On 2023-09-19 16:52:46 +0200, Pino Toscano wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: grantl...@packages.debian.org, 
> > pkg-kde-t...@alioth-lists.debian.net
> > Control: affects -1 + src:grantlee5
> > 
> > Hi,
> > 
> > grantlee (packaged in Debian in src:grantlee5) is a library (two
> > libraries, in practice) that has a stable API/ABI. The new release
> > 5.3.x, currently in experimental, is generally usable by users
> > built with the old version.
> > 
> > The only gotcha is that plugins for it are installed and loaded from
> > paths with the major and minor version in it, i.e.
> >   ../plugins/grantlee/./
> > This means that, after the upgrade to a new minor series, the plugins
> > installed after building with the old version are not used anymore;
> > usually software using grantlee and shipping plugins for it follows
> > the grantlee version, so a simple rebuild is enough to fix the issue.
> 
> Please go ahead.

grantlee5 and its reverse dependencies migrated.

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

Bug#1028489: transition: boost1.81

[Anton Gladky]

Hi James,

thanks for the offer. At the moment I am preparing 1.83 and will ask for
transition soon.

Best regards

David James  schrieb am Mi., 4. Okt. 2023, 20:23:

> Hi Anton,
>
> Is there anything I can do to help this transition along? I wish to
> package software that does not build on 1.74, but does on 1.81 and 1.82.
> If there's anyway I can assist with bumping boost-defaults to 1.81 or 1.82
> I would be happy to help.
>
> Regards,
>
> David James
>
>

Re: Upcoming changes to Debian Linux kernel packages

[Bastian Blank]

On Tue, Oct 03, 2023 at 03:00:53PM -0500, Robert Nelson wrote:
> On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk  wrote:
> > How will the user get the headers matching this previously-used kernel
> > that are required until we provide a kernel with the regression fixed?

The same as now: nowhere, because those packages have been removed from
the archive already.

And sadly you did not answer the question why a second degree error must
not be worse then a worked around first degree error?

> I know there is a lot of history behind the linux-headers package in
> debian.  However since 5.2 there is a kernel config option, which
> allows you to build the kernel headers as a module (built-in or
> external)..
> https://cateee.net/lkddb/web-lkddb/IKHEADERS.html
> As long as this was enabled (ignore bugs/regressions), users can go
> back and forth on kernel versions as they wish.

If it would be so easy.  This would include all the generated things of
the build.  But it still needs all the static headers, all the support
binaries and scripts (shipped as linux-kbuild-*), which also change with
every version.

Regards,
Bastian

-- 
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
   stardate 4842.6

Re: Upcoming changes to Debian Linux kernel packages

[Bastian Blank]

Hi Andreas

On Tue, Oct 03, 2023 at 11:58:29PM +0200, Andreas Beckmann wrote:
> That should solve the problem where several source packages need to be
> updated together.

The problem does not come from multiple source packages that need to be
updated together.  Instead it comes from the way Debian does signing of
secure boot components.  After the linux packages got built and accepted,
an automatic process takes the output and produces a new source package
that is uploaded, built and accepted.  So the signed stuff will always
come later (between hours or days in normal cases, but esp for backports
even more then a week later).

Regards,
Bastian

-- 
Insults are effective only where emotion is present.
-- Spock, "Who Mourns for Adonais?"  stardate 3468.1