Bug#1070659: transition: re2

[stefanor]

Hi Adrian (2024.05.07_17:39:58_+)
> Could this be solved through Provides, so that it could be handled 
> with binNMUs during abseil transitions?

Implemented in 20240501-2.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

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

[Craig Small]

On Wed, 8 May 2024 at 09:03, Jun MO  wrote:

> 1) I hope there will still be the original
> w(1)/last(1)/lastb(1)/lastlog(1)/faillog(1)
> tools which can still read *old* format utmp/wtmp/lastlog in Debian at
> least for
> a while after switch to Y2038-safe replacements. Those tools can read
>

I can only speak for w.  It currently prefers what it gets from systemd or
elogind, effectively
iterating over the sessions coming from sd_get_sessions() if sd_booted()
returns true.

If sd_booted() returns false, then it uses the old utmp/utmpx files for
now. Besides the Y2038
issue, the utmp "API" is pretty awful with things like errors pretty much
undetectable. There is also
the problem about who (e.g. which process) should be writing to those files
as you have pointed out
in your email.

For now w/uptime will use utmp as a fallback, but I'll be happy if this
gets updated to something better; it's a low-priority
for me because systemd/elogind do what I need most of the time.

 - Craig

Bug#1070723: bullseye-pu: package bart/0.6.00-3+deb11u1

[Santiago Vila]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: b...@packages.debian.org, sanv...@debian.org
Control: affects -1 + src:bart

[ Reason ]
This upload fixes Bug #1026061 FTBFS randomly in bullseye.

[ Impact ]
Anybody who try to build the package from source may find
that the package FTBFS unexpectedly.

[ Tests ]
I've tested the fixed package in the AWS instances where it
used to fail, and it does not fail anymore.

[ Risks ]
Very low risk, as the change merely increases the tolerance for
a floating point comparison in the tests. The program itself
does not really change.

[ 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 ]
See debdiff.

[ Other info ]
I'm going to upload the package after sending this report,
but I'll wait for approval before pushing changes to salsa.diff -Nru bart-0.6.00/debian/changelog bart-0.6.00/debian/changelog
--- bart-0.6.00/debian/changelog2020-09-21 16:16:16.0 +0200
+++ bart-0.6.00/debian/changelog2024-05-07 23:05:00.0 +0200
@@ -1,3 +1,11 @@
+bart (0.6.00-3+deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * Cherry-pick 0004-relax-failing-unit-test.patch from
+release 0.7.00-1. Fixes FTBFS bug. Closes: #1026061.
+
+ -- Santiago Vila   Tue, 07 May 2024 23:05:00 +0200
+
 bart (0.6.00-3) unstable; urgency=medium
 
   * Team upload
diff -Nru bart-0.6.00/debian/patches/0004-relax-failing-unit-test.patch 
bart-0.6.00/debian/patches/0004-relax-failing-unit-test.patch
--- bart-0.6.00/debian/patches/0004-relax-failing-unit-test.patch   
1970-01-01 01:00:00.0 +0100
+++ bart-0.6.00/debian/patches/0004-relax-failing-unit-test.patch   
2024-05-07 23:05:00.0 +0200
@@ -0,0 +1,21 @@
+From: Martin Uecker 
+Date: Mon, 25 Oct 2021 18:59:03 +0200
+Subject: relax failing unit test
+
+---
+ utests/test_nufft.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/utests/test_nufft.c b/utests/test_nufft.c
+index ec02762..95b65c5 100644
+--- a/utests/test_nufft.c
 b/utests/test_nufft.c
+@@ -114,7 +114,7 @@ static bool test_nufft_adjoint(void)
+ 
+   debug_printf(DP_DEBUG1, "adjoint diff: %f\n", diff);
+ 
+-  bool ret = (diff < 1.E-6f);
++  bool ret = (diff < 1.E-5f);
+ 
+   linop_free(op);
+ 
diff -Nru bart-0.6.00/debian/patches/series bart-0.6.00/debian/patches/series
--- bart-0.6.00/debian/patches/series   2020-09-21 16:16:16.0 +0200
+++ bart-0.6.00/debian/patches/series   2024-05-07 23:05:00.0 +0200
@@ -1,3 +1,4 @@
 0001-makefile-change-for-compatibility-with-debian.patch
 0002-remove-empty-directory.patch
 0003-deactivate-ode-unit-tests.patch
+0004-relax-failing-unit-test.patch

Processed: bullseye-pu: package bart/0.6.00-3+deb11u1

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:bart
Bug #1070723 [release.debian.org] bullseye-pu: package bart/0.6.00-3+deb11u1
Added indication that 1070723 affects src:bart

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

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

[Jun MO]

Dear Developers,

A bit from a Debian user. Please note that I am not come to here to 
blame/complain
against the Upstream/Maintainer of the pam package and the Maintainer of 
the shadow
package, or come to here to request something. I just come to here to 
present

some of my hope.

I often use the w(1)/last(1) command, and sometimes use the lastb(1) 
command.
Several days ago, I noticed that records logged in from 
console(tty{1..6}) are missing
from the output of last(1) while records from ssh/tmux/lightdm are still 
there,
and I started to guess maybe some of my recent changes to the system 
caused this.
Today I try to find out what happened, and after several hours of 
fruitless effort
(try different options of agetty/login, use strace/gdb on agetty/login 
and read
the source of the shadow package), I noticed that a word "pam_lastlog" 
in the

source code. Finally I find out the problem is caused by that login(1) use
pam_lastlog.so to write /var/log/wtmp, but pam_lastlog.so was not longer 
included
in the libpam-modules package. (It was somehow related to #1068229, but 
I missed

it.)

From my understanding, why we need to deal with the Y2038 issue is that 
the issue
may cause problems, some of which will be big problems, after year 2038. 
But so,
let's now rush some changes, to confuse users or break something? (Just 
joke and,
again I am not to blame anyone.) Are there issues using 
utmp/wtmp/lastlog and
w(1)/last(1)/lastlog(1), *currently*? Are there security issues, big 
defects or

are they hard to maintain?

If not, I prefer a bit more slow pace, compatible and less disturbed 
process.

More specifically, regarding to some changes proposed in the wiki [1],

1) I hope there will still be the original 
w(1)/last(1)/lastb(1)/lastlog(1)/faillog(1)
tools which can still read *old* format utmp/wtmp/lastlog in Debian at 
least for
a while after switch to Y2038-safe replacements. Those tools can read 
old format

files without convert/import to new format. I am keeping old wtmp files for
several years. Starting from 2016 my system with a proprietary nvidia 
driver failed to

resume from suspend2ram and playing a video using hardware accelerator would
cause the system unstable. Five years later, still having the problem, 
with some
help of reading kernel version from `last -f /var/log/wtmp.*', I finally 
found
out that there is a commit change in the kernel caused the problem. This 
shows
that having those tools installed may provide a few help. Another point 
may be
that package from 3rd parties may still write old-format 
utmp/wtmp/lastlog, it
will be good still having those tools installed at least for a while. 
Those tools
may be modified that when invoked, print messages to inform users 
time/date maybe
incorrect after the year 2038, and suggest/recommend/urge users only use 
those

tools to read old files and switch to use new replacements. Anyway it seems
keeping those tools have little harm. And I have a look into wtmpdb, 
from salsa[2].
From manpage and --help, it seems to me the current version 0.11.0 of 
wtmpdb does
not support read/import/migrate from /var/log/wtmp, the suggest of 
/usr/bin/wtmpdb
take over last(1) in the wiki is not feasible as some user may still 
expect using
`last -f /var/log/wtmp.*' to read old files. Even if new version of 
wtmpdb can
read from /var/log/wtmp without import it into 
/var/lib/wtmpdb/wtmpdb.db, it is
still good to have a choose to use the original last(1) to read from 
/var/log/wtmp.
(Also see below.) It is similar to lastlog2. I see lastlog2 can already 
import
from /var/log/lastlog, but from usage() [3], it will always import to a 
lastlog2

database.
2) I hope I can choose keeping or deleting the old utmp/wtmp/lastlog 
files when
switch to Y2038-safe replacements. By default, those old files may be 
automatically
deleted, but before extracting new package/running maint scripts, there 
may be a prompt
telling users that those files will be deleted and asking users chose 
whether continue
or not; if not, dpkg should exit without deleted those files. Or those 
will not be
automatically deleted, instead a Debian.NEWS may be displayed or maint 
script can
print a message telling those files can be safely deleted after 
converted. I think
the current dpkg already have functions to implement aforementioned 
actions as I
have seen something alike many times. I known normally purge a package 
will deleted
its log(and configuration), but wtmp/btmp/lastlog/faillog do not belong 
to any
package and many program can read from/write to them. Also it seems to 
me that
deleting logs during upgrade is not so good, and maybe leave it to users 
to decide.
You may ask why I want to keep those old format files instead of 
converting them
and use new tools to read? I can not exactly tell why, but I maybe 
afraid the
converting may not perfect and I want to compare both output before 
deleting the
old ones. For example, the old format files may have corrupted, and the 
conve

Re: Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Simon McVittie]

Control: severity 1070706 normal
Control: severity 1070714 normal

On Tue, 07 May 2024 at 22:53:33 +0200, Cyril Brulebois wrote:
> Simon McVittie  (2024-05-07):
> > do the release/installer teams consider udeb dependencies
> > on non-udeb packages, by udebs that d-i does not currently need or use,
> > to be a RC issue or merely a nice-to-have?
> 
> If udebs are actually used, I call that an RC bug and try to get it
> fixed swiftly (sometimes NMUing right away when time is of the essence).
> Otherwise I usually let those fly (without even filing bug reports).

In that case I'm downgrading #1070714 and #1070706 to normal, because the
issues I noticed while investigating #1070706 are worth tracking and being
aware of but non-RC, and the issue that Peter originally reported is not
actionable for the gtk4 maintainers (it needs to be fixed via a binNMU).

We'll need to revisit #1070714 and #1070706 if someone makes a concerted
effort to GTK3ize the installer, but that has been on my to-do list since
before bookworm and shows no signs of approaching the top, so it might
have to be someone else's project.

Thanks!

smcv

Re: Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Cyril Brulebois]

Hi Simon,

Simon McVittie  (2024-05-07):
> Looking at the d-i Packages.gz for amd64, the only other source
> package that has picked up the bad libpng16-16t64-udeb dependency
> seems to be matchbox-keyboard, which needs a sourceful upload to fix an
> implicit-declarations FTBFS anyway, therefore isn't useful to binNMU.

Yeah, I forgot to mention it when I worked on making d-i buildable and
runnable again, then decided it didn't matter as it's not used (TTBOMK)
at the moment.

> After that: do the release/installer teams consider udeb dependencies
> on non-udeb packages, by udebs that d-i does not currently need or use,
> to be a RC issue or merely a nice-to-have?

If udebs are actually used, I call that an RC bug and try to get it
fixed swiftly (sometimes NMUing right away when time is of the essence).
Otherwise I usually let those fly (without even filing bug reports).

See: https://d-i.debian.org/dose/
Some backstory: https://lists.debian.org/debian-boot/2024/03/msg00102.html


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


signature.asc
Description: PGP signature

Re: Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Simon McVittie]

On Tue, 07 May 2024 at 22:02:12 +0200, Paul Gevers wrote:
> On 07-05-2024 7:49 p.m., Simon McVittie wrote:
> > The version in testing, 4.12.5+ds-3, has the same dependencies, so this
> > is not a regression.
> 
> Is it? It seems that the version in unstable depends on libpng16-16t64-udeb
> where the version in testing depends on libpng16-16-udeb. The later exists,
> the former not.

Oh, well spotted! It looks as though src:gtk4 needs a binNMU against
libpng-dev (>= 1.6.43-4) for #1066069, because we were unlucky with
the timing of gtk4's most recent upload and so it got built against the
incorrect libpng-dev.

My understanding is that a binNMU would be better than a sourceful upload
of gtk4 because it won't reset the migration clock. If that's correct,
please could someone with release team or wanna-build powers schedule it?

nmu gtk4_4.12.5+ds-6 . ALL . -m 'rebuild with #1066069 fixed'

Looking at the d-i Packages.gz for amd64, the only other source
package that has picked up the bad libpng16-16t64-udeb dependency
seems to be matchbox-keyboard, which needs a sourceful upload to fix an
implicit-declarations FTBFS anyway, therefore isn't useful to binNMU.

After those binNMUs, the gtk4 udeb will still not be installable into
the debian-installer environment (either in testing or in unstable), but
it should at least be able to migrate, because all of its dependencies
will be packages that exist (whether deb or udeb).

After that: do the release/installer teams consider udeb dependencies
on non-udeb packages, by udebs that d-i does not currently need or use,
to be a RC issue or merely a nice-to-have?

Thanks,
smcv

Re: Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Paul Gevers]

Hi,

On 07-05-2024 7:49 p.m., Simon McVittie wrote:

The version in testing, 4.12.5+ds-3, has the same dependencies, so this
is not a regression.


Is it? It seems that the version in unstable depends on 
libpng16-16t64-udeb where the version in testing depends on 
libpng16-16-udeb. The later exists, the former not.



Is this requirement newly enforced by britney?


No.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070708: marked as done (unblock: rust-chrono/0.4.38-2)

[Debian Bug Tracking System]

Your message dated Tue, 7 May 2024 20:45:18 +0200
with message-id <751079c1-944a-4350-a5f5-80775c7e2...@debian.org>
and subject line Re: Bug#1070708: unblock: rust-chrono/0.4.38-2
has caused the Debian Bug report #1070708,
regarding unblock: rust-chrono/0.4.38-2
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.)


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

rust-chrono's testing excuses say (and have listed for at least a day or so)

autopkgtest for rust-trash/3.3.1-1: amd64: Test in progress, arm64: Pass, i386: 
Pass, ppc64el: Pass, s390x: Pass

However, when I look over on debci I do not see any relavent pending tests.
There is a test that looks relavent to me a few days ago

rust-chrono/0.4.38-2 rust-fundu/1.0.0...
src:rust-chrono from unstable
src:rust-fundu from unstable
src:rust-pure-rust-locales from unstable 

which passed, but britney seems to be ignoring it. 

Can you figure out what is going wrong and either fix it or override the tests?
--- End Message ---
--- Begin Message ---

Forgot to close in my previous message.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---

Bug#1070708: unblock: rust-chrono/0.4.38-2

[Paul Gevers]

Hi,

On 07-05-2024 5:55 p.m., plugwash wrote:

Can you figure out what is going wrong and either fix it or override the tests?


As noted on IRC, it's unclear what caused this. I retriggered the test 
and it's now picked up.


For those watching, britney2 would have done this by itself too after 5 
days:

https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/autopkgtest.py?ref_type=heads#L138

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070659: transition: re2

[stefanor]

Hi Adrian (2024.05.07_17:39:58_+)
> Could this be solved through Provides, so that it could be handled 
> with binNMUs during abseil transitions?
> 
> Example:
> 
> Package: libboost-regex1.74.0
> Depends: ..., libicu72 (>= 72.1~rc-1~),...
> Provides: libboost-regex1.74.0-icu72
> 
> $ cat /var/lib/dpkg/info/libboost-regex1.74.0\:amd64.shlibs 
> libboost_regex 1.74.0 libboost-regex1.74.0-icu72

That's a neat trick. Can definitely do that.

I notice that libboost-regex doesn't include -icuXX in the soname, just
the package. That's probably good enough and I'll copy that.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Simon McVittie]

Control: tags -1 + d-i
Control: found -1 4.12.5+ds-3
Control: retitle -1 gtk4 udeb has unsatisfiable dependencies
Control: clone -1 -2
Control: retitle -2 libvte-2.91-0-udeb depends on both GTK 3 and GTK 4
Control: reassign -2 src:vte2.91 0.75.92-1

On Tue, 07 May 2024 at 15:44:02 +0100, Peter Michael Green wrote:
> According to britney, gtk4's udebs are uninstallable.

gtk4 is not yet used by debian-installer (which is still on GTK 2)
so the udeb is not actually necessary, and one workaround would be to
disable it entirely (but then we'd have to put GTK 4 through NEW again
if we are ever able to upgrade d-i to it).

The version in testing, 4.12.5+ds-3, has the same dependencies, so this
is not a regression. Is this requirement newly enforced by britney?

I think a large part of the problem is that when GTK 4 support was added
to src:vte2.91, both the GTK 3 and GTK 4 versions were put into the same
udeb package, libvte-2.91-0-udeb, instead of giving the GTK 4 version
its own udeb. However, I'm unsure how that change got into testing -
if britney is enforcing installability of udebs, I would have expected
that the updated libvte-2.91-0-udeb would have been newly-uninstallable,
preventing its migration?

It seems most realistic that d-i in Debian 13 will depend on GTK 3 if
someone finds the time to do the necessary porting and testing, or stay
on GTK 2 if not, so libvte-2.91-0-udeb should become a udeb version of
only libvte-2.91-0 (i.e. GTK 3 only) as it was in Debian 12, and drop
its GTK 4 parts. That would mean that GTK 4 would no longer be regressing
the installability of libvte-2.91-0-udeb.

If there is a serious attempt to get d-i using GTK *4*, then that would
require a new libvte-2.91-gtk4-0-udeb. However, GTK 4's threading model
is definitely incompatible with the current design of cdebconf-gtk (it
calls into GTK from more than one thread, which is discouraged in GTK
3 and not allowed at all in GTK 4), so a prerequisite for that would
be to move all of cdebconf-gtk's GTK interactions onto one thread,
with message-passing between that thread and the cdebconf thread.

I'm also unsure how GTK 4 can possibly have caused libvte-2.91-0-udeb's
installability to regress anyway, because libvte-2.91-0-udeb in testing
depends on liblz4-1, which does not have a corresponding udeb. That
will need fixing (by adding a liblz4-1-udeb, or linking it statically,
or allowing .deb libraries to satisfy udebs' dependencies) if we ever
want a GTK 3 or later installer.

Making the GTK 4 udeb installable looks like a significant task. It depends
on:

OK - fontconfig-udeb (>= 2.15.0),
OK - libc6-udeb (>= 2.37),
!! - libcairo-script-interpreter2 (>= 1.18.0),
OK - libcairo2-udeb (>= 1.18.0),
OK - libepoxy0-udeb (>= 1.5.4),
OK - libfribidi0-udeb (>= 1.0.13),
OK - libgdk-pixbuf-2.0-0-udeb (>= 2.42.10+dfsg),
OK - libglib2.0-udeb (>= 2.78.4),
!! - libgraphene-1.0-0 (>= 1.10.8),
OK - libharfbuzz0-udeb (>= 8.3.0),
!! - libjpeg62-turbo (>= 1:2.1.5),
OK - libpango1.0-udeb (>= 1.52.1+ds),
OK - libpng16-16t64-udeb (>= 1.6.2),
!! - libtiff6 (>= 4.5.1+git230720),
OK - libx11-6-udeb (>= 2:1.6.0),
OK - libxcursor1-udeb (>> 1.1.2),
!! - libxdamage1 (>= 1:1.1),
OK - libxext6-udeb (>= 2:1.3.0),
OK - libxfixes3-udeb (>= 1:5.0),
OK - libxi6-udeb (>= 2:1.6.99.1),
OK - libxinerama1-udeb (>= 2:1.1.4),
OK - libxrandr2-udeb (>= 2:1.5)

cairo has a udeb, but it doesn't include the equivalent of
libcairo-script-interpreter2. It might be possible to disable the GTK
features that rely on that library? Or it might be possible to add the
script interpreter to the udeb?

graphene does not have udebs at all, and I think it's a mandatory
dependency for GTK 4, so if we ever want a GTK-4-based d-i, there is
no avoiding adding a graphene udeb.

libjpeg-turbo, tiff and libxdamage are in the same situation as graphene
(these were optional in GTK 3 but are required in GTK 4). Unlike graphene,
these are not maintained by the GNOME team, so we cannot unilaterally
add udebs to them.

smcv

Bug#1070659: transition: re2

[Adrian Bunk]

On Mon, May 06, 2024 at 01:09:37PM -0400, Stefano Rivera wrote:
>...
> included a new dependency on abseil. This broke most of the
> reverse-dependencies. It also means that transitions will get more
> frequent, as every abseil transition will change re2's ABI.
>...

Could this be solved through Provides, so that it could be handled 
with binNMUs during abseil transitions?

Example:

Package: libboost-regex1.74.0
Depends: ..., libicu72 (>= 72.1~rc-1~),...
Provides: libboost-regex1.74.0-icu72

$ cat /var/lib/dpkg/info/libboost-regex1.74.0\:amd64.shlibs 
libboost_regex 1.74.0 libboost-regex1.74.0-icu72
$

> Stefano

cu
Adrian

Bug#1070708: unblock: rust-chrono/0.4.38-2

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

rust-chrono's testing excuses say (and have listed for at least a day or so)

autopkgtest for rust-trash/3.3.1-1: amd64: Test in progress, arm64: Pass, i386: 
Pass, ppc64el: Pass, s390x: Pass

However, when I look over on debci I do not see any relavent pending tests.
There is a test that looks relavent to me a few days ago

rust-chrono/0.4.38-2 rust-fundu/1.0.0...
src:rust-chrono from unstable
src:rust-fundu from unstable
src:rust-pure-rust-locales from unstable 

which passed, but britney seems to be ignoring it. 

Can you figure out what is going wrong and either fix it or override the tests?

Processed: Re: Bug#1070703: transition: libunibreak

[Debian Bug Tracking System]

Processing control commands:

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

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

Bug#1070703: transition: libunibreak

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 07/05/2024 15:52, Pino Toscano wrote:

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: libunibr...@packages.debian.org
Control: affects -1 + src:libunibreak
User: release.debian@packages.debian.org
Usertags: transition

Hi,

I'd like to request a transition slot for the update of the libunibreak
library 5.1 to 6.1. Each new major version bumps the SOVERSION, and in
this case there are only few new symbols.

There are few users of libunibreak in Debian:
- fbreader
- krita
- libass
I verified that all of them build fine using the new version of
libunibreak.


Go ahead.

Emilio

Processed: transition: libunibreak

[Debian Bug Tracking System]

Processing control commands:

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

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

Bug#1070703: transition: libunibreak

[Pino Toscano]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: libunibr...@packages.debian.org
Control: affects -1 + src:libunibreak
User: release.debian@packages.debian.org
Usertags: transition

Hi,

I'd like to request a transition slot for the update of the libunibreak
library 5.1 to 6.1. Each new major version bumps the SOVERSION, and in
this case there are only few new symbols.

There are few users of libunibreak in Debian:
- fbreader
- krita
- libass
I verified that all of them build fine using the new version of
libunibreak.

Ben file:

title = "libunibreak";
is_affected = .depends ~ "libunibreak5" | .depends ~ "libunibreak6";
is_good = .depends ~ "libunibreak6";
is_bad = .depends ~ "libunibreak5";

Thanks,
-- 
Pino

Processed: bookworm-pu: package nano/7.2-1+deb12u1

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:nano
Bug #1070702 [release.debian.org] bookworm-pu: package nano/7.2-1+deb12u1
Added indication that 1070702 affects src:nano

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

Bug#1070702: bookworm-pu: package nano/7.2-1+deb12u1

[Jordi Mallach]

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

As we did in previous Debian releases, this is an update
for Debian stable's nano package with selected patches from
the upstream maintainer.

3 of the patches minor security issues, and the other one
fixes a potential data-loss issue.

Additionally there's a minor update to the default nanorc which
is a backport from 7.2-2, which was meant to be included in
Debian 12.0 but freeze came along. It just gets rid of some
control characters in some commented-out example bindings,
replacing them with the new style syntax.

[ 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

This source update was prompted by Salvatore while discussing one of the
3 security issues.

Thanks in advance,
Jordi
diff -Nru nano-7.2/debian/changelog nano-7.2/debian/changelog
--- nano-7.2/debian/changelog   2023-01-18 16:31:52.0 +0100
+++ nano-7.2/debian/changelog   2024-05-06 08:10:01.0 +0200
@@ -1,3 +1,15 @@
+nano (7.2-1+deb12u1) bookworm; urgency=medium
+
+  * The "Premio Nacional de Tauromaquia" release.
+  * Fix a partial sync of debian/nanorc in the previous upload.
+This updates some example bindings to the new syntax, avoiding
+having control characters in the configuration file (closes: #1032422).
+  * Add 4 post-7.2 upstream patches to fix two minor security issues and
+a potential data-loss situation. Thanks, Benno Schulenberg!
+  * Set debian-branch to bookworm.
+
+ -- Jordi Mallach   Mon, 06 May 2024 08:10:01 +0200
+
 nano (7.2-1) unstable; urgency=medium
 
   * The "Blue checkmark" release.
diff -Nru nano-7.2/debian/gbp.conf nano-7.2/debian/gbp.conf
--- nano-7.2/debian/gbp.conf2022-12-07 23:10:44.0 +0100
+++ nano-7.2/debian/gbp.conf2024-05-06 08:09:34.0 +0200
@@ -1,5 +1,5 @@
 [DEFAULT] 
 pristine-tar = true 
-debian-branch = master 
+debian-branch = bookworm
 upstream-branch = upstream
 upstream-vcs-tag = v%(version)s
diff -Nru nano-7.2/debian/nanorc nano-7.2/debian/nanorc
--- nano-7.2/debian/nanorc  2023-01-18 15:37:55.0 +0100
+++ nano-7.2/debian/nanorc  2024-05-06 08:04:37.0 +0200
@@ -286,15 +286,14 @@
 
 ## For quickly uppercasing or lowercasing the word under or after the cursor.
 ## (These effectively select a word and pipe it through a sed command.)
-# bind Sh-M-U "Oc|sed 's/.*/\U&/'
" main
-# bind Sh-M-L "Oc|sed 's/.*/\L&/'
" main
+#bind Sh-M-U "{nextword}{mark}{prevword}{execute}|sed 's/.*/\U&/'{enter}" main
+#bind Sh-M-L "{nextword}{mark}{prevword}{execute}|sed 's/.*/\L&/'{enter}" main
 
 ## For copying a marked region to the system clipboard:
 # bind Sh-M-T "{execute}|xsel -ib{enter}{undo}" main
 
 ## For snipping trailing blanks when you save a file:
 # bind ^S "{execute}| sed 's/\s\+$//' {enter}{savefile}" main
-# bind Sh-M-T "|xsel -ib
u" main
 
 ## If you would like nano to have keybindings that are more "usual",
 ## such as ^O for Open, ^F for Find, ^H for Help, and ^Q for Quit,
diff -Nru 
nano-7.2/debian/patches/0001-linter-use-a-format-string-to-deflect-format-string-.patch
 
nano-7.2/debian/patches/0001-linter-use-a-format-string-to-deflect-format-string-.patch
--- 
nano-7.2/debian/patches/0001-linter-use-a-format-string-to-deflect-format-string-.patch
 1970-01-01 01:00:00.0 +0100
+++ 
nano-7.2/debian/patches/0001-linter-use-a-format-string-to-deflect-format-string-.patch
 2024-05-06 08:08:19.0 +0200
@@ -0,0 +1,47 @@
+From f2e042114d2c1696031bc2f2251e28a9c8eceaff Mon Sep 17 00:00:00 2001
+From: Benno Schulenberg 
+Date: Mon, 27 Mar 2023 11:47:37 +0200
+Subject: [PATCH 1/4] linter: use a format string, to deflect format-string
+ attacks
+
+This fixes the first part of https://savannah.gnu.org/bugs/?63964.
+
+Reported-by: Vince Vince
+---
+ src/text.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/text.c b/src/text.c
+index f4a3d7c5..34551fea 100644
+--- a/src/text.c
 b/src/text.c
+@@ -2846,7 +2846,7 @@ void do_linter(void)
+   confirm_margin();
+ #endif
+   edit_refresh();
+-  statusline(NOTICE, curlint->msg);
++  statusline(NOTICE, "%s", curlint->msg);
+   bottombars(MLINTER);
+   }
+ 
+@@ -2877,7 +2877,7 @@ void do_linter(void)
+   beep();
+   napms(600);
+   last_wait = time(NULL);
+-  statusline(NOTICE, curlint->msg);
++  statusline(NOTICE, "%s", curlint->msg);
+   }
+   } else if (function == do_page_down || function =

Processed: Re: Bug#1070698: transition: ticcutils

[Debian Bug Tracking System]

Processing control commands:

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

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

Bug#1070698: transition: ticcutils

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 07/05/2024 14:21, Bastian Germann wrote:

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: ticcut...@packages.debian.org
Control: affects -1 + src:ticcutils
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-ticcutils.html

User: release.debian@packages.debian.org
Usertags: transition

I am requesting a transition slot for ticcutils. The experimental version builds 
libticcutils9 while the unstable version has libticcutils8t64. The referenced 
tracker is okay. All reverse dependencies build with the experimental version 
(where an experimental version exists, it is the one that builds with 
libticcutils9).


Go ahead.

Emilio

Processed: transition: ticcutils

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:ticcutils
Bug #1070698 [release.debian.org] transition: ticcutils
Added indication that 1070698 affects src:ticcutils
> forwarded -1 https://release.debian.org/transitions/html/auto-ticcutils.html
Bug #1070698 [release.debian.org] transition: ticcutils
Set Bug forwarded-to-address to 
'https://release.debian.org/transitions/html/auto-ticcutils.html'.

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

Bug#1070698: transition: ticcutils

[Bastian Germann]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: ticcut...@packages.debian.org
Control: affects -1 + src:ticcutils
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-ticcutils.html
User: release.debian@packages.debian.org
Usertags: transition

I am requesting a transition slot for ticcutils. The experimental version builds libticcutils9 while the unstable 
version has libticcutils8t64. The referenced tracker is okay. All reverse dependencies build with the experimental 
version (where an experimental version exists, it is the one that builds with libticcutils9).

Bug#1059535: marked as done (transition: abseil)

[Debian Bug Tracking System]

Your message dated Tue, 7 May 2024 12:56:47 +0200
with message-id 
and subject line Re: Bug#1059535: transition: abseil
has caused the Debian Bug report #1059535,
regarding transition: abseil
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.)


-- 
1059535: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059535
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: abs...@packages.debian.org, Rene Engelhard 
Control: affects -1 + src:abseil

Abseil 20230802 has been out for a while, and I'd like to transition sid
to it. The new version has a new ABI (with a new SONAME and new binary
package names).

Tests for 20230802.1-2 in experimental are green on all supported
architectures except mips64el and riscv64. mips64el had no installable
libc when the builders ran; I expect it'll be fine when the transition
actually happens. Large parts of Abseil (including the version already
in sid) are broken on riscv64 right now because of
https://bugs.debian.org/1059532; transitioning doesn't introduce any new
issues.

A number of packages in sid depend directly on Abseil. To give early
warning of breakages, I've done trial rebuilds as appropriate on the
amd64 porterbox. Packages that work fine with the new version:

  - grpc
  - libgav1
  - libphonenumber
  - mujoco
  - open-vm-tools
  - ycmd

Packages that are broken by the new version:

  - mozc: FTBFS because it depends on a symbol in the absl::internal
namespace that changed without warning

  - re2: FTBFS because it needs changes to some symbols files

  - s2geometry: FTBFS because it hard-codes std=c+11 and the new version
requires -std=c++14 or later (https://bugs.debian.org/1059228)

  - webrtc-audio-processing: FTBFS because it relies on transitive
#includes that have changed

Packages that I'm not sure about:

  - dm-tree: has an active FTBFS (https://bugs.debian.org/1055686)

  - ortools: has an active FTBFS (https://bugs.debian.org/1024790)

  - libreoffice: too big to build on a porterbox, so left untested

Although doing a transition now will break some packages in sid, I
believe waiting is likely to cause more issues. Upstreams (LibreOffice
in particular) are starting to use features from the new version of
Abseil, and keeping the old version in sid is starting to create work
for other DDs. The breakages in sid will have to be fixed eventually
anyway, and none of them should be challenging to repair.

Ben file:

title = "abseil";
is_affected = .depends ~ /\blibabsl20220623\b/ | .depends ~ 
/\blibabsl20230802\b/;
is_good = .depends ~ /\blibabsl20230802\b/;
is_bad = .depends ~ /\blibabsl20220623\b/;
--- End Message ---
--- Begin Message ---
On 2024-04-01 16:51:16 +0200, Sebastian Ramacher wrote:
> 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.

It's finally done. abseil migrated and the old binaries got removed.

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

Processed: webdis: FTBFS with msgpack-c 6.x

[Debian Bug Tracking System]

Processing control commands:

> block 1070689 by -1
Bug #1070689 [release.debian.org] transition: msgpack-c
1070689 was blocked by: 1070692 1070693 1070691
1070689 was not blocking any bugs.
Added blocking bug(s) of 1070689: 1070694

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

Processed: tmate: FTBFS with msgpack-c 6.x

[Debian Bug Tracking System]

Processing control commands:

> block 1070689 by -1
Bug #1070689 [release.debian.org] transition: msgpack-c
1070689 was blocked by: 1070691 1070692
1070689 was not blocking any bugs.
Added blocking bug(s) of 1070689: 1070693

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

Processed: libdata-messagepack-stream-perl: FTBFS with msgpack-c 6.x

[Debian Bug Tracking System]

Processing control commands:

> block 1070689 by -1
Bug #1070689 [release.debian.org] transition: msgpack-c
1070689 was blocked by: 1070691
1070689 was not blocking any bugs.
Added blocking bug(s) of 1070689: 1070692

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

Processed: tmate-ssh-server: FTBFS with msgpack-c 6.x

[Debian Bug Tracking System]

Processing control commands:

> block 1070689 by -1
Bug #1070689 [release.debian.org] transition: msgpack-c
1070689 was not blocked by any bugs.
1070689 was not blocking any bugs.
Added blocking bug(s) of 1070689: 1070691

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

Processed: transition: msgpack-c

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:msgpack-c
Bug #1070689 [release.debian.org] transition: msgpack-c
Added indication that 1070689 affects src:msgpack-c

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

Bug#1070689: transition: msgpack-c

[James McCoy]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: msgpac...@packages.debian.org
Control: affects -1 + src:msgpack-c
User: release.debian@packages.debian.org
Usertags: transition

The msgpack-c upstream renamed their C library from libmsgpackc.so to
libmsgpack-c.so. I've renamed the binary packages accordingly
(libmsgpack-dev -> libmsgpack-c-dev, libmsgpackc2 -> libmsgpack-c2) and
the former "Provides: libmsgpack-dev" to help ease the transition.

The following build dependencies will need fixes to build against the
new msgpack-c version:

* libdata-messagepack-stream-perl
* tmate
* tmate-ssh-server
* webdis

This is just related to how the packages detect whether msgpack is
available, since the APIs/ABIs themselves did not change.

Ben file:

title = "msgpack-c";
is_affected = .depends ~ "libmsgpackc2" | .depends ~ "libmsgpack-c2";
is_good = .depends ~ "libmsgpack-c2";
is_bad = .depends ~ "libmsgpackc2";

Bug#1059852: marked as done (transition: glibc 2.38)

[Debian Bug Tracking System]

Your message dated Tue, 7 May 2024 09:47:20 +0200
with message-id 
and subject line Re: Bug#1059852: transition: glibc 2.38
has caused the Debian Bug report #1059852,
regarding transition: glibc 2.38
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.)


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

Dear release team,

I would like to get a transition slot for glibc 2.38. It has been
available in experimental for a few months and does not have any known
issue anymore. It has been built successfully on all release
architectures and most ports architectures, and the experimental
pseudo-excuses look good overall.

As glibc is using symbol versioning, there is no soname change. That
said a few packages are using libc internal symbols and have to be
rebuilt for this transition. Here is the corresponding ben file:

  title = "glibc";
  is_affected = .depends ~ /libc[0-9.]* \(<--- End Message ---
--- Begin Message ---
On 2024-05-03 22:08:00 +0200, Aurelien Jarno wrote:
> Hi,
> 
> On 2024-01-02 13:23, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: gl...@packages.debian.org
> > Control: affects -1 + src:glibc
> > 
> > Dear release team,
> > 
> > I would like to get a transition slot for glibc 2.38. It has been
> > available in experimental for a few months and does not have any known
> > issue anymore. It has been built successfully on all release
> > architectures and most ports architectures, and the experimental
> > pseudo-excuses look good overall.
> > 
> > As glibc is using symbol versioning, there is no soname change. That
> > said a few packages are using libc internal symbols and have to be
> > rebuilt for this transition. Here is the corresponding ben file:
> > 
> >   title = "glibc";
> >   is_affected = .depends ~ /libc[0-9.]* \(< >   is_good = .depends ~ /libc[0-9.]* \(<< 2.39\)/;
> >   is_bad = .depends ~ /libc[0-9.]* \(<< 2.38\)/;
> > 
> > The main symbol related changes in this version are the addition of
> > strlcat and strlcpy and related functions, coming from the BSD world. A
> > few packages have their own implementation exported in their symbols
> > file. With glibc 2.38 starting to provide those functions, the packages
> > stops providing compatibility functions and the associated symbols,
> > causing them to FTBFS. Many of them have been identified thanks to the
> > hurd-amd64 bootstrap and have been fixed. The known remaining ones are:
> >  - #1055297 ruby3.1: fails to build against glibc 2.38
> >  - #1055316 heimdal: fails to build against glibc 2.38
> > 
> > Other than that a few symbols have been added to support the C2X binary
> > constant handling in scanf family of functions. There are unlikely to be
> > widely used at this point and thus that new packages start to use them,
> > blocking their migration to testing during the transition.
> > 
> > Thanks for considering.
> 
> As discussed on IRC, I just uploaded it.

Thanks! glibc migrated, closing.

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