Bug#1037192: sd: version is lower than in squeeze

[Blair Noctis]

Actually the maintainer is OK with bumping to 1.0, saving the effort to go
epoch: https://github.com/chmln/sd/issues/200

I'll wait for its release. The point release is unfortunately missed, however.

-- 
Sdrager,
Blair Noctis

Bug#1038750: file.1: a few remarks and editorial fixes for the manual

[Christoph Biedl]

Control: tags 1038750 confirmed
Control: forwarded 1038750 
https://mailman.astron.com/pipermail/file/2023-July/001201.html

Bjarni Ingi Gislason wrote...

> here are some notes and fixes for the man page.

Thanks, now forwarded upstream where applicable, the rest fixed locally.

Christoph


signature.asc
Description: PGP signature

Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386

[Dirk Eddelbuettel]

On 23 July 2023 at 11:03, Dirk Eddelbuettel wrote:
| Note that the mlmRev authors / maintainers are the same as / a subset of the
| lme4 authors. They may have an idea.
| 
| https://cran.r-project.org/package=mlmRev

I just ran `R CMD check mlmRev_*tar.gz` on my amd64 (under Ubuntu 23.04), it
ran fine but also took a moment. In parallel I am also running it in a i386
Docker container for Debian unstable and that seems slow esp on the second
file tests/lmerTest.R

So if it were me I'd just skip that test file on i386 and move on.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1041787: ifupdown: networking service won't restart because eth0 has been renamed

[Daniel Essin]

Package: ifupdown
Version: 0.8.41
Severity: important
X-Debbugs-Cc: es...@ieee.org

Dear Maintainer,


   * What led up to the situation?
When my system boots, eth0 gets renamed to enp5s0
When issuing systemctl restart networking, it fails and says can't find eth0

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I made the following modification to /etc/default/grub

#GRUB_CMDLINE_LINUX=""
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

followed by:
grub-mkconfig -o /boot/grub/grub.cfg
reboot

   * What was the outcome of this action?
After preventing the renaming, systemctl restart networking succeeds

The renaming of  eth0 is apparently very common. After speding several hours
searching the web I finally hit upong the right serch terms and see that dozens
of people have questions relating the this renaming process.

Since it so common to have eth0 renamed, the networking service should be aware
of this and not fail because it can't find eth0. It should, instead, be able to
detect the presence of the alias name that has been assigned to eth0 and then
use that to start, stop or restart the service. It should not fail simply
because some other component of the system has decided (?) that renaming was
advisable.

Perhaps the default for Debian (linux?) should be to not rename but to provide
a command to rename or create an alias in those situations where it is
absolutely essential.


-- Package-specific info:
--- /etc/network/interfaces:
source-directory /etc/network/interfaces.d
auto eth0
iface eth0 inet dhcp

--- /etc/network/interfaces.d/setup:
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

--- up and down scripts installed:
/etc/network/if-down.d:
total 8
-rwxr-xr-x 1 root root 1015 Aug  8  2022 avahi-autoipd
lrwxrwxrwx 1 root root   29 Jan 25 13:11 bridge -> /lib/bridge-utils/ifupdown.sh
-rwxr-xr-x 1 root root  759 Dec  9  2022 resolved
lrwxrwxrwx 1 root root   32 Feb 24 05:01 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-post-down.d:
total 4
lrwxrwxrwx 1 root root   29 Jan 25 13:11 bridge -> /lib/bridge-utils/ifupdown.sh
-rwxr-xr-x 1 root root 1409 Mar  7  2020 wireless-tools
lrwxrwxrwx 1 root root   32 Feb 24 05:01 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-pre-up.d:
total 8
lrwxrwxrwx 1 root root   29 Jan 25 13:11 bridge -> /lib/bridge-utils/ifupdown.sh
-rwxr-xr-x 1 root root 4191 Mar  7  2020 wireless-tools
lrwxrwxrwx 1 root root   32 Feb 24 05:01 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-up.d:
total 12
-rwxr-xr-x 1 root root  923 Aug  8  2022 avahi-autoipd
-rwxr-xr-x 1 root root 4663 Dec  9  2022 resolved
lrwxrwxrwx 1 root root   32 Feb 24 05:01 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/16 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 ifupdown depends on:
ii  adduser   3.134
ii  iproute2  6.1.0-3
ii  libc6 2.36-9+deb12u1

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.3-P1-2

Versions of packages ifupdown suggests:
ii  ppp 2.4.9-1+1.1+b1
pn  rdnssd  

-- no debconf information

Bug#1041786: codeblocks: randomly crashes when writing c++ code

[Onsemeliot]

Package: codeblocks
Version: 20.03+svn13046-0.1+b2
Severity: important
X-Debbugs-Cc: onsemel...@gmail.com

Dear Maintainer,

I installed codeblocks on two of my laptops after doing fresh installs with 
Debian 12. On both systems I try to learn C++ using learncpp.com and writing 
the code examples there. On one I installed the GNOME desktop and on the other 
I use LXDE. In both cases codeblocks crashes often after just a few minutes of 
writing rather simple beginners exercises. I need to save my project every few 
seconds because my project file can't be restored if codeblocks crashes. I get 
a warning that an automatic report will be sent, but I didn't find any hint of 
such a report when I checked out the Debian bug tracking web page for 
codeblocks.

Nevertheless, thank you for providing such a great tool.

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages codeblocks depends on:
ii  codeblocks-common20.03+svn13046-0.1
ii  libastyle3   3.1-3+b1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9+deb12u1
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libcodeblocks0   20.03+svn13046-0.1+b2
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libharfbuzz0b6.0.0+dfsg-3
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libstdc++6   12.2.0-14
ii  libtinyxml2.6.2v52.6.2-6
ii  libwxbase3.2-1   3.2.2+dfsg-2
ii  libwxgtk3.2-13.2.2+dfsg-2
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages codeblocks recommends:
ii  g++4:12.2.0-3
ii  gcc4:12.2.0-3
ii  gdb13.1-3
ii  xterm  379-1

Versions of packages codeblocks suggests:
pn  codeblocks-contrib  
pn  libwxgtk3.0-dev 

-- no debconf information

Bug#1041785: /usr-merge: continuous archive analysis

[Helmut Grohne]

Source: systemd-cron
Version: 1.16-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Hi Alexandre,

Please note that your email address bounces. I am therefore filing this
response as a Debian bug hoping to reach you this way. I strongly
recommend using a non-bouncing email provider for interacting with
Debian.

On Sun, Jul 23, 2023 at 04:53:33PM +0200, Alexandre Detiste wrote:
> I'm also interrested in the crossbuild effort
> and even forwarded some (parts) of your patchs to various upstreams.

Thank you.

> Here I'm upstream for systemd-cron and I can't help myself to fix the
> cross build.
> 
> https://salsa.debian.org/detiste-guest/systemd-cron/-/pipelines/554789
> 
> It seams $(CC) always turns as "cc" and I don't know why.

The typical way to cross build autoconf based packages is passing --host
to configure. Now your configure doesn't accept that option and your
override does not pass it. Still debhelper assumes that you have somehow
transferred that information to the build system (which you have not)
and therefore does not pass it in the dh_auto_build stage. We can force
that explicit passing by forcing the makefile buildsystem (instead of
the automatically selected autoconf buildsystem) and that makes
dh_auto_build pass CC and that makes things just work.

In my bounced mail, I asked you to not do any /usr-merge conversion for
systemd-cron.

Helmut
diff -Nru systemd-cron-1.16/debian/changelog systemd-cron-1.16/debian/changelog
--- systemd-cron-1.16/debian/changelog  2023-07-22 18:14:03.0 +0200
+++ systemd-cron-1.16/debian/changelog  2023-07-23 17:55:55.0 +0200
@@ -1,3 +1,10 @@
+systemd-cron (1.16-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 23 Jul 2023 17:55:55 +0200
+
 systemd-cron (1.16-1) unstable; urgency=low
 
   * major rewrite in an OO fashion
diff -Nru systemd-cron-1.16/debian/rules systemd-cron-1.16/debian/rules
--- systemd-cron-1.16/debian/rules  2023-07-10 22:36:26.0 +0200
+++ systemd-cron-1.16/debian/rules  2023-07-23 17:55:54.0 +0200
@@ -22,6 +22,9 @@
 --enable-yearly=yes \
 --enable-persistent=yes
 
+override_dh_auto_build:
+   dh_auto_build --buildsystem=makefile
+
 override_dh_installsystemd:
# Only enable+start cron.target, it pulls in all the others via .timer 
files.
dh_installsystemd cron.target

Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386

[Dirk Eddelbuettel]

On 23 July 2023 at 15:07, Graham Inggs wrote:
| Hi
| 
| On Sun, 23 Jul 2023 at 13:11, Nilesh Patra  wrote:
| > How do you conclude that?
| > The versions of affected packages are same in unstable and testing. They
| > fail in i386 with a newer version of lme4.
| 
| For what it's worth, r-cran-afex[1] and r-cran-mertools[2] **are**
| passing in unstable.

Ah. So maybe I did look at that...

| So perhaps whatever package fixed this condition has been uploaded, but not
| yet migrated.
| 
| Yet r-cran-mlmrev[3] still seems to have the timeout issue in unstable.

Note that the mlmRev authors / maintainers are the same as / a subset of the
lme4 authors. They may have an idea.

https://cran.r-project.org/package=mlmRev

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1041784: apt: upgrade to 12.1 stalls on install of /etc/systemd/system.conf

[Jonathan Leivent]

Package: apt
Version: 2.6.1
Severity: important
X-Debbugs-Cc: jleiv...@comcast.net

Dear Maintainer,

   * What led up to the situation?

I have a systemd service that does upgrades during shutdown.  It stalled while 
attempting to do the upgrade to 12.1.  The service is a oneshot 
remain-after-exit
type that uses ExecStop to run a script containing the following:

export DEBIAN_FRONTEND=noninteractive
apt update
apt upgrade -y -o Dpkg::Options::="--force-confdef" -o 
Dpkg::Options::="--force-confold" 
apt autoremove -y

When attempted the upgrade to 12.1, it got to the following point:

Setting up libsystemd-shared:amd64 (252.12-1~deb12u1) ...
Setting up systemd (252.12-1~deb12u1) ...
Installing new version of config file /etc/systemd/system.conf ...

and then stalled.  I tried switching to a different console, but that did not 
work and
the machine became completely unresponsive.

Was this some kind of deadlock between the install and the systemd service 
performing it?

If we are not supposed to use systemd services to do unattended upgrades at 
shutdown,
what works instead?

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I had to do a hardware reboot.  Then I did apt update and apt upgrade by hand.

   * What was the outcome of this action?

Seems OK now.


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "true";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || 
true; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: 

Bug#1041779: "ERROR: Unhandled exception" when opening Settings > Saving Books to disk

[yokota]

Hello,

> Calibre settings are currently broken on my system. Opening "Saving Books to 
> disk", "Sending Books to device" in the preferences fails with the following 
> error : "TypeError:SaveTemplate._init_() got an unexpected keyword argument 
> 'parent'"
> Additionally, other menus like "Behavior" are broken, with checkboxes and 
> empty drop-downs in random places (https://i.imgur.com/v4odGA5.png for 
> example).

I think this bug is same bug that fixed in Debian unstable but not in
Debian stable.
See also Debian bug #1034089:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034089

If you have package build environment, you can try patch:
  
https://github.com/debian-calibre/calibre/blob/debian/6.15.1-4/debian/patches/0027-TypeError-on-opening-Preferences-Closes-1034089.patch

--
YOKOTA

Bug#1041783: ocaml-cry FTBFS: Error (alert deprecated): SSLv23

[Adrian Bunk]

Source: ocaml-cry
Version: 0.6.7-1
Severity: serious
Tags: ftbfs trixie sid

https://buildd.debian.org/status/logs.php?pkg=ocaml-cry=0.6.7-1%2Bb3

...
Command [10] exited with code 2:
$ (cd _build/default && /usr/bin/ocamlc.opt -w 
@1..3@5..28@30..39@43@46..47@49..57@61..62-40 -strict-sequence -strict-formats 
-short-paths -keep-locs -g -bin-annot -I src/.cry.objs/byte -I 
/usr/lib/ocaml/ssl -no-alias-deps -opaque -open Cry__ -o 
src/.cry.objs/byte/cry__Cry_https.cmo -c -impl src/cry_https.ml)
File "src/cry_https.ssl.ml", line 29, characters 33-43:
Error (alert deprecated): SSLv23
SSL 2.0 was deprecated in 2011 by RFC 6176.
make[1]: *** [debian/rules:17: override_dh_auto_build] Error 1



This might have been caused by the new ocaml-ssl?

Bug#1041041: file: superflous 0 prepended to serial number in ntfs filesystem detection

[Christoph Biedl]

Control: tags 1041041 confirmed
Control: forwarded 1041041 
https://mailman.astron.com/pipermail/file/2023-July/001200.html

sowg09+39vc9e5tpgdtw@cs.email wrote...

(...)

> I propose that `file` should either drop the leading 0, so that it
> shows 34f5ee1202469ff7, or it should put an 'x' after the leading
> zero, like 0x34f5ee1202469ff7 similarly to how it does it for FAT32
> filesystems.

Well spotted, now forwarded to upstream.

Cheers,

Christoph


signature.asc
Description: PGP signature

Bug#1041782: nginx-dev: separate dh package

[Slavko]

Package: nginx-dev
Version: 1.24.0-1
Severity: wishlist

Please, separate debhelper things to separate module, to allow install it 
without
whole -dev suite.

For now, it is not possible even to run debclean on own modules without 
nginx-dev
and all its dependencies and building package inside pbuilder is tricky too as 
it
requires --use-pdebuild-internal (which skips some important steps).

BTW, today i finally decide to switch all my modules (packages) to your "new"
build system and it works great, good job ;-)

thanks

Bug#1041781: configure script mentions /etc/ipset/ipset while data is really being saved to /etc/iptables/ipset

[Christian]

Package: ipset-persistent
Version: 1.0.20

When I run

dpkg-reconfigure ipset-persistent

the configure script says

"Current ipsets can be saved to the configuration file 
/etc/ipset/ipsets. These ipsets will then be loaded automatically during 
system startup."


Really, the data is being saved to /etc/iptables/ipsets. I believe the 
problem is in


/var/lib/dpkg/info/ipset-persistent.templates

The message should be corrected... 

Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386

[Paul Gevers]

Hi,

On 23-07-2023 15:51, Dirk Eddelbuettel wrote:

But if you all think we are better auto-removing lme4 over i386 fails _of
packages using it_ as opposed to fails in itself then I cannot stop you.


As I mentioned already, we can't even do that easily because lme4 is 
currently a key package, and key packages are not autoremoved [1].


Paul

[1] https://release.debian.org/key-packages.html



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036811: bullseye-pu: package ncurses/6.2+20201114-2+deb11u2

[Sven Joachim]

On 2023-07-23 14:12 +0100, Jonathan Wiltshire wrote:

> Control: tag -1 moreinfo
>
> On Fri, May 26, 2023 at 08:51:55PM +0200, Sven Joachim wrote:
>> [ Risks ]
>> Users who are relying on their own terminfo files under
>> ${HOME}/.terminfo can no longer use them in setuid/setgid programs and
>> will have to work around that, e.g. by changing their TERM environment
>> variable, using a different terminal emulator or asking their sysadmin
>> for help.
>>
>> On my systems I did not find any setuid binaries linked to the tinfo
>> library, but some setgid games in the bsdgames package.
>
> Would a news entry highlighting this be appropriate?

Probably not, since the vast majority of users (at least 99%, more
likely 99.9%) will not be affected.  The Bookworm version of ncurses
does not contain such a news entry either, and I have not heard of any
bug reports (just checked the bsdgames package) or support questions.

Cheers,
   Sven

Bug#1041780: geoclue-2.0: D-Bus policy is installed in /etc instead of /usr

[Gioele Barabucci]

Package: geoclue-2.0
Version: 2.7.0-2
Tags: patch
Usertags: conffiles-reduction

Dear geoclue-2.0 maintainers,

geoclue-2.0 installs its D-Bus policy file in `/etc/dbus-1`. Since 
Debian 9 the standard directory for package-installed dbus policies is 
`/usr/share/dbus-1`.


See: https://bugs.debian.org/1006631

Lintian complains with `dbus-policy-in-etc`.

A patch to fix this issue is available at

https://salsa.debian.org/freedesktop-team/geoclue-2.0/-/merge_requests/13

Regards,

--
Gioele Barabucci

Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386

[Graham Inggs]

Hi

On Sun, 23 Jul 2023 at 13:11, Nilesh Patra  wrote:
> How do you conclude that?
> The versions of affected packages are same in unstable and testing. They
> fail in i386 with a newer version of lme4.

For what it's worth, r-cran-afex[1] and r-cran-mertools[2] **are**
passing in unstable.  So perhaps whatever package fixed this condition
has been uploaded, but not yet migrated.

Yet r-cran-mlmrev[3] still seems to have the timeout issue in unstable.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-cran-afex/unstable/i386/
[2] https://ci.debian.net/packages/r/r-cran-mertools/unstable/i386/
[3] https://ci.debian.net/packages/r/r-cran-mlmrev/unstable/i386/

Bug#1041685: foot-terminfo: Please let ncurses-term take over the foot terminfo entries

[Sven Joachim]

On 2023-07-23 15:44 +0200, Sven Joachim wrote:

> On 2023-07-23 13:42 +0200, Birger Schacht wrote:
>
>> Hi Sevn,
>>
>> On 7/22/23 16:44, Sven Joachim wrote:
>>> Hi Birger,
>>> thanks for the quick reply.
>>> On 2023-07-22 12:39 +0200, Birger Schacht wrote:
>>>
 Sure, lets do this!

 I've created https://salsa.debian.org/birger/foot/-/merge_requests/5
 to prepare the switch.
>>> The version of ncurses-term in unstable is 6.4+20230625-1, so foot
>>> and
>>> the transitional foot-terminfo package need to depend on ncurses-term
>>> (>= 6.4+20230625-2).
>>
>> Thanks, I've updated the MR. Ready to upload any time.
>
> Thanks! I pushed the ncurses changes to the master branch, will upload
> later today unless the Salsa CI pipeline fails unexpectedly.

Just uploaded to unstable, waiting for acceptance by the FTP masters.

Cheers,
   Sven

Bug#1041475: bullseye-pu: package hnswlib/0.4.0-3+deb11u1

[Étienne Mollier]

Hi Jonathan,

Jonathan Wiltshire, on 2023-07-23:
> On Wed, Jul 19, 2023 at 01:20:03PM +0200, Étienne Mollier wrote:
> > hnswlib is affected by CVE-2023-37365 marked no-dsa, documented
> > through the important bug #1041426.  Quoting the CVE for short:
> > hnswlib has a double free in init_index when the M argument is a
> > large integer.
> 
> Please go ahead.

I went ahead and received feedback that the package is accepted
in oldstable-proposed-updates->oldstable-new.  Thanks!

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-on air: Liquid Tension Experiment - Acid rain


signature.asc
Description: PGP signature

Bug#1041633: cmake: FindPython.cmake returns /usr/local/lib/python3.11/dist-packages for Python_SITEARCH

[Timo Röhling]

On Sun, 23 Jul 2023 15:59:19 +0200 Sebastiaan Couwenberg  
wrote:

Control: tags -1 pending

On 7/23/23 15:26, Timo Röhling wrote:
> It is the package maintainer's responsibility to set
> DEB_PYTHON_INSTALL_LAYOUT=deb in d/rules, either implicitly through
> the use of pybuild, or explicitly with "export
> DEB_PYTHON_INSTALL_LAYOUT", as you already did in Salsa.

The advise for packages should be DEB_PYTHON_INSTALL_LAYOUT=deb_system 
based on the python3 changelog as that's intended for package builds.

You are right. "deb" also works, but "deb_system" is the canonical
scheme name.


Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1041779: "ERROR: Unhandled exception" when opening Settings > Saving Books to disk

[jorniste]

Package: calibre
Version: 6.13.0+repack-2
Severity: important

Dear Maintainer,

Calibre settings are currently broken on my system. Opening "Saving Books to 
disk", "Sending Books to device" in the preferences fails with the following 
error : "TypeError:SaveTemplate._init_() got an unexpected keyword argument 
'parent'"
Additionally, other menus like "Behavior" are broken, with checkboxes and empty 
drop-downs in random places (https://i.imgur.com/v4odGA5.png for example).
I have tried deleting the config files and reinstalling the backage without 
success. This computer has nvidia drivers, but I got the same issue on another 
one without proprietary drivers. I haven't been able to test the newer package 
in testing because requires newer packages not in stable.

Best regards

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages calibre depends on:
ii  ca-certificates20230311
ii  calibre-bin6.13.0+repack-2
ii  fonts-liberation2  2.1.5-1
ii  libjpeg-turbo-progs1:2.1.5-2
ii  libjxr-tools   1.2~git20170615.f752187-5
ii  libqt6webenginecore6-bin   6.4.2-final+dfsg-1
ii  optipng0.7.7-2+b1
ii  poppler-utils  22.12.0-2+b1
ii  pyqt6-dev-tools6.4.2-1
ii  python33.11.2-1+b1
ii  python3-apsw   3.40.0.0-2+b1
ii  python3-bs44.11.2-2
ii  python3-chm0.8.6-3+b4
ii  python3-css-parser 1.0.8-1
ii  python3-cssselect  1.2.0-2
ii  python3-dateutil   2.8.2-2
ii  python3-feedparser 6.0.10-1
ii  python3-html2text  2020.1.16-2
ii  python3-html5-parser   0.4.10-8+b1
ii  python3-html5lib   1.1-3
ii  python3-jeepney0.8.0-3
ii  python3-lxml   4.9.2-1+b1
ii  python3-markdown   3.4.1-2
ii  python3-mechanize  1:0.4.8+pypi-5
ii  python3-msgpack1.0.3-2+b1
ii  python3-netifaces  0.11.0-2+b1
ii  python3-pil9.4.0-1.1+b1
ii  python3-pkg-resources  66.1.1-1
ii  python3-py7zr  0.11.3+dfsg-5
ii  python3-pycryptodome   3.11.0+dfsg1-4
ii  python3-pygments   2.14.0+dfsg-1
ii  python3-pyparsing  3.0.9-1
ii  python3-pyqt6  6.4.2-1
ii  python3-pyqt6.qtquick  6.4.2-1
ii  python3-pyqt6.qtsvg6.4.2-1
ii  python3-pyqt6.qtwebengine  6.4.0-1
ii  python3-pyqt6.sip  13.4.1-1
ii  python3-regex  0.1.20221031-1+b1
ii  python3-routes 2.5.1-3
ii  python3-speechd0.11.4-2
ii  python3-zeroconf   0.47.3-1
ii  python3.11 3.11.2-6
ii  xdg-utils  1.1.3-4.1

Versions of packages calibre recommends:
ii  python3-dnspython  2.3.0-1
ii  python3-ipython8.5.0-4
ii  qt6-wayland6.4.2-1
ii  udisks22.9.4-4

Versions of packages calibre suggests:
pn  python3-unrardll  

-- no debconf information

Bug#1033656: bt full with dbgsym

[Uwe Kleine-König]

Control: affects -1 + minidlna

The same bug affects minidlna:

uwe@crater:~$ gdb /usr/sbin/minidlnad
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/minidlnad...
Reading symbols from 
/usr/lib/debug/.build-id/8d/c7b6b6d717dcb1c814fff9a3e5a4dba526.debug...
(gdb) run
Starting program: /usr/sbin/minidlnad
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
hwy::(anonymous namespace)::robust_statistics::CountingSort 
(values=0xbeffecb8, num_values=256)
at ./hwy/nanobenchmark.cc:214
214 ./hwy/nanobenchmark.cc: No such file or directory.
(gdb) disassemble
Dump of assembler code for function hwy::(anonymous 
namespace)::robust_statistics::CountingSort(unsigned long 
long*, size_t):
   0xb546afb0 <+0>: stmdb   sp!, {r4, r5, r6, r7, r8, r9, r10, r11, lr}
   0xb546afb4 <+4>: mov r9, r1
   0xb546afb6 <+6>: ldr r1, [pc, #492]  @ (0xb546b1a4 (unsigned long 
long*, size_t)+500>)
   0xb546afb8 <+8>: sub sp, #52 @ 0x34
   0xb546afba <+10>:ldr r2, [pc, #492]  @ (0xb546b1a8 (unsigned long 
long*, size_t)+504>)
   0xb546afbc <+12>:add r1, pc
=> 0xb546afbe <+14>:vmov.i32d16, #0 @ 0x
   0xb546afc2 <+18>:movsr6, #0
   0xb546afc4 <+20>:str r6, [sp, #16]
   0xb546afc6 <+22>:ldr r2, [r1, r2]
   0xb546afc8 <+24>:ldr r2, [r2, #0]
   0xb546afca <+26>:str r2, [sp, #44]   @ 0x2c
   0xb546afcc <+28>:mov.w   r2, #0
   0xb546afd0 <+32>:vstrd16, [sp, #8]
   0xb546afd4 <+36>:cmp.w   r9, #0
   0xb546afd8 <+40>:beq.w   0xb546b180 (unsigned long 
long*, size_t)+464>
   0xb546afdc <+44>:mov r4, r0
   0xb546afde <+46>:mov r5, r6
   0xb546afe0 <+48>:mov r8, r6
   0xb546afe2 <+50>:mov.w   r10, #1
   0xb546afe6 <+54>:add.w   r11, sp, #24
   0xb546afea <+58>:sub.w   r3, r0, #8
   0xb546afee <+62>:str r3, [sp, #4]
   0xb546aff0 <+64>:ldr r2, [sp, #4]
   0xb546aff2 <+66>:subsr3, r5, r6
   0xb546aff4 <+68>:mov.w   r12, r3, asr #6
   0xb546aff8 <+72>:asrsr0, r3, #4
   0xb546affa <+74>:ldr.w   r1, [r2, #8]!
   0xb546affe <+78>:cmp.w   r12, #0
   0xb546b002 <+82>:str r2, [sp, #4]
   0xb546b004 <+84>:ldr r2, [r2, #4]
   0xb546b006 <+86>:ble.w   0xb546b19a (unsigned long 
long*, size_t)+490>
   0xb546b00a <+90>:add.w   r12, r6, r12, lsl #6
   0xb546b00e <+94>:mov r3, r6
   0xb546b010 <+96>:b.n 0xb546b03c (unsigned long 
long*, size_t)+140>
   0xb546b012 <+98>:ldrdr0, r7, [r3, #16]
--Type  for more, q to quit, c to continue without paging--q
Quit
(gdb) bt
#0  hwy::(anonymous namespace)::robust_statistics::CountingSort (values=0xbeffecb8, num_values=256)
at ./hwy/nanobenchmark.cc:214
#1  0xb546b256 in hwy::(anonymous namespace)::robust_statistics::Mode (num_values=256, values=0xbeffecb8)
at ./hwy/nanobenchmark.cc:286
#2  hwy::(anonymous namespace)::robust_statistics::Mode (values=...) at ./hwy/nanobenchmark.cc:292
#3  hwy::platform::TimerResolution () at ./hwy/nanobenchmark.cc:480
#4  0xb5469e0e in __static_initialization_and_destruction_0 (__priority=65535, 
__initialize_p=1) at ./hwy/nanobenchmark.cc:488
#5  _GLOBAL__sub_I_nanobenchmark.cc(void) () at ./hwy/nanobenchmark.cc:763
#6  0xb6fe444c in call_init (env=0xbefff53c, argv=0xbefff534, argc=1, 
l=) at dl-init.c:70
#7  call_init (l=, argc=1, argv=0xbefff534, env=0xbefff53c) at 
dl-init.c:26
#8  0xb6fe44f2 in _dl_init (main_map=0xb6fffa68, argc=1, argv=0xbefff534, 
env=0xbefff53c) at dl-init.c:117
#9  0xb6ff17cc in _dl_start_user () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

I installed 1.0.5~git20230620.ed184dc-3 from expermental, that doesn't
fix the problem.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Bug#1041778: python3.11: 'posix_local' scheme conflicts with 'base' and 'platbase' prefix overrides

[Timo Röhling]

Package: python3.11
Version: 3.11.4-1
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Control: found -1 3.11.2-6

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

the 'posix_local' scheme will unexpectedly insert "/local"s into path
names if the 'base' prefix is changed to something other than '/usr':

>>> import sysconfig
>>> sysconfig.get_path('purelib')
'/usr/local/lib/python3.11/dist-packages'
>>> sysconfig.get_path('purelib', vars={'base': '/opt/mystuff'})
'/opt/mystuff/local/lib/python3.11/dist-packages'
>>> sysconfig.get_path('purelib', vars={'base': './'})
'local/lib/python3.11/dist-packages'
>>> sysconfig.get_path('purelib', vars={'base': '/usr/local'})
'/usr/local/local/lib/python3.11/dist-packages'

As code like the above is actually being used "in the wild" to create
FHS-like directory structures in locations other than /usr, we should
consider if and how we manage the implied expectation behind that code.

As far as I understand the rationale behind the 'posix_local' scheme, it
is supposed to prevent local installations into the dpkg-managed
/usr/lib, for the reasons given in PEP-668. To that end, the scheme is
arguably slightly "overpowered", as it does more than just divert
'purelib' and 'platlib' from /usr/lib.

We could make sysconfig.get_path() and sysconfig.get_paths() check if
'base' or 'platbase' are overridden to something other than '/usr'
before applying the 'posix_local' scheme for 'purelib' and 'platlib',
respectively. This would certainly help minimize the impact of the
Debian-specific posix_local scheme. Technically, it means that the
posix_local scheme can no longer be expressed as a simple dict, but as
far as I see it, this is just a current implementation detail and
nothing promised by the sysconfig API.

So while it is possible that we would violate other expectations about the
behavior of get_path() along the way, I believe we would make the
Debianized version of Python more compatible with other platforms and
behave less surprisingly in the common use case, which I consider a Good
Thing.

Feel free to rebut (or second) my reasoning. :)


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmS9PJgACgkQ+C8H+466
LVlrvQv/S8NjYecZVDu1ARN/DiYg5qCVdWQjpTzWhm+VSBLJ/fkcjyYNLWB+/ott
H9DA0bTMsDTKn1G+VZ238Wb8Nm9Hwhx+aVQRENGKh6LR9JLDZT8RzpTQrp/4e9gM
KPYaS5KcLi3vpy+9eiu0V0zFTBv5sPLy91bipQ9Cbh6it69Cv7QhUBGNkVz6ckLN
5YWqlK56z2nu2tvaedS/1LrxB7zy6axo1RPLZKKkbk12rTCaeVBSetBnYos978eu
4puSqgKdYKAskvOFo0XCKDR9msBLdKm1V907mkzVfRoh3wWX00gMz9/BplPPnkHB
tavi3fqdwkunvq+a1zAn2YKX15JH31vzuTKfIB+XPVgsRuAV9y7y8X/CrMYpy7zX
RGRTq8Ycg8BRRMyxIwv/TDJqpXjF6iiL5Qbt/ju7gy/pyDVyqi6VS7BNxhJhprlJ
Xk8ctWYj1495hf7O0Hrn1U0q31AW8s9dGJ6ilF+VqAsDqrmsm4vp2dmURHC+0jGn
KXOiI8T1
=TwPy
-END PGP SIGNATURE-

Bug#1041777: cups-pk-helper: new upstream version 0.2.7

[Gioele Barabucci]

Package: cups-pk-helper
Version: 0.2.6-1
Usertags: conffiles-reduction
Severity: wishlist

Dear cups-pk-helper maintainer,

could you please package version 0.2.7 of cups-pk-helper, released on 
2022-08-09?


Among other things, version 0.2.7 contains a fix for the Lintian warning 
`dbus-policy-in-etc`, see .


Regards,

--
Gioele Barabucci

Bug#1041767: Subject: eln-cache piling up

[Sean Whitton]

Hello,

On Sun 23 Jul 2023 at 05:39am -05, Dan Jacobson wrote:

> Package: emacs-bin-common
> Version: 1:28.2+1-15
>
> These are piling up on user's disks,
>
> $ du -sh .emacs.d/eln-cache/*
> 4.0K.emacs.d/eln-cache/28.2-43f520ab
> 19M .emacs.d/eln-cache/28.2-467432cd
> 4.0K.emacs.d/eln-cache/28.2-7a6329ed
> 23M .emacs.d/eln-cache/28.2-8ab3e389
> 31M .emacs.d/eln-cache/28.2-e4556eb6
> 26M .emacs.d/eln-cache/28.2-fd960886
>
> with no cleaning happening.
> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13684
> mentions it might be some flag left on during compiling.

Upstreams intent is to leave it to users to clean them up, e.g. with
M-x native-compile-prune-cache.  It would be nice to do better than
that, but the discussion should probably happen upstream.

-- 
Sean Whitton

Bug#1041776: transition: libwebsockets

[GCS]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: affects -1 + src:libwebsockets

Hi RMs,

This transition missed Bookworm, but now I would like to start it. All
reverse dependencies are built correctly on amd64. I'm going to test
i386 as well, but I do not expect any failure.

Thanks for considering,
Laszlo/GCS

Bug#1041775: iio-sensor-proxy: D-Bus policy is installed in /etc instead of /usr

[Gioele Barabucci]

Package: iio-sensor-proxy
Version: 3.4-2
Tags: patch
Usertags: conffiles-reduction

Dear iio-sensor-proxy maintainers,

iio-sensor-proxy installs its D-Bus policy file in `/etc/dbus-1`. Since 
Debian 9 the standard directory for package-installed dbus policies is 
`/usr/share/dbus-1`.


See: https://bugs.debian.org/1006631

Lintian complains with `dbus-policy-in-etc`.

A patch to fix this issue is available at

https://salsa.debian.org/debian/iio-sensor-proxy/-/merge_requests/7

Regards,

--
Gioele Barabucci

Bug#929265: me too!

[David Bremner]

Currently the version of ipopt is too old to be used by SCIP
(https://scipopt.org). 

Bug#1030394: Bug#1040690: Bug#1030394: Bug#1040690: reassign bug to correct package

[Richard Lewis]

On Sun, 23 Jul 2023, 12:34 David Bremner,  wrote:

> Richard Lewis  writes:
>
> > I suspect a plain chroot isnt 'enough', i had success with
> systemd-nspawn:
> >
> > ln -s /tmp/bullseye/ /var/lib/machines
> >
> > # im sure there is a better way than these two lines
> > cp /etc/passwd bullseye/etc/passwd
> > cp /etc/shadow bullseye/etc/shadow
> >
> > systemd-nspawn --ephemeral --boot --machine bullseye
> > # (you dont really need --ephemeral of course)
> >
> > log into the container as root:
> > # apt install emacs-gtk
> >
> > (and say yes to allow the installation to finish)
> >
> > # ls /usr/share/emacs/site-lisp/elpa
> > dash-2.17.0  dash-functional-1.2.0  elisp-refs-1.4  helpful-0.18
> loop-1.3
> > dash-2.19.1  elisp-refs-1.3 f-0.20.0helpful-0.19
> s-1.12.0
> >
> > Shows the 'duplicate' dirs for the old versions of elpa-dash and
> elpa-helpful
> >
>
> Did you start from a clean debootstrap here?  Because I don't see where
> in your second reproducer the addon packages get installed.
>

no, i reused the chroot from the "first attempt" reproducer
A clean recipe, not requiring any 'login' is:

mkdir -p /tmp/bullseye
cd /tmp/bullseye
debootstrap bullseye . https://deb.debian.org/debian
ln -s /tmp/bullseye /var/lib/machines/bullseye
systemd-nspawn --machine bullseye apt install emacs elpa-helpful
# at this stage we have:
# $ ls /tmp/bullseye/usr/share/emacs/site-lisp/elpa/
# dash-2.17.0  dash-functional-1.2.0  elisp-refs-1.3  f-0.20.0
 helpful-0.18  loop-1.3  s-1.12.0
sed -i /bullseye/bookworm/ tmp/bullseye/apt/sources.list
#
systemd-nspawn --machine bullseye apt update
systemd-nspawn --machine bullseye apt upgrade
# this all works, including upgrading emacs :)
# but, old directories for elpa-dash and elpa-helpful and elpa-elisp-refs
have not been removed:
# $ ls /tmp/bullseye/usr/share/em$ ls
/tmp/bullseye/usr/share/emacs/site-lisp/elpa{,-src}
/tmp/bullseye/usr/share/emacs/site-lisp/elpa:
dash-2.17.0  dash-functional-1.2.0  elisp-refs-1.4  helpful-0.18  loop-1.3
dash-2.19.1  elisp-refs-1.3 f-0.20.0helpful-0.19  s-1.12.0

/tmp/bullseye/usr/share/emacs/site-lisp/elpa-src:
dash-2.19.1  dash-functional-1.2.0  elisp-refs-1.4  f-0.20.0  helpful-0.19
 loop-1.3  s-1.12.0

# nb: on the host /tmp/bullseye and the symlink /var/lib/machine/bullseye
should be removed once finished!

>

Bug#1041774: udisks2: Hangs for about 20 secs. and timeout error after upgrading to 2.10.0-3 on trixie

[Ricardo Pérez]

Package: udisks2
Version: 2.10.0-3
Severity: important
X-Debbugs-Cc: rica...@ubuntu.com

Dear Maintainer,

After upgrading to 2.10.0-3 on trixie, when I try to run Thunar or
something similar, it hangs for about 20 secs. and then I got the
following error message:

Error creating proxy: Error calling StartServiceByName for 
org.gtk.vfs.UDisks2VolumeMonitor: Timeout was reached (g-io-error-quark, 24)

Then, Thunar doesn't show my USB-connected external hard drive. With
udisks2 2.9, it works perfectly fine.

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

Kernel: Linux 6.3.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 udisks2 depends on:
ii  dbus   1.14.8-2
ii  libacl12.3.1-3
ii  libatasmart4   0.19-5
ii  libblkid1  2.38.1-6
ii  libblockdev-crypto33.0.1-2
ii  libblockdev-fs33.0.1-2
ii  libblockdev-loop3  3.0.1-2
ii  libblockdev-mdraid33.0.1-2
ii  libblockdev-nvme3  3.0.1-2
ii  libblockdev-part3  3.0.1-2
ii  libblockdev-swap3  3.0.1-2
ii  libblockdev-utils3 3.0.1-2
ii  libblockdev3   3.0.1-2
ii  libc6  2.37-6
ii  libglib2.0-0   2.76.4-3
ii  libgudev-1.0-0 237-2
ii  libmount1  2.38.1-6
ii  libpolkit-agent-1-0122-4
ii  libpolkit-gobject-1-0  122-4
ii  libsystemd0253.5-1
ii  libudisks2-0   2.10.0-3
ii  libuuid1   2.38.1-6
ii  parted 3.6-3
ii  udev   253.5-1

Versions of packages udisks2 recommends:
ii  dosfstools  4.2-1
ii  e2fsprogs   1.47.0-2
ii  eject   2.38.1-6
ii  exfatprogs  1.2.1-2
ii  libpam-systemd  253.5-1
ii  ntfs-3g 1:2022.10.3-1+b1
ii  polkitd 122-4

Versions of packages udisks2 suggests:
pn  btrfs-progs
pn  f2fs-tools 
pn  mdadm  
pn  nilfs-tools
pn  reiserfsprogs  
pn  udftools   
pn  udisks2-btrfs  
pn  udisks2-lvm2   
pn  xfsprogs   

-- no debconf information

Bug#1041633: cmake: FindPython.cmake returns /usr/local/lib/python3.11/dist-packages for Python_SITEARCH

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 7/23/23 15:26, Timo Röhling wrote:

It is the package maintainer's responsibility to set
DEB_PYTHON_INSTALL_LAYOUT=deb in d/rules, either implicitly through
the use of pybuild, or explicitly with "export
DEB_PYTHON_INSTALL_LAYOUT", as you already did in Salsa.


The advise for packages should be DEB_PYTHON_INSTALL_LAYOUT=deb_system 
based on the python3 changelog as that's intended for package builds.


Kind Regards,

Bas

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

Bug#1033385: Any progress?

[Pierre Tomon]

Le Sun, 23 Jul 2023 15:09:31 +0200,
justhate  a écrit :

> Same issue here as Karine explained.
> 
> The bug was reported 4 months ago and here we are, upgraded glib
> yesterday [libglib2.0-0:amd64 (2.74.6-2, 2.76.4-3)] and Openbox
> (3.6.1-10) is quite unusable.
> 
> Despite the icculus bug report seems to be a bit in an unknown state
> isn't the patch good enough to be applied?
> 

There is an updated package of Openbox, but it requires a sponsor:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041486

Bug#989387: fixed ages ago

[Russell Coker]

close 989387
thanks

$ dpkg -c warzone2100-data_4.3.3-3_all.deb |grep fr
drwxr-xr-x root/root 0 2023-01-13 04:28 ./usr/share/locale/fr/
drwxr-xr-x root/root 0 2023-01-13 04:28 ./usr/share/locale/fr/
LC_MESSAGES/
-rw-r--r-- root/root304515 2023-01-13 04:28 ./usr/share/locale/fr/
LC_MESSAGES/warzone2100.mo

The version from the Bookworm release has this fixed.

$ dpkg -l warzone2100-data
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----
=
ii  warzone2100-data 4.3.5-1  all  data files for warzone2100
$ dpkg -L warzone2100-data|grep fr
/usr/share/locale/fr
/usr/share/locale/fr/LC_MESSAGES
/usr/share/locale/fr/LC_MESSAGES/warzone2100.mo

The version in Unstable has this fixed.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386

[Dirk Eddelbuettel]

On 23 July 2023 at 18:42, Nilesh Patra wrote:
| On Sun, 23 Jul 2023 07:15:09 -0500 Dirk Eddelbuettel  wrote
| > Is this is not an example of a release manager override? The affectect
| > packages all work together in unstable and could migrate.
| 
| How do you conclude that?
| The versions of affected packages are same in unstable and testing. They
| fail in i386 with a newer version of lme4.

Sorry, my fault. I was wrong here so thanks for the correction. I looked at
the bottom of one of those logs, saw a PASS and missed the FAIL preceding it.

Still, it is a self-imposed problem by Debian.  At some point we managed to
let go of m68k too.

But if you all think we are better auto-removing lme4 over i386 fails _of
packages using it_ as opposed to fails in itself then I cannot stop you. That
does not mean I concur with the decision.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1041685: foot-terminfo: Please let ncurses-term take over the foot terminfo entries

[Sven Joachim]

On 2023-07-23 13:42 +0200, Birger Schacht wrote:

> Hi Sevn,
>
> On 7/22/23 16:44, Sven Joachim wrote:
>> Hi Birger,
>> thanks for the quick reply.
>> On 2023-07-22 12:39 +0200, Birger Schacht wrote:
>>
>>> Sure, lets do this!
>>>
>>> I've created https://salsa.debian.org/birger/foot/-/merge_requests/5
>>> to prepare the switch.
>> The version of ncurses-term in unstable is 6.4+20230625-1, so foot
>> and
>> the transitional foot-terminfo package need to depend on ncurses-term
>> (>= 6.4+20230625-2).
>
> Thanks, I've updated the MR. Ready to upload any time.

Thanks! I pushed the ncurses changes to the master branch, will upload
later today unless the Salsa CI pipeline fails unexpectedly.

Cheers,
   Sven

Bug#1041773: wpasupplicant: probably wrong "handshake" for hotspot with WPA2-Personal

[Shai Berger]

Package: wpasupplicant
Version: 2:2.10-12
Severity: normal

Dear Maintainer,

I have been using wpasupplucant with NetworkManager under KDE for
several years, in order to make an access point in my study (where
the home wifi signal is too weak). I've been using a Samsung S9
phone, and all was well.

Lately, I bought a newer phone -- a Samsung S20 -- and with that
phone, I could not connect to the access point. I searched high and low,
until I found this
https://www.reddit.com/r/kde/comments/soqzo4/unable_to_connect_to_hotspot_made_with/
with the recommendation to use iwd instead of wpasupplicant.

And just like for that responder, iwd "just worked".

In addition to the S20 refusing to connect, I also have a laptop
running Ubuntu 20.04. When that laptop was scanning the relevant
network (with wpasupplicant), the access point showed up with
"unknown encryption scheme". With iwd, it says "WPA2-PSK".
(just to make perfectly clear: the computer where the backend
was switched is a Debian desktop. The laptop uses whatever is
default in Ubuntu, and nothing in it was changed).

BTW the Reddit page leads to a KDE bug
https://bugs.kde.org/show_bug.cgi?id=449265
but my guess would be that the bug is not in KDE, but
somewhere between wpasupplicant and NetworkManager.


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

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

Versions of packages wpasupplicant depends on:
ii  adduser3.137
ii  libc6  2.37-6
ii  libdbus-1-31.14.8-2
ii  libnl-3-2003.7.0-0.2+b1
ii  libnl-genl-3-200   3.7.0-0.2+b1
ii  libnl-route-3-200  3.7.0-0.2+b1
ii  libpcsclite1   2.0.0-1
ii  libreadline8   8.2-1.3
ii  libssl33.0.9-1

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

-- no debconf information

Bug#1041706: debian-handbook: Wrong advice on APT::Default-Release preventing security updates

[Salvatore Bonaccorso]

FWIW, there is a related discussion in #1041708, so cross-referencing.

Regards,
Salvatore

Bug#1041633: cmake: FindPython.cmake returns /usr/local/lib/python3.11/dist-packages for Python_SITEARCH

[Timo Röhling]

Control: reassign -1 qgis 3.28.8+dfsg-1
Control: retitle -1 qgis: needs DEB_PYTHON_INSTALL_LAYOUT=deb to build


Hi Bas,

* Sebastiaan Couwenberg  [2023-07-21 17:17]:

Changes between bookworm and sid:

cmake 3.25.1:

``Python_SITELIB``
  Third-party platform independent installation directory.

  Information returned by

``distutils.sysconfig.get_python_lib(plat_specific=False,standard_lib=False)``
  or else ``sysconfig.get_path('purelib')``.
``Python_SITEARCH``
  Third-party platform dependent installation directory.

  Information returned by

``distutils.sysconfig.get_python_lib(plat_specific=True,standard_lib=False)``
  or else ``sysconfig.get_path('platlib')``.

cmake 3.27.0:

``Python_SITELIB``
  Third-party platform independent installation directory.

  Information returned by ``sysconfig.get_path('purelib')``.
``Python_SITEARCH``
  Third-party platform dependent installation directory.

  Information returned by ``sysconfig.get_path('platlib')``.

On bookworm distutils is still used which returns:

>>> distutils.sysconfig.get_python_lib(
plat_specific=False,
standard_lib=False,
)
'/usr/lib/python3/dist-packages'

On sid sysconfig is used which results:

>>> sysconfig.get_path('platlib')
'/usr/local/lib/python3.11/dist-packages'

To get the right path for the Debian python3 interpreter,
you need to add 'deb_system':

>>> sysconfig.get_path('platlib', 'deb_system')
'/usr/lib/python3/dist-packages'


After a bit of discussion in #d-python, I believe that
CMake actually behaves as intended now, and the previous behavior was
unintended.

The default use-case is a local user build, not a package build, and
the default SITELIB reflects that.

It is the package maintainer's responsibility to set
DEB_PYTHON_INSTALL_LAYOUT=deb in d/rules, either implicitly through
the use of pybuild, or explicitly with "export
DEB_PYTHON_INSTALL_LAYOUT", as you already did in Salsa.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1040758: bullseye-pu: package spip/3.2.11-3+deb11u9

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Mon, Jul 10, 2023 at 07:37:38AM +0200, David Prévot wrote:
> This issue is similar to #1040756 in bookworm.
> 
> Another upstream release fixed a security issue. It introduces some
> factorisation adding two more clean up in sessions. We agreed with the
> security team that this don’t warrant a DSA.
> 
> https://blog.spip.net/Mise-a-jour-de-maintenance-et-securite-sortie-de-SPIP-4-2-4-SPIP-4-1-11.html

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1040865: bullseye-pu: package yajl/2.1.0-3+deb11u2

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Tue, Jul 11, 2023 at 08:01:20PM +0200, Tobias Frost wrote:
> Previous o-s-p-u upload was #1040137; two additional CVEs have
> been fixed since then and the fix for CVE-2023-33460 has been found
> to be incomplete.
> 
> This upload is part of fixing yajl for every release. So far sid, buster
> (DLA-3492), stretch and jessie (ELA-892-1) has been targeted.
> bookworm s-p-u is pending, see #1040863

Please elaborate a little on what those CVEs are about in debian/changelog;
otherwise, go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386

[Nilesh Patra]

On Sun, 23 Jul 2023 07:15:09 -0500 Dirk Eddelbuettel  wrote
> Is this is not an example of a release manager override? The affectect
> packages all work together in unstable and could migrate.

How do you conclude that?
The versions of affected packages are same in unstable and testing. They
fail in i386 with a newer version of lme4.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1036811: bullseye-pu: package ncurses/6.2+20201114-2+deb11u2

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On Fri, May 26, 2023 at 08:51:55PM +0200, Sven Joachim wrote:
> [ Risks ]
> Users who are relying on their own terminfo files under
> ${HOME}/.terminfo can no longer use them in setuid/setgid programs and
> will have to work around that, e.g. by changing their TERM environment
> variable, using a different terminal emulator or asking their sysadmin
> for help.
> 
> On my systems I did not find any setuid binaries linked to the tinfo
> library, but some setgid games in the bsdgames package.

Would a news entry highlighting this be appropriate?

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1037236: bullseye-pu: package gss/1.0.3-6+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Fri, Jun 09, 2023 at 12:52:39AM +0200, Andreas Beckmann wrote:
> libgss3 has a file conflict with libgss0, which may have remained
> installed on a system originating from lenny

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1033385: Any progress?

[justhate]

Same issue here as Karine explained.

The bug was reported 4 months ago and here we are, upgraded glib
yesterday [libglib2.0-0:amd64 (2.74.6-2, 2.76.4-3)] and Openbox
(3.6.1-10) is quite unusable.

Despite the icculus bug report seems to be a bit in an unknown state
isn't the patch good enough to be applied?

Bug#1039020: bullseye-pu: package schleuder/3.6.0-3+deb11u2

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sat, Jun 24, 2023 at 04:05:45PM +, Georg Faerber wrote:
> [ Reason ]
> Missing versioning of the ruby-activerecord dependency might lead to
> failing upgrades from buster to bullseye if done in two stages, in
> contrast to only one stage. This issue was reported by Hendrik Jäger and
> Andreas Beckmann, both privately and in Debian via #1036950.

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1023205: bullseye-pu: package memtest86+/6.00-1

[Fabio Fantoni]

Il 23/07/2023 14:50, Felix Zielcke ha scritto:

(Adding Fabio)

Am Sonntag, dem 23.07.2023 um 13:42 +0100 schrieb Jonathan Wiltshire:

Control: tag -1 moreinfo

Hi,

On Mon, Oct 31, 2022 at 05:38:07PM +0100, Felix Zielcke wrote:

memtest86+ 5.01-3.1 in stable is very old and doestn't run
correctly
on recent hardware.

In the meantime I see there has been a backport of 6 to bullseye-
backports.
Is it still the best course of action to remove 5.01-3.1 from stable,
or
does it work well enough on old hardware to be worth keeping?

Thanks,


Hi,

actually now I think we could just keep it in bullseye. Anyone with
recent hardware could get it from backports and probable also will (if
not have already) upgrade to bookworm.
Or what do you think Fabio? Should the old memtest still be removed
from oldstable?

I at least didn't get any complains about the old version, since I
became a co-maintainer of memtest86+


Hi, old version doesn't work on many hardwares but deleting memtest86+ 
from oldstable repo doesn't seem like a good thing to me, rather now 
that there is a new stable I suppose oldstable is much less used and 
relevant and could stay that way; because I suppose that almost all 
sysadmin/users now have the new iso and in case they need to test the 
old systems without being able to load the iso, they install the new 
memtest86+ version from backports before. or am I wrong?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041397: asmtools 7.0-b09-2~deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1041397 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: asmtools
Version: 7.0-b09-2~deb11u1

Explanation: backport to bullseye for future openjdk-11 builds

Bug#1040668: tang 8-3+deb11u2 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1040668 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: tang
Version: 8-3+deb11u2

Explanation: fix race condition when creating/rotating keys; assert restrictive 
permissions on key directory [CVE-2023-1672]; make tangd-rotate-keys executable

Bug#1041475: bullseye-pu: package hnswlib/0.4.0-3+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Wed, Jul 19, 2023 at 01:20:03PM +0200, Étienne Mollier wrote:
> hnswlib is affected by CVE-2023-37365 marked no-dsa, documented
> through the important bug #1041426.  Quoting the CVE for short:
> hnswlib has a double free in init_index when the M argument is a
> large integer.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1040930: bullseye-pu: package ca-certificates-java/20190909+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Wed, Jul 12, 2023 at 04:11:04PM +0200, Andreas Beckmann wrote:
> The bullseye-security upload of openjdk-17 broke the very fragile
> assumption in ca-certificates-java that a jre can be used even
> before it was configured for the first time.
> As a result new installations of openjdk-17-jre-headless from
> bullseye-security (or -pu) (and its circular dependency
> ca-certificates-java from bookworm) will fail, #1039472, (but
> upgrades seem to work fine, since the jre has been configured at
> least once in the past).

Please go ahead. Should it be published even before the next point release
is scheduled?

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1039994: bullseye-pu: package logrotate/3.18.0-2+deb11u2

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Fri, Jun 30, 2023 at 08:22:02PM +0200, Christian Göttsche wrote:
> The previous upload (3.18.0-2+deb11u1) cherry picked several commits
> around the state file handling of logrotate.
> In particular 
> debian/patches/applied-upstream/Do-not-lock-state-file-dev-null.patch
> added the following wording to the man page:
> 
> If /dev/null is given as the state file, then logrotate will not
> try to lock or write the state file.
> 
> In the current bullseye version this is only true for locking but nor
> for writing since the related commit was not included.
> Thus the usage of /dev/null as the state file can lead to /dev/null
> being replaced by a regular file.
> See #1039868 as an example.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1023205: bullseye-pu: package memtest86+/6.00-1

[Felix Zielcke]

(Adding Fabio)

Am Sonntag, dem 23.07.2023 um 13:42 +0100 schrieb Jonathan Wiltshire:
> Control: tag -1 moreinfo
> 
> Hi,
> 
> On Mon, Oct 31, 2022 at 05:38:07PM +0100, Felix Zielcke wrote:
> > memtest86+ 5.01-3.1 in stable is very old and doestn't run
> > correctly
> > on recent hardware.
> 
> In the meantime I see there has been a backport of 6 to bullseye-
> backports.
> Is it still the best course of action to remove 5.01-3.1 from stable,
> or
> does it work well enough on old hardware to be worth keeping?
> 
> Thanks,
> 

Hi,

actually now I think we could just keep it in bullseye. Anyone with
recent hardware could get it from backports and probable also will (if
not have already) upgrade to bookworm.
Or what do you think Fabio? Should the old memtest still be removed
from oldstable?

I at least didn't get any complains about the old version, since I
became a co-maintainer of memtest86+

Bug#1041772: [INTL:es] Spanish translation of isc-kea debconf template

[Camaleón]

Package: isc-kea
Severity: wishlist
Tags: patch l10n

Hello,

You can find enclosed the Spanish translation template to be uploaded with the 
latest package build.

Kindly place this file in debian/po/ as es.po for your next upload.

Cheers,
-- 
Camaleón# Translation of isc-kea debconf templates to Spanish.
# Copyright (C) 2023 Camaleón 
# This file is distributed under the same license as the isc-kea package.
# Camaleón , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: isc-kea\n"
"Report-Msgid-Bugs-To: isc-...@packages.debian.org\n"
"POT-Creation-Date: 2023-03-29 14:20-0300\n"
"PO-Revision-Date: 2023-07-09 16:50+0200\n"
"Language-Team: Debian Spanish \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.4.2\n"
"Last-Translator: Camaleón \n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"Language: es\n"

#. Type: password
#. Description
#: ../kea-ctrl-agent.templates:1001
msgid "New password for the kea control agent \"kea_api\" user:"
msgstr "Nueva contraseña del usuario «kea-api» del Agente de Control Kea:"

#. Type: password
#. Description
#: ../kea-ctrl-agent.templates:1001
msgid "This password will be stored in the /etc/kea/kea-api-password file."
msgstr ""
"Esta contraseña se guardará en el archivo «/etc/kea/kea-api-password»."

#. Type: password
#. Description
#: ../kea-ctrl-agent.templates:1001
msgid "NOTE: if the password is empty, no action will be taken."
msgstr ""
"NOTA: si deja la contraseña en blanco, no se llevará a cabo ninguna acción."

#. Type: password
#. Description
#: ../kea-ctrl-agent.templates:2001
msgid "Repeat password for the kea control agent \"kea_api\" user:"
msgstr ""
"Vuelva a introducir la contraseña del usuario «kea-api» del Agente de "
"Control Kea:"

#. Type: error
#. Description
#: ../kea-ctrl-agent.templates:3001
msgid "Password input error"
msgstr "Error al introducir la contraseña"

#. Type: error
#. Description
#: ../kea-ctrl-agent.templates:3001
msgid "The two passwords you endered were not the same. Please try again."
msgstr "Las contraseñas que ha introducido no coinciden. Inténtelo de nuevo."

#. Type: select
#. Description
#: ../kea-ctrl-agent.templates:4001
msgid "Kea control agent authentication configuration"
msgstr "Configuración de la autentificación del Agente de Control Kea"

#. Type: select
#. Description
#: ../kea-ctrl-agent.templates:4001
msgid ""
"Starting with this version, the Kea Control Agent will be configured to "
"require authentication by default."
msgstr ""
"A partir de esta versión, el Agente de Control Kea se configurará para "
"requerir autentificación de manera predeterminada."

#. Type: select
#. Description
#: ../kea-ctrl-agent.templates:4001
msgid "The available options are:"
msgstr "Las opciones disponibles son:"

#. Type: select
#. Description
#: ../kea-ctrl-agent.templates:4001
msgid ""
" do nothing:\n"
"  Until you create /etc/kea/kea-api-password, either manually or using one "
"the other options described here, the service will not start."
msgstr ""
" no hacer nada:\n"
"  El servicio no se iniciará hasta que no se genere el archivo «/etc/kea/"
"kea-api-password», bien manualmente o utilizando alguna de las otras "
"opciones descritas en este apartado."

#. Type: select
#. Description
#: ../kea-ctrl-agent.templates:4001
msgid ""
" configured with a random password:\n"
"  The packaging will generate a random password for you, save it, and start "
"the service."
msgstr ""
" configurado con una contraseña aleatoria:\n"
"  El paquete generará una contraseña aleatoria para usted, la guardará e "
"iniciará el servicio."

#. Type: select
#. Description
#: ../kea-ctrl-agent.templates:4001
msgid ""
" configured with password:\n"
"  The packaging will save the password you supply, and start the service. "
"Note that an empty password will result in no action and be equivalent to "
"\"do nothing\" above."
msgstr ""
" configurado con contraseña:\n"
"  El paquete guardará la contraseña que introduzca e iniciará el servicio. "
"Tenga en cuenta que una contraseña en blanco no generará ninguna acción y "
"será equivalente a la opción «no hacer nada»."

#. Type: select
#. Description
#: ../kea-ctrl-agent.templates:4001
msgid ""
"The username is `kea-api`, and the password will be expected to be in `/etc/"
"kea/kea-api-password`."
msgstr ""
"El nombre de usuario es «kea-api» y se espera que la contraseña esté en el "
"archivo «/etc/kea/kea-api-password»."

Bug#1036240: bullseye-pu: package kscreenlocker/5.20.5-1+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Wed, May 17, 2023 at 10:56:53PM +0200, Patrick Franz wrote:
> When trying to unlock the screen and entering a wrong password,
> it can lead to an endless loop when using the PAM module.
> This fix applies a patch from upstream that fixes the
> behaviour.
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035732

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1023205: bullseye-pu: package memtest86+/6.00-1

[Jonathan Wiltshire]

Control: tag -1 moreinfo

Hi,

On Mon, Oct 31, 2022 at 05:38:07PM +0100, Felix Zielcke wrote:
> memtest86+ 5.01-3.1 in stable is very old and doestn't run correctly
> on recent hardware.

In the meantime I see there has been a backport of 6 to bullseye-backports.
Is it still the best course of action to remove 5.01-3.1 from stable, or
does it work well enough on old hardware to be worth keeping?

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1041769: geeqie: TIFF renders as an upside-down mirror of former CCITT docs

[Andreas Rönnquist]

On Sun, 23 Jul 2023 12:45:45 +0200
debbug.gee...@sideload.33mail.com wrote:

Thanks for your report - 

>Bug 646982 reports a problem with correcting the orientation, but we
>have to ask why the TIFF orientation needed correction in the first
>place. This entry in the release notes looks interesting:
>
>===8<--
>geeqie (1:1.5.1+git20200708-1) unstable; urgency=medium
>
>  * Update README.Debian - mention GDK_CORE_DEVICE_EVENT, remove obsolete
>info about gqview
>  * New upstream git snapshot 1.5.1+git20200708 - Fixes rendering
>under wayland (Closes: #964441)
>  * Remove patches applied upstream:
>  0001-Fix-710-Apply-the-orientation-to-image-content-not-w.patch
>  0002-Fix-736-Please-migrate-from-gnome-doc-tool-to-yelp-b.patch
>  0004-Fix-741-Crash-when-creating-new-dir-with-same-name-a.patch
>  fix_multiple_definitions_with_gcc_10.patch
>  * Refresh patch 0003-Remove-changelog-from-menu-item.patch
>  * Add patch to fix version number on git snapshot and
>add Forwarded: not-needed to silence lintian
>===8<--
>
>Might that removed patch (0001-…) be related?  Because of that
>possibility, I did not mark this bug as upstream.

This changelog marks the removal of this patch, since the content of it
were applied to geeqie upstream at this time.

Upstream commit applying the content of the patch here:
https://github.com/BestImageViewer/geeqie/commit/fdb45ac5f99283775d655fa36b23b4be7905951e

>
>Unfortunately I have no sample to attach. Perhaps I can scan an
>arbitrary non-personal document in the future to supply a sample, if
>needed.
>

A sample would be helpful - I have tried saving an tiff image in
gimp and shown it in geeqie, but that showed without error.

I would very much suppose that the behaviour in this case is the same
in the upstream source as in the Debian package. 

/Andreas

Bug#1041742: RFS: keepassxc-proxy-client/0.1.6-1 [ITP] -- Library to access a running KeepassXC instance

[Antonio Russo]

Hello all,

Upstream has released another version incorporating a typo lintian found, and 
now
pushes version tags (but does not yet have a gpg key to sign them). I've updated
the packaging and pushed another release to mentors:

   https://mentors.debian.net/package/keepassxc-proxy-client/

Alternatively, you can download the package with 'dget' using this command:

   dget -x 
https://mentors.debian.net/debian/pool/main/k/keepassxc-proxy-client/keepassxc-proxy-client_0.1.7-1.dsc

All changes are squashed into the initial release:

 keepassxc-proxy-client (0.1.7-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1041718)

Best,
Antonio Russo

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036799: sylpheed: unable to send or read email after upgrading to Debian 12

[José Luis González]

control: severity -1 grave

Hi Ricardo,

> Right, but that doesn't deserve a 'grave' severity as only gsmtp users
> are affected and no data is lost or security hole is introduced. I've
> adjusted this accordingly.

The definition of grave severity is:

  grave
  makes the package in question unusable or mostly so, or causes
  data loss, or introduces a security hole allowing access to the
  accounts of users who use the package.

This bug renders sylpheed unusuable or mostly so for me, so it is
indeed a grave bug. I am restoring severity accordingly.

> That has been reported on the list that downgrading to 3.7.0 fixes the
> problem: https://www.sraoss.jp/pipermail/sylpheed/2023-May/007129.html

> Can you check if downgrading fixes it?

I wish I could check it but so far the only way I have to do so is
installing from source. What I can confirm is the bug appeared when
upgrading from version 3.7.0 to version 3.8.0~beta1-1.

I hope you understand this bug is preventing me from using sylpheed
and so from reading and writing email, unless from gmail's web
interface. I find of great concern that the bug is in Debian's new
stable distribution: bookworm. If you know the bug is in version
3.8.0~beta1-1 I would suggest downgrading stable to 3.7.0 if you can
manage to do so.

Best regards,
José Luis

Bug#1040950: autofs 5.1.7-1+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1040950 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: autofs
Version: 5.1.7-1+deb11u1

Explanation: fix missing mutex unlock; do not use rpcbind for NFS4 mounts

Bug#1041498: testng7 7.5-2~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1041498 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: testng7
Version: 7.5-2~deb12u1

Explanation: backport to stable for future openjdk-17 builds

Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386

[Dirk Eddelbuettel]

Paul,

Is this is not an example of a release manager override? The affectect
packages all work together in unstable and could migrate.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1040951: bookworm-pu: package dhcpcd5/9.4.1-24 deb12u1

[Jonathan Wiltshire]

On Sun, Jul 23, 2023 at 01:59:38PM +0300, Martin-Éric Racine wrote:
> Looking at upstream, it seems that there stil are infrequent updates
> for branch 9. Currently up to 9.5.2. Those are cherry-picks from
> branch 10.
> 
> I tried a quick build. It's Lintian clean, and it removes the need for
> debian/patches.
> 
> Would this be acceptable for Bookworm? If yes, what would be the
> correct version to use?

Impossible to say without a diff, but there's generally no gain to
packaging new upstreams in stable just to remove patches unless there is
some other fix included as well. If you think there are things which meet
the criteria please open a fresh request to review them, don't keep adding
things onto this bug.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1041771: postinst: Unknown option: q

[Daniel Leidert]

Package: open-vm-tools-containerinfo
Version: 2:12.2.5-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The postinst throws this warning:

open-vm-tools-containerinfo (2:12.2.5-1) [..]
Unknown option: q
inactive

The -q switch used does not exist. The output ćan be redirected to /dev/null.

Regards, Daniel



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

Kernel: Linux 6.3.0-2-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 open-vm-tools-containerinfo depends on:
ii  libabsl20220623  20220623.1-1
ii  libc62.37-6
ii  libcurl4 7.88.1-10
ii  libgcc-s113.1.0-9
ii  libglib2.0-0 2.76.4-3
ii  libgrpc++1.511.51.1-3+b2
ii  libgrpc291.51.1-3+b2
ii  libprotobuf323.21.12-6
ii  libstdc++6   13.1.0-9
ii  open-vm-tools2:12.2.5-1

open-vm-tools-containerinfo recommends no packages.

open-vm-tools-containerinfo suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmS9EzkACgkQS80FZ8KW
0F1aKQ//Zr/NgG70m5TGB3mts1bUgd/HCKzlAb+YIzalf7ZgyvEzzmhai+g5ZViM
l1IS8m/gGLi+e7DzFTC1fZJdJF59ZUoFZscY5V5G9DRy0wdCn6tshd1NqJ+GfyMK
ufkLBsbAiJOEI5XuFKNKJEpqVy2vOEX9SSEBOGg9VKaLRWsLRyQXsXoJL3kLhx1D
HIAMuvZ1Q4fh0If8BQrUo8ghztNFkUl+mUfadcwlb5HEZYGpvpM7m+5nXiBu7jZ5
aiQShB9NzWpi2udkz3W/Xv/YKbGZ6py7yfR1lyBHgOHabWHU0II+N6hdi9PZBT3X
Ib1RZThV5pxqx4smzBGnjfZoBcB6U0q3kGw2I9b2e/I11m747d4xlqV5DgIwMu5O
O6kG6ujL2/z7WQnuwGVqzP86864bbiurM7N4BxaKqPFW4Ji+aa1oU9Lnrnqhaq8O
4CssZxZAy3e995JvGHLLtrs/r4cLSObsXkfRrf65EC0I+SVDcmhGMHT5mxQa1HQp
8DAtVdM8A+P0BU8F7Uhb9dZ9VxYmZdKmEIY6Ce+dx2YI7dKOHEsChTWkEIyKvQIe
jMWqzwPka7AuBCddFSXgoDwKCYfM2U+zyq3rkn3coTgUxnQZ7qOYveKUqF+JcdU9
mBR+awgVsLwa8A+Xw7OvPtkziHs3/DqY5ZwXpsRuxYPKnx9NqN8=
=1r/4
-END PGP SIGNATURE-

Bug#1041750: apt-get changelog nvidia-driver fails with "Changelog unavailable"

[David Kalnischkies]

On Sat, Jul 22, 2023 at 11:14:43PM -0400, Allan Wind wrote:
> $ apt-get changelog nvidia-driver
> Err:1 https://metadata.ftp-master.debian.org nvidia-graphics-drivers 
> 525.125.06-1~deb12u1 Changelog
>   Changelog unavailable for nvidia-graphics-drivers=525.125.06-1~deb12u1 (404 
>  Not Found [IP: 146.75.34.132 443])
> E: Failed to fetch 
> https://metadata.ftp-master.debian.org/changelogs/non-free/n/nvidia-graphics-drivers/nvidia-graphics-drivers_525.125.06-1%7edeb12u1_changelog
>   Changelog unavailable for nvidia-graphics-drivers=525.125.06-1~deb12u1 (404 
>  Not Found [IP: 146.75.34.132 443])
> 
> The information exist as I was able to find it via:
> 
> https://www.debian.org/News/2023/20230722 ->
> https://packages.debian.org/search?searchon=sourcenames=nvidia-graphics-drivers
>  ->
> https://packages.debian.org/source/bullseye/nvidia-graphics-drivers ->
> https://metadata.ftp-master.debian.org/changelogs//non-free-firmware/n/nvidia-graphics-drivers/nvidia-graphics-drivers_525.125.06-1~deb12u1_changelog

The problem here is that the (binary) package you request is in section
non-free, while the source package this boils down to is in section
non-free-firmware.

A similar situation could arise with main/contrib or contrib/non-free
I presume, so this isn't a new problem.


`pkgAcqChangelog::URI(pkgCache::VerIterator const&)` in
apt-pkg/acquire-item.cc would need to be changed from using
a VerFileIterator from the binary package to going 'manually' on the
hunt for a (= there be many…) Sources file(s) containing the source
package and from there get the Section and from that also the Release
file.

Alternatively, the server side could just merge the components as there
can't really be different source packages with the same name in different
components and the metadata hopefully doesn't have the same restrictions
applied to it than the packages itself…


Either way, that just as a comment as I won't be working on a fix for
now as I remember people talking about completely overhauling the
implementation/setup client and/or server anyhow.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1041685: foot-terminfo: Please let ncurses-term take over the foot terminfo entries

[Birger Schacht]

Hi Sevn,

On 7/22/23 16:44, Sven Joachim wrote:

Hi Birger,

thanks for the quick reply.

On 2023-07-22 12:39 +0200, Birger Schacht wrote:


Sure, lets do this!

I've created https://salsa.debian.org/birger/foot/-/merge_requests/5
to prepare the switch.


The version of ncurses-term in unstable is 6.4+20230625-1, so foot and
the transitional foot-terminfo package need to depend on ncurses-term
(>= 6.4+20230625-2).


Thanks, I've updated the MR. Ready to upload any time.

cheers,
Birger

Bug#1033658: [m...@debian.org: Re: Bug#1033658: ftp.debian.org: Please add "riscv64" to the archive]

[Mark Hymers]

- Forwarded message from Mark Hymers  -

> Date: Sun, 23 Jul 2023 11:25:21 +0100
> From: Mark Hymers 
> To: "Manuel A. Fernandez Montecelo" , 
> 1033658-d...@bugs.debian.orgg
> Cc: Aurelien Jarno 
> Subject: Re: Bug#1033658: ftp.debian.org: Please add "riscv64" to the archive
> 
> mhy@fasolo:~$ dak ls acl -s unstable
> acl| 2.3.1-3   | unstable   | source, amd64, arm64, armel, armhf, 
> i386, mips64el, mipsel, ppc64el, riscv64, s390x
> 
> Done
> 
> -- 
> Mark Hymers 

- End forwarded message -

-- 
Mark Hymers 

Bug#1030394: Bug#1040690: Bug#1030394: Bug#1040690: reassign bug to correct package

[David Bremner]

Richard Lewis  writes:

> I suspect a plain chroot isnt 'enough', i had success with systemd-nspawn:
>
> ln -s /tmp/bullseye/ /var/lib/machines
>
> # im sure there is a better way than these two lines
> cp /etc/passwd bullseye/etc/passwd
> cp /etc/shadow bullseye/etc/shadow
>
> systemd-nspawn --ephemeral --boot --machine bullseye
> # (you dont really need --ephemeral of course)
>
> log into the container as root:
> # apt install emacs-gtk
>
> (and say yes to allow the installation to finish)
>
> # ls /usr/share/emacs/site-lisp/elpa
> dash-2.17.0  dash-functional-1.2.0  elisp-refs-1.4  helpful-0.18  loop-1.3
> dash-2.19.1  elisp-refs-1.3 f-0.20.0helpful-0.19  s-1.12.0
>
> Shows the 'duplicate' dirs for the old versions of elpa-dash and elpa-helpful
>

Did you start from a clean debootstrap here?  Because I don't see where
in your second reproducer the addon packages get installed.

Bug#1041590: nvidia-installer-cleanup install fail

[Terrance Hendrik]

YES!

I did
```
unset DEBIAN_PRIORITY
unset DEBIAN_FRONTEND
```
Then a ncurse window popped up and the install finished.

Thanks!!


On Sat, Jul 22, 2023 at 3:49 AM Andreas Beckmann  wrote:

> On 21/07/2023 06.41, Terrance Hendrik wrote:
> > Unpacking nvidia-installer-cleanup (20220217+3) ...
> > Setting up nvidia-installer-cleanup (20220217+3) ...
> > dpkg: error processing package nvidia-installer-cleanup (--configure):
> >   installed nvidia-installer-cleanup package post-installation script
> > subprocess returned error exit status 30
>
> This sounds like debconf couldn't display a question.
>
> Did you customize the debconf priority on this system? Or do you use
> something like DEBIAN_FRONTEND=noninteractive ?
>
> Have you ever had the nvidia driver installed from the .run installer on
> this machine?
>
> Andreas
>

Bug#1040951: dhcpcd5 9.4.1-24~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1040951 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: dhcpcd5
Version: 9.4.1-24~deb12u1

Explanation: ease upgrades with leftovers from wheezy; drop deprecated ntpd 
integration

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Luca Boccassi]

On Tue, 20 Jun 2023 22:53:24 +0100 Luca Boccassi 
wrote:
> On Sun, 18 Jun 2023 13:38:12 +0100 Luca Boccassi 
> wrote:
> > On Sun, 18 Jun 2023 at 13:03, Sean Whitton

> wrote:
> > >
> > > Hello,
> > >
> > > On Fri 16 Jun 2023 at 05:57PM +01, Luca Boccassi wrote:
> > >
> > > > Is there anything needed from me to make progress on this? Any
> changes
> > > > required to the last revision posted?
> > >
> > > Yes, Russ posted some comments on your most recent revision, I
> believe.
> > 
> > Last one I can find with specifics is:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945269#140
> > 
> > Which I think I have addressed in a follow-up. Did I miss
something?
> 
> Russ, anything I've missed that you want me to change from the most
> recent revision at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945269#160 ?

Monthly ping. Anything I can do to unblock this?

-- 
Kind regards,
Luca Boccassi


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

Bug#1041758: libcudf-dev is not installable due to bogus janitor change

[Sven Joachim]

On 2023-07-23 10:57 +0300, Adrian Bunk wrote:

> On Sun, Jul 23, 2023 at 09:03:24AM +0200, Sven Joachim wrote:
>> On 2023-07-23 09:37 +0300, Adrian Bunk wrote:
>>
 > I haven't checked whether the replacement package names are correct,
>> > but the = dependences hardcoded in debian/control are clearly wrong.
>>
>> Hardcoding a dependency on libtinfo6 is also wrong, but libncurses-dev
>> is indeed the successor of libncurses5-dev.
>
> I think the root cause is that the janitor did an automatic and
> incorrect replacement based on the transitional package in buster:
>
> Package: libncurses5-dev
> Version: 6.1+20181013-2+deb10u2
> Depends: libtinfo6 (= 6.1+20181013-2+deb10u2), libncurses-dev (= 
> 6.1+20181013-2+deb10u2)
>
> libncurses5-dev depending on libtinfo6 might be unnecessary since
> libncurses-dev already depends on it, but that doesn't make it bogus.

That dependency was created by dh_link, since
/usr/share/doc/libncurses5-dev was a symlink to libtinfo6.  I could have
used libncurses-dev as target of the symlink instead and thereby avoid a
direct dependency on libtinfo6 at the cost of slightly complicating
debian/rules, but that is moot now.

> Using = dependencies in a transitional package is unusual but not
> incorrect when these packages are built from the same source package.

Again, the /usr/share/doc symlink forced a strict dependency anyway.

> The dependency of libncurses5-dev could therefore likely be simplified to
>   Depends: libncurses-dev

That is correct.

> but the problem is seems to that the janitor does not have a sanity check
> to refuse a replacement.
>
> I see two bugs in the janitor here:
>
> 1. >= or >> dependencies in the replacement are OK, = dependencies are not.
> <= or << dependencies should likely also be refused since they should
> be checked by a human.
>
> 2. Dependencies on two packages are usually a package split, automatic
> replacement works but might often be wrong for the different reason that
> it creates too many dependencies.

Agreed.

Cheers,
   Sven

Bug#1041554: openscap 1.3.7+dfsg-1+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1041554 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: openscap
Version: 1.3.7+dfsg-1+deb12u1

Explanation: fix dependencies of openscap-utils and python3-openscap

Bug#1041555: stunnel4 5.68-2+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1041555 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: stunnel4
Version: 5.68-2+deb12u1

Explanation: fix handling of a peer closing TLS connection without proper 
shutdown messaging

Bug#1041468: hnswlib 0.6.2-2+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1041468 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: hnswlib
Version: 0.6.2-2+deb12u1

Explanation: fix double free in init_index when the M argument is a large 
integer [CVE-2023-37365]

Bug#1040951: bookworm-pu: package dhcpcd5/9.4.1-24 deb12u1

[Martin-Éric Racine]

On Sat, Jul 22, 2023 at 7:33 PM Adam D. Barratt
 wrote:
>
> On Sat, 2023-07-22 at 19:29 +0300, Martin-Éric Racine wrote:
> > On Sat, Jul 22, 2023 at 7:26 PM Adam D. Barratt
> >  wrote:
> > > On Sat, 2023-07-22 at 18:03 +0300, Martin-Éric Racine wrote:
> > > > Sure enough, I had forgotten to change the version used in
> > > > dhcpcd.preinst to the tilde one. Fixed as per attachment.
> > >
> > > Please could we have an interdiff from ~deb12u1, to make seeing the
> > > specific change simpler?
> >
> > Sure. Attached.
> >
>
> Thanks, please feel free upload with that diff.

Done.

Looking at upstream, it seems that there stil are infrequent updates
for branch 9. Currently up to 9.5.2. Those are cherry-picks from
branch 10.

I tried a quick build. It's Lintian clean, and it removes the need for
debian/patches.

Would this be acceptable for Bookworm? If yes, what would be the
correct version to use?

Thanks!
Martin-Éric

Bug#1041770: systemctl preset failed on greetd.service: No such file or directory

[Dan Jacobson]

Package: greetd
Version: 0.9.0-3

Unpacking greetd (0.9.0-3) ...
Setting up greetd (0.9.0-3) ...
Failed to preset unit, file "/etc/systemd/system/display-manager.service" 
already exists and is a symlink to "/lib/systemd/system/xdm.service".
/usr/bin/deb-systemd-helper: error: systemctl preset failed on greetd.service: 
No such file or directory

Bug#1040690: reproducer(s)

[Richard Lewis]

On Sun, 23 Jul 2023, 11:19 David Bremner,  wrote:

> Richard Lewis  writes:
>
> > I suspect a plain chroot isnt 'enough', i had success with
> systemd-nspawn:
> >
>
> Not sure what you mean here. The reproducer using chroot you posted
> works fine for me, it's just that AFAICT the real bug is the emacs
> upgrade failing (and more precisely, in emacs being unable to run a
> simple batch-byte-compile command after the new version is installed),
> nothing to do with addon packages.
>


i may be wrong, but i suspect there are two separate issues:

- a previously undetected bug where upgrading emacs in a plain chroot
doesnt work. clearly emacs can be upgraded on a normal system or in a
container or it would have been spotted well before now. my guess is that
this will be found to be caused by emacs relying in some complex way on
some feature of a "real" system not suported by plain old chroots..( i have
no idea what but maybe it needs /dev/pts mounted or i think inotify might
not work in a chroot).

- upgrading emacs and dh-elpa and (some) packages made using dh-elpa doesnt
properly remove the "old" directories in /usr/share/emacs. (#1040690)


it is not obvious to me that fixing the first will help with the second,
because if we do everything in a systemd-nspawn container we dont hit the
first but at all, but do still see the second. (and the second is the one
that im really hoping someone can solve !)

of couse this is just my speculation, and may all be nonsense.

Bug#1041769: geeqie: TIFF renders as an upside-down mirror of former CCITT docs

[debbug . geeqie]

Package: geeqie
Version: 1:1.6-9+deb11u1
Severity: important
X-Debbugs-Cc: debbug.gee...@sideload.33mail.com

TIFF files display as an upside-down mirror image. The reproduction steps are:

  1. Scan a text document on a Konica Minolta bizhub C360i MFD & save to USB
  2. $ pdfimages -all $scanned_pdf innards
  3. $ fax2tiff $(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646982

Bug 646982 reports a problem with correcting the orientation, but we
have to ask why the TIFF orientation needed correction in the first
place. This entry in the release notes looks interesting:

===8<--
geeqie (1:1.5.1+git20200708-1) unstable; urgency=medium

  * Update README.Debian - mention GDK_CORE_DEVICE_EVENT, remove obsolete
info about gqview
  * New upstream git snapshot 1.5.1+git20200708 - Fixes rendering
under wayland (Closes: #964441)
  * Remove patches applied upstream:
  0001-Fix-710-Apply-the-orientation-to-image-content-not-w.patch
  0002-Fix-736-Please-migrate-from-gnome-doc-tool-to-yelp-b.patch
  0004-Fix-741-Crash-when-creating-new-dir-with-same-name-a.patch
  fix_multiple_definitions_with_gcc_10.patch
  * Refresh patch 0003-Remove-changelog-from-menu-item.patch
  * Add patch to fix version number on git snapshot and
add Forwarded: not-needed to silence lintian
===8<--

Might that removed patch (0001-…) be related?  Because of that
possibility, I did not mark this bug as upstream.

Unfortunately I have no sample to attach. Perhaps I can scan an
arbitrary non-personal document in the future to supply a sample, if
needed.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages geeqie depends on:
ii  geeqie-common1:1.6-9+deb11u1
ii  libc62.31-13+deb11u5
ii  libcairo21.16.0-5
ii  libchamplain-0.12-0  0.12.20-1
ii  libchamplain-gtk-0.12-0  0.12.20-1
ii  libclutter-1.0-0 1.26.4+dfsg-2
ii  libclutter-gtk-1.0-0 1.8.4-4
ii  libcogl201.22.8-2
ii  libdjvulibre21   3.5.28-2
ii  libexiv2-27  0.27.3-3+deb11u1
ii  libffmpegthumbnailer4v5  2.1.1-0.2+b1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libheif1 1.11.0-1
ii  libjpeg62-turbo  1:2.0.6-4
ii  liblcms2-2   2.12~rc1-2
ii  liblirc-client0  0.10.1-6.3
ii  liblua5.1-0  5.1.5-8.1+b3
ii  libopenjp2-7 2.4.0-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpoppler-glib8 20.09.0-3.1+deb11u1
ii  libstdc++6   10.2.1-6
ii  libtiff5 4.2.0-1+deb11u1
ii  libwebp6 0.6.1-2.1
ii  sensible-utils   0.0.14

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.3.3op2-3+deb11u2
ii  exiftran 2.10-4
ii  exiv20.27.3-3+deb11u1
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  librsvg2-common  2.50.3+dfsg-1
ii  zenity   3.32.0-6

Versions of packages geeqie suggests:
pn  geeqie-dbg 
ii  gimp   2.10.22-4
pn  libjpeg-progs  
pn  xpaint 

-- no debconf information

Bug#1041768: start-stop-daemon: pid value must be a number greater than 0

[Dan Jacobson]

Package: xdm
Version: 1:1.1.11-3+b2

# dpkg-reconfigure xdm #and then chose xdm. Then we see:
start-stop-daemon: pid value must be a number greater than 0
Try 'start-stop-daemon --help' for more information.

Bug#1041767: Subject: eln-cache piling up

[Dan Jacobson]

Package: emacs-bin-common
Version: 1:28.2+1-15

These are piling up on user's disks,

$ du -sh .emacs.d/eln-cache/*
4.0K.emacs.d/eln-cache/28.2-43f520ab
19M .emacs.d/eln-cache/28.2-467432cd
4.0K.emacs.d/eln-cache/28.2-7a6329ed
23M .emacs.d/eln-cache/28.2-8ab3e389
31M .emacs.d/eln-cache/28.2-e4556eb6
26M .emacs.d/eln-cache/28.2-fd960886

with no cleaning happening.
https://gitlab.alpinelinux.org/alpine/aports/-/issues/13684
mentions it might be some flag left on during compiling.

Bug#1041766: xtrx-dkms: Getting a conflict for gcc-12. xtrx-dkms wants kernel 6.4.3 but says debian version already built. Brand new Kali install with Kernel upgrade to 6.4.3

[Brent LaGasa]

Package: xtrx-dkms
Version: 0.0.1+git20190320.5ae3a3e-3.2+kali1
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: anonymousro...@proton.me

Dear Maintainer,

Get:1 http://http.kali.org/kali kali-rolling/main amd64 lshw amd64 
02.19.git.2021.06.19.996aaad9c7-2+b1 [300 kB]
Get:2 http://mirrors.ocf.berkeley.edu/kali kali-rolling/main amd64 
python3-gpumodules all 3.8.0-1 [39.1 kB]
Get:3 http://mirrors.ocf.berkeley.edu/kali kali-rolling/main amd64 
rickslab-gpu-utils all 3.8.0-1 [582 kB]
Fetched 921 kB in 1s (982 kB/s) 
Selecting previously unselected package lshw.
(Reading database ... 748769 files and directories currently installed.)
Preparing to unpack .../lshw_02.19.git.2021.06.19.996aaad9c7-2+b1_amd64.deb ...
Unpacking lshw (02.19.git.2021.06.19.996aaad9c7-2+b1) ...
Selecting previously unselected package python3-gpumodules.
Preparing to unpack .../python3-gpumodules_3.8.0-1_all.deb ...
Unpacking python3-gpumodules (3.8.0-1) ...
Selecting previously unselected package rickslab-gpu-utils.
Preparing to unpack .../rickslab-gpu-utils_3.8.0-1_all.deb ...
Unpacking rickslab-gpu-utils (3.8.0-1) ...
Setting up xtrx-dkms (0.0.1+git20190320.5ae3a3e-3.2+kali1) ...
Removing old xtrx-0.0.1+git20190320.5ae3a3e-3.2+kali1 DKMS files...
Deleting module xtrx-0.0.1+git20190320.5ae3a3e-3.2+kali1 completely from the 
DKMS tree.
Loading new xtrx-0.0.1+git20190320.5ae3a3e-3.2+kali1 DKMS files...
Building for 6.4.3-060403-generic
Building initial module for 6.4.3-060403-generic
Error! Bad return status for module build on kernel: 6.4.3-060403-generic 
(x86_64)
Consult /var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.2+kali1/build/make.log 
for more information.
dpkg: error processing package xtrx-dkms (--configure):
 installed xtrx-dkms package post-installation script subprocess returned error 
exit status 10
Setting up lshw (02.19.git.2021.06.19.996aaad9c7-2+b1) ...
Setting up python3-gpumodules (3.8.0-1) ...
Setting up rickslab-gpu-utils (3.8.0-1) ...
Processing triggers for doc-base (0.11.1) ...
Processing 1 added doc-base file...
Processing triggers for man-db (2.11.2-2) ...
Processing triggers for kali-menu (2023.3.3) ...
Errors were encountered while processing:
 xtrx-dkms
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

ghost@oracle:~$ sudo nano 
/var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.2+kali1/build/make.log

ghost@oracle:~$ clinfo
Command 'clinfo' not found, but can be installed with:
sudo apt install clinfo
Do you want to install it? (N/y)y
sudo apt install clinfo
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  gir1.2-javascriptcoregtk-4.0 gir1.2-soup-2.4 gir1.2-webkit2-4.0 
gobject-introspection king-phisher libgdal32 liblc3-0
  libmongocrypt0 libmujs2 libncurses5 libsoup-gnome2.4-1 libtinfo5 libyara9 
python3-advancedhttpserver python3-boltons
  python3-cairo-dev python3-flask-security python3-geojson python3-graphene 
python3-graphene-sqlalchemy
  python3-graphql-core python3-graphql-relay python3-icalendar 
python3-jaraco.classes python3-promise
  python3-pytz-deprecation-shim python3-rule-engine python3-rx tftp
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
  clinfo
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 56.8 kB of archives.
After this operation, 193 kB of additional disk space will be used.
Get:1 http://mirrors.ocf.berkeley.edu/kali kali-rolling/main amd64 clinfo amd64 
3.0.23.01.25-1 [56.8 kB]
Fetched 56.8 kB in 1s (75.8 kB/s)
Selecting previously unselected package clinfo.
(Reading database ... 748816 files and directories currently installed.)
Preparing to unpack .../clinfo_3.0.23.01.25-1_amd64.deb ...
Unpacking clinfo (3.0.23.01.25-1) ...
Setting up xtrx-dkms (0.0.1+git20190320.5ae3a3e-3.2+kali1) ...
Removing old xtrx-0.0.1+git20190320.5ae3a3e-3.2+kali1 DKMS files...
Deleting module xtrx-0.0.1+git20190320.5ae3a3e-3.2+kali1 completely from the 
DKMS tree.
Loading new xtrx-0.0.1+git20190320.5ae3a3e-3.2+kali1 DKMS files...
Building for 6.4.3-060403-generic
Building initial module for 6.4.3-060403-generic
Error! Bad return status for module build on kernel: 6.4.3-060403-generic 
(x86_64)
Consult /var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.2+kali1/build/make.log 
for more information.
dpkg: error processing package xtrx-dkms (--configure):
 installed xtrx-dkms package post-installation script subprocess returned error 
exit status 10
Setting up clinfo (3.0.23.01.25-1) ...
Processing triggers for kali-menu (2023.3.3) ...
Processing triggers for man-db (2.11.2-2) ...
Errors were encountered while processing:
 xtrx-dkms
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)


-- Above is the result of every attempted install of a pkg.  Sometimes the 
package 

Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)

[Jonathan Wiltshire]

Control: tag -1 = bookworm confirmed

On Sat, Jul 22, 2023 at 11:41:18PM -0700, Otto Kekäläinen wrote:
> Control: tag -1 moreinfo
> 
> Right, I will add this missing line to changelog:
> 
>   * New upstream version 10.11.4. Includes fixes for several severe 
> regressions,
> see details at https://mariadb.com/kb/en/mariadb-10-11-4-release-notes/
> 
> 
> (Same as unstable version in
> https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/b14ddfab21cc30c15714dd44bd4ed0a6c2998ce3)

Go ahead.

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1041152: udisks2: udisksd no longer mounts my USB-disk

[Gottfried Schwieters]

Maybe that this bug-report can be closed.

After my latest "aptitude update; aptitude full-upgrade" done this
morning, automount of the usb disk now works again. Since package
udisks2 is still version 2.10.0-3 there might have been a problem in
some other package or one of the dependencies (?) that got fixed.

So for the moment the problem is solved for me.

Greetings

Gottfried

Am Sonntag, dem 23.07.2023 um 10:01 +0200 schrieb Michael Biebl:
> Control: tags -1 + upstream
> 
> On Sat, 15 Jul 2023 10:51:15 +0200 Gottfried Schwieters 
>  wrote:
> > Package: udisks2
> > Version: 2.10.0-3
> > Severity: important
> > 
> > After the latest upgrade of udisksd it fails now to mount my USB
> > device
> > (external disk 5TB, ntfs). It gives the error shown below. (Manual
> > mount "mount /dev/sdc1 /mnt" still works).
> 
> Does it work if you run
> udisksctl mount --block-device /dev/sdc1
> 
> > 2023-07-15T10:38:11.497185+02:00 Anaga udisksd[938]: Error probing
> > device:
> > Error sending ATA command IDENTIFY DEVICE to '/dev/sdc': Unexpected
> > sense data
> > returned:#012: f0 00 01 00  00 00 00 0a  00 00 00 00  00 1d 00
> > 00
> > #0120010: 00 00 00 00  00 00 00 00  00 00 00 00  00
> > 00
> > 00 00
> > #012 (g-io-error-quark, 0)
> > 
> 
> Would probably be best to file this upstream at
> https://github.com/storaged-project/udisks/issues/

Bug#1041731: groff-base: "-" mapped as HYPHEN

[G. Branden Robinson]

At 2023-07-23T09:46:51+0100, Colin Watson wrote:
> On Sat, Jul 22, 2023 at 11:54:24PM -0500, G. Branden Robinson wrote:
> > I know it's not very generous to observe that Sven either made this
> > claim without verifying it first, or had no concern for the facts
> > when making it, but it's hard to account for otherwise.
> > 
> > https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0#n206
[snip]
> Please don't do this?  I really don't think there's a need to link
> [...] carelessness in bug reporting to a [...] conspiracy theory.

Okay, fair--my point would have been made as well or better if I had
used only a citing URL to punctuate it rather than indulging my tendency
to conduct social philosophy.

I'll shuffle a further thought on this to the end of the mail.

> > My reasoning is this:
> [...]
> > It is only through the efforts of people in groups 2 and 4 that any
> > headway will be made on the problem.  That is where the Sisyphean
> > effort lies.  The good news is that this effort distributes...but
> > only if distributors decide not to hide the problems.
> 
> OK.  Thanks for making the good-faith attempt, but I'm afraid this has
> not convinced me.  My reasoning is that, no matter what way you slice
> it, it should always be the case that there are many more people who
> read manual pages than people who write them.

Heh--you countered my oblique reference to the Debian Social Contract
with an oblique reference (wittingly or not) to the Ada 83 Rationale
document (though the insight is surely older still).  Well played!

> If you want to bring in real-world analogies: externalizing costs onto
> relatively powerless consumers in the hope of using them to relay
> complaints to the people in power offends my sense of natural justice.

The trouble with knowing me is that you know the best arguments to use
against me...

> Incidentally, I realize belatedly that in writing this I'm implying
> that correct typography in PDF output is without value.  I don't mean
> to imply that.

Admittedly off-topic, but...

Deri James has done terrific work on gropdf.  I've been wondering what
its prospects for moving into groff-base might be.  The day might not be
too far off when it make sense for 'pdf' rather than 'ps' to become
groff's default output format.  (Maybe sooner if I learn package
triggers well enough to resolve Debian #609549.)

> For a campaign that would put the burden closer to the correct set of
> shoulders, I suggest agitating for the reversal of
> https://bugs.debian.org/785353.

I was unaware of this report.  Thanks.  I see that one of the premises
for retirement of the Lintian warning is "these days even upstream groff
renders both - and \- as HYPHEN-MINUS."  That was never entirely true,
but it is once more not true on the 'utf8' output device.

> Lintian is in a better position to bother developers without causing
> problems for users in the meantime, and I somewhat regret not pushing
> back on that particular change at the time.  It's also in a position
> to give us quantitative distribution-wide data.

Fair.  Maybe Lintian developers can help me see a path to structuring
the style warnings for man pages that groff now supports, which is such
an ad hoc feature in its present form that I _didn't_ document it.
(Alex Colomar is already using it for Linux man-pages, though.)

https://savannah.gnu.org/bugs/?62042

> > [3] In full disclosure, the inclusion of "NEWS" in the release
> > announcement was at my prompting, because we got essentially no
> > feedback on the first 1.23.0 release candidate 3 years ago, and
> > I had thought that the reason was because we didn't tell people
> > what was new in it, to motivate them to upgrade.  (It's also
> > common, but not universal, practice in GNU software release
> > announcements.)
> > 
> > I now have to modify my understanding.  Much distribution
> > maintenance is robotic (often, I think, because it is done in
> > the course of professional employment, which was not the case
> > nearly as often in the 1990s when I became part of the FLOSS
> > ecosystem).
> 
> I'd also say that there's just a lot more to do than there was in the
> 1990s

[Please excuse a digression.]

We also enjoy productivity advantages that we didn't have back then.
CI/CD infrastructures were in their infancy in 2002, when Debian stable
had 11 architectures to support.  My professional experience
(anecdote!) leads me to believe that there is, at most, as much time
for on-the-clock engineering as there was then.  Just as "work expands
to fill the schedule allotted for it", any engineer time freed up by
improvements in processes or technology is not left for staff to attack
unsolved problems they perceive, be those problems within the firm's
mission or not.  Instead, it's swiftly reallocated to manager-directed
activities (usually meetings), particularly since the pandemic/Zoom era.
Middle managers in particular perceive themselves to 

Bug#1040690: reproducer(s)

[David Bremner]

Richard Lewis  writes:

> I suspect a plain chroot isnt 'enough', i had success with systemd-nspawn:
>

Not sure what you mean here. The reproducer using chroot you posted
works fine for me, it's just that AFAICT the real bug is the emacs
upgrade failing (and more precisely, in emacs being unable to run a
simple batch-byte-compile command after the new version is installed),
nothing to do with addon packages.

Bug#1041689: [Pkg-utopia-maintainers] Bug#1041689: Bug#1041689: Bug#1041689: udisks2: After upgrading to 2.10.0-3 on trixie, the service udisks2 does not start.

[Marc Bres Gil]

Hello Michael,

I went to upstream with the traces, and found an already reported bug there
on issues after updating to 2.10 with kde plasma (
https://github.com/storaged-project/udisks/issues/1139) . Added the info to
that bug report, for what I understand from the gdb trace, seems related to
some nvme function. Will see if it helps there.

Thanks for your guidance

Missatge de Michael Biebl  del dia dg., 23 de jul. 2023 a
les 10:03:

> Am 23.07.23 um 09:53 schrieb Michael Biebl:
>
> > @Marc: Can you please install the udisks2/libblockdev dbgsym package,
> > gather a backtrace and then filing the issue upstream.
>
>
> https://wiki.debian.org/HowToGetABacktrace
>


-- 
Marc Bres Gil
m...@bres.cat
marc.b...@gmail.com

Bug#1039613: nmap breaks udptunnel autopkgtest: UDPTunnel communication failed

[Paul Wise]

On Tue, 27 Jun 2023 21:40:14 +0200 Paul Gevers wrote:

> Source: nmap, udptunnel
> Control: found -1 nmap/7.94+dfsg1-1
> Control: found -1 udptunnel/1.1-9
...
> With a recent upload of nmap the autopkgtest of udptunnel fails in 
> testing when that autopkgtest is run with the binary packages of nmap 
> from unstable. It passes when run with only packages from testing.

I think this is likely to be a bug in nmap ncat, when I remove
udptunnel from the script by connecting ncat directly to ncat,
then the failure still happens with the autopkgtest.

I was able to reproduce this issue outside a chroot. I have attached a
pair of scripts; bad fails and good succeeds. In the good case, I use
`sleep` to hold stdin of `ncat -l` open for 2s, in the bad case I let
it use the stdin provided by the shell (a GNOME terminal pty here).

Looking at the diff between the verbose logs is interesting.
In the good case one select fd is ready and one becomes ready later,
the latter one gets used, but in the bad case both fds appear to be
ready immediately but neither of them get used.

-NCAT DEBUG: select returned 1 fds ready
-NCAT DEBUG: fd 3 is ready
-NCAT DEBUG: selecting, fdmax 3
-NCAT DEBUG: select returned 1 fds ready
+NCAT DEBUG: select returned 2 fds ready

So the issue can be worked around in the udptunnel script by piping
sleep to the ncat listener instead of launching ncat and then sleeping,
or the ncat change that caused this can get bisected and fixed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


bad
Description: application/shellscript
+ rm rx tx
+ echo foo
+ sleep 2s
+ ncat - -u -l 127.0.0.1 1234
Ncat: Version 7.94 ( https://nmap.org/ncat )
NCAT DEBUG: Initialized fdlist with 102 maxfds
Ncat: Listening on 127.0.0.1:1234
NCAT DEBUG: Added fd 3 to list, nfds 1, maxfd 3
NCAT DEBUG: Added fd 0 to list, nfds 2, maxfd 3
NCAT DEBUG: Initialized fdlist with 100 maxfds
NCAT DEBUG: selecting, fdmax 3
+ ncat -u 127.0.0.1 1234
NCAT DEBUG: select returned 1 fds ready
NCAT DEBUG: fd 3 is ready
NCAT DEBUG: Swapping fd[0] (3) with fd[1] (0)
NCAT DEBUG: Removed fd 3 from list, nfds 1, maxfd 0
Ncat: Connection from 127.0.0.1:57558.
NCAT DEBUG: Added fd 3 to list, nfds 2, maxfd 3
NCAT DEBUG: Added fd 3 to list, nfds 1, maxfd 3
NCAT DEBUG: selecting, fdmax 3
NCAT DEBUG: select returned 2 fds ready
NCAT DEBUG: fd 0 is ready
NCAT DEBUG: EOF on stdin
+ sleep 2s
+ head -vn-0 tx rx
==> tx <==
foo

==> rx <==
+ echo tx
tx
+ hd tx
  66 6f 6f 0a   |foo.|
0004
+ echo rx
rx
+ hd rx
+ echo diff
diff
+ diff -u tx rx
--- tx	2023-07-23 16:49:32.411502343 +0800
+++ rx	2023-07-23 16:49:32.411502343 +0800
@@ -1 +0,0 @@
-foo


good
Description: application/shellscript
+ rm rx tx
+ echo foo
+ + sleep 2sncat
 -u 127.0.0.1 1234
+ ncat - -u -l 127.0.0.1 1234
Ncat: Version 7.94 ( https://nmap.org/ncat )
NCAT DEBUG: Initialized fdlist with 102 maxfds
Ncat: Listening on 127.0.0.1:1234
NCAT DEBUG: Added fd 3 to list, nfds 1, maxfd 3
NCAT DEBUG: Added fd 0 to list, nfds 2, maxfd 3
NCAT DEBUG: Initialized fdlist with 100 maxfds
NCAT DEBUG: selecting, fdmax 3
NCAT DEBUG: select returned 1 fds ready
NCAT DEBUG: fd 3 is ready
NCAT DEBUG: Swapping fd[0] (3) with fd[1] (0)
NCAT DEBUG: Removed fd 3 from list, nfds 1, maxfd 0
Ncat: Connection from 127.0.0.1:36688.
NCAT DEBUG: Added fd 3 to list, nfds 2, maxfd 3
NCAT DEBUG: Added fd 3 to list, nfds 1, maxfd 3
NCAT DEBUG: selecting, fdmax 3
NCAT DEBUG: select returned 1 fds ready
NCAT DEBUG: fd 3 is ready
NCAT DEBUG: selecting, fdmax 3
+ sleep 2s
NCAT DEBUG: select returned 1 fds ready
NCAT DEBUG: fd 0 is ready
NCAT DEBUG: EOF on stdin
+ head -vn-0 tx rx
==> tx <==
foo

==> rx <==
foo
+ echo tx
tx
+ hd tx
  66 6f 6f 0a   |foo.|
0004
+ echo rx
rx
+ hd rx
  66 6f 6f 0a   |foo.|
0004
+ echo diff
diff
+ diff -u tx rx


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

Bug#1041765: nextcloud-desktop: Tray icon no longer works with gnome + indicator extension

[Ralf Jung]

Package: nextcloud-desktop
Version: 3.9.0-1
Severity: normal

Dear Maintainer,

since installing nextcloud-desktop 3.9, the systray icon no longer works as 
expected in Gnome (with the AppIndicator extension):
it shows shows three white dots instead of the nextcloud icon.
Nextcloud shows everything as fully synced, so I am fairly sure that these are 
the three dots Gnome shows when it cannot find the icon.
However, I am not sure why the icon can no longer be found -- it used to work 
fine before I did a big "apt upgrade" yesterday.

Here's another report of the same problem, with a screenshot:
https://forum.manjaro.org/t/nextcloud-client-icon-is-not-showing-correctly/138545

Kind regards,
Ralf

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

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

Versions of packages nextcloud-desktop depends on:
ii  libc6  2.37-5
ii  libcloudproviders0 0.3.1-2
ii  libgcc-s1  13.1.0-6
ii  libglib2.0-0   2.74.6-2
ii  libkf5archive5 5.107.0-1
ii  libnextcloudsync0  3.9.0-1
ii  libqt5core5a   5.15.8+dfsg-12
ii  libqt5dbus55.15.8+dfsg-12
ii  libqt5gui5 5.15.8+dfsg-12
ii  libqt5keychain10.14.1-1
ii  libqt5network5 5.15.8+dfsg-12
ii  libqt5qml5 5.15.8+dfsg-3
ii  libqt5quick5   5.15.8+dfsg-3
ii  libqt5quickcontrols2-5 5.15.8+dfsg-2
ii  libqt5sql5-sqlite  5.15.8+dfsg-12
ii  libqt5svg5 5.15.8-3
ii  libqt5webenginecore5   5.15.13+dfsg-1~deb12u1
ii  libqt5webenginewidgets55.15.13+dfsg-1~deb12u1
ii  libqt5widgets5 5.15.8+dfsg-12
ii  libstdc++6 13.1.0-6
ii  nextcloud-desktop-common   3.9.0-1
ii  nextcloud-desktop-l10n 3.9.0-1
ii  qml-module-qt-labs-platform5.15.8+dfsg-2
ii  qml-module-qtgraphicaleffects  5.15.8-2
ii  qml-module-qtqml   5.15.8+dfsg-3
ii  qml-module-qtqml-models2   5.15.8+dfsg-3
ii  qml-module-qtquick-controls2   5.15.8+dfsg-2
ii  qml-module-qtquick-dialogs 5.15.8-2
ii  qml-module-qtquick-layouts 5.15.8+dfsg-3
ii  qml-module-qtquick-window2 5.15.8+dfsg-3
ii  qml-module-qtquick25.15.8+dfsg-3

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  3.9.0-1

nextcloud-desktop suggests no packages.

-- no debconf information

Bug#1041731: groff-base: "-" mapped as HYPHEN

[Colin Watson]

On Sun, Jul 23, 2023 at 09:46:53AM +0100, Colin Watson wrote:
> On Sat, Jul 22, 2023 at 11:54:24PM -0500, G. Branden Robinson wrote:
> > My reasoning is this:
> [...]
> > It is only through the efforts of people in groups 2 and 4 that any
> > headway will be made on the problem.  That is where the Sisyphean effort
> > lies.  The good news is that this effort distributes...but only if
> > distributors decide not to hide the problems.
> 
> OK.  Thanks for making the good-faith attempt, but I'm afraid this has
> not convinced me.  My reasoning is that, no matter what way you slice
> it, it should always be the case that there are many more people who
> read manual pages than people who write them.  If you want to bring in
> real-world analogies: externalizing costs onto relatively powerless
> consumers in the hope of using them to relay complaints to the people in
> power offends my sense of natural justice.

Incidentally, I realize belatedly that in writing this I'm implying that
correct typography in PDF output is without value.  I don't mean to
imply that.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1041731: groff-base: "-" mapped as HYPHEN

[Colin Watson]

On Sat, Jul 22, 2023 at 11:54:24PM -0500, G. Branden Robinson wrote:
> On Sun, 23 Jul 2023 00:37:43 +0100, Colin Watson wrote:
> > > [...] the upstream NEWS file [...] make[s] [no] mention of this
> > > change, or how to revert it locally.
> 
> Yeah, see, that's where the hyphen-minus brigade gives itself away.
> 
> I know it's not very generous to observe that Sven either made this
> claim without verifying it first, or had no concern for the facts when
> making it, but it's hard to account for otherwise.
> 
> https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0#n206
[...]
> As annoyed as someone might be by "-" not copying and pasting correctly,
> be assured that I am at least ten times as annoyed by people adopting
> this QAnon-esque approach to software defect reporting.

Please don't do this?  I really don't think there's a need to link some
slight carelessness in bug reporting to a dangerous conspiracy theory.

There's a lot to be said for the simple observation that there is a
great deal of material in upstream's NEWS file and so it's easy for
perfectly well-meaning people to miss things.

> My reasoning is this:
[...]
> It is only through the efforts of people in groups 2 and 4 that any
> headway will be made on the problem.  That is where the Sisyphean effort
> lies.  The good news is that this effort distributes...but only if
> distributors decide not to hide the problems.

OK.  Thanks for making the good-faith attempt, but I'm afraid this has
not convinced me.  My reasoning is that, no matter what way you slice
it, it should always be the case that there are many more people who
read manual pages than people who write them.  If you want to bring in
real-world analogies: externalizing costs onto relatively powerless
consumers in the hope of using them to relay complaints to the people in
power offends my sense of natural justice.

For a campaign that would put the burden closer to the correct set of
shoulders, I suggest agitating for the reversal of
https://bugs.debian.org/785353.  Lintian is in a better position to
bother developers without causing problems for users in the meantime,
and I somewhat regret not pushing back on that particular change at the
time.  It's also in a position to give us quantitative distribution-wide
data.

> [3] In full disclosure, the inclusion of "NEWS" in the release
> announcement was at my prompting, because we got essentially no
> feedback on the first 1.23.0 release candidate 3 years ago, and I
> had thought that the reason was because we didn't tell people what
> was new in it, to motivate them to upgrade.  (It's also common, but
> not universal, practice in GNU software release announcements.)
> 
> I now have to modify my understanding.  Much distribution
> maintenance is robotic (often, I think, because it is done in the
> course of professional employment, which was not the case nearly as
> often in the 1990s when I became part of the FLOSS ecosystem).

I'd also say that there's just a lot more to do than there was in the
1990s (or perhaps I notice it more now that I'm a parent rather than a
student).  I gave up maintenance of one of my packages recently because
it was only sustainable for me when it was part of my full-time
employment.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1035312: minetest: New upstream version available (5.7.0)

[Tobias Frost]

Control:  tags -1 confirmed

On Sun, 23 Jul 2023 01:33:49 +0200 tuxayo  wrote:
> Hi :)
> 
> Hopefully the update is easy, the arch package changelog shows only tag 
> bumps for MT and irrlichtmt.
> 
> https://gitlab.archlinux.org/archlinux/packaging/packages/minetest/-/commit/88eb2e21e5c813103bae315b77b464ff9c28eafe

Just a note to {myself|whomever of the games team wanting to tackle this new 
upstream version}:

https://github.com/minetest/minetest/issues/12778#issuecomment-1250255332:
"For this reason building with system Lua will become impossible with 5.7.0 as 
Minetest will ship a minimally modified version that fixes these 
interoperability issues (#12445)."
 
#12445 is: https://github.com/minetest/minetest/pull/12445

--> we will need to use the bundled lua.

Bug#1041689: [Pkg-utopia-maintainers] Bug#1041689: Bug#1041689: Bug#1041689: udisks2: After upgrading to 2.10.0-3 on trixie, the service udisks2 does not start.

[Michael Biebl]

Am 23.07.23 um 09:53 schrieb Michael Biebl:

@Marc: Can you please install the udisks2/libblockdev dbgsym package, 
gather a backtrace and then filing the issue upstream.



https://wiki.debian.org/HowToGetABacktrace


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041152: udisks2: udisksd no longer mounts my USB-disk

[Michael Biebl]

Control: tags -1 + upstream

On Sat, 15 Jul 2023 10:51:15 +0200 Gottfried Schwieters 
 wrote:

Package: udisks2
Version: 2.10.0-3
Severity: important

After the latest upgrade of udisksd it fails now to mount my USB device
(external disk 5TB, ntfs). It gives the error shown below. (Manual
mount "mount /dev/sdc1 /mnt" still works).


Does it work if you run
udisksctl mount --block-device /dev/sdc1


2023-07-15T10:38:11.497185+02:00 Anaga udisksd[938]: Error probing
device:
Error sending ATA command IDENTIFY DEVICE to '/dev/sdc': Unexpected
sense data
returned:#012: f0 00 01 00  00 00 00 0a  00 00 00 00  00 1d 00 00
#0120010: 00 00 00 00  00 00 00 00  00 00 00 00  00 00
00 00
#012 (g-io-error-quark, 0)



Would probably be best to file this upstream at
https://github.com/storaged-project/udisks/issues/


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041758: libcudf-dev is not installable due to bogus janitor change

[Adrian Bunk]

On Sun, Jul 23, 2023 at 09:03:24AM +0200, Sven Joachim wrote:
> On 2023-07-23 09:37 +0300, Adrian Bunk wrote:
> 
> > Package: libcudf-dev
> > Version: 0.10-1
> > Severity: serious
> > X-Debbugs-Cc: team+jani...@tracker.debian.org
> >
> > The following packages have unmet dependencies:
> >  libcudf-dev : Depends: libtinfo6 (= 6.1+20181013-2+deb10u2) but 
> > 6.4+20230625-1 is to be installed
> >Depends: libncurses-dev (= 6.1+20181013-2+deb10u2) but 
> > 6.4+20230625-1 is to be installed
> >
> > This is due to:
> >
> > https://salsa.debian.org/ocaml-team/cudf/-/merge_requests/2
> >
> > cudf (0.10-1) unstable; urgency=medium
> > ...
> >   [ Debian Janitor ]
> > ...
> >* Remove constraints unnecessary since buster (oldstable):
> >  + libcudf-dev: Replace dependency on transitional package 
> > libncurses5-dev
> >with replacement libtinfo6 (= 6.1+20181013-2+deb10u2), 
> > libncurses-dev (=
> >6.1+20181013-2+deb10u2) in Depends.
> > ...
> >
> >
> > I haven't checked whether the replacement package names are correct,
> > but the = dependences hardcoded in debian/control are clearly wrong.
> 
> Hardcoding a dependency on libtinfo6 is also wrong, but libncurses-dev
> is indeed the successor of libncurses5-dev.

I think the root cause is that the janitor did an automatic and 
incorrect replacement based on the transitional package in buster:

Package: libncurses5-dev
Version: 6.1+20181013-2+deb10u2
Depends: libtinfo6 (= 6.1+20181013-2+deb10u2), libncurses-dev (= 
6.1+20181013-2+deb10u2)

libncurses5-dev depending on libtinfo6 might be unnecessary since 
libncurses-dev already depends on it, but that doesn't make it bogus.

Using = dependencies in a transitional package is unusual but not 
incorrect when these packages are built from the same source package.

The dependency of libncurses5-dev could therefore likely be simplified to
  Depends: libncurses-dev
but the problem is seems to that the janitor does not have a sanity check
to refuse a replacement.

I see two bugs in the janitor here:

1. >= or >> dependencies in the replacement are OK, = dependencies are not.
<= or << dependencies should likely also be refused since they should 
be checked by a human.

2. Dependencies on two packages are usually a package split, automatic
replacement works but might often be wrong for the different reason that 
it creates too many dependencies. 

> Cheers,
>Sven

cu
Adrian

Bug#1041760: src:python-geopandas: unsatisfied build dependency in testing: python3-pyepsg

[Sebastiaan Couwenberg]

On 7/23/23 09:07, Paul Gevers wrote:

Can you please investigate the situation and figure out how to resolve
it? python-pyepsg is affected by an RC issue [2] and has been removed 
from testing, you could help its maintainers to solve the issue.


python-geopandas was marked for autoremoval from testing due to the RC 
bug affecting python-pyepsg but then wasn't. That suggests an issue in 
britney.


pyepsg doesn't appear to be used anymore although it's still referenced 
in documentation. I'll drop the build dependency to resolve this issue.


Kind Regards,

Bas

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

Bug#1041689: [Pkg-utopia-maintainers] Bug#1041689: Bug#1041689: Bug#1041689: udisks2: After upgrading to 2.10.0-3 on trixie, the service udisks2 does not start.

[Michael Biebl]

Am 23.07.23 um 08:57 schrieb Marc Bres Gil:
missing error shows, only the multiple "error getting loop6/7" errors 


Those errors are just a red herring afaics


and ends with a *** stack smashing detected ***: terminated message.


That's the relevant part.

@Marc: Can you please install the udisks2/libblockdev dbgsym package, 
gather a backtrace and then filing the issue upstream.


https://github.com/storaged-project/udisks/

As mentioned, unfortunately I can't reproduce the SIGABRT.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386

[Paul Gevers]

Hi Dirk,

On 22-07-2023 23:14, Dirk Eddelbuettel wrote:

It could be an issue as simple as CRAN (and
upstream) no longer checking on i386 though it usually does not fail there.


This is what I suspected, but it needs to be resolved in Debian by 
somebody, somehow. lme4 is a key package, removing it from i386 isn't 
going to be easy if at all possible. If you don't want to investigate 
yourself, maybe contact the i386 porter (bunk) and ask his help. Another 
option is to file bugs for your reverse dependencies if you believe they 
are at fault. At least r-cran-mlmrev isn't a key package so with an RC 
bug filed against it, it will be autoremoved in due time.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037790: nix: ftbfs with GCC-13

[Peter Pentchev]

control: tag -1 + pending

On Wed, Jun 14, 2023 at 09:29:02AM +, Matthias Klose wrote:
> Package: src:nix
> Version: 2.8.0-1.1
> Severity: normal
> Tags: sid trixie
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-13
> 
> [This bug is targeted to the upcoming trixie release]
[snip]
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-13/g++-13, but succeeds to build with gcc-12/g++-12. The
> severity of this report will be raised before the trixie release.
> 
> The full build log can be found at:
> http://qa-logs.debian.net/2023/05/22/logs/nix_2.8.0-1.1_unstable_gccexp.log
> The last lines of the build log are at the end of this report.
[snip]
> src/libutil/json.cc: In function ‘void nix::toJSON(std::ostream&, const 
> char*, const char*)’:
> src/libutil/json.cc:33:22: error: ‘uint16_t’ was not declared in this scope
>33 | put(hex[(uint16_t(*i) >> 12) & 0xf]);
>   |  ^~~~
> src/libutil/json.cc:5:1: note: ‘uint16_t’ is defined in header ‘’; 
> did you forget to ‘#include ’?
> 4 | #include 
>   +++ |+#include 
> 5 | 
> make[1]: *** [mk/patterns.mk:3: src/libutil/json.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make[1]: Leaving directory '/<>'
> dh_auto_build: error: make -j8 returned exit code 2
> make: *** [debian/rules:31: binary] Error 25
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2

I am attaching the debdiff of the NMU that I uploaded to DELAYED/5 yesterday.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
diff -Nru nix-2.8.0/debian/changelog nix-2.8.0/debian/changelog
--- nix-2.8.0/debian/changelog  2022-10-15 13:28:28.0 +0300
+++ nix-2.8.0/debian/changelog  2023-07-22 19:16:28.0 +0300
@@ -1,3 +1,11 @@
+nix (2.8.0-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add the gcc13 patch to fix the build with GCC 13.
+Closes: #1037790
+
+ -- Peter Pentchev   Sat, 22 Jul 2023 19:16:28 +0300
+
 nix (2.8.0-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru nix-2.8.0/debian/patches/gcc13.patch 
nix-2.8.0/debian/patches/gcc13.patch
--- nix-2.8.0/debian/patches/gcc13.patch1970-01-01 02:00:00.0 
+0200
+++ nix-2.8.0/debian/patches/gcc13.patch2023-07-22 19:13:41.0 
+0300
@@ -0,0 +1,17 @@
+Description: Fix the build with GCC 13
+ Include the  header for the definition of the uint16_t type.
+Bug-Debian: https://bugs.debian.org/1037790
+Forwarded: no
+Author: Peter Pentchev 
+Last-Update: 2023-07-22
+
+--- a/src/libutil/json.cc
 b/src/libutil/json.cc
+@@ -1,6 +1,7 @@
+ #include "json.hh"
+ 
+ #include 
++#include 
+ #include 
+ 
+ namespace nix {
diff -Nru nix-2.8.0/debian/patches/series nix-2.8.0/debian/patches/series
--- nix-2.8.0/debian/patches/series 2022-05-02 21:55:23.0 +0300
+++ nix-2.8.0/debian/patches/series 2023-07-22 19:16:28.0 +0300
@@ -4,3 +4,4 @@
 fix_nix_DIR_in_doc_local_mk.patch
 
 lowdown_does_not_declare_bsd_dep.patch
+gcc13.patch


signature.asc
Description: PGP signature

Bug#1041763: src:starlette: fails to migrate to testing for too long: triggers autopkgtest failure

[Paul Gevers]

Source: starlette
Version: 0.26.1-1
Severity: serious
Control: close -1 0.30.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: affects -1 src:fastapi

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:starlette has been trying to migrate for 
31 days [2]. Hence, I am filing this bug. The version in unstable 
triggers autopkgtest failures in fastapi.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=starlette



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041762: src:monty: fails to migrate to testing for too long: dropping architectures impacts reverse dependencies

[Paul Gevers]

Source: monty
Version: 2022.9.9+dfsg-1
Severity: serious
Control: close -1 2023.5.8+dfsg-4
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:monty has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable makes 
pymatgen uninstallable on the architectures where support has been 
droppped but that hasn't been discussed with or reported to its maintainer.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=monty



OpenPGP_signature
Description: OpenPGP digital signature