Bug#1063938: tmux: Does not automatically set mode-keys to vi based on VISUAL or EDITOR environment

[Philip Chung]

Package: tmux
Version: 3.4-1
Severity: minor

Dear Maintainer,

The mode-keys option is no longer being set to vi based on the EDITOR 
environment variable.


Steps to reproduce:

1. Set EDITOR environment variable to /usr/bin/vi and set export flag
2. Start tmux
3. Type Enter a few times to get some lines in the terminal
4. Type Ctrl-[ to enter copy mode
5. Type k to nagivate up
6. Observe that the cursor does not move

When I explicitly set mode-keys (Ctrl-b followed by ":set mode-keys 
vi"), navigation with h, j, k, and l works.


I can also reproduce this with version 3.3a-5 (current version in testing).

According to the man page, tmux automatically sets the mode-keys option 
to vi when the user's preferred editor is vi:


> mode-keys [vi | emacs]
> Use vi or emacs-style key bindings in copy mode. The  default is 
emacs, unless VISUAL or EDITOR contains ‘vi’.


Philip Chung

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tmux depends on:
ii  libc62.37-15
ii  libevent-core-2.1-7  2.1.12-stable-8
ii  libsystemd0  255.3-2
ii  libtinfo66.4+20240113-1
ii  libutempter0 1.2.1-3

tmux recommends no packages.

tmux suggests no packages.

-- no debconf information

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Dirk Hünniger]

HI Georges, Paul,

thank you for uploading the package. Unfortunately the system still says

https://qa.debian.org/excuses.php?package=mediawiki2latex

 * Issues preventing migration:
 o missing build on armel
   

 o missing build on mips64el
   

 o missing build on s390x
   

 o arch:armel not built yet, autopkgtest delayed there
 o arch:s390x not built yet, autopkgtest delayed there
 o Too young, only 0 of 5 days old

So it still wants to build on s390x armel and mips64el. Possibly its not 
possible to drop support for an architecture that once was supported.


So possible we need to tell the system that it can still build on all 
architectures, but the the dependency to chromium is only needed on all 
architectures but  s390x armel and mips64el



Yours Dirk

On 14.02.24 17:01, Dirk Hünniger wrote:

Hi,

Ok.

So if I understood correctly all that has to be done is to add an 
architecture qualifier. And the person who has can do it is Georges. 
So I herewith ask him to do so.


Yours Dirk

On 14.02.24 16:58, Paul Gevers wrote:

Hi,

On 14-02-2024 16:53, Dirk Hünniger wrote:
If it helps to change the dependency to chromium and 
chromium-sandbox from Depends to Recommends I would like to ask 
Georges to do so.


If you think the Depends is best, make it conditional on the 
architecture, because ideally also Recommends can be installed (so 
would benefit from the architecture qualifier).


Paul

Bug#1056419: Spinx help needed

[Andreas Tille]

Control: tags -1 pending

Hi,

I pushed fixes for #1056419 and #1058311 to Git and I think should be
fixed as well.  The only remaining build problem is new and caused by
sphinx[1]:

  dh_sphinxdoc -i -O--buildsystem=pybuild
dh_sphinxdoc: error: 
debian/python-lmfit-doc/usr/share/doc/python3-lmfit/html/search.html top-level 
node does not have data-content_root attribute


Unfortunately I have no idea how to fix this.  Any ideas?

Kind regards
Andreas.


[1] https://buildd.debian.org/status/package.php?p=lmfit-py=experimental

-- 
http://fam-tille.de

Bug#1063937: glibc: Please add workaround to fix posix_spawn() on sparc64

[John Paul Adrian Glaubitz]

Source: glibc
Version: 2.37-15
Severity: important
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: 
debian-sp...@lists.debian.org,ker...@mkarcher.dialup.fu-berlin.de,s...@gentoo.org

Hello,

there is currently a nasty bug on sparc64 that breaks posix_spawn() [1]
and potentially any package that uses gcc since libiberty switched to
using posix_spawn() with gcc-14.

The attached patch comes from Michael Karcher (CC'ed) and unbreaks
posix_spawn() so that gcc works again without posix_spawn() failing
with "Bad Address".

Since this patch is just a workaround and we're not even sure whether
the bug is in the kernel or glibc, it's not been pushed upstream yet.

Adrian

> [1] 
> https://lore.kernel.org/sparclinux/fe5cc47167430007560501aabb28ba154985b661.ca...@physik.fu-berlin.de

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- glibc-2.37.orig/sysdeps/unix/sysv/linux/sparc/sparc32/clone.S
+++ glibc-2.37/sysdeps/unix/sysv/linux/sparc/sparc32/clone.S
@@ -28,6 +28,9 @@
.text
 ENTRY (__clone)
save%sp,-96,%sp
+   save%sp,-96,%sp
+   flushw
+   restore
cfi_def_cfa_register(%fp)
cfi_window_save
cfi_register(%o7, %i7)
--- glibc-2.37.orig/sysdeps/unix/sysv/linux/sparc/sparc64/clone.S
+++ glibc-2.37/sysdeps/unix/sysv/linux/sparc/sparc64/clone.S
@@ -32,6 +32,9 @@
 
 ENTRY (__clone)
save%sp, -192, %sp
+   save%sp, -192, %sp
+   flushw
+   restore
cfi_def_cfa_register(%fp)
cfi_window_save
cfi_register(%o7, %i7)

Bug#1063599: More info (Was: mathgl: FTBFS on amd64: tests seg fault)

[Andreas Tille]

Control: tags -1 moreinfo
Control: severity -1 important

Hi Sebastian,

the package builds nicely in my local pbuilder, in Salsa CI as well as
in the autobuilders.  Thus I'm tagging the bug moreinfo and set severity
to important.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1063329: libselinux1t64: breaks system in upgrade from unstable

[Steve Langasek]

On Wed, Feb 07, 2024 at 09:06:58AM +0100, Helmut Grohne wrote:
> On Wed, Feb 07, 2024 at 04:32:45AM +0100, Guillem Jover wrote:
> > Yes, I'm not sure I understand either. This is what symbol versioning
> > makes possible, even providing different variants for the same symbol,
> > see for example glibc or libbsd.

> I think symbol versioning is subtly different and glibc does not use
> symbol versioning for e.g. gettimeofday selection. With symbol
> versioning, you select a default version at release time and stick to
> it. In other words, building against the updated libselinux does not
> allow you to use the older 32bit variant of the symbol even if you opt
> out of lfs and time64 and you always get the 64bit symbol. What glibc
> does is a little more fancy than my simplistic #define in that it uses
> asm("name") instead. Still this approach allows for selecting which
> symbol is being used via macros (e.g. _FILE_OFFSET_BITS). Please correct
> me if I am misrepresenting this as my experience with symbol versioning
> is fairly limited.

Agreed.  libselinux as it happens does use a symbol version map so there is
symbol versioning involved in some sense? but not the sense you really mean.

(We could make the symbol map expose the two different function variants
under the same name but different symbols; that's fine but I'll leave that
for upstream to decide.)

> > In any case, if going the bi-ABI path, I think upstream should get
> > involved, and the shape of this decided with them. In addition
> > the library should also be built with LFS by the upstream build
> > system, which it does not currently, to control its ABI.

> I agree that involving upstream is a good idea and my understanding is
> that someone from Canonical is doing that already, which is why the
> schedule was delayed.

Well, "already" is not exactly correct, but the need to resolve this
critical showstopper bug in libselinux before making changes to the
toolchain behavior in unstable and breaking the world has affected the
timeline, yes.

I now have a tested patch that I've raised as an MP in salsa:

  https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/9

I welcome review from the Debian libselinux maintainers prior to opening a
discussion with upstream.  (Which I will plan to do sometime Thursday
US/Pacific)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1063925: victoriametrics: Occasional FTBFS: VictoriaMetrics/lib/storage/inmemory_part.go:37 BUG: Inmemory.InitFromRows must accept at least one row

[Denys Holius]

Hello folks,

This version is an old and not supported version deprecated six month ago.
I belive this bug has been fixed in the newest versions of VictoriaMetrics.
Please see https://victoriametrics.com/blog/lts-status-h2-2023/  to find
the actual list of supported versions.

FYI: https://docs.victoriametrics.com/changelog/#v1972  is the latest LTS
version. Feel free to ping me if you have any questions or concerns.

On Thu, Feb 15, 2024, 01:27 Mathias Gibbens  wrote:

> Source: victoriametrics
> Version: 1.79.14+ds1-1
> Severity: normal
> Tags: trixie sid ftbfs
>
>   In a clean sid schroot, I observed an occasional test failure (2/9
> builds):
>
> > 2024-02-14T22:25:03.764Zpanic
>  VictoriaMetrics/lib/storage/inmemory_part.go:37 BUG: Inmemory.InitFromRows
> must accept at least one row
> > --- FAIL: TestMergeBlockStreamsManyStreamsManyBlocksManyRows (0.00s)
> > panic: BUG: Inmemory.InitFromRows must accept at least one row
> [recovered]
> > panic: BUG: Inmemory.InitFromRows must accept at least one row
> >
> > goroutine 56566 [running]:
> > testing.tRunner.func1.2({0x6e5360, 0xc005603000})
> > /usr/lib/go-1.21/src/testing/testing.go:1545 +0x238
> > testing.tRunner.func1()
> > /usr/lib/go-1.21/src/testing/testing.go:1548 +0x397
> > panic({0x6e5360?, 0xc005603000?})
> > /usr/lib/go-1.21/src/runtime/panic.go:914 +0x21f
> >
> github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.logMessage({0x72f3fd
> ,
> 0x5}, {0xc0058a0e80, 0x37}, 0x0?)
> > /build/victoriametrics-1.79.14+ds1/_build/src/
> github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:269 +0x95e
> >
> github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.logLevelSkipframes(0x1,
> {0x72f3fd, 0x5}, {0x747753?, 0xc0017bee30?}, {0x0?, 0x90?, 0x7166e0?})
> > /build/victoriametrics-1.79.14+ds1/_build/src/
> github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:137 +0x194
> > github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.logLevel(...)
> > /build/victoriametrics-1.79.14+ds1/_build/src/
> github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:129
> > github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.Panicf(...)
> > /build/victoriametrics-1.79.14+ds1/_build/src/
> github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:125
> >
> github.com/VictoriaMetrics/VictoriaMetrics/lib/storage.(*inmemoryPart).InitFromRows(0xc0036eb200,
> {0x0, 0x0, 0x0})
> > /build/victoriametrics-1.79.14+ds1/_build/src/
> github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/inmemory_part.go:37
> +0x58
> >
> github.com/VictoriaMetrics/VictoriaMetrics/lib/storage.newTestBlockStreamReader(0xc001934878?,
> {0x0, 0x0, 0x0})
> > /build/victoriametrics-1.79.14+ds1/_build/src/
> github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/block_stream_reader_test.go:151
> +0x45
> >
> github.com/VictoriaMetrics/VictoriaMetrics/lib/storage.TestMergeBlockStreamsManyStreamsManyBlocksManyRows(0x60a440
> ?)
> > /build/victoriametrics-1.79.14+ds1/_build/src/
> github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/merge_test.go:325
> +0x11b
> > testing.tRunner(0xc001811860, 0x7cc288)
> > /usr/lib/go-1.21/src/testing/testing.go:1595 +0xff
> > created by testing.(*T).Run in goroutine 1
> > /usr/lib/go-1.21/src/testing/testing.go:1648 +0x3ad
> > FAILgithub.com/VictoriaMetrics/VictoriaMetrics/lib/storage  12.339s
>

Bug#1063908: [Debian-pan-maintainers] Bug#1063908: node-jupyter-widgets-{base, base-manager, control}: ships files already in python3-widgetsnbextension

[Yadd]

On 2/14/24 20:26, Andreas Beckmann via Debian-pan-maintainers wrote:

Package: 
node-jupyter-widgets-base,node-jupyter-widgets-base-manager,node-jupyter-widgets-controls
Version: 6.0.7+~cs14.23.94-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

 From the attached log (scroll to the bottom...):

   Preparing to unpack 
.../node-jupyter-widgets-base_6.0.7+~cs14.23.94-1_all.deb ...
   Unpacking node-jupyter-widgets-base (6.0.7+~cs14.23.94-1) ...
   dpkg: error processing archive 
/var/cache/apt/archives/node-jupyter-widgets-base_6.0.7+~cs14.23.94-1_all.deb 
(--unpack):
trying to overwrite 
'/usr/share/nodejs/@jupyter-widgets/base/css/index.css', which is also in 
package python3-widgetsnbextension 8.1.1-2
   Errors were encountered while processing:

/var/cache/apt/archives/node-jupyter-widgets-base_6.0.7+~cs14.23.94-1_all.deb


Hi,

why does python3-widgetsnbextension install an unusable node.js module 
into a nodejs directory ?

Bug#1063935: stac-validator: Vcs-Git field points to wrong repo

[Sebastiaan Couwenberg]

Control: tags -1 pending.

Fixed in git.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1063935: stac-validator: Vcs-Git field points to wrong repo

[Stuart Prescott]

Source: stac-validator
Version: 3.3.2+ds-2
Severity: wishlist
X-Debbugs-Cc: stu...@debian.org

Dear Maintainer,

The Vcs-Git/Vcs-Browser fields in debian/control for this package point
to the upstream development repository. They should instead point to the
Debian packaging repository:

https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-vcs-fields

Vcs-Browser: https://github.com/stac-utils/stac-validator
Vcs-Git: https://github.com/stac-utils/stac-validator.git

vs

https://salsa.debian.org/debian-gis-team/stac-validator/

regards
Stuart

Bug#1062722: qt-qml-models: NMU diff for 64-bit time_t transition

[Wookey]

On 2024-02-02 22:34 +, Sergio Durigan Junior wrote:
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> qt-qml-models as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).

This library is packaged as a dependency of cavewhere. But cavewhere
has not yet been uploaded to the archive. It's quite specific and thus
has no other reverse dependencies, so in fact it has no dependencies and is
currently effectively unused in the archive.

Thus there is no need to rename it as part of this transition. A
rebuild when it's dependencies (qtbase5-dev, qtbase5-private-dev,
qtdeclarative5-dev) are uploaded would be sufficient.

I will try and get it to pass the abi-checker and see if it actually
changes ABI or not. I suspect not, but qt is complicated so it's possible.


Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1063744: Mistake

[Alexandre Almeida]

Please disregard this bug, as I forgot the "Package: wnpp" part.

The new bug containing the same RFP is #1063934.

Bug#1063934: Update

[Alexandre Almeida]

Update: version 2024.02.13.0 has been released.

Bug#1063934: RFP: alexvsbus - a platform runner game

[Alexandre Almeida]

Package: wnpp
Severity: wishlist

* Package name: alexvsbus
  Version : 2024.02.10.0
  Upstream Author : M374LX
* URL : https://github.com/M374LX/alexvsbus
* License : GPL
  Programming Lang: C
  Description : a platform runner game

It would be nice if the new FOSS game I have just
released could be included in Debian's repositories.

In case a compelling reason is needed, it is a complete
game, no longer WIP.

Please disregard bug #1063744, as I forgot the "wnpp" part.

Bug#1060267: -qmake: emits wrong QT_HOST_LIBEXECS - fix

[Maarten van der Schrieck]

Package: qmake6
Version: 6.4.2+dfsg-21
Followup-For: Bug #1060267
X-Debbugs-Cc: maar...@railconnected.eu

Dear Maintainer,

Cross building with qmake6 fails due to QT_HOST_LIBEXECS having a wrong
value. For completeness: QT_HOST_LIBEXECS refers to the config file
variable HostLibraryExecutables, and is internally referred to as
QMakeLibraryInfo::HostLibraryExecutablesPath and
QMakeLibraryInfo::LibraryPathQMakeExtras::HostLibraryExecutablesPath in
the qmake source code.

The issue is that HostLibraryExecutables defaults to the *default* value
of LibraryExecutables. LibraryExecutables is set to the right value (a
concatenation of Prefix + LibraryExecutables with the value
"/usr/lib/qt6/libexec"), but its default value is Prefix + "libexec".

As the cross build config /usr/lib//qt6/qt6.conf specifies
Prefix as "/usr", the default of LibraryExecutables, and hence the
default of HostLibraryExecutables, is now "/usr/libexec", which is the
wrong value.

The simple fix is to supply the value of HostLibraryExecutables in
/usr/lib//qt6/qt6.conf explicitly:

...
HostLibraryExecutables=lib/qt6/libexec
...

The better fix would possibly be, upstream, to take the *actual* value
of LibraryExecutables as the default value for HostLibraryExecutables,
and not the default value.

This bug was observed on bookworm, trixie and sid, when cross building
on x86-64 for armel, and on each of these releases it was fixed by
adding the proposed line to qt6.conf. A diff to the source package:

*** qt6-base-6.4.2+dfsg/debian/qt.conf.in.orig2024-02-13 03:28:31.532410597 
+0100
--- qt6-base-6.4.2+dfsg/debian/qt.conf.in2024-02-13 03:28:38.716318378 +0100
***
*** 10,15 
--- 10,16 
  HostLibraries=lib/@DEB_HOST_MULTIARCH@
  Libraries=lib/@DEB_HOST_MULTIARCH@
  LibraryExecutables=lib/qt6/libexec
+ HostLibraryExecutables=lib/qt6/libexec
  Plugins=lib/@DEB_HOST_MULTIARCH@/qt6/plugins
  Qml2Imports=lib/@DEB_HOST_MULTIARCH@/qt6/qml
  Settings=/etc/xdg

For completeness I include a script below to demonstrate the problem and
the fix in a self-contained manner; save as gen-mre.sh and run:  /dev/null
then
echo "Cannot find debootstrap; check \$PATH."
echo "Refusing to run sbuild-createchroot."
exit
fi

BASEDIST=$1

MAX_LINE_LEN=$(stty size |awk '{print ($2>80)?$2:80}')
echo "Truncating lines to $MAX_LINE_LEN"

{ # All output is fed through sed to indent subprocess output; lines starting
  # with @@ are not indented.

CHROOT_BASENAME=qt6-mre-$BASEDIST
echo "@@Looking for schroots named source.*$CHROOT_BASENAME..."
CHROOT=$(schroot -l |egrep "source.*$CHROOT_BASENAME")
if [ "$CHROOT" == "" ]
then
echo "Not found. Creating schroot..."
sbuild-createchroot --merged-usr --chroot-prefix=$CHROOT_BASENAME \
$BASEDIST $CHROOT_BASENAME
CHROOT=$(schroot -l |egrep "source.*$CHROOT_BASENAME")
if [ "$CHROOT" == "" ]
then
echo "Failed to create chroot, bailing out"
exit
fi
echo "schroot created with name $CHROOT"
else
echo "Found $CHROOT"
fi

run() {
echo "\$ $@"
schroot --chroot $CHROOT --directory /tmp -- "$@"
}

echo "@@Testing schroot..."
run cat /etc/debian_chroot

echo "@@Adding architecture armel..."
run sh -c "dpkg --add-architecture armel && apt-get -q update"

echo "@@Installing base utils..."
run apt-get -q -y install qt6-base-dev qmake6 libqt6core6 libqt6network6
run apt-get -q -y install qt6-base-dev:armel qmake6:armel libqt6core6:armel \
  libqt6network6:armel
run apt-get -q -y install g++-arm-linux-gnueabi file wget

echo "@@Fetching demo application..."
for fn in http.pro authenticationdialog.ui httpwindow.cpp httpwindow.h main.cpp
do

URL=https://raw.githubusercontent.com/qt/qtbase/dev/examples/network/http/$fn
run wget -nc --no-verbose $URL
done

echo "@@Performing a simple build on the demo project..."
run sh -c "ls -al && qmake6 && make -j"
echo "@@Resulting binary:"
run ls -alh http
run file http
echo "@@The above is expected to show a valid native binary"

QT6CONF=/usr/lib/arm-linux-gnueabi/qt6/qt6.conf
LINE=HostLibraryExecutables=lib/qt6/libexec
echo "@@Removing proposed patch (will give an error on first run, no worries)"
run cp -v $QT6CONF.orig $QT6CONF
echo "@@Backing up unpatched $QT6CONF..."
run cp -v $QT6CONF $QT6CONF.orig

echo "@@Cross compiling for armel, without patch..."
run sh -c "arm-linux-gnueabi-qmake6 && make"
echo "@@The above is expected to give an error '/usr/libexec/uic: not found'"

echo "This is fixed by adding the following line to $QT6CONF"
echo "   $LINE"
run sh -c "echo \"$LINE\" >> $QT6CONF"

echo "@@Cross compiling for armel, with patch..."
run sh -c "make clean && arm-linux-gnueabi-qmake6 && make -j"
echo "@@Resulting binary:"
run ls -alh http
run file http
echo "@@The above is expected to show a valid ARM binary of ~79K"

} 2>&1 | sed -e "s/^/   /;s/^   

Bug#1063882: gcc: Internal error from ternary cond as inline asm parameter

[some body]

On Wed, 14 Feb 2024 08:26:41 +0100 Matthias Klose  wrote:
> Control: tags -1 + moreinfo
>
> On 14.02.24 02:10, VictorBW wrote:
> > Package: gcc
> > Version: 4:12.2.0-3
> > Severity: normal
> > X-Debbugs-Cc: knodewaeee+debb...@gmail.com
> >
> > Dear Maintainer,
> >
> > I wanted to dynamically select registers for use in an inline assembly
statement, so I tried the questionmark conditional operator, as in this
minimal example:
> >
> > namespace gpr {
> >volatile register int64_t r12 asm("r12");
> >volatile register int64_t r13 asm("r13");
> > ...
> > asm volatile ("mov %0, blah" : "+r"((reg) ? gpr::r13 : gpr::r12));
> >
>
> please post the complete code example.
>
> please also recheck with newer GCC versions (GCC 13, GCC 14) in newer
> Debian development versions.
>
I do not have GCC 13/14 installed, but godbolt.org's copy of GCC 13 and
trunk will not compile the following complete example

int main(int argc, char** argv) {
register long reg_1 asm("r12");
register long reg_2 asm("r13");
asm volatile ("mov %0, %%r11" : "+r"((argc) ? reg_2 : reg_1));
}

I note that in C mode (gcc minbug.c) a different error is produced (error:
lvalue required in ‘asm’ statement), but in C++ mode (g++ minbug.c) we get
the internal compiler error, and that selecting an input parameter the same
way (rather than an output parameter) seems to work correctly.

Bug#1023397: Unwanted files in the flightgear binary package

[Ernesto Domato]

Hi,

It's correct that the file /usr/share/icons/hicolor/CMakeLists.txt should
be deleted from the binary package, but I think that the file
/usr/share/applications/org.flightgear.FlightGear.desktop has more entries
(is better) that the file /usr/share/applications/flightgear.desktop so
this one should be deleted or replaced by the former one.

Greetings.
Ernesto

Bug#1063933: bookworm-pu: package nvidia-graphics-drivers/525.147.05-7~deb12u1

[Andreas Beckmann]

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

[ Reason ]
Regression in nvidia-detect, introduced in 525.147.05-6~deb12u1.

[ Impact ]
nvidia-detect does not detect cards supported by
nvidia-graphics-drivers-tesla-470.

[ Tests ]
Manual verification of the nvidia-detect fix.

[ Risks ]
Low.

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

[ Changes ]
nvidia-graphics-drivers (525.147.05-7~deb12u1) bookworm; urgency=medium

  * Rebuild for bookworm.

 -- Andreas Beckmann   Thu, 15 Feb 2024 01:08:15 +0100

nvidia-graphics-drivers (525.147.05-7) unstable; urgency=medium

  * nvidia-detect: Fix mismerge breaking Tesla 470 detection.
(Closes: #1063910)
  * Relax dh-dkms build-dependency, satisfied in stable.

 -- Andreas Beckmann   Thu, 15 Feb 2024 00:55:07 +0100

 debian/README.source   |  2 +-
 debian/changelog   | 17 -
 debian/control |  1 -
 debian/control.in  |  1 -
 debian/control.md5sum  |  4 ++--
 debian/control.models  |  2 +-
 debian/detect/nvidia-detect.in |  2 +-
 7 files changed, 21 insertions(+), 8 deletions(-)

The versioned dh-dkms B-D has been dropped, because dh-sequence-dkms is
sufficient. Simplifies bullseye backports.

[ Other info ]
I'll directly upload the package after filing this bug.

Andreas
diff --git a/debian/README.source b/debian/README.source
index 8e720253..a03295fa 100644
--- a/debian/README.source
+++ b/debian/README.source
@@ -65,7 +65,7 @@ The branch structure in the GIT repository
 tesla-450/transition-470  bullseye,sidtesla-460/transition-470
 460 EoL   (bullseye)  470, tesla-460/main
 tesla-460/main  EoL   (bullseye),(sid)tesla-470/main, 
tesla-460/transition-470
-tesla-460/transition-470  bullseye,sid
+tesla-460/transition-470  bullseye,sidtesla/transition
 470   bullseye525, tesla-470/main
 tesla-470/mainbullseye,bookworm,sid tesla/525
 525 EoL   bookworm,sid535, tesla/525
diff --git a/debian/changelog b/debian/changelog
index b6adb99f..3427ffdd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+nvidia-graphics-drivers (525.147.05-7~deb12u1) bookworm; urgency=medium
+
+  * Rebuild for bookworm.
+
+ -- Andreas Beckmann   Thu, 15 Feb 2024 01:08:15 +0100
+
+nvidia-graphics-drivers (525.147.05-7) unstable; urgency=medium
+
+  * nvidia-detect: Fix mismerge breaking Tesla 470 detection.
+(Closes: #1063910)
+  * Relax dh-dkms build-dependency, satisfied in stable.
+
+ -- Andreas Beckmann   Thu, 15 Feb 2024 00:55:07 +0100
+
 nvidia-graphics-drivers (525.147.05-6~deb12u1) bookworm; urgency=medium
 
   * Rebuild for bookworm.
@@ -1413,7 +1427,7 @@ nvidia-graphics-drivers (460.106.00-14) UNRELEASED; 
urgency=medium
   * Apply pfn_valid patch from gentoo to fix kernel module build for
 Linux 6.1.76, 6.6.15, 6.7.3, 6.8.
 
- -- Andreas Beckmann   Wed, 07 Feb 2024 04:12:22 +0100
+ -- Andreas Beckmann   Tue, 13 Feb 2024 14:49:02 +0100
 
 nvidia-graphics-drivers (460.106.00-13) UNRELEASED; urgency=medium
 
@@ -1559,6 +1573,7 @@ nvidia-graphics-drivers (460.106.00-1) UNRELEASED; 
urgency=medium
   * bug-script: Show the nvidia and glx alternatives (470.82.00-1).
   * nvidia-alternative: libnvidia-cfg.so.1 on its own is not
 sufficient to activate a nvidia alternative (470.82.00-1).
+(Closes: #996595)
   * Fix bashisms in upstream scripts (470.82.00-1).
   * Drop the unusable leftover non-GLVND libegl1-nvidia package
 (470.82.00-1).
diff --git a/debian/control b/debian/control
index 22264293..abd62e11 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,6 @@ Build-Depends:
  debhelper-compat (= 13),
 Build-Depends-Arch:
  dh-sequence-dkms,
- dh-dkms (>= 3.0.3-4~),
  dh-exec,
  libnvidia-egl-wayland1,
  libvulkan1 (>= 1.0.42),
diff --git a/debian/control.in b/debian/control.in
index ed4b6497..994d241e 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -11,7 +11,6 @@ Build-Depends:
  debhelper-compat (= 13),
 Build-Depends-Arch:
  dh-sequence-dkms,
- dh-dkms (>= 3.0.3-4~),
  dh-exec,
  libnvidia-egl-wayland1,
  libvulkan1 (>= 1.0.42),
diff --git a/debian/control.md5sum b/debian/control.md5sum
index 0b1209ee..1341f552 100644
--- a/debian/control.md5sum
+++ b/debian/control.md5sum
@@ -1,5 +1,5 @@
-10952fe89c0b1063bfb28b01dfd73b70  debian/control
-ae28324bcc8c570835da30b9d493  debian/control.in
+82088c2f83b089d86f743cb5ee877305  debian/control
+2f126ed9154b517184ccbac554b1f690  debian/control.in
 8489c83cfe0171c9de6d052c01a6d19b  debian/gen-control.pl
 98a9e959f8732af1a963c2adfb0879ca  debian/rules
 7f525d302e0e76e1de1f4e6cce0efbe8  debian/rules.defs
diff --git 

Bug#1063049: visp: NMU diff for 64-bit time_t transition

[Steve Langasek]

On Wed, Feb 07, 2024 at 07:11:17PM +0100, Fabien Spindler wrote:
> Dear,

> Thanks for this patch. If I understand well you will apply the patch.
> I don't have to apply it to the upstream. I'm right?

Correct.  Indeed, this is a packaging change so there's nothing to apply
upstream.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

> Le 04/02/2024 à 19:19, Steve Langasek a écrit :
> > Source: visp
> > Version: 3.6.0-2
> > Severity: serious
> > Tags: patch pending sid trixie
> > Justification: library ABI skew on upgrade
> > User: debian-...@lists.debian.org
> > Usertags: time-t
> > 
> > NOTICE: these changes must not be uploaded to unstable yet!
> > 
> > Dear maintainer,
> > 
> > As part of the 64-bit time_t transition required to support 32-bit
> > architectures in 2038 and beyond
> > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> > visp as a source package shipping runtime libraries whose ABI
> > either is affected by the change in size of time_t, or could not be
> > analyzed via abi-compliance-checker (and therefore to be on the safe
> > side we assume is affected).
> > 
> > To ensure that inconsistent combinations of libraries with their
> > reverse-dependencies are never installed together, it is necessary to
> > have a library transition, which is most easily done by renaming the
> > runtime library package.
> > 
> > Since turning on 64-bit time_t is being handled centrally through a change
> > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> > important that libraries affected by this ABI change all be uploaded close
> > together in time.  Therefore I have prepared a 0-day NMU for visp
> > which will initially be uploaded to experimental if possible, then to
> > unstable after packages have cleared binary NEW.
> > 
> > Please find the patch for this NMU attached.
> > 
> > If you have any concerns about this patch, please reach out ASAP.  Although
> > this package will be uploaded to experimental immediately, there will be a
> > period of several days before we begin uploads to unstable; so if 
> > information
> > becomes available that your package should not be included in the 
> > transition,
> > there is time for us to amend the planned uploads.
> > 
> > 
> > 
> > -- System Information:
> > Debian Release: trixie/sid
> >APT prefers unstable
> >APT policy: (500, 'unstable')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> 


signature.asc
Description: PGP signature

Bug#1063932: firefox-esr: "Gah. Your tab just crashed" on *some* pages

[Stefan Monnier]

Package: firefox-esr
Version: 115.7.0esr-1
Severity: normal

Dear Maintainer,

For some reason my `firefox-esr` is refusing to show me some pages.
Most pages work fine, but some give me the dreaded "Gah. Your tab just
crashed".

Two example URLs which suffer this fate are:

https://diro.umontreal.ca/accueil/
https://www.nserc-crsng.gc.ca/students-etudiants/ug-pc/usra-brpc_eng.asp

in both cases, if I `firefox-esr --safe-mode ` it starts up and (after
confirming that I understand what "safe-mode" means), it gives me the "gah..."
instead of showing me the page.  On stdout/stderr I see:

[Parent 18669, IPC I/O Parent] WARNING: process 18781 exited on signal 15:
file ./ipc/chromium/src/base/process_util_posix.cc:264

I tried `aptitude reinstall firefox-esr` but that made no difference.

I downloaded Mozilla's own `firefox-esr` and this one does *not* exhibit the
problem.
I also tried to `aptitude reinstall libnss3:i386 libnspr4:i386` which are
apparently the other packages containing the `.so` libs included in Mozilla's
own tarball, but that did not help.

I tried running `firefox-esr` under GDB but the error is apparently caught
internally because GDB did not show me anything beside loads of creation (and
exit) of threads and the same IPC I/O error message as quoted above.

I don't know how to track this down further :-(


Stefan


-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-security'), (100, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox-esr depends on:
ii  debianutils  5.16
ii  fontconfig   2.14.2-6+b1
ii  libasound2   1.2.10-3
ii  libatk1.0-0  2.50.0-1+b1
ii  libc62.37-15
ii  libcairo-gobject21.18.0-1+b1
ii  libcairo21.18.0-1+b1
ii  libdbus-1-3  1.14.10-4
ii  libdbus-glib-1-2 0.112-3+b1
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-2
ii  libfontconfig1   2.14.2-6+b1
ii  libfreetype6 2.13.2+dfsg-1+b1
ii  libgcc-s114-20240201-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0 2.78.3-2
ii  libgtk-3-0   3.24.41-1
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.96.1-1
ii  libpango-1.0-0   1.51.0+ds-4
ii  libstdc++6   14-20240201-3
ii  libvpx8  1.13.1-2
ii  libx11-6 2:1.8.7-1
ii  libx11-xcb1  2:1.8.7-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:4.0.4-4
ii  zlib1g   1:1.3.dfsg-3+b1

Versions of packages firefox-esr recommends:
ii  libavcodec57  7:3.4.3-1
ii  libavcodec58  7:4.4.2-1+b3
ii  libavcodec60  7:6.1.1-1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.005-1
ii  fonts-stix [otf-stix]  1.1.1-5
ii  libcanberra0   0.30-11
ii  libgssapi-krb5-2   1.20.1-5+b1
pn  pulseaudio 

-- no debconf information

Bug#1063930: bwrap --dev prevents mount commands from working

[Michael Gold]

Package: bubblewrap
Version: 0.8.0-2

When the --dev option is used, the 'mount' command cannot be used inside
the container, even when permissions would appear to allow it.  A script
that demonstrates this is attached:
$ ./bwrap-test.sh
bash-5.2$ mount -t tmpfs x /tmp
mount: /tmp: must be superuser to use mount.
   dmesg(1) may have more information after failed mount system 
call.
bash-5.2$ exit
exit
$ ./bwrap-test.sh -a
bash-5.2$ mount -t tmpfs x /tmp
bash-5.2$ exit
exit
$ 

When "-a" is used, "--dev-bind /dev /dev" replaces "--dev /dev", and the
"mount" command works.  This is kind of the opposite of what I'd expect,
as --dev seems safer than a full --dev-bind.  Nothing is logged to dmesg
either way.

A work-around is to use something like "--dev-bind /dev /real-dev", then
bind-mount chosen devices to a new /dev tree before unmounting /real-dev
("umount --no-mtab --lazy /real-dev" seems to work).

- Michael


-- Package-specific info:
Permissions of /usr/bin/bwrap:
-rwxr-xr-x 1 root root 72080 Feb 28  2023 /usr/bin/bwrap
/etc/sysctl.d/*-bubblewrap.conf:
cat: '/etc/sysctl.d/*-bubblewrap.conf': No such file or directory
/usr/lib/sysctl.d/50-bubblewrap.conf:
# Enable unprivileged creation of new user namespaces in older Debian
# kernels.
#
# If this is not desired, copy this file to
# /etc/sysctl.d/50-bubblewrap.conf and change the value of this parameter
# to 0, then use dpkg-statoverride to make /usr/bin/bwrap setuid root.
#
# For more details see https://deb.li/bubblewrap or
# /usr/share/doc/bubblewrap/README.Debian
kernel.unprivileged_userns_clone=1
/proc/sys/kernel/unprivileged_userns_clone:
1
/proc/sys/user/max_cgroup_namespaces:
256640
/proc/sys/user/max_ipc_namespaces:
256640
/proc/sys/user/max_mnt_namespaces:
256640
/proc/sys/user/max_net_namespaces:
256640
/proc/sys/user/max_pid_namespaces:
256640
/proc/sys/user/max_time_namespaces:
256640
/proc/sys/user/max_user_namespaces:
256640
/proc/sys/user/max_uts_namespaces:
256640

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bubblewrap depends on:
ii  libc62.37-15
ii  libcap2  1:2.66-5
ii  libselinux1  3.5-2

Versions of packages bubblewrap recommends:
ii  procps  2:4.0.4-4

bubblewrap suggests no packages.

-- no debconf information
#!/bin/sh
set -e  #errexit
set -u  #nounset

alt_dev=0
while getopts 'a' opt
do
case "$opt" in
a) alt_dev=1;;
\? | *) exit 2;;
esac
done
shift "$((OPTIND - 1))"

if test "$#" -ne 0
then
printf 'Usage: %s [-a]\n' "${0##*/}" >&2
exit 2
fi

set -- bwrap
set -- "$@" --unshare-pid
set -- "$@" --cap-add CAP_DAC_OVERRIDE
set -- "$@" --cap-add CAP_SETPCAP
set -- "$@" --cap-add CAP_SYS_ADMIN
set -- "$@" --ro-bind /usr/ /usr
set -- "$@" --setenv PATH /usr/bin
set -- "$@" --symlink /usr/lib/ /lib
set -- "$@" --symlink /usr/lib64/ /lib64
set -- "$@" --proc /proc
set -- "$@" --dir /tmp

if test "$alt_dev" -eq 0
then
# this prevents future 'mount' calls...
set -- "$@" --dev /dev
else
# ...but this does not
set -- "$@" --dev-bind /dev/ /dev
fi

#printf '%s\n' "$*"
"$@" -- /usr/bin/bash


signature.asc
Description: PGP signature

Bug#1063931: "strace -f" gets an infinite SIGSEGV loop if namespace PID 1 calls abort()

[Michael Gold]

Package: strace
Version: 6.5-0.1

When the process being strace'd is PID 1 in a PID namespace and calls
abort(), strace shows an infinite SIGSEGV loop.  Here's a test case:
#include 
int main() { abort(); }

With glibc, running "unshare -prf ./a.out" results in the process dying
from a segmentation fault.

By contrast, "strace -f unshare -prf ./a.out" produces an infinite loop
of segfaults.  Perhaps this could be considered a bug in glibc or Linux,
but it seems less than ideal that strace loops forever in a case where
the non-strace'd process would have died.

If strace is capable of detecting that the traced process has no handler
for the signal, it would be nice to detect and avoid the loop.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages strace depends on:
ii  libc6   2.37-15
ii  libunwind8  1.6.2-3

strace recommends no packages.

strace suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1063928: Patch v2

[cen]

There was also a missing import, attaching a revised patch.
diff --git a/scripts/debrebuild.pl b/scripts/debrebuild.pl
index 561db866..01c445d5 100755
--- a/scripts/debrebuild.pl
+++ b/scripts/debrebuild.pl
@@ -20,6 +20,7 @@ use autodie;
 use Getopt::Long qw(:config gnu_getopt no_bundling no_auto_abbrev);
 
 use Dpkg::Control;
+use Dpkg::Control::FieldsCore;
 use Dpkg::Index;
 use Dpkg::Deps;
 use Dpkg::Source::Package;
@@ -234,16 +235,20 @@ my $srcpkgver  = $cdata->{Version};
 # make $@ local, so we don't print "Undefined subroutine" error message
 # in other parts where we evaluate $@
 local $@ = '';
+# in some cases the source field contains a version in the form: name (version)
+# for example: binclock (1.5-6)
 # field_parse_binary_source is only available starting with dpkg 1.21.0
-eval { ($srcpkgname, $srcpkgver) = field_parse_binary_source($cdata); };
-if ($@) {
-($srcpkgname, $srcpkgver) = split / /, $srcpkgname, 2;
-# Add a simple control check to avoid the worst surprises and stop
-# obvious cases of garbage-in-garbage-out.
-die("Unexpected source package name: ${srcpkgname}\n")
-  if $srcpkgname =~ m{[ \t_/\(\)<>!\n%&\$\#\@]};
-# remove the surrounding parenthesis from the version
-$srcpkgver =~ s/^\((.*)\)$/$1/;
+if ($srcpkgname =~ / /) {
+eval { ($srcpkgname, $srcpkgver) = field_parse_binary_source($cdata); };
+if ($@) {
+($srcpkgname, $srcpkgver) = split / /, $srcpkgname, 2;
+# Add a simple control check to avoid the worst surprises and stop
+# obvious cases of garbage-in-garbage-out.
+die("Unexpected source package name: ${srcpkgname}\n")
+  if $srcpkgname =~ m{[ \t_/\(\)<>!\n%&\$\#\@]};
+# remove the surrounding parenthesis from the version
+$srcpkgver =~ s/^\((.*)\)$/$1/;
+}
 }
 }
 

Bug#1063929: ITP: golang-github-go-quicktest-qt -- Quick helpers for testing Go applications using generics.

[Loren M. Lang]

Package: wnpp
Severity: wishlist
Owner: Loren M. Lang 

* Package name: golang-github-go-quicktest-qt
  Version : 1.101.0-1
  Upstream Author : 
* URL : https://github.com/go-quicktest/qt
* License : Expat
  Programming Lang: Go
  Description : Quick helpers for testing Go applications using generics.

 qt: quicker Go tests
 .
 go get github.com/go-quicktest/qt
 .
 Package qt provides a collection of Go helpers for writing tests. It
 uses generics, so requires Go 1.18 at least.
 .
 For a complete API reference, see the package documentation
 (https://pkg.go.dev/github.com/go-quicktest/qt).
 .
 Quicktest helpers can be easily integrated inside regular Go tests, for
 instance:
 .
   import "github.com/go-quicktest/qt"
 .
   func TestFoo(t *testing.T) {
   t.Run("numbers", func(t *testing.T) {
   numbers, err := somepackage.Numbers()
   qt.Assert(t, qt.DeepEquals(numbers, []int{42, 47})
   qt.Assert(t, qt.ErrorMatches(err, "bad wolf"))
   })
   t.Run("nil", func(t *testing.T) {
   got := somepackage.MaybeNil()
   qt.Assert(t, qt.IsNil(got), qt.Commentf("value: %v",
 somepackage.Value))
   })
   }
 .
 Assertions
 .
 An assertion looks like this, where qt.Equals could be replaced by any
 available checker. If the assertion fails, the underlying t.Fatal method
 is called to describe the error and abort the test.
 .
   qt.Assert(t, qt.Equals(someValue, wantValue))
 .
 If you don’t want to abort on failure, use Check instead, which calls
 Error instead of Fatal:
 .
   qt.Check(t, qt.Equals(someValue, wantValue))
 .
 The library provides some base checkers like Equals, DeepEquals,
 Matches, ErrorMatches, IsNil and others. More can be added by
 implementing the Checker interface.
 .
 Other helpers
 .
 The Patch helper makes it a little more convenient to change a global or
 other variable for the duration of a test.


This package is being added to support cilium/pwru which is RFP in BTS
#1063031.

Bug#1063928: Attach patch

[cen]

Forgot to attach the patch file.
diff --git a/scripts/debrebuild.pl b/scripts/debrebuild.pl
index 561db866..93f94617 100755
--- a/scripts/debrebuild.pl
+++ b/scripts/debrebuild.pl
@@ -234,16 +234,20 @@ my $srcpkgver  = $cdata->{Version};
 # make $@ local, so we don't print "Undefined subroutine" error message
 # in other parts where we evaluate $@
 local $@ = '';
+# in some cases the source field contains a version in the form: name (version)
+# for example: binclock (1.5-6)
 # field_parse_binary_source is only available starting with dpkg 1.21.0
-eval { ($srcpkgname, $srcpkgver) = field_parse_binary_source($cdata); };
-if ($@) {
-($srcpkgname, $srcpkgver) = split / /, $srcpkgname, 2;
-# Add a simple control check to avoid the worst surprises and stop
-# obvious cases of garbage-in-garbage-out.
-die("Unexpected source package name: ${srcpkgname}\n")
-  if $srcpkgname =~ m{[ \t_/\(\)<>!\n%&\$\#\@]};
-# remove the surrounding parenthesis from the version
-$srcpkgver =~ s/^\((.*)\)$/$1/;
+if ($srcpkgname =~ / /) {
+eval { ($srcpkgname, $srcpkgver) = field_parse_binary_source($cdata); };
+if ($@) {
+($srcpkgname, $srcpkgver) = split / /, $srcpkgname, 2;
+# Add a simple control check to avoid the worst surprises and stop
+# obvious cases of garbage-in-garbage-out.
+die("Unexpected source package name: ${srcpkgname}\n")
+  if $srcpkgname =~ m{[ \t_/\(\)<>!\n%&\$\#\@]};
+# remove the surrounding parenthesis from the version
+$srcpkgver =~ s/^\((.*)\)$/$1/;
+}
 }
 }
 

Bug#1063928: devscripts: Fix field_parse_binary_source usage in debrebuild

[cen]

Package: devscripts
Version: 2.23.7
Severity: normal
X-Debbugs-Cc: jo...@debian.org

Dear Maintainer,

this fixes a missing include for field_parse_binary_source and only parses the 
Source if whitespace is detected.
Error was: Use of uninitialized value $srcpkgver in substitution (s///)
Also see commit 45deacb245862f1bcef7772a53e0fe33b2cc3da7 where the whitespace 
check was I think (accidentally) removed.

My first ever contribution and line of perl code so please review carefully and 
have patience. :)

-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
Not present

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-17-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages devscripts depends on:
ii  dpkg-dev  1.22.4
ii  file  1:5.45-2+b1
ii  gnupg 2.2.40-1.1
ii  gpgv  2.2.40-1.1+b1
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-2
ii  libfile-touch-perl0.12-2
ii  libfile-which-perl1.27-2
ii  libipc-run-perl   20231003.0-1
ii  libmoo-perl   2.005005-1
ii  libwww-perl   6.76-1
ii  patchutils0.4.2-1
ii  perl  5.38.2-3
ii  python3   3.11.6-1
ii  sensible-utils0.0.22
ii  wdiff 1.2.2-6

Versions of packages devscripts recommends:
ii  apt 2.7.11
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2023.12.24
ii  dput1.1.3
ii  equivs  2.3.1
ii  libdistro-info-perl 1.7
ii  libdpkg-perl1.22.4
ii  libencode-locale-perl   1.05-3
ii  libgit-wrapper-perl 0.048-2
ii  libgitlab-api-v4-perl   0.27-1
ii  libjson-perl4.1-1
ii  liblist-compare-perl0.55-2
ii  liblwp-protocol-https-perl  6.13-1
ii  libsoap-lite-perl   1.27-3
ii  libstring-shellquote-perl   1.04-3
ii  libtry-tiny-perl0.31-2
ii  liburi-perl 5.26-1
ii  licensecheck3.3.9-1
ii  lintian 2.117.0
ii  man-db  2.12.0-3
ii  patch   2.7.6-7
ii  pristine-tar1.50
ii  python3-apt 2.7.5
ii  python3-debian  0.1.49
ii  python3-magic   2:0.4.27-2
ii  python3-requests2.31.0+dfsg-1
ii  python3-unidiff 0.7.3-1
ii  python3-xdg 0.28-2
ii  strace  6.5-0.1
ii  unzip   6.0-28
ii  wget1.21.4-1+b1
ii  xz-utils5.4.5-0.3

Versions of packages devscripts suggests:
pn  adequate   
pn  at 
pn  autopkgtest
pn  bls-standalone 
pn  bsd-mailx | mailx  
ii  build-essential12.10
pn  check-all-the-things   
pn  cvs-buildpackage   
ii  debhelper  13.13
pn  diffoscope 
pn  disorderfs 
pn  dose-extra 
pn  duck   
pn  elpa-devscripts
ii  faketime   0.9.10-2.1+b1
pn  gnuplot
pn  how-can-i-help 
ii  libauthen-sasl-perl2.1700-1
pn  libdbd-pg-perl 
ii  libfile-desktopentry-perl  0.22-3
pn  libterm-size-perl  
ii  libtimedate-perl   2.3300-2
pn  libyaml-syck-perl  
ii  mmdebstrap 1.4.3-1
pn  mutt   
pn  piuparts   
pn  postgresql-client  
pn  pristine-lfs   
pn  quilt  
pn  ratt   
pn  reprotest  
pn  ssh-client 
pn  svn-buildpackage   
pn  w3m

-- no debconf information

Bug#1063927: xpdf: FTBFS with poppler 24.02.0

[Amin Bandali]

Source: xpdf
Version: 3.04+git20240124-1
Severity: important
Tags: ftbfs patch upstream fixed-upstream
X-Debbugs-Cc: band...@debian.org

Dear Maintainer,

I recently uploaded new poppler 24.02.0 to experimental, and xpdf is
one of the affected packages that fails to build from source with it.

Please consider cherry-picking upstream commit
0698734c46d6414c5285d9fa985c3bd4e380aaa8 (also attached to this bug
report for your convenience) to fix the build with the new poppler.

Thanks,
-a

>From 0698734c46d6414c5285d9fa985c3bd4e380aaa8 Mon Sep 17 00:00:00 2001
From: Adam Sampson 
Date: Fri, 2 Feb 2024 13:58:46 +
Subject: [PATCH] OutlineItem's title is a vector in Poppler 24.02.

---
 configure.ac   |  3 +++
 xpdf/XPDFViewer.cc | 12 +---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index d591291..d7d6ad2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -69,6 +69,9 @@ PKG_CHECK_EXISTS([poppler >= 22.05.0], [
 PKG_CHECK_EXISTS([poppler >= 23.06.0], [
   AC_DEFINE([ADDFONTFILE_STRING])
 ])
+PKG_CHECK_EXISTS([poppler >= 24.02.0], [
+  AC_DEFINE([OUTLINEITEM_TITLE_VECTOR])
+])
 
 AC_SEARCH_LIBS([XmDropDownGetArrow], [Xm], [], [
   AC_MSG_ERROR([Motif >= 2.3 is required])
diff --git a/xpdf/XPDFViewer.cc b/xpdf/XPDFViewer.cc
index c191931..e34a657 100644
--- a/xpdf/XPDFViewer.cc
+++ b/xpdf/XPDFViewer.cc
@@ -2623,7 +2623,7 @@ void XPDFViewer::setupOutlineItems(PCONST OutlineItemList *items,
   Widget label;
   Arg args[20];
   XmString s;
-  int i, j, n;
+  int i, n;
 
   for (i = 0; i < (int)items->getOILSize(); ++i) {
 #ifdef NO_GOOLIST
@@ -2636,9 +2636,15 @@ void XPDFViewer::setupOutlineItems(PCONST OutlineItemList *items,
 std::string title;
 mbstate_t state;
 memset(, 0, sizeof state);
-for (j = 0; j < item->getTitleLength(); ++j) {
+#ifdef OUTLINEITEM_TITLE_VECTOR
+for (auto ch : item->getTitle()) {
+#else
+for (int j = 0; j < item->getTitleLength(); ++j) {
+  Unicode ch = item->getTitle()[j];
+#endif
+
   char buf[8];
-  n = wcrtomb(buf, (wchar_t)item->getTitle()[j], );
+  n = wcrtomb(buf, (wchar_t)ch, );
   if (n == -1) {
 // unmappable character
 title.push_back(' ');
-- 
2.43.0

Bug#1063916: RFP: freenginx -- a fork of nginx maintained by Maxim Dounin and the development community

[Alejandro Colomar]

+1


signature.asc
Description: PGP signature

Bug#1063926: gambas3: FTBFS with poppler 24.02.0

[Amin Bandali]

Source: gambas3
Version: 3.18.4-3
Severity: important
Tags: ftbfs patch upstream
X-Debbugs-Cc: band...@debian.org

Dear Maintainer,

I recently uploaded new poppler 24.02.0 to experimental, and gambas3
is one of the affected packages that fails to build from source with
it.  Please find attached a patch to fix the build, forwarded upstream
as well.

>From f5177f706b71a0ef918021c95ace9f60c0754313 Mon Sep 17 00:00:00 2001
From: Amin Bandali 
Date: Wed, 14 Feb 2024 09:56:10 -0500
Subject: [PATCH] make 'gb.pdf' compile with poppler 24.02.0
Forwarded: https://gitlab.com/gambas/gambas/-/merge_requests/330

---
 gb.pdf/configure.ac |  2 ++
 gb.pdf/src/CPdfDocument.cpp | 21 +
 2 files changed, 23 insertions(+)

diff --git a/gb.pdf/configure.ac b/gb.pdf/configure.ac
index 6931e2c48..6e612e40a 100644
--- a/gb.pdf/configure.ac
+++ b/gb.pdf/configure.ac
@@ -34,6 +34,8 @@ if test "$have_poppler" = "yes"; then
   AC_DEFINE_UNQUOTED(POPPLER_VERSION_21_06_0, $((1-$?)), Poppler version >= 21.06.0)
   $PKG_CONFIG --atleast-version=22.06.0 poppler
   AC_DEFINE_UNQUOTED(POPPLER_VERSION_22_06_0, $((1-$?)), Poppler version >= 22.06.0)
+  $PKG_CONFIG --atleast-version=24.02.0 poppler
+  AC_DEFINE_UNQUOTED(POPPLER_VERSION_24_02_0, $((1-$?)), Poppler version >= 24.02.0)
 fi
 
 AC_CONFIG_FILES([\
diff --git a/gb.pdf/src/CPdfDocument.cpp b/gb.pdf/src/CPdfDocument.cpp
index 8f4aac7fb..5dfbfefc1 100644
--- a/gb.pdf/src/CPdfDocument.cpp
+++ b/gb.pdf/src/CPdfDocument.cpp
@@ -102,6 +102,22 @@ END_PROPERTY
 
 /
 
+#if POPPLER_VERSION_24_02_0
+static void return_unicode_string(const std::vector )
+{
+	GooString gstr;
+	char buf[8]; /* 8 is enough for mapping an unicode char to a string */
+	int n;
+
+	const UnicodeMap *uMap = globalParams->getUtf8Map();
+	for (const auto  : unicode) {
+		n = uMap->mapUnicode(c, buf, sizeof(buf));
+		gstr.append(buf, n);
+	}
+
+	GB.ReturnNewZeroString(gstr.getCString());
+}
+#else
 static void return_unicode_string(const Unicode *unicode, int len)
 {
 	GooString gstr;
@@ -128,6 +144,7 @@ static void return_unicode_string(const Unicode *unicode, int len)
 
 	GB.ReturnNewZeroString(gstr.getCString());
 }
+#endif
 
 
 static void aux_return_string_info(void *_object, const char *key)
@@ -776,7 +793,11 @@ END_PROPERTY
 BEGIN_PROPERTY(PDFINDEX_title)
 
 	OutlineItem *item = CPDF_index_get(THIS->currindex);
+#if POPPLER_VERSION_24_02_0
+	return_unicode_string(item->getTitle());
+#else
 	return_unicode_string(item->getTitle(), item->getTitleLength());
+#endif
 
 END_PROPERTY
 
-- 
2.43.0

Bug#1063925: victoriametrics: Occasional FTBFS: VictoriaMetrics/lib/storage/inmemory_part.go:37 BUG: Inmemory.InitFromRows must accept at least one row

[Mathias Gibbens]

Source: victoriametrics
Version: 1.79.14+ds1-1
Severity: normal
Tags: trixie sid ftbfs

  In a clean sid schroot, I observed an occasional test failure (2/9
builds):

> 2024-02-14T22:25:03.764Zpanic   
> VictoriaMetrics/lib/storage/inmemory_part.go:37 BUG: Inmemory.InitFromRows 
> must accept at least one row
> --- FAIL: TestMergeBlockStreamsManyStreamsManyBlocksManyRows (0.00s)
> panic: BUG: Inmemory.InitFromRows must accept at least one row [recovered]
> panic: BUG: Inmemory.InitFromRows must accept at least one row
> 
> goroutine 56566 [running]:
> testing.tRunner.func1.2({0x6e5360, 0xc005603000})
> /usr/lib/go-1.21/src/testing/testing.go:1545 +0x238
> testing.tRunner.func1()
> /usr/lib/go-1.21/src/testing/testing.go:1548 +0x397
> panic({0x6e5360?, 0xc005603000?})
> /usr/lib/go-1.21/src/runtime/panic.go:914 +0x21f
> github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.logMessage({0x72f3fd, 
> 0x5}, {0xc0058a0e80, 0x37}, 0x0?)
> 
> /build/victoriametrics-1.79.14+ds1/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:269
>  +0x95e
> github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.logLevelSkipframes(0x1, 
> {0x72f3fd, 0x5}, {0x747753?, 0xc0017bee30?}, {0x0?, 0x90?, 0x7166e0?})
> 
> /build/victoriametrics-1.79.14+ds1/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:137
>  +0x194
> github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.logLevel(...)
> 
> /build/victoriametrics-1.79.14+ds1/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:129
> github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.Panicf(...)
> 
> /build/victoriametrics-1.79.14+ds1/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:125
> github.com/VictoriaMetrics/VictoriaMetrics/lib/storage.(*inmemoryPart).InitFromRows(0xc0036eb200,
>  {0x0, 0x0, 0x0})
> 
> /build/victoriametrics-1.79.14+ds1/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/inmemory_part.go:37
>  +0x58
> github.com/VictoriaMetrics/VictoriaMetrics/lib/storage.newTestBlockStreamReader(0xc001934878?,
>  {0x0, 0x0, 0x0})
> 
> /build/victoriametrics-1.79.14+ds1/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/block_stream_reader_test.go:151
>  +0x45
> github.com/VictoriaMetrics/VictoriaMetrics/lib/storage.TestMergeBlockStreamsManyStreamsManyBlocksManyRows(0x60a440?)
> 
> /build/victoriametrics-1.79.14+ds1/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/merge_test.go:325
>  +0x11b
> testing.tRunner(0xc001811860, 0x7cc288)
> /usr/lib/go-1.21/src/testing/testing.go:1595 +0xff
> created by testing.(*T).Run in goroutine 1
> /usr/lib/go-1.21/src/testing/testing.go:1648 +0x3ad
> FAILgithub.com/VictoriaMetrics/VictoriaMetrics/lib/storage  12.339s


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

Bug#1056936: bookworm-pu: package glewlwyd/2.7.5-3

[Nicolas Mora]

Hello,

I've updated the debdiff to add a fix for CVE-2024-25715

/Nicolasdiff -Nru glewlwyd-2.7.5/debian/changelog glewlwyd-2.7.5/debian/changelog
--- glewlwyd-2.7.5/debian/changelog	2023-05-04 07:21:27.0 -0400
+++ glewlwyd-2.7.5/debian/changelog	2023-11-23 17:12:13.0 -0500
@@ -1,3 +1,12 @@
+glewlwyd (2.7.5-3+deb12u1) bookworm; urgency=medium
+
+  * d/patches: Fix CVE-2023-49208
+possible buffer overflow during FIDO2 credentials validation
+  * d/patches: Fix CVE-2024-25715
+open redirection via redirect_uri
+
+ -- Nicolas Mora   Thu, 23 Nov 2023 17:12:13 -0500
+
 glewlwyd (2.7.5-3) unstable; urgency=medium
 
   * Install config.json as config-2.7.json (Closes: #1035503)
diff -Nru glewlwyd-2.7.5/debian/patches/CVE-2023-49208.patch glewlwyd-2.7.5/debian/patches/CVE-2023-49208.patch
--- glewlwyd-2.7.5/debian/patches/CVE-2023-49208.patch	1969-12-31 19:00:00.0 -0500
+++ glewlwyd-2.7.5/debian/patches/CVE-2023-49208.patch	2023-11-23 17:12:13.0 -0500
@@ -0,0 +1,21 @@
+Description: Fix CVE-2023-49208 for bookworm
+Author: Nicolas Mora 
+Forwarded: not-needed
+--- a/src/scheme/webauthn.c
 b/src/scheme/webauthn.c
+@@ -2260,13 +2260,13 @@
+ for (i=0; i
+Forwarded: not-needed
+--- a/src/plugin/protocol_oauth2.c
 b/src/plugin/protocol_oauth2.c
+@@ -696,7 +696,7 @@
+ 
+ static json_t * check_client_valid(struct _oauth2_config * config, const char * client_id, const char * client_header_login, const char * client_header_password, const char * redirect_uri, unsigned short authorization_type, int implicit_flow, const char * ip_source) {
+   json_t * j_client, * j_element = NULL, * j_return;
+-  int uri_found, authorization_type_enabled;
++  int uri_found = 0, authorization_type_enabled;
+   size_t index = 0;
+   
+   if (client_id == NULL) {
+@@ -707,20 +707,17 @@
+ return json_pack("{si}", "result", G_ERROR_PARAM);
+   }
+   j_client = config->glewlwyd_config->glewlwyd_callback_check_client_valid(config->glewlwyd_config, client_id, client_header_password);
+-  if (check_result_value(j_client, G_OK)) {
++  if (check_result_value(j_client, G_OK) && json_object_get(json_object_get(j_client, "client"), "enabled") == json_true()) {
+ if (!implicit_flow && client_header_password == NULL && json_object_get(json_object_get(j_client, "client"), "confidential") == json_true()) {
+   y_log_message(Y_LOG_LEVEL_DEBUG, "check_client_valid - oauth2 - Error, confidential client must be authentified with its password, origin: %s", ip_source);
+   j_return = json_pack("{si}", "result", G_ERROR_UNAUTHORIZED);
+ } else {
+   if (redirect_uri != NULL) {
+-uri_found = 0;
+ json_array_foreach(json_object_get(json_object_get(j_client, "client"), "redirect_uri"), index, j_element) {
+   if (0 == o_strcmp(json_string_value(j_element), redirect_uri)) {
+ uri_found = 1;
+   }
+ }
+-  } else {
+-uri_found = 1;
+   }
+   
+   authorization_type_enabled = 0;
+@@ -2444,8 +2441,8 @@
+   // Check if client is allowed to perform this request
+   if (check_result_value(j_client, G_OK)) {
+ // Client is allowed to use auth_code grant with this redirection_uri
+-if (u_map_has_key(request->map_url, "g_continue")) {
+-  if (!o_strnullempty(u_map_get(request->map_url, "scope"))) {
++if (!o_strnullempty(u_map_get(request->map_url, "scope"))) {
++  if (u_map_has_key(request->map_url, "g_continue")) {
+ j_session = validate_session_client_scope(config, request, u_map_get(request->map_url, "client_id"), u_map_get(request->map_url, "scope"));
+ if (check_result_value(j_session, G_OK)) {
+   if (json_object_get(json_object_get(j_session, "session"), "authorization_required") == json_false()) {
+@@ -2526,26 +2523,20 @@
+ }
+ json_decref(j_session);
+   } else {
+-// Scope is not allowed for this user
+-y_log_message(Y_LOG_LEVEL_DEBUG, "check_auth_type_auth_code_grant - oauth2 - scope list is missing or empty, origin: %s", ip_source);
+-response->status = 302;
+-redirect_url = msprintf("%s%serror=invalid_scope%s", u_map_get(request->map_url, "redirect_uri"), (o_strchr(u_map_get(request->map_url, "redirect_uri"), '?')!=NULL?"&":"?"), state_param);
++// Redirect to login page
++redirect_url = get_login_url(config, request, "auth", u_map_get(request->map_url, "client_id"), u_map_get(request->map_url, "scope"), NULL);
+ ulfius_add_header_to_response(response, "Location", redirect_url);
+ o_free(redirect_url);
++response->status = 302;
+   }
+ } else {
+-  // Redirect to login page
+-  redirect_url = get_login_url(config, request, "auth", u_map_get(request->map_url, "client_id"), u_map_get(request->map_url, "scope"), NULL);
+-  ulfius_add_header_to_response(response, "Location", redirect_url);
+-  o_free(redirect_url);
+-  response->status = 302;
++  // 

Bug#1047893: ssvnc: Fails to build source after successful build

[Vladimir Petko]

Dear Maintainers,

 Would it be possible to consider the attached debdiff as a solution
for this bug?

Best Regards,
 Vladimir.


ssvnc_1.0.29-6_to_1.0.29-7.debdiff
Description: Binary data

Bug#916380: (no subject)

[Thiago Marques]

Hi Helmut,
Thanks for the patch. It worked with DH level 9. The autotools is
selecting the right cross-compile.
But as I bumped the DH level to 13, the build is working fine for
cross platform. Selecting the right compiler for the target and not using
the guest compiler.

This bug will be fixed with the new DH level.

Regards,
Thiago Marques

Bug#1062739: marked as done (libydpdict: NMU diff for 64-bit time_t transition)

[Marcin Owsiany]

I just wanted to make sure this was not closed by mistake, since the
subject of your message mentions libydpdict, while the body
mentions cuneiform.

Marcin

śr., 14 lut 2024 o 22:18 Debian Bug Tracking System 
napisał(a):

> Your message dated Wed, 14 Feb 2024 13:15:04 -0800
> with message-id 
> and subject line Re: libydpdict: NMU diff for 64-bit time_t transition
> has caused the Debian Bug report #1062739,
> regarding libydpdict: NMU diff for 64-bit time_t transition
> 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.)
>
>
> --
> 1062739: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062739
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Steve Langasek 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Fri, 02 Feb 2024 23:00:51 +
> Subject: libydpdict: NMU diff for 64-bit time_t transition
> Source: libydpdict
> Version: 1.0.4-3
> Severity: serious
> Tags: patch pending sid trixie
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
>
> NOTICE: these changes must not be uploaded to unstable yet!
>
> Dear maintainer,
>
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> libydpdict as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
>
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
>
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time.  Therefore I have prepared a 0-day NMU for libydpdict
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
>
> Please find the patch for this NMU attached.
>
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if
> information
> becomes available that your package should not be included in the
> transition,
> there is time for us to amend the planned uploads.
>
>
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
>
>
> -- Forwarded message --
> From: Steve Langasek 
> To: 1062739-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Wed, 14 Feb 2024 13:15:04 -0800
> Subject: Re: libydpdict: NMU diff for 64-bit time_t transition
> Happily, we can report that an improved analysis shows cuneiform does not
> have an ABI affected by this transition.  We will not be uploading to
> unstable, and the NMU in experimental can be ignored/superseded/requested
> to
> be removed.
>
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
>

Bug#1063924: libnetplan1 has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libnetplan.so.0.0

[Helmut Grohne]

Package: libnetplan1
Version: 0.107.1-3+exp1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libnetplan0
X-Debbugs-Cc: Lukas Märdian , vor...@debian.org

libnetplan1 has an undeclared file conflict. This may result in an
unpack error from dpkg.

The file /usr/lib/x86_64-linux-gnu/libnetplan.so.0.0 is contained in the
packages
 * libnetplan0
   * 0.101-4 as present in bullseye
   * 0.106-2+deb12u1 as present in bookworm
   * 0.107.1-3 as present in trixie|unstable
 * libnetplan1/0.107.1-3+exp1 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1063921: gstreamer1.0-plugins-good has an undeclared file conflict

[Helmut Grohne]

Package: gstreamer1.0-plugins-good
Version: 1.23.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + gstreamer1.0-plugins-ugly

gstreamer1.0-plugins-good has an undeclared file conflict. This may
result in an unpack error from dpkg.

The files
 * /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrnb.so
 * /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrwbdec.so
are contained in the packages
 * gstreamer1.0-plugins-good/1.23.1-1 as present in experimental
 * gstreamer1.0-plugins-ugly
   * 1.22.0-2+deb12u1 as present in bookworm|bookworm-security
   * 1.22.10-1 as present in unstable
   * 1.22.9-1 as present in trixie

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1063923: node-shapefile has an undeclared file conflict

[Helmut Grohne]

Package: node-shapefile
Version: 0.3.1+~cs14.23.94-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + shapelib

node-shapefile has an undeclared file conflict. This may result in an
unpack error from dpkg.

The files
 * /usr/bin/dbfcat
 * /usr/bin/shpcat
are contained in the packages
 * node-shapefile/0.3.1+~cs14.23.94-1 as present in unstable
 * shapelib
   * 1.5.0-2 as present in bullseye
   * 1.5.0-3+b1 as present in bookworm
   * 1.6.0-1 as present in trixie|unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1063922: libnfft3-long4 has an undeclared file conflict

[Helmut Grohne]

Package: libnfft3-long4
Version: 3.5.3-3
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libnfft3-long2

libnfft3-long4 has an undeclared file conflict. This may result in an
unpack error from dpkg.

The files
 * /usr/lib/x86_64-linux-gnu/libnfft3l.so.4
 * /usr/lib/x86_64-linux-gnu/libnfft3l.so.4.0.3
 * /usr/lib/x86_64-linux-gnu/libnfft3l_threads.so.4
 * /usr/lib/x86_64-linux-gnu/libnfft3l_threads.so.4.0.3
are contained in the packages
 * libnfft3-long2/3.5.3-1 as present in unstable
 * libnfft3-long4/3.5.3-3 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1063920: console-setup: initramfs keymap is not set and breaks my root crypted boot

[Daniel Dehennin]

Package: console-setup
Version: 1.226
Severity: important

Dear Maintainer,

Since the upgrade to 1.226, I can't open my LUKS root FS beause of broken 
initramfs.

I can still boot under 6.6.11 since its initramfs is not updated with latest 
tools.

I compared both initramfs and found different console-setup keymap files and 
SHA256:

$ sha256sum 11/main/etc/console-setup/cached_UTF-8_del.kmap 
15/main/etc/console-setup/tmpkbd.aXFBap 
d9ca379b8ca9b6ce6c451d19820ed99e530cd0a6c4cf1d11601f6c8d4d8c4d24  
11/main/etc/console-setup/cached_UTF-8_del.kmap
742d84819c114f3aefd59ed87477beaedf05f2a9fc615159369021e2ff58a89f  
15/main/etc/console-setup/tmpkbd.aXFBap

I hope it will help you to find what's going on.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.11-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages console-setup depends on:
ii  console-setup-linux 1.226
ii  debconf [debconf-2.0]   1.5.86
ii  keyboard-configuration  1.226
ii  xkb-data2.41-2

console-setup recommends no packages.

Versions of packages console-setup suggests:
ii  locales2.37-15
ii  sysvinit-utils [lsb-base]  3.08-6

Versions of packages keyboard-configuration depends on:
ii  debconf [debconf-2.0]   1.5.86
ii  liblocale-gettext-perl  1.07-6+b1
ii  xkb-data2.41-2

Versions of packages console-setup-linux depends on:
ii  init-system-helpers 1.66
ii  kbd 2.6.4-2
ii  keyboard-configuration  1.226

console-setup-linux suggests no packages.

Versions of packages console-setup is related to:
pn  console-common
pn  console-data  
pn  console-tools 
ii  gnome-control-center  1:46~beta-1
ii  kbd   2.6.4-2
ii  systemd   255.3-2

-- debconf information excluded

-- 
Daniel Dehennin
Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
Fingerprint: 3E69 014E 5C23 50E8 9ED6  2AAD CC1E 9E5B 7A6F E2DF

Bug#1063919: ITP: python-pyu2f -- pure python U2F host library

[Harlan Lieberman-Berg]

Package: wnpp
Severity: wishlist
Owner: Harlan Lieberman-Berg 
X-Debbugs-Cc: debian-de...@lists.debian.org, hlieber...@debian.org

* Package name: python-pyu2f
  Version : 0.1.5
  Upstream Contact: Google 
* URL : https://www.github.com/google/pyu2f
* License : Apache-2.0
  Programming Lang: Python
  Description : pure python U2F host library

pyu2f is a python based U2F host library for Linux, Windows, and MacOS. It
provides functionality for interacting with a U2F device over USB.
.
pyu2f uses ctypes to make system calls directly to interface with the USB HID
device. This means that no platform specific shared libraries need to be
compiled for pyu2f to work.

Bug#1063210: pari: NMU diff for 64-bit time_t transition

[Bill Allombert]

On Mon, Feb 05, 2024 at 02:43:30PM -0300, Lucas Kanashiro wrote:
> Source: pari
> Version: 2.15.4-2
> Severity: serious
> Tags: patch pending sid trixie
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
> 
> NOTICE: these changes must not be uploaded to unstable yet!
> 
> Dear maintainer,
> 
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> pari as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
> 
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
> 
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time.  Therefore I have prepared a 0-day NMU for pari
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
> 
> Please find the patch for this NMU attached.
> 
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.

My concern is, as you can see, that the new library package is empty:

libpari-gmp-tls8t64_2.15.4-2.1~exp1_amd64.deb
-

drwxr-xr-x root/root 0 2024-02-05 17:43 ./
drwxr-xr-x root/root 0 2024-02-05 17:43 ./usr/
drwxr-xr-x root/root 0 2024-02-05 17:43 ./usr/share/
drwxr-xr-x root/root 0 2024-02-05 17:43 ./usr/share/doc/
drwxr-xr-x root/root 0 2024-02-05 17:43 
./usr/share/doc/libpari-gmp-tls8t64/
-rw-r--r-- root/root  1463 2024-02-05 17:43 
./usr/share/doc/libpari-gmp-tls8t64/changelog.Debian.gz
-rw-r--r-- root/root  9997 2023-06-27 18:38 
./usr/share/doc/libpari-gmp-tls8t64/changelog.gz
-rw-r--r-- root/root   766 2022-09-05 21:10 
./usr/share/doc/libpari-gmp-tls8t64/copyright

Compare to the one in unstable:

libpari-gmp-tls8_2.15.4-2_amd64.deb
---

drwxr-xr-x root/root 0 2023-07-12 10:08 ./
drwxr-xr-x root/root 0 2023-07-12 10:08 ./usr/
drwxr-xr-x root/root 0 2023-07-12 10:08 ./usr/lib/
drwxr-xr-x root/root 0 2023-07-12 10:08 ./usr/lib/x86_64-linux-gnu/
-rw-r--r-- root/root  13002328 2023-07-12 10:08 
./usr/lib/x86_64-linux-gnu/libpari-gmp-tls.so.2.15.4
lrwxrwxrwx root/root 0 2023-07-12 10:08 
./usr/lib/x86_64-linux-gnu/libpari-gmp-tls.so.8 -> libpari-gmp-tls.so.2.15.4
drwxr-xr-x root/root 0 2023-07-12 10:08 ./usr/share/
drwxr-xr-x root/root 0 2023-07-12 10:08 ./usr/share/doc/
drwxr-xr-x root/root 0 2023-07-12 10:08 
./usr/share/doc/libpari-gmp-tls8/
-rw-r--r-- root/root  1368 2023-07-12 10:08 
./usr/share/doc/libpari-gmp-tls8/changelog.Debian.gz
-rw-r--r-- root/root  9997 2023-06-27 18:38 
./usr/share/doc/libpari-gmp-tls8/changelog.gz
-rw-r--r-- root/root   766 2022-09-05 21:10 
./usr/share/doc/libpari-gmp-tls8/copyright

It is missing all the important files.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1063918: geary FTBFS with the nocheck build profile: ../meson.build:226:6: ERROR: Program 'update-desktop-database' not found or not executable

[Helmut Grohne]

Source: geary
Version: 44.1-1
Severity: serious
Tags: ftbfs trixie sid

geary fails to build from source in unstable when enabling the nocheck
build profile. Since trixie, such a failure is considered
release-critical. A build ends with:

| ../meson.build:226:6: ERROR: Program 'update-desktop-database' not found or 
not executable
| dh_auto_configure: error: cd obj-x86_64-linux-gnu && 
DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 meson setup .. 
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=lib/x86_64-linux-gnu -Dpython.bytecompile=-1 
-Drevno=Debian/44.1-1 -Dprofile=release returned exit code 1
| make[1]: *** [debian/rules:24: override_dh_auto_configure] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:21: binary] Error 2
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

Consider dropping inappropriate  annotations.

Helmut

Bug#1063917: ITP: python-pylatex -- Python library for creating LaTeX files and snippets

[Yogeswaran Umasankar]

Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar 
X-Debbugs-Cc: debian-de...@lists.debian.org, kd8...@gmail.com

* Package name: python-pylatex
  Version : 1.4.2
  Upstream Contact: Jelte Fennema 
* URL : https://github.com/JelteF/PyLaTeX
* License : Expat
  Programming Lang: Python
  Description : Python library for creating LaTeX files and snippets

PyLaTeX is a Python library for creating and compiling LaTeX files or
 snippets. The goal of this library is being an easy, but extensible
 interface between Python and LaTeX. This package is depends for some of
 the scientific packages. Planning to maintain under Debian Python Team
 and need sponsorship.

Bug#1063916: RFP: freenginx -- a fork of nginx maintained by Maxim Dounin and the development community

[Jeffrey Walton]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: freenginx
  Version : 1.24.0
  Upstream Author : Maxim Dounin and the development community
  Section: web
* URL : http://freenginx.org/
* License : GPL
  Programming Lang: C
  Description : a fork of nginx maintained by Maxim Dounin and the
development community

-

In February 2024, Maxim Dounin forked Nginx and created the freenginx
project. According to Maxim's announcement on the nginx-users mailing
list 
():


Hello!

As you probably know, F5 closed Moscow office in 2022, and I no
longer work for F5 since then.  Still, we’ve reached an agreement
that I will maintain my role in nginx development as a volunteer.
And for almost two years I was working on improving nginx and
making it better for everyone, for free.

Unfortunately, some new non-technical management at F5 recently
decided that they know better how to run open source projects.  In
particular, they decided to interfere with security policy nginx
uses for years, ignoring both the policy and developers’ position.

That’s quite understandable: they own the project, and can do
anything with it, including doing marketing-motivated actions,
ignoring developers position and community.  Still, this
contradicts our agreement.  And, more importantly, I no longer able
to control which changes are made in nginx within F5, and no longer
see nginx as a free and open source project developed and
maintained for the public good.

As such, starting from today, I will no longer participate in nginx
development as run by F5.  Instead, I’m starting an alternative
project, which is going to be run by developers, and not corporate
entities:

http://freenginx.org/

The goal is to keep nginx development free from arbitrary corporate
actions.  Help and contributions are welcome.  Hope it will be
beneficial for everyone.

-- 
Maxim Dounin
http://freenginx.org/

Bug#1059535: transition: abseil

[Sebastian Ramacher]

On 2024-02-14 14:48:49 -0500, Benjamin Barenblat wrote:
> I’d like to alter this transition request. Instead of transitioning to
> version 20230802, I’d like to transition to version 20240116, which
> upstream recently released.
> 
> Is that okay? If so, I’ll upload 20240116 to experimental and reexamine
> reverse dependencies. If not, please let me know how to proceed; a
> 20230802 -> 20240116 upgrade would require a second transition, and I
> don’t want to create extra work.

That's okay. There is enough time to prepare a tranistion to 20240116
until we have finished the time_t transition.

Cheers
-- 
Sebastian Ramacher

Bug#1059535: transition: abseil

[Benjamin Barenblat]

I’d like to alter this transition request. Instead of transitioning to
version 20230802, I’d like to transition to version 20240116, which
upstream recently released.

Is that okay? If so, I’ll upload 20240116 to experimental and reexamine
reverse dependencies. If not, please let me know how to proceed; a
20230802 -> 20240116 upgrade would require a second transition, and I
don’t want to create extra work.

Bug#1063914: bookworm-pu: package nvidia-graphics-drivers-tesla/525.147.05-7~deb12u1

[Andreas Beckmann]

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

[ Reason ]
After integrating src:nvidia-graphics-drivers-tesla into
src:nvidia-graphics-drivers we can turn
src:nvidia-graphics-drivers-tesla into transitional packages.

The pfn_valid patch is also needed for this package. (The transitional
packages are not empty but still have their original content. This
scheme has been used with previous transitional packages: tesla-450 ->
tesla-470, tesla-460 -> tesla-450, tesla-510 -> tesla.)

[ Impact ]
nvidia-graphics-drivers-tesla is currently unusable in stable due to the
module build regression in the point release last weekend..

[ Tests ]
Would require use of nvidia hardware and driver.
Intial installation tests were done, more installation and upgrade tests
with piuparts will follow once the package is in proposed-updates.

[ Risks ]
The transitional packages need to be checked thoroughly, there were
still some dependency issues with -6 in sid.

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

[ Changes ]
This package update contains the changes from
src:nvidia-graphics-drivers 525.147.05-6~deb12u1 and then turning the
packages into transitionals.

nvidia-graphics-drivers-tesla (525.147.05-7~deb12u1) bookworm; urgency=medium

  * Rebuild for bookworm.

 -- Andreas Beckmann   Wed, 14 Feb 2024 17:43:16 +0100

nvidia-graphics-drivers-tesla (525.147.05-7) unstable; urgency=medium

  * Relax the dependencies on libnvidia*-glcore/libnvidia*-eglcore for the
transitional packages.

 -- Andreas Beckmann   Wed, 14 Feb 2024 16:14:35 +0100

nvidia-graphics-drivers (525.147.05-7) UNRELEASED; urgency=medium

  * nvidia-detect: Fix mismerge breaking Tesla 470 detection.
  * Relax dh-dkms build-dependency, satisfied in stable.

 -- Andreas Beckmann   Wed, 14 Feb 2024 12:46:50 +0100

nvidia-graphics-drivers (525.147.05-6~deb12u1) bookworm; urgency=medium

  * Rebuild for bookworm.

 -- Andreas Beckmann   Sun, 11 Feb 2024 02:35:05 +0100

nvidia-graphics-drivers (525.147.05-6) unstable; urgency=medium

  * Apply pfn_valid patch from gentoo to fix kernel module build for
Linux 6.1.76, 6.6.15, 6.7.3, 6.8.  (Closes: #1063363, #1062932)
  * nvidia-detect: Tesla and regular driver packages have been merged.
  * nvidia-detect: Add superficial autopkgtest for checking codename support.
  * Update lintian overrides.

 -- Andreas Beckmann   Fri, 09 Feb 2024 20:43:30 +0100

nvidia-graphics-drivers-tesla (525.147.05-6) unstable; urgency=medium

  * Turn metapackages into transitional packages to aid switching to
nvidia-graphics-drivers.
  * Provide less virtual packages.
  * Remove the Tesla driver from the nvidia alternative.

 -- Andreas Beckmann   Sun, 04 Feb 2024 00:06:52 +0100

nvidia-graphics-drivers-tesla (525.147.05-5) unstable; urgency=medium

  * Rebuild as Tesla driver.

 -- Andreas Beckmann   Thu, 25 Jan 2024 21:46:30 +0100

nvidia-graphics-drivers (525.147.05-5) unstable; urgency=medium

  * Switch src:nvidia-graphics-drivers to the Tesla driver series.
  * Build for ppc64el.
  * Build all unversioned packages from src:nvidia-graphics-drivers.
  * Enable nvidia-suspend-common.  (Closes: #1059581, #1056557, #1062281)
  * nvidia-suspend-common: Depend on kbd for chvt.  (Closes: #1058081)
  * New Romanian (ro) debconf translations by Remus-Gabriel Chelu.
(Closes: #1059590)

 -- Andreas Beckmann   Tue, 23 Jan 2024 18:13:36 +0100

 debian/README.source   |  63 ++-
 debian/bug-control.mk  |   4 +-
 debian/changelog   | 211 --
 debian/control | 162 +---
 debian/control.in  | 295 +++---
 debian/control.md5sum  |   8 +-
 debian/control.models  |   2 +-
 debian/copyright   |   7 +-
 debian/detect/nvidia-418.ids   | 304 --
 debian/detect/nvidia-470.ids   | 439 -
 debian/detect/nvidia-detect.in | 119 +++---
 debian/detect/nvidia-tesla.ids | 370 -
 debian/gbp.conf|   2 +-
 debian/libnvidia-eglcore.lintian-overrides.in  |   1 +
 debian/libnvidia-glcore.lintian-overrides.in   |   1 +
 debian/not-installed.in|   9 +-
 debian/nvidia-alternative.postinst.in  |   2 +-
 debian/nvidia-alternative.preinst.in   |   7 +
 debian/nvidia-detect.install   |   5 +-
 debian/nvidia-suspend-common.lintian-overrides |   3 -
 debian/nvidia.NEWS |  25 ++
 

Bug#877016: Time to drop cpufrequtils?

[Boyuan Yang]

X-Debbugs-CC: kkama...@gmail.com

Hi,

Reading all comments in https://bugs.debian.org/877016 , I think a proper step 
might
be orphaning the package so that those who really want to do something on top 
of the
dead upstream codebase can get get code modifications packaged.

Please let me know asap if you have any comments or objections on that; 
otherwise
I expect do mark the package as orphaned after 1 month of time.

Thanks,
Boyuan Yang


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

Bug#1063913: mutt: background_edit and sidebar_visible changes lead to corrup screen

[Lionel Elie Mamane]

Package: mutt
Version: 2.2.12-0.1
Severity: normal

:set background_edit
:set sidebar_visible
# start a new message; invoke "mail" or "reply" or "group-reply" or ...
# actually enter edition of the message with external editor,
# not merely mutt Compose screen
q # press q to background the message edition - invoke exit
:unset sidebar_visible
B # press B to invoke background-compose-menu
# select the backgrounded message edition if necessary
# this enters the mutt Compose screen

The left part of the Compose screen is garbled (the sidebar is
superimposed upon the Compose screen). Pressing ^L does not solve the
issue. On has to:

:set sidebar_visible

and then after exiting the Compose screen (sending the message or
aborting it or postponing it), again a second time

:set sidebar_visible


-- Package-specific info:
Mutt 2.2.12 (2023-09-09)
Copyright (C) 1996-2023 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 5.10.0-27-amd64 (x86_64)
ncurses: ncurses 6.2.20201114 (compiled with 6.4)
libidn2: 2.3.0 (compiled with 2.3.4)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 13.2.0-3' 
--with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-13 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--enable-libphobos-checking=release --with-target-system-zlib=auto 
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/reproducible-path/gcc-13-13.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/reproducible-path/gcc-13-13.2.0/debian/tmp-gcn/usr
 --enable-offload-defaulted --without-cuda-driver --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu 
--with-build-config=bootstrap-lto-lean --enable-link-serialization=3
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Debian 13.2.0-3) 

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
'--includedir=${prefix}/include' '--mandir=${prefix}/share/man' 
'--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
'--libdir=${prefix}/lib/x86_64-linux-gnu' --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking 
--with-mailpath=/var/mail --enable-compressed --enable-debug --enable-fcntl 
--enable-hcache --enable-gpgme --enable-imap --enable-smtp --enable-pop 
--enable-sidebar --enable-dotlock --disable-fmemopen --with-curses 
--with-gnutls --with-gss --with-idn2 --with-mixmaster --with-gsasl 
--without-gdbm --without-bdb --without-qdbm --with-tokyocabinet 
build_alias=x86_64-linux-gnu 'CFLAGS=-g -O2 
-ffile-prefix-map=/build/reproducible-path/mutt-2.2.12=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-ffile-prefix-map=/build/reproducible-path/mutt-2.2.12=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  -USE_SASL  +USE_GSASL  +USE_GSS  
+HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  +HAVE_FUTIMENS  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  
+HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  -HAVE_LIBIDN  +HAVE_LIBIDN2  +HAVE_GETSID  
+USE_HCACHE  
+USE_SIDEBAR  +USE_COMPRESSED  +USE_INOTIFY  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"

To 

Bug#1062343: htmlcxx: NMU diff for 64-bit time_t transition

[Stephen Kitt]

On Wed, 14 Feb 2024 09:48:05 +0100, Adrien Nader  wrote:
> On Wed, Feb 14, 2024, Stephen Kitt wrote:
> > Would it be possible to re-run the analysis on htmlcxx with 0.87-4?  
> 
> I ran the analysis again but since the new package wasn't being picked
> up yet, I added the change as a quirk to the analysis script. The ABI
> isn't impacted by time_t nor LFS and I'm therefore also closing this
> issue. Thanks for also fixing the issue in the package!
> 
> Like I said in the other issue, consolidated results will not be
> available immediately but only in a couple days.

Fantastic, thanks for the quick turnaround on both issues!

Regards,

Stephen


pgpmCA4FJJySm.pgp
Description: OpenPGP digital signature

Bug#1063912: ITP: pass-extension-update -- pass extension that provides an easy flow for updating passwords

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: pass-extension-update
  Version : 2.1
  Upstream Contact: Alex roddhjav
* URL : https://github.com/roddhjav/pass-update
* License : GPL-3
  Programming Lang: Shell
  Description : pass extension that provides an easy flow for updating 
passwords

pass update extends the pass utility with an update command providing
an easy flow for updating passwords. It supports path, directory and
wildcard update. Moreover, you can select how to update your passwords
by automatically generating new passwords or manually setting your
own.

pass update assumes that the first line of the password file is the
password and so only ever updates the first line unless the
--multiline option is specified.

By default, pass update prints the old password and waits for the user
before generating a new one. This behaviour can be changed using the
provided options.



I need something like this for work so I'll take a look at how
reasonable this is. There's already a Debian package in the upstream
source too.$

Bug#889036: kazam: When selecting an area, the screen is greyed-out

[Wookey]

I just tried this software and got the same problem. This is on Debian 12 
(bookworm). My desktop is xfce. It does not have a compositor running. (I had 
to turn the compositor off because it gives me serious tearing/flashing/sync 
issues with any window that isn't firefox).

I did not get a warning about a compositor when running it from a console. I do 
get this on startup:
$ kazam
WARNING Kazam - Failed to correctly detect operating system.
/usr/lib/python3/dist-packages/kazam/app.py:145: Warning: value "((GtkIconSize) 
32)" of type 'GtkIconSize' is invalid or out of range for property 'icon-size' 
of type 'GtkIconSize'
  self.builder.add_from_file(os.path.join(prefs.datadir, "ui", "kazam.ui"))

(kazam:3156444): Gtk-WARNING **: 18:52:04.693: Can't set a parent on widget 
which has a parent

(kazam:3156444): Gtk-WARNING **: 18:52:04.702: Can't set a parent on widget 
which has a parent

There are no further messages when blindly selecting the window.

The recording 'per window' does not work. I get a black screen with the mouse 
cursor on it and many ghosts of the cursos as it moves about. Nothing in the 
actual window is recorded. 

Recording of the whole screen _does_ work, but it only records the top
left-hand quarter of the screen. This will be an issue with the hidpi screen 
and the
fact that GDK_SCALE=2. That should be a different bug report.


Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1062567: libpg-query: NMU diff for 64-bit time_t transition

[Steve Langasek]

Hi again,

On Mon, Feb 05, 2024 at 02:46:35PM +0100, Christoph Berg wrote:
> Control: tags -1 = moreinfo

> Re: Steve Langasek
> > If you have any concerns about this patch, please reach out ASAP.  Although
> > this package will be uploaded to experimental immediately, there will be a
> > period of several days before we begin uploads to unstable; so if 
> > information
> > becomes available that your package should not be included in the 
> > transition,
> > there is time for us to amend the planned uploads.

> I just found out that libpg-query is included because it was thought
> to be "uninstallable":

> https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/logs/libpg-query-dev/apt.log

> [2024-01-20T03:02:49+00:00] apt-get install libpg-query-dev libprotobuf-c-dev 
> postgresql-server-dev-15 abi-compliance-checker
> E: Unable to locate package postgresql-server-dev-15

> I think that's bogus, the package has not been depending on PG15 for
> some time.

> Please exclude it from the NMUs.

> Also, why did I not get a bug for that? I understand that you can't
> look at 1500 packages individually, but checking the 40-something on the
> https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/summary/results_uninstallable.txt
> list would surely have been possible?

This uninstallability got addressed in a refreshed run, and libpg-query-dev
now shows as its ABI affected by time_t.

So unfortunately it does appear this package needs to be included in the
transition.

https://adrien.dcln.fr/misc/armhf-time_t/2024-02-09T15%3A12%3A00/compat_reports/libpg-query-dev/lfs_to_time_t/compat_report.html

(and fwiw even if this is a false positive, it also shows up as having an
ABI that's sensitive to LFS:
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-09T15%3A12%3A00/compat_reports/libpg-query-dev/base_to_lfs/compat_report.html)

postgresql-server-dev-16 also shows up as impacted by LFS but the output is
confusing, mentioning only redefinitions of constants from perl and python
headers, why should those have disappeared based on defining LFS flags?  The
changes are suspicious enough that I'm not prepared to conclusively declare
it a false positive.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#982776: mpdtoys: mpfade does not work for a stopped MPD server with PulseAudio output

[Boyuan Yang]

Hi,

On Sun, 14 Feb 2021 05:21:46 -0500 Asher Gordon  wrote:
> Package: mpdtoys
> Version: 0.25.0
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: Asher Gordon 
> 
> Dear Maintainer,
> 
> I have configured my MPD daemon to output through PulseAudio (the PA
> server is running as my local user). After doing so, when the daemon is
> stopped (no song playing or paused), the volume displays as 'n/a' in
> 'mpc status' and is returned as undef by the 'volume' method of the
> Audio::MPD::Common::Status class in the Audio::MPD Perl library. I'm not
> sure why this is--possibly due to a limitation in the PulseAudio
> interface--but it breaks mpfade when the MPD daemon is stopped. mpfade
> thinks the volume was changed manually, even though it wasn't, and thus
> exits erroneously.
> 
> Here is the exact message:
> 
> $ mpfade 0.5 100
> fading up from 0 to 100 over 30 seconds
> manual volume change, aborting fade up
> 
> I've written a patch to fix this problem. Unfortunately, it's a bit of a
> hack, but it should work. I took the liberty of adding a
> debian/changelog entry in my name, but of course, feel free to put my
> name in brackets and change the name at the bottom. The patch is as
> follows:

Please contact the mpdtoys upstream author directly. Since mpdtoys package
is not being actively monitored in Debian, forwarding your patch to upstream
will gain more possibility in having your fix merged.

Thanks,
Boyuan Yang


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

Bug#1062259: libcomps: NMU diff for 64-bit time_t transition

[Steve Langasek]

On Wed, Feb 07, 2024 at 08:05:52PM +, Holger Levsen wrote:
> On Wed, Feb 07, 2024 at 04:25:17PM +, Luca Boccassi wrote:
> > Control: tags -1 -pending
> > Control: close -1
> [...]
> > There are no mentions of 'time_t' in the public headers of this
> > library. The logs shows that it's a false positive, as the automated
> > tool simply wasn't able to build it:
> [...] 
> > Closing as not applicable.

> thanks for closing this bug and thanks for the t64 transition in the first 
> place!
> that said, someone needs to request the removal of src:libcomps from 
> experimental
> now, and if this would only affect src:libcomps I would probably do that 
> myself,
> but knowing there are several many cases of this: please also request removal 
> of
> those packages from experimental which were accidently uploaded there! thanks 
> for
> that too & already!

Well, these packages will be garbage collected from experimental upon the
next upload of a package to unstable or experimental with a higher version;
so this is a low priority vs the work to actually get the transition done
successfully.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1062320: libgpiod: NMU diff for 64-bit time_t transition

[Steve Langasek]

Hello,

On Thu, Feb 08, 2024 at 11:13:51PM +0800, 賴建宇 wrote:
> Hi Steve,

> I am working on upgrading the libgpiod version, so I also took time to
> investigate this 64-bit time_t topic.

> I noticed that the libgpiod2.symbols and libgpiod2t64.symbols are identical
> in the debdiff file. I am wondering if it is necessary to rename this
> package in this case. Please correct me if I miss anything.

> Thanks for your great effort.

This report explains:

https://adrien.dcln.fr/misc/armhf-time_t/2024-02-03T09%3A18%3A00/compat_reports/libgpiod-dev/lfs_to_time_t/compat_report.html

There are ABI changes that do not show up in the type signatures of C++
functions and therefore do not affect C++ symbol mangling.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1062012: libwebkit2gtk-4.1-0: Video playback is buggy, particularly after seeking or resuming

[erusan]

Same bug.

Reportbug crashed when I sent the first one, but apparently it went
through after all.

On Wed, 2024-02-14 at 16:24 +, Alberto Garcia wrote:
> On Tue, Jan 30, 2024 at 04:54:16PM -0500, erusan wrote:
> > Package: libwebkit2gtk-4.1-0
> > Version: 2.42.4-1
> > Severity: normal
> > X-Debbugs-Cc: eru...@gmail.com
> > 
> > Dear Maintainer,
> > 
> > Video playback is buggy on many (all?) sites, with regular YouTube
> > and Odysee use confirming this issue.
> 
> Hello, what is the difference between this and #1062009 ? ("Video
> streaming sites seem to have all sorts of problems. Odysee.com,
> YouTube, others.")
> 
> Berto

Bug#1063907: time_t 64bit transition

[Michael Fladischer]

I was also affected by this error. I think it has to do with the recent 
time_t transition in experimental. I had libapt-pkg6.0t64:riscv64 
2.7.10+nmu1~exp1 installed before.

Bug#1063911: davmail-server.service fails in a LXC container

[Mark Gardner]

Package: davmail-server
Version: 6.0.1.3390-7
Severity: wishlist
X-Debbugs-Cc: none, m...@vt.edu

Dear Maintainer,

The issue is repeatable with a fresh install of a Debian 12 LXC container:

$ lxc launch images:debian/12 davmail-bug
$ lxc exec davmail-bug bash

# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;

# apt-get install less man zile curl reportbug ca-certificates
openjdk-17-jre-headless davmail-server
# cp -p /etc/davmail/davmail.properties /etc/davmail/davmail.properties.orig
# patch 

Bug#1063707: liblua5.4-0: C++ library missing all "lua*" function symbols

[P. J. McDermott]

Control: tags -1 - patch

After submitting the aforementioned merge request (and another one with
other improvements including CI pipelines), I see now that the patch
removal was intentional:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032533

On 2023-03-08 at 14:44, Jackson wrote:
> This patchfile undermines that Lua can be built as C++ to manage unwinding
> exceptions; according to the date, it has been in the Debian Lua repository 
> for
> over seven years. For example, future releases of MAME (package: mame) will
> break using USE_SYSTEM_LUA_LIB if this fallacy not resolved, since they link
> their own copy.

I'm not sure what this bug report is trying to say or how `extern "C"`
(simply preventing C++ name mangling) could undermine or break anything
in what is really a C library (C symbol names, just compiled to throw
and catch C++ exceptions).  (Does MAME link against both a system C++
Lua and its own C Lua copy?)  But whatever.

And from https://salsa.debian.org/lua-team/lua5.4/-/merge_requests/4#note_444235
> With this we found that the current c++ library in sid is probably broken 
> (and unused since nobody complained so far)

Yes, it is broken, but I'm trying to use it for the upcoming
wesnoth-1.18 which can now use a system copy of Lua (after over a month
of work toward that goal):
https://github.com/wesnoth/wesnoth/pull/8234

Since lua5.4 was promoted to Ubuntu main in 23.10 and Wesnoth now uses
Lua without modifications, the goal is for wesnoth-1.18 to use the
lua5.4 package supported in Ubuntu main (instead of Wesnoth's embedded
code copy stuck in universe) before the Ubuntu Noble Debian Import
Freeze on 2024-02-29.  So I hope this can somehow be fixed well before
then (wesnoth-1.18 still has to go through NEW before that date).

I found that the reason it is broken with `extern "C"` removed and name
mangling newly enabled is that debian/patches/0001-build-system.patch
links using the export map debian/version-script which doesn't list
the C++ symbols.  Adding the C++ symbols to debian/version-script and
debian/liblua5.4-0.symbols as I attempted in the updated merge requests
would fix this, however C++ symbol names are architecture-specific.
So we'll have to either collect arch-specific names with `(arch=foo)`
tags[1] (by making buildds fail for a while[2]) or switch to using
shlibs[3].  The wiki recommends shlibs: "For C++ libraries it is often
better not to ship symbols files."[1]  Sounds good, especially since
going through multiple uploads and waiting for buildds to fail would
take time.  Except switching to shlibs means losing the version
information noting that the mangled symbols didn't exist before now,
so users who install a package (that uses the C++ library's mangled
symbols) without updating liblua5.4-0 will see run-time linker errors.
To solve that, we need to also bump the C++ library's SONAME version
(which is appropriate anyway, given that the ABI completely changed).
So unless you disagree (or beat me to it), I'll work on switching to
shlibs and bumping the SONAME version.

Restoring `extern "C"` would avoid all this mess and keep the previous
unmangled symbols in case anyone was using the C++ library before now.
But the previous bug report claims that this breaks something (so let's
break everything else instead).

[1]: https://wiki.debian.org/UsingSymbolsFiles#C.2B-.2B-_libraries
[2]: https://www.eyrie.org/~eagle/journal/2012-01/008.html
[3]: https://www.eyrie.org/~eagle/journal/2012-02/001.html
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1063910: nvidia-detect fails to detect 470-series devices

[John Bazik]

Package: nvidia-detect
Version: 525.147.05-6~deb12u1
Severity: normal

Dear Maintainer,

$ grep 10DE128B /usr/share/nvidia/*.ids
/usr/share/nvidia/nvidia-legacy-390xx.ids:10DE128B
/usr/share/nvidia/nvidia-tesla-418.ids:10DE128B
/usr/share/nvidia/nvidia-tesla-440.ids:10DE128B
/usr/share/nvidia/nvidia-tesla-450.ids:10DE128B
/usr/share/nvidia/nvidia-tesla-460.ids:10DE128B
/usr/share/nvidia/nvidia-tesla-470.ids:10DE128B
$ nvidia-detect 10DE128B
Checking driver support for PCI ID [10de:128B]
Your card is only supported by the Tesla 418 drivers series, which is only 
available up to bullseye.

In the script, it looks like VERSIONS[471] is set, but never checked.  
Incomplete merge of tesla ids?

-- Package-specific info:
uname -a:
Linux asdf 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) 
x86_64 GNU/Linux

/proc/version:
Linux version 6.1.0-18-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  525.147.05  Wed Oct 25 20:27:35 
UTC 2023
GCC version:  gcc version 12.2.0 (Debian 12.2.0-14) 

lspci 'display controller [030?]':
26:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP108 [GeForce GT 
1030] [10de:1d01] (rev a1) (prog-if 00 [VGA controller])
Subsystem: eVga.com. Corp. GP108 [GeForce GT 1030] [3842:6339]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 Feb 12 18:07 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Feb 12 18:07 /dev/dri/renderD128
crw-rw-rw-  1 root root   195, 254 Feb 12 18:07 /dev/nvidia-modeset
crw-rw-rw-  1 root root   195,   0 Feb 12 18:07 /dev/nvidia0
crw-rw-rw-  1 root root   195, 255 Feb 12 18:07 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Feb 12 18:07 pci-:26:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Feb 12 18:07 pci-:26:00.0-render -> ../renderD128
video:x:44:

Alternative 'nvidia':
nvidia - auto mode
  link best version is /usr/lib/nvidia/current
  link currently points to /usr/lib/nvidia/current
  link nvidia is /usr/lib/nvidia/nvidia
  slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
  slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
  slave nvidia--libcuda.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so
  slave nvidia--libcuda.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so.1
  slave nvidia--libglxserver_nvidia.so is /usr/lib/nvidia/libglxserver_nvidia.so
  slave nvidia--libnvidia-cfg.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
  slave nvidia--libnvidia-ml.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so
  slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1
  slave nvidia--libnvidia-ptxjitcompiler.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ptxjitcompiler.so.1
  slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nvidia.so.1
  slave nvidia--nv-control-dpy is /usr/bin/nv-control-dpy
  slave nvidia--nvidia-application-profiles-key-documentation is 
/usr/share/nvidia/nvidia-application-profiles-key-documentation
  slave nvidia--nvidia-blacklists-nouveau.conf is 
/etc/nvidia/nvidia-blacklists-nouveau.conf
  slave nvidia--nvidia-bug-report.sh is /usr/lib/nvidia/nvidia-bug-report.sh
  slave nvidia--nvidia-debugdump is /usr/bin/nvidia-debugdump
  slave nvidia--nvidia-drm-outputclass.conf is 
/etc/nvidia/nvidia-drm-outputclass.conf
  slave nvidia--nvidia-load.conf is /etc/nvidia/nvidia-load.conf
  slave nvidia--nvidia-modprobe.conf is /etc/nvidia/nvidia-modprobe.conf
  slave nvidia--nvidia-options.conf is /etc/modprobe.d/nvidia-options.conf
  slave nvidia--nvidia-settings is /usr/bin/nvidia-settings
  slave nvidia--nvidia-settings.1.gz is /usr/share/man/man1/nvidia-settings.1.gz
  slave nvidia--nvidia-settings.desktop is 
/usr/share/applications/nvidia-settings.desktop
  slave nvidia--nvidia-smi is /usr/bin/nvidia-smi
  slave nvidia--nvidia-smi.1.gz is /usr/share/man/man1/nvidia-smi.1.gz
  slave nvidia--nvidia_drv.so is /usr/lib/nvidia/nvidia_drv.so
/usr/lib/nvidia/current - priority 525
  slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libEGL_nvidia.so.0
  slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGLX_nvidia.so.0
  slave nvidia--libcuda.so-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libcuda.so
  slave nvidia--libcuda.so.1-x86_64-linux-gnu: 

Bug#962786: Are you still working on pcpp?

[Alastair McKinstry]

Hi

Just checking again. Do you mind if I upload python3-pcpp?

Thanks

Alastair

On 01/02/2024 14:55, Alastair McKinstry wrote:

Hi,

I need pcpp for my own package "loki-ecmwf".

I have it ready to upload if you have no interest anymore.

Best regards

Alastair


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

Bug#1058740: gtk4,librsvg: big-endian support is at risk of being removed

[Gayathri Berli]

Hi Simon,

I am working As a Debian maintainer on s390x in IBM. Sorry I missed out this 
bug because I am engaged with the other issues like librsvg related.
In librsvg also we have seen some test failures and regressions. when we 
debugged, we came to know that pixman code changes are triggering the 
regression in librsvg. In the current issue of gtk4 When I tried to reproduce 
the issue on s390x there are 1507 tests that are failing. Can you please 
suggest that version of dependency packages being used/issue reproduce 
steps/logs.

Log:
Ok:38
Expected Fail:0
Fail:1507
Unexpected Pass:  0
Skipped: 1
Timeout: 0


Thanks,
Gayathri.

Bug#1062012: libwebkit2gtk-4.1-0: Video playback is buggy, particularly after seeking or resuming

[Alberto Garcia]

On Tue, Jan 30, 2024 at 04:54:16PM -0500, erusan wrote:
> Package: libwebkit2gtk-4.1-0
> Version: 2.42.4-1
> Severity: normal
> X-Debbugs-Cc: eru...@gmail.com
> 
> Dear Maintainer,
> 
> Video playback is buggy on many (all?) sites, with regular YouTube
> and Odysee use confirming this issue.

Hello, what is the difference between this and #1062009 ? ("Video
streaming sites seem to have all sorts of problems. Odysee.com,
YouTube, others.")

Berto

Bug#1063907: apt: symbol lookup error

[Julian Andres Klode]

Control: tag -1 unreproducible

On Wed, Feb 14, 2024 at 04:22:21PM +0100, Michael Ott wrote:
> Package: apt
> Version: 2.7.11
> Severity: important
> 
> Dear Maintainer,
> 
> after update apt I got the following error:
> apt autoremove --purge
> apt: symbol lookup error: /lib/x86_64-linux-gnu/libapt-private.so.0.0:
> undefined symbol: _ZNK11pkgDepCache14PhasingAppliedEN8pkgCache11PkgIteratorE,
> version APTPKG_6.0

I'm afraid something on your system is messed up, but I don't see
how this can be a bug in apt.

This should not be possible, the apt binary and libapt-private
are in the same binary package (apt), and that Depends on libapt-pkg6.0
(>= 2.7.11) which adds the symbol.

The autopkgtests have passed, it runs on my (Ubuntu) system, and
works fine in a clean OCI container:

root@b6047fa9374e:/#  apt autoremove --purge
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1063905: mksh: /usr/bin/mksh and /usr/bin/mksh-static are no longer in /etc/shells

[Thorsten Glaser]

close 1063905
thanks
and keep it closed

Vincent Lefevre dixit:
>On 2024-02-14 15:22:43 +, Thorsten Glaser wrote:
>> Vincent Lefevre dixit:
>>
>> >/usr/bin/mksh and /usr/bin/mksh-static are no longer in /etc/shells:
>>
>> That’s correct. Their presence was a bug caused by add-shells
>> misbehaviour which I have worked around in maintainer scripts.

>This is not a bug in add-shell, but done on purpose as the presence
>of the real path in /etc/shells is *needed* by some programs. See

It *is* a bug in add-shell, it should never have followed
symbolic links, because they are subject to change without
notice.

>> They should never have been in there.

For example /bin/mksh-static is a symbolic link and points
to whereever works, and users who want to use this are sup‐
posed to have that symlink as shell, never the target which
can go away.

>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168

The OP’s $SHELL should not be set to /usr/bin/bash as that
value is not in /etc/shells and not its canonical path in
the first place.

The whole *purpose* of /etc/shells is to document the shells’
canonical paths that can be used as login shells for user
accounts, so therefore, the info in /etc/shells is the
primary source for the paths and must be consulted, and
whatever set the OP’s $SHELL to a different path was buggy.

For the mksh package, exactly the canonical path /bin/mksh
and, since some releases ago, /bin/mksh-static are supported
as shell entries, no other paths.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"

Bug#1042730: Follow-up on zfs-linux in bookworm-pu

[陈 晟祺]

Hi,

> Please cherry-pick a fix for this and propose a new debdiff; the upstream
> release contains too much else to be accepted.

The current version 2.1.11 of zfs-linux in bookworm suffers from CVE-2023-49298,
which leads to potential data loss. I believe Aron’s latest proposed patch 
contains some
useful stability fixes including this one. Would there be any follow-up on this 
bug?
Or do we need to further narrow down the patch for it to be accepted?

Thanks,
Shengqi Chen

Bug#1063908: node-jupyter-widgets-{base,base-manager,control}: ships files already in python3-widgetsnbextension

[Andreas Beckmann]

Package: 
node-jupyter-widgets-base,node-jupyter-widgets-base-manager,node-jupyter-widgets-controls
Version: 6.0.7+~cs14.23.94-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../node-jupyter-widgets-base_6.0.7+~cs14.23.94-1_all.deb 
...
  Unpacking node-jupyter-widgets-base (6.0.7+~cs14.23.94-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/node-jupyter-widgets-base_6.0.7+~cs14.23.94-1_all.deb 
(--unpack):
   trying to overwrite '/usr/share/nodejs/@jupyter-widgets/base/css/index.css', 
which is also in package python3-widgetsnbextension 8.1.1-2
  Errors were encountered while processing:
   /var/cache/apt/archives/node-jupyter-widgets-base_6.0.7+~cs14.23.94-1_all.deb
 

cheers,

Andreas


python3-widgetsnbextension=8.1.1-2_node-jupyter-widgets-base=6.0.7+~cs14.23.94-1.log.gz
Description: application/gzip

Bug#1063905: mksh: /usr/bin/mksh and /usr/bin/mksh-static are no longer in /etc/shells

[Vincent Lefevre]

Control: reopen 1063905

On 2024-02-14 15:22:43 +, Thorsten Glaser wrote:
> Vincent Lefevre dixit:
> 
> >/usr/bin/mksh and /usr/bin/mksh-static are no longer in /etc/shells:
> 
> That’s correct. Their presence was a bug caused by add-shells
> misbehaviour which I have worked around in maintainer scripts.
> They should never have been in there.

This is not a bug in add-shell, but done on purpose as the presence
of the real path in /etc/shells is *needed* by some programs. See

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1062756: initramfs-tools: fix compatibility with libpam-tmpdir and /tmp mounted with noexec

[Patrick Schleizer]

bug report / feature request:

Dear maintainer,

could you fix initramfs-tools compatibility with libpam-tmpdir and /tmp 
mounted with noexec please?


Cheers,
Patrick

Bug#1063888: Update on bug 1063888

[Shengqi Chen]

Hi Steve,

I downloaded the (seemingly latest) dump result from [1]. And you script gives:

harry@harry-nuc:~/Workspace/armhf-time_t$ ./diff_package.sh libzfslinux-dev
[2024-02-14T23:57:33+08:00] => libzfslinux-dev: base=>lfs, lfs=>time_t
[2024-02-14T23:57:34+08:00] <= libzfslinux-dev: lfs=false, time_t=false

Does this mean zfs-linux is actually not affected by this transition?

[1]: 
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-09T15%3A12%3A00/dumps/libzfslinux-dev.dump.tar.xz

Thanks,
Shengqi Chen

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Dirk Hünniger]

Hi,

Ok.

So if I understood correctly all that has to be done is to add an 
architecture qualifier. And the person who has can do it is Georges. So 
I herewith ask him to do so.


Yours Dirk

On 14.02.24 16:58, Paul Gevers wrote:

Hi,

On 14-02-2024 16:53, Dirk Hünniger wrote:
If it helps to change the dependency to chromium and chromium-sandbox 
from Depends to Recommends I would like to ask Georges to do so.


If you think the Depends is best, make it conditional on the 
architecture, because ideally also Recommends can be installed (so 
would benefit from the architecture qualifier).


Paul

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Paul Gevers]

Hi,

On 14-02-2024 16:53, Dirk Hünniger wrote:
If it helps to change the dependency to chromium and chromium-sandbox 
from Depends to Recommends I would like to ask Georges to do so.


If you think the Depends is best, make it conditional on the 
architecture, because ideally also Recommends can be installed (so would 
benefit from the architecture qualifier).


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Dirk Hünniger]

Hi Paul,

thank you for the explanation. So the dependency on chromium is the 
problem on these architectures.


Chromium is used to render tables in tables to pdf if command line 
option -a is given.


Otherwise Chromium is not used.

If it helps to change the dependency to chromium and chromium-sandbox 
from Depends to Recommends I would like to ask Georges to do so.


Yours Dirk

On 14.02.24 16:47, Paul Gevers wrote:

Hi,

On 14-02-2024 14:27, Georges Khaznadar wrote:
At the same time, 
https://buildd.debian.org/status/package.php?p=mediawiki2latex

says that the package could be installed,


I understand the confusing but the word "installed" on buildd.d.o 
means something else than that you can install the binaries. It means 
that the packages were incorporated (installed) into the archive.



so its runtime dependencies
are correct, on architectures: amd64, arm64, armel, armhf, i386, 
mips64el,

ppc64el, riscv64, s390x, alpha, hurd-i386, ia64, ppc64, sparc64.


Maybe you can try to install the binaries in a clean environment (I've 
done so, pasted below).


Paul

root@autopkgtest-lxc-vtalsf:/tmp/autopkgtest-lxc.c47fu43n/downtmp/build.Nel/src# 
apt install mediawiki2latex

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 mediawiki2latex : Depends: chromium but it is not installable
   Depends: chromium-sandbox but it is not installable
   Recommends: calibre but it is not going to be 
installed
   Recommends: latex2rtf but it is not going to be 
installed
   Recommends: libreoffice but it is not going to be 
installed

E: Unable to correct problems, you have held broken packages.

Bug#1063897: firefox: poor performance compared to vendor package

[Sylvestre Ledru]

Le 14/02/2024 à 13:00, Lorenzo Bertini a écrit :

Package: firefox
Version: 122.0.1-1
Severity: normal
X-Debbugs-Cc: lorenzobertin...@gmail.com

Dear Maintainer,

Firefox on debian (both ESR and sid versions) is performing poorly. Here are the
results on one of my machines, but it's consistent with all the others:

Test: Browserbench Speedometer 2.1 (https://browserbench.org/Speedometer2.1)

Gentoo: 290 (+65%)
Debian sid with vendor package: 260 (+50%)
Debian sid firefox: 175 (-)
Debian sid firefox-esr: 160 (-10%)

Upon inspection, I think the cause is the optimization flags, including LTO, 
PGO, O3.
Please take this report in consideration, as the performance increase is 
massive.


it is expected and why Mozilla is providing a Debian package now

Cheers

Sylvestre

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Paul Gevers]

Hi,

On 14-02-2024 14:27, Georges Khaznadar wrote:

At the same time, https://buildd.debian.org/status/package.php?p=mediawiki2latex
says that the package could be installed,


I understand the confusing but the word "installed" on buildd.d.o means 
something else than that you can install the binaries. It means that the 
packages were incorporated (installed) into the archive.



so its runtime dependencies
are correct, on architectures: amd64, arm64, armel, armhf, i386, mips64el,
ppc64el, riscv64, s390x, alpha, hurd-i386, ia64, ppc64, sparc64.


Maybe you can try to install the binaries in a clean environment (I've 
done so, pasted below).


Paul

root@autopkgtest-lxc-vtalsf:/tmp/autopkgtest-lxc.c47fu43n/downtmp/build.Nel/src# 
apt install mediawiki2latex

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 mediawiki2latex : Depends: chromium but it is not installable
   Depends: chromium-sandbox but it is not installable
   Recommends: calibre but it is not going to be installed
   Recommends: latex2rtf but it is not going to be 
installed
   Recommends: libreoffice but it is not going to be 
installed

E: Unable to correct problems, you have held broken packages.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063905: mksh: /usr/bin/mksh and /usr/bin/mksh-static are no longer in /etc/shells

[Thorsten Glaser]

Dixi quod…

>Vincent Lefevre dixit:
>
>>/usr/bin/mksh and /usr/bin/mksh-static are no longer in /etc/shells:
>
>That’s correct. Their presence was a bug caused by add-shells
>misbehaviour which I have worked around in maintainer scripts.
>They should never have been in there.

I should perhaps note that their presence only occurred when
using a nōn-standard filesystem layout not supported by dpkg
anyway.

On a proper Debian bullseye system, /etc/shells contains…

/bin/mksh
/bin/mksh-static
/usr/lib/klibc/bin/mksh-static

… the latter caused by the same bug. The intended amount
of entries for mksh is:

/bin/mksh
/bin/mksh-static

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Bug#1062756: cryptsetup-initramfs Debian bug with libpam-tmpdir and /tmp mounted with noexec

[Patrick Schleizer]

Ok, not a bug in cryptsetup-initramfs.

Let's reassign to initramfs-tools-core as a bug or feature request? 
(Depending on how one wanted to look at it.)


Would that be appropriate?

And also forward to upstream, which has its issue tracker hosted at 
launchpad initramfs-tools?

Bug#1063907: apt: symbol lookup error

[Michael Ott]

Package: apt
Version: 2.7.11
Severity: important

Dear Maintainer,

after update apt I got the following error:
apt autoremove --purge
apt: symbol lookup error: /lib/x86_64-linux-gnu/libapt-private.so.0.0:
undefined symbol: _ZNK11pkgDepCache14PhasingAppliedEN8pkgCache11PkgIteratorE,
version APTPKG_6.0


-- Package-specific info:

-- apt-config dump --

apt-config: symbol lookup error: /lib/x86_64-linux-gnu/libapt-private.so.0.0: 
undefined symbol: _ZNK11pkgDepCache14PhasingAppliedEN8pkgCache11PkgIteratorE, 
version APTPKG_6.0

-- System Information:
Debian Release: trixie/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64

Kernel: Linux 6.7-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt depends on:
ii  adduser   3.137
ii  base-passwd   3.6.3
ii  debian-archive-keyring2023.4
ii  gpgv  2.4.4-2
ii  libapt-pkg6.0 2.7.11
ii  libapt-pkg6.0t64 [libapt-pkg6.0]  2.7.10+nmu1~exp2
ii  libc6 2.38-6
ii  libgcc-s1 14-20240207-1
ii  libgnutls30   3.8.3-1
ii  libseccomp2   2.5.5-1
ii  libstdc++614-20240207-1
ii  libsystemd0   255.3-2

Versions of packages apt recommends:
ii  ca-certificates  20240203

Versions of packages apt suggests:
pn  apt-doc 
ii  dpkg-dev1.22.4
ii  gnupg   2.4.4-2
ii  powermgmt-base  1.37
ii  synaptic0.91.3

-- no debconf information

Bug#1063906: ITP: monitoring-plugins-check-smart -- check S.M.A.R.T. storage system monitoring plugin for nagios compatible monitoring systems

[John Lines]

Package: wnpp
Severity: wishlist
Owner: John Lines 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: monitoring-plugins-check-smart
  Version : 6.14.1
  Upstream Contact: Claudio Kuenzler
* URL : 
https://www.claudiokuenzler.com/monitoring-plugins/check_smart.php
* License : GPL
  Programming Lang: Perl
  Description : check S.M.A.R.T. storage system monitoring plugin for 
nagios compatible monitoring systems

The check_smart monitoring plugin uses smartmontools to monitor the
health of physical hard drives via a central nagios based monitoring
system.

Ideally it should be maintained within the Debian Nagios Maintainer
Group. It could alternatively be added to monitoring-plugins-contrib,
adding extra sugests for smartmontools and sudo.

Bug#1063905: mksh: /usr/bin/mksh and /usr/bin/mksh-static are no longer in /etc/shells

[Vincent Lefevre]

Package: mksh
Version: 59c-34
Severity: normal

/usr/bin/mksh and /usr/bin/mksh-static are no longer in /etc/shells:

This is an automated report from zira.
Recent changes to /etc/shells:

4 -rw-r--r-- 1 root root 325 Feb  7 11:07 /etc/shells

diff  -Ndu  /var/cache/diffmon/old_file_dir/zira:!etc!shells.gz /etc/shells
--- /tmp/diffmon60322024-02-08 07:37:34.427704557 +0100
+++ /etc/shells 2024-02-07 11:07:49.984040544 +0100
@@ -15,8 +15,6 @@
 /usr/bin/rbash
 /usr/bin/dash
 /usr/bin/zsh-static
-/usr/bin/mksh
-/usr/bin/mksh-static
 /usr/bin/yash
 /usr/bin/fish
 /bin/ksh93

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.11-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mksh depends on:
ii  libc6  2.37-15

Versions of packages mksh recommends:
ii  ed  1.20-1

mksh suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1063904: ITS: tiny-initramfs

[Victor Westerhuis]

Source: tiny-initramfs
Severity: important
X-Debbugs-Cc: christ...@iwakd.de, m...@qa.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

A bit over a week ago I filed RC bug #1063142 against tiny-initramfs,
because it failed to build working initrds for default Debian
installations. I supplied a patch in the bug report and after a few days
I uploaded a NMU with that patch to Mentors. Yesterday, the NMU was
uploaded to DELAYED/5 by Tobias Frost.

There are multiple open non-RC bugs. The oldest without maintainer
interaction is #976881, filed in December 2020. Christian Seiler is also
the upstream maintainer. His last activity at
https://github.com/chris-se/tiny-initramfs dates back to 2016. According
to https://contributors.debian.org/contributor/christian%40iwakd.de/
Christian Seiler has not been active at all in Debian since 2021, so I'm
CC'ing this ITS to the MIA team.

In 2022 I opened bug report #1018290 and I also opened 2 upstream pull
requests for new features on Github, both without response. I want to
fix that bug and I'm looking into fixing at least #976881 and #983121.
I also want to merge my and others' upstream pull requests.

To do that I want to salvage this package, fork the upstream repository,
and switch this package to the forked upstream. I have made a start at
https://salsa.debian.org/debian/tiny-initramfs/-/tree/wip/its and
https://github.com/viccie30/tiny-initramfs.

Christian: Thanks for creating and maintaining tiny-initramfs. If you
don't want me to salvage tiny-initramfs, just let me know. You're
welcome to use or discard any of the changes I've prepared so far.

- --
Vriendelijke groet, Kind regards,

Victor Westerhuis

- -- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.6.13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_NL.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US:en:nl_NL:nl
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmXM1hITHHZpY3RvckB3
ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+8Y0EACHP9Fe+2i+ZtV+eKjGnOTBlOF3jNt0
b4/+2xF0OcGAwEOEjIaSCDFTu1n3pRUtTuhOCwLzkU/IayDvpyzhVFJ5a40MATjJ
sqmc6bj8O049bUUiPpH7kXfo0KYzkspzQ3Gu5hkaqMjYNz1xAvOy/KT7xBEXeVo5
pSZL4ZLUEI22fe5LOdlF/qPFL/Rr6H8bh4RMEqBI0gYZc1a0ofXtNKucEzfUsa8d
TIvnqWwiooA3Q7Slw0a0SuGtmsj12q2qLtBK0lF9OlxY54TIgXJBGh0p9RHAU2iN
96hD+CI4+Q3ENoXaefZnbPfySm2J/sF9pQiKHlMHdbQOfieHlzvqrtxjqiLB5LYu
0ly69HYFvFqFNo5yEMKqkr7lb+WPHAU/Pz0kjhu6LrImOOTDnLtq2Pomktk8JHJw
F4hhJqvSENWjOfAPCRosW66Ci/rfOJdhRBRGrSDYPNTgr6PhePRS8QV/CTJWPQgj
UzQdmFiaomPFdNlwbFOy2speeqT0VJ2g0eXtwdaC2uikhXx7aVaxaYxl2M7kc0Ra
e4lh7IRVIiUBT5vxzBnGOLR1YGAZMHCNbb2cJIOZM+qoGDzPVr+COLSUdQ2LVF1g
V79SqakA+xPTQOGfLbJtmWu8GTXup9iYqGmby4xXdoJjwx6F+2ytkEtCcSb6imoh
KnqQe7ccnPWc0w==
=ov7w
-END PGP SIGNATURE-

Bug#1042573: Ping: Scrub still out of date

[Peter Hyman]

Should be an easy update.

--
Peter Hyman

Bug#1057145: (no subject)

[Ken Sharp]

What command are you using to run debootstrap?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063903: gi-docgen: Are -doc dependencies necessary?

[Jeremy Bícha]

Source: gi-docgen
Version: 2023.3+ds-1

When GNOME libraries used gtk-doc for their API documentation, we
needed to have Build-Depends for dependent documentation (like gtk4
might need the glib docs installed) so that the links would be
correct?

I'm filing this bug as a reminder for us to check whether those extra
dependencies can be dropped for libraries that are now using
gi-docgen.

Thank you,
Jeremy Bícha

Bug#1059385: r-cran-ggally: autopkgtest regression

[Graham Inggs]

Control: severity -1 important

r-cran-ggally's autopgktests for migration started to pass yesterday
[1].  I'm lowering the severity of this bug so that r-cran-ggally can
migrate.

Comparing the installed packages between the failing test on
2024-02-07 16:12:49 UTC and the passing test on 2024-02-12 16:17:47
UTC, it seems the difference was in the version of r-cran-withr;
2.5.2+dfsg-1 in the former, and 3.0.0+dfsg-1 in the later.

Does r-cran-ggally perhaps miss a versioned dependency on r-cran-withr?


[1] https://ci.debian.net/packages/r/r-cran-ggally/testing/ppc64el/

Bug#1062756: cryptsetup-initramfs Debian bug with libpam-tmpdir and /tmp mounted with noexec

[Guilhem Moulin]

On Wed, 14 Feb 2024 at 13:58:00 +, Patrick Schleizer wrote:
> This is not a bug in a downstream distribution.
> […]
> Could this be fixed in Debian please?

I don't see how this would be a bug in cryptsetup-initramfs when
mkinitramfs(8) explicitely says DESTDIR should not be mounted with the
noexec mount option.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1033482: debootstrap fails when invoked with --merged-usr

[Ken Sharp]

This fails on a number of host/target combinations, but not all of them.

A mips64el target, for example, fails every time.

Would the maintainer(s) prefer separate bugs for each arch? The fault(s) 
may not lie in the debootstrap package.


debootstrap 1.0.134


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063901: node-shapefile: /usr/bin/dbfcat and usr/bin/shpcat are already shipped by shapelib

[Andreas Beckmann]

Package: node-shapefile
Version: 0.3.1+~cs14.23.94-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + src:shapelib

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package node-shapefile.
  Preparing to unpack .../21-node-shapefile_0.3.1+~cs14.23.94-1_all.deb ...
  Unpacking node-shapefile (0.3.1+~cs14.23.94-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-ARoRiL/21-node-shapefile_0.3.1+~cs14.23.94-1_all.deb 
(--unpack):
   trying to overwrite '/usr/bin/dbfcat', which is also in package shapelib 
1.6.0-1
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-ARoRiL/21-node-shapefile_0.3.1+~cs14.23.94-1_all.deb

These files are in conflict:
  /usr/bin/dbfcat
  /usr/bin/shpcat

I have no idea whether the two packages provide similar functionality
or are completely unrelated and only picked the same names by chance.


cheers,

Andreas


shapelib=1.6.0-1_node-shapefile=0.3.1+~cs14.23.94-1.log.gz
Description: application/gzip

Bug#1062756: cryptsetup-initramfs Debian bug with libpam-tmpdir and /tmp mounted with noexec

[Patrick Schleizer]

This is not a bug in a downstream distribution.

To reproduce this bug in Debian:

1) sudo apt install libpam-tmpdir

2) Mount /tmp with noexec.

Could this be fixed in Debian please?

Bug#1063900: gstreamer1.0-plugins-good: missing Breaks+Replaces: gstreamer1.0-plugins-ugly (<< 1.23)

[Andreas Beckmann]

Package: gstreamer1.0-plugins-good
Version: 1.23.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
This error may also be triggered by having a predecessor package from
'sid' installed while installing the package from 'experimental'.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../gstreamer1.0-plugins-good_1.23.1-1_amd64.deb ...
  Unpacking gstreamer1.0-plugins-good:amd64 (1.23.1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/gstreamer1.0-plugins-good_1.23.1-1_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrnb.so', which is also in 
package gstreamer1.0-plugins-ugly:amd64 1.22.9-1
  Errors were encountered while processing:
   /var/cache/apt/archives/gstreamer1.0-plugins-good_1.23.1-1_amd64.deb

The following files are in conflict:

/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrnb.so
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrwbdec.so
/usr/share/gstreamer-1.0/presets/GstAmrnbEnc.prs


cheers,

Andreas


gstreamer1.0-plugins-ugly=1.22.9-1_gstreamer1.0-plugins-good=1.23.1-1.log.gz
Description: application/gzip

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Dirk Hünniger]

Hi Georges,

I think its a good idea to wait for 24 hours. I am not sure if I will be 
available during the next few weeks. So just take the decisions you 
consider useful and don't bother about me.


Yours Dirk

On 14.02.24 14:27, Georges Khaznadar wrote:

Hello Paul, Dirk,

Dirk Hünniger a écrit :

https://qa.debian.org/excuses.php?package=mediawiki2latex
says:

Issues preventing migration:

  * mediawiki2latex/armel has unsatisfiable dependency
  * mediawiki2latex/mips64el has unsatisfiable dependency
  * mediawiki2latex/s390x has unsatisfiable dependency

At the same time, https://buildd.debian.org/status/package.php?p=mediawiki2latex
says that the package could be installed, so its runtime dependencies
are correct, on architectures: amd64, arm64, armel, armhf, i386, mips64el,
ppc64el, riscv64, s390x, alpha, hurd-i386, ia64, ppc64, sparc64.

I have no precise idea about this misbehavior, unfortunately.
However the excuses page tells that the package is 5 days old (needing 5
days), maybe we should wait 24 hours longer ?

If the migrations keeps failing, I can make some trivial change and make
another source upload.

Best regards,   Georges.

Bug#1056419: Can we also move uncertainties to DPT (Was: python-hug: autopkgtest failure with Python 3.12)

[Andreas Tille]

Hi,

thanks for Federico confirming, thus I will move the package to not
need to ask again in a possible future attempt.

Am Wed, Feb 14, 2024 at 12:24:03PM +0100 schrieb Alexandre Detiste:
> Hi Andreas,
> 
> I think usage of "past" has been neutered since:
> 
> if sys.version_info < (3,):
>  from past.builtins import basestring
> else:
>  # Avoid importing from past in Python 3 since it utilizes the builtin
>  # 'imp' module, which is deprecated as of Python 3.4, see
>  # https://docs.python.org/3/library/imp.html. The 2to3 tool replaces
>  # basestring with str, so that's what we effectively do here as well:
>  basestring = str
> 
> My attempt to rebuild lmfit-py in experimental failed for another reason:
> 
> https://buildd.debian.org/status/package.php?p=lmfit-py=experimental

Thanks for the hint.  I try to seek about a solution for this sphinx issue.
 
> Le mer. 14 févr. 2024 à 12:19, Federico Ceratto  a écrit 
> :
> 
> > I'm a fan of team-maintained packages - I just set the maintainer field to 
> > DPMT in the git repo.
> 
> Thank you too

Thanks to both of you.  Its always fun to work together with you

   Andreas.

-- 
http://fam-tille.de

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Georges Khaznadar]

Hello Paul, Dirk,

Dirk Hünniger a écrit :
> https://qa.debian.org/excuses.php?package=mediawiki2latex
> says:
> 
> Issues preventing migration:
> 
>  * mediawiki2latex/armel has unsatisfiable dependency
>  * mediawiki2latex/mips64el has unsatisfiable dependency
>  * mediawiki2latex/s390x has unsatisfiable dependency

At the same time, https://buildd.debian.org/status/package.php?p=mediawiki2latex
says that the package could be installed, so its runtime dependencies
are correct, on architectures: amd64, arm64, armel, armhf, i386, mips64el,
ppc64el, riscv64, s390x, alpha, hurd-i386, ia64, ppc64, sparc64.

I have no precise idea about this misbehavior, unfortunately.
However the excuses page tells that the package is 5 days old (needing 5
days), maybe we should wait 24 hours longer ?

If the migrations keeps failing, I can make some trivial change and make
another source upload.

Best regards,   Georges.



signature.asc
Description: PGP signature

Bug#891009: debootstrap: wrongly falls back to https://deb.debian.org when try to create Ubuntu chroot

[Ken Sharp]

This should be fixed in the next release.
https://salsa.debian.org/installer-team/debootstrap/-/commit/7e5923030e331f466ec1b56d875b023a274e9220


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1040382: slapd: debian12 ships with slapd-2.5.13+dfsg-5 which crashes (segfault in dynlist.la).

[wouldsmina]

Hello Ryan,

The answer to your first question is in the title of this ticket :
(segfault in dynlist.la)

I'm afraid splge may not follow up on your request. He compiled the latest
version of OpenLdap.

On my end, I used the packages from https://ltb-project.org/ , but I would
prefer to use the version in the Debian repository.




Le mer. 24 janv. 2024 à 17:02, Quanah Gibson-Mount  a
écrit :

>
>
> --On Wednesday, January 24, 2024 3:07 PM +0100 wouldsmina
>  wrote:
>
> >
> >
> > Hello,
> >
> >
> > I am experiencing the same issue. Here are the logs I obtain in the
> > syslog:
> > 2024-01-24T09:38:16.810558+01:00 ldap kernel: [ 1553.168747]
> > slapd[13335]: segfault at 0 ip 7fc2370b49c1 sp 7fbd359fc0c0 error
> > 4 in dynlist-2.5.so.0.1.8[7fc2370b1000+6000] likely on CPU 1 (core 0,
> > socket 2)
> > 2024-01-24T09:38:16.810568+01:00 ldap kernel: [ 1553.168761] Code: 48 29
> > d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 10 02
> > 00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39
> > 73 64 74 09 45 84 e4 0f 85 22 03 00 00 48
> > 2024-01-24T09:38:16.840012+01:00 ldap slapd[13342]: Stopping OpenLDAP:
> > slapd.
> >
> >
> > To reproduce, simply activate the dynlist module and try to make an LDAP
> > query. In slapd.conf add:
> >
> > moduleload   dynlist
> > overlay dynlist
>
> Likely .
>
> --Quanah
>
>

Bug#1061802: Did Python 3.12 developers honestly broke special regexp sequences? (Was: hatop fails its autopkg tests with Python 3.12)

[Stéphane Blondon]

Hello Andreas,

On 13/02/2024 18:21, Andreas Tille wrote:

I was constantly shaking my had above bug #1061802 featuring
Syntaxwarnings like

SyntaxWarning: invalid escape sequence '\.'
573s   CLI_INPUT_RE = re.compile('[a-zA-Z0-9_:\.\-\+; /#%]')
573s /tmp/autopkgtest.G4v4eK/autopkgtest_tmp/hatop.py:215:
SyntaxWarning: invalid escape sequence '\s'
573s   'software_name':re.compile('^Name:\s*(?P\S+)'),




Python 3.12 added some SyntaxWarning when there is invalid sequences in 
a string. (If I remember correctly, it has already happened in the 
past.) It's a warning so the code should work properly.


If a string contains 'invalid sequences' (like regexp), you can declare 
it as raw string: they are prefixed with an 'r' character.


The source code should be:
'software_name':re.compile(r'^Name:\s*(?P\S+)'),


The fix comes from the second point in:
https://docs.python.org/3/whatsnew/3.12.html#other-language-changes



--
Stéphane


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1032530: (no subject)

[Ken Sharp]

If that's the case then this is working as intended.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#694886: (no subject)

[Ken Sharp]

This is an old one! Does this still occur?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#997094: debootstrap: 764:debootstrap cp "$0" "$TARGET/ instead of cp "/usr/sbin/$0" "$TARGET/

[Ken Sharp]

cp needs the fully-qualified path - not just $0/progname


I've tested this on Bash, Dash, Zsh and Tcsh on Linux and FreeBSD and 
${0} already expands to the fully-qualified path. It never expands to 
${0}/progname as that would always fail. Can you give and example of 
where this fails?



Also in functions:1520 "$2" can sometimes be set to //path which causes
the subsequent perl line to fail (difficult to reproduce) So ${2#/} worked
for me - it currently works for me with no modification.


Can you give an example of where this happens? You could also submit a 
patch if you wish.


OpenPGP_signature.asc
Description: OpenPGP digital signature