Bug#1021894: openjfx: FTBFS on arm64 and armhf

[tony mancill]

On Sat, Jul 15, 2023 at 01:46:02PM -0700, tony mancill wrote:
> I intend to build and upload in the next few days, but you are welcome
> to NMU if you would prefer.

Uploaded as 11.0.11+1-3.1.  (The version number was a slight mistake on
my part; I meant to remove the NMU suffix in the changelog before the
upload.  I will fix it on the next upload.)

Bug#1041204: dhcpcd-base: dhcpcd -T wlp3s0 produces Segmentation fault

[Martin-Éric Racine]

On Sun, 16 Jul 2023 07:40:19 +0300
=?UTF-8?Q?Martin=2D=C3=89ric_Racine?= 
wrote:
> On Sat, 15 Jul 2023 18:14:53 +0200 Ingo Wichmann
>  wrote:
> > Package: dhcpcd-base
> > Version: 9.4.1-22
> > Severity: normal
> > X-Debbugs-Cc: iw-deb...@linuxhotel.de
> >
> > Dear Maintainer,
> >
> > I tried out
> >   dhcpcd -T wlp3s0
> > to fetch information from my local dhcp-server. After some lines of output 
> > the
> > programm stops with 'Segmentation fault'.
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024357 is a similar bug 
> > that has been closed upstream with 
> > https://github.com/NetworkConfiguration/dhcpcd/issues/156 and seems to have 
> > been fixed in testing or sid.
>
> It indeed was fixed in later releases. You can try with dhcpcd-base 10
> (currently in Unstable).

One thing that would be usefull is if you could open a bug upstream
and attach a backtrace, just so that we can confirm whether it is a
different bug.  This would be good to know, because the patch for the
earlier bug you mention has been merged in 9.4.1-12, so it likely is a
different issue.

Martin-Éric

Bug#1035310: bullseye-pu: package xz-utils/5.2.11-0~deb11u1

[Helge Kreutzmann]

Hello Jonathan,
sorry for my late answer, I was on holidays.

On Tue, Jun 27, 2023 at 10:17:30PM +0200, Sebastian Andrzej Siewior wrote:
> On 2023-06-26 18:10:57 [+0100], Jonathan Wiltshire wrote:
> > Control: tag -1 moreinfo
> > 
> > You're both going to have to help me a) understand what is the user-facing
> > problem you're solving which is necessary to fix in stable and b) whether
> > you're both agreed on how to fix it.
> 
> a) The bpo of manpages-de and manpages-fr contains a manpage for xz. The
>regular (non-bpo) package does not contain such the man-page nor does
>the package in the following stable contain this man-page.
>The user facing problem is the installation of both
>manpages-de|manpages-fr and xz-utils/5.2.11-0~deb11u1 because both
>provide the same man-page/file and dpkg doesn't like that.

That is basically the issue, except that there are several man pages
(IIRC, I can check tonight).

> b) I *think* we agreed on removing the man-pages from bpo of
>manpages-[de|fr] in the next upload if the upload of
>xz-utils/5.2.11-0~deb11u1 is confirmed. Otherwise it makes no sense
>to anything, the upgrade path bpo -> next-stable is working due to
>proper package relations.

As always, when such a transfer occurs, I can provide an upload
without the affected man pages and with the proper package releations.
Now sínce bookworm is released I do not intend to provide any further
upload to oldstable and I do not see any reason to processes this
issue any further, affected users can upgrade to stable now to get the
latest localized man pages from xz-utils proper.

If there are technical issues for performing this upload to oldstable
and hence actions form my side (to enable smooth upgrading) are needed
please let me know.

Greetings

Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1041204: dhcpcd-base: dhcpcd -T wlp3s0 produces Segmentation fault

[Martin-Éric Racine]

On Sat, 15 Jul 2023 18:14:53 +0200 Ingo Wichmann
 wrote:
> Package: dhcpcd-base
> Version: 9.4.1-22
> Severity: normal
> X-Debbugs-Cc: iw-deb...@linuxhotel.de
>
> Dear Maintainer,
>
> I tried out
>   dhcpcd -T wlp3s0
> to fetch information from my local dhcp-server. After some lines of output the
> programm stops with 'Segmentation fault'.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024357 is a similar bug 
> that has been closed upstream with 
> https://github.com/NetworkConfiguration/dhcpcd/issues/156 and seems to have 
> been fixed in testing or sid.

It indeed was fixed in later releases. You can try with dhcpcd-base 10
(currently in Unstable).

Martin-Éric

Bug#1037685: guitarix: ftbfs with GCC-13

[Hermann Meyer]

Hi

This bug is already fixed in upstream, here is the related patch:

https://github.com/brummer10/guitarix/commit/b52736180b6966f24398f8a5ad179a58173473ec


regards

hermann

Bug#1041231: bluetooth on debian bookworm@macbook pro 2012

[Alex Wibowo]

Package: installation-reports

Boot method: USB stick
Image version: 
Date: 

Machine: Macbook pro 2012 non retina
Processor: i7
Memory: 16GB
Partitions:
Filesystem Type 1K-blocks Used Available Use% Mounted on
udev   devtmpfs   81230920   8123092   0% /dev
tmpfs  tmpfs  1631312 1844   1629468   1% /run
/dev/sda2  ext4 478096136 13534948 440201764   3% /
tmpfs  tmpfs  81565520   8156552   0% /dev/shm
tmpfs  tmpfs 5120   12  5108   1% /run/lock
/dev/sda1  vfat523244 5972517272   2% /boot/efi
tmpfs  tmpfs  1631308 2508   1628800   1% /run/user/1000


Output of lspci -knn (or lspci -nn):
00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor
DRAM Controller [8086:0154] (rev 09)
Subsystem: Apple Inc. 3rd Gen Core processor DRAM Controller [106b:00fb]
Kernel driver in use: ivb_uncore
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen
Core processor PCI Express Root Port [8086:0151] (rev 09)
Subsystem: Apple Inc. Xeon E3-1200 v2/3rd Gen Core processor PCI
Express Root Port [106b:00fb]
Kernel driver in use: pcieport
00:01.1 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen
Core processor PCI Express Root Port [8086:0155] (rev 09)
Subsystem: Apple Inc. Xeon E3-1200 v2/3rd Gen Core processor PCI
Express Root Port [106b:00fb]
Kernel driver in use: pcieport
00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen
Core processor Graphics Controller [8086:0166] (rev 09)
Subsystem: Apple Inc. 3rd Gen Core processor Graphics Controller 
[106b:00fb]
Kernel driver in use: i915
Kernel modules: i915
00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
Subsystem: Intel Corporation 7 Series/C210 Series Chipset Family USB
xHCI Host Controller [8086:7270]
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
00:16.0 Communication controller [0780]: Intel Corporation 7
Series/C216 Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
Subsystem: Intel Corporation 7 Series/C216 Chipset Family MEI
Controller [8086:7270]
Kernel driver in use: mei_me
Kernel modules: mei_me
00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C216 Chipset
Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
Subsystem: Intel Corporation 7 Series/C216 Chipset Family USB
Enhanced Host Controller [8086:7270]
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C216 Chipset
Family High Definition Audio Controller [8086:1e20] (rev 04)
Subsystem: Intel Corporation 7 Series/C216 Chipset Family High
Definition Audio Controller [8086:7270]
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C216 Chipset
Family PCI Express Root Port 1 [8086:1e10] (rev c4)
Subsystem: Intel Corporation 7 Series/C216 Chipset Family PCI Express
Root Port 1 [8086:7270]
Kernel driver in use: pcieport
00:1c.1 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series
Chipset Family PCI Express Root Port 2 [8086:1e12] (rev c4)
Subsystem: Intel Corporation 7 Series/C210 Series Chipset Family PCI
Express Root Port 2 [8086:7270]
Kernel driver in use: pcieport
00:1c.2 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series
Chipset Family PCI Express Root Port 3 [8086:1e14] (rev c4)
Subsystem: Intel Corporation 7 Series/C210 Series Chipset Family PCI
Express Root Port 3 [8086:7270]
Kernel driver in use: pcieport
00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C216 Chipset
Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
Subsystem: Intel Corporation 7 Series/C216 Chipset Family USB
Enhanced Host Controller [8086:7270]
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:1f.0 ISA bridge [0601]: Intel Corporation HM77 Express Chipset LPC
Controller [8086:1e57] (rev 04)
Subsystem: Intel Corporation HM77 Express Chipset LPC Controller 
[8086:7270]
Kernel driver in use: lpc_ich
Kernel modules: lpc_ich
00:1f.2 SATA controller [0106]: Intel Corporation 7 Series Chipset
Family 6-port SATA Controller [AHCI mode] [8086:1e03] (rev 04)
Subsystem: Intel Corporation 7 Series Chipset Family 6-port SATA
Controller [AHCI mode] [8086:7270]
Kernel driver in use: ahci
Kernel modules: ahci
00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C216 Chipset Family
SMBus Controller [8086:1e22] (rev 04)
Subsystem: Intel Corporation 7 Series/C216 Chipset Family SMBus
Controller [8086:7270]
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801
01:00.0 VGA compatible controller [0300]: 

Bug#1041146: guix: installation script should call "guix archive --generate-key"

[Vagrant Cascadian]

On 2023-07-15, Martin Monperrus wrote:
> Version: 1.3.0-4

This is a quite old version of guix already, stable has 1.4.0-3...


> Systemd job `guix-publish.service` fails with
>
> ```
> systemd[1]: guix publish: error: open-file: No such file or directory:
> "/etc/guix/signing-key.pub"
> systemd[1]: guix-publish.service: Main process exited, code=exited,
> status=1/FAILURE
> systemd[1]: guix-publish.service: Failed with result 'exit-code'.
> ```

This is not a great default behavior, agreed!

I have noticed this issue in the past and not quite gotten around to
figuring out what to do about it.


> Workaround:
>
> call `guix archive --generate-key` manually to create "/etc/guix/signing-
> key.pub". this should be part of the Deb package installation script.

I think it would be better if guix-publish was not enabled by default,
as this matches the defaults of Guix System upstream and I *think* also
guix installed from script on a foreign distro.

Some instructions on how to enable it could be added to README.Debian,
including mentioning generating the key.


> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers jammy-updates
>   APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 
> 'jammy'), (100, 'jammy-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386

This seems like some hybrid Debian and Ubuntu system, which is as far as
I know is unsupported on both Debian and Ubuntu...

That said, I can confirm the issue is present on regular Debian install
as well..


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1025073: Bug persists in the latest release

[dianlujitao]

On Sat, 15 Jul 2023 18:20:07 +0800 dianlujitao  
wrote:

> I encountered the same issue with two Debian 12 (package version:
> 1.42.4-1) machines, one fresh installed and the other upgraded from
> Debian 11.
>
> Both of them use PPPoE to connect to the Internet. After connected,
> /proc/sys/net/ipv6/conf/ppp0/accept_ra is always reset to 0 and thus no

> ipv6 address is assigned.

Found a workaround to this issue, that is to create 
/etc/ppp/ipv6-up.d/00-iface-config with the following contents:


#!/bin/sh

echo 1 > /proc/sys/net/ipv6/conf/$1/accept_ra

>
> In addition, I tested on the latest Debian testing, with NM version
> 1.42.8-1, and it also has the same issue. However, my Archlinux machine
> with NM 1.42.6 works fine. Hence, I suspect that this is a downstream
> Debian bug.
>
Not exactly, Arch's ppp package ships 
/etc/ppp/ipv6-up.d/00-iface-config.sh to write that node.

Bug#1040265: fixing CVE-2023-36813 in kanboard/bookworm

[Joe Nahmias]

On Fri, Jul 14, 2023 at 11:47:18PM +0200, Moritz Mühlenhoff wrote:
> Am Wed, Jul 12, 2023 at 08:32:56PM -0400 schrieb Joe Nahmias:
> > Please see attached proposed debdiff for fixing CVE-2023-36813 in bookworm.
> > 
> > --Joe
> 
> > diff -Nru kanboard-1.2.26+ds/debian/changelog 
> > kanboard-1.2.26+ds/debian/changelog
> > --- kanboard-1.2.26+ds/debian/changelog 2023-06-15 23:02:33.0 
> > -0400
> > +++ kanboard-1.2.26+ds/debian/changelog 2023-07-12 20:13:20.0 
> > -0400
> > @@ -1,3 +1,13 @@
> > +kanboard (1.2.26+ds-2+deb12u2) bookworm; urgency=high
>   
> 
> This should be bookworm-security, with that change please upload to 
> security-master,
> I'll take care of the DSA.

Done.

> Cheers,
> Moritz
--Joe

Bug#1041220: src:libgitlab-api-v4-perl: fails to migrate to testing for too long: triggers autopkgtest regression in devscripts

[Yadd]

On 7/15/23 22:46, Paul Gevers wrote:

Source: libgitlab-api-v4-perl
Version: 0.26-3
Severity: serious
Control: close -1 0.27-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1038486

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:libgitlab-api-v4-perl has been trying to 
migrate for 32 days [2]. Hence, I am filing this bug. The package in 
unstable triggers an autopkgtest issue in devscripts, which is reported 
in bug 1038486.


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


Hi,

the error looks to be:

 55s t/salsa-config.t .. ok
 56s Undefined subroutine ::to_json called at ./t/salsa.pm line 49.
 56s # Tests were run but no plan was declared and done_testing() was 
not seen.

 56s # Looks like your test exited with 255 just after 1.
 56s t/salsa.t .

Gitlab::API::v4 uses JSON::MaybeXS which may use a different JSON stack. 
I just added a "use JSON" in t/salsa.pm. Maybe this is enough to fix 
this issue


https://salsa.debian.org/debian/devscripts/-/commit/5bbc8778

Regards,
Yadd

Bug#1040757: dose: (W)CudfAdd: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe

[Paul Wise]

On Sat, 2023-07-15 at 10:58 +0200, Ralf Treinen wrote:

> The version of dose-distcheck installed on quantz is very old (5.0.1-12,
> form oldoldstable). The version in bookworm is 7.0.0-1+b2. I can't tell
> yet whether more recent versions of dose fix the problem, but do you have
> plans for upgrading quantz ?

There will be an upgrade at some point but I'm not sure when.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1041013:

[Hector Cao]

Thanks Bastian for your help
How can I get the list of bugs that were opened at the package removal ?

-- 
Hector CAO
Software Engineer – Partner Engineering Team
hector@canonical.com
https://launc hpad.net/~hectorcao

Bug#1041230: onetbb 2021.9.0-1 FTBFS on multiple release architectures

[M. Zhou]

Source: onetbb
Version: 2021.9.0-1
Severity: serious

I'm aware of this issue. I'm slightly faster than buildd for toolchain
upgrades. The issue will automatically disappear once our amd64 buildd
migrates to gcc-13. The gcc-12 will lead to the FTBFS you see now.

Local sbuild with gcc-13 has no issue.

Bug#1041162: bogus test triggers with unused compilers

[Andreas Beckmann]

On 15/07/2023 12.11, Matthias Klose wrote:

Package: src:dkms
Version: 3.0.11-3



seen with
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dkms/35776414/log.gz


That's an autopkgtest pinning problem:

autopkgtest uses this command to build the list of binary packages to 
pin for these flags:

  --add-apt-release=unstable --pin-packages=unstable=src:gcc-12

apt-cache showsrc gcc-12 | awk '/^Package-List:/ { show=1; next } (/^ / 
&& show==1) { print $1; next } { show=0 }' |sort -u | tr '\n' ' '


Unfortunately that includes obsolete information from Extra-Source-Only 
packges, e.g.


Package: gcc-12
Binary: gcc-12-base, libgcc-s1, libgcc-s2, libgcc-s4, libgcc-12-dev, 
lib64gcc-s1, lib64gcc-12-dev, lib32gcc-s1, lib32gcc-12-dev, 
libn32gcc-s1, libn32gcc-12-dev, libx32gcc-s1, libx32gcc-12-dev, gcc-12, 
gcc-12-multilib, gcc-12-test-results, gcc-12-plugin-dev,,
 libx32objc4, gfortran-12, gfortran-12-multilib, libgfortran-12-dev, 
lib64gfortran-12-dev, lib32gfortran-12-dev, libn32gfortran-12-dev, 
libx32gfortran-12-dev, libgfortran5, lib64gfortran5, lib32gfortran5, 
libn32gfortran5, libx32gfortran5, gccgo-12, gccgo-12,
 gm2-12-doc, gcc-12-offload-nvptx, libgomp-plugin-nvptx1, 
gcc-12-offload-amdgcn, libgomp-plugin-amdgcn1,

 gcc-12-source
Version: 12.2.0-14
...
Homepage: http://gcc.gnu.org/
Package-List:
...
 libasan8 deb libs optional arch=any
...
Extra-Source-Only: yes


So it pins libasan8 to sid because it believes that is built from 
src:gcc-12, but that is now built from src:gcc-13 and all binary 
packages built by src:gcc-13 that were never built by src:gcc-12 are 
pinned to testing ... and that makes some packages uninstallable ...


Andreas

Bug#1039583: libltdl-dev: missing Breaks+Replaces: libltdl3-dev

[Vincent Lefevre]

Hi,

On 2023-06-27 14:50:30 +0200, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package fails to upgrade from
> 'lenny' to 'squeeze' to 'wheezy' to 'jessie' to 'stretch' to 'buster'.
> It installed fine in 'lenny', and upgraded to 'squeeze', 'wheezy',
> 'jessie', 'stretch', 'buster', and 'bullseye'  successfully,
> but then the upgrade to 'bookworm' failed,
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.

The added Breaks+Replaces is incorrect as it yields a fatal error
in dpkg, which cannot configure libltdl-dev 2.4.7-6:

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

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

Bug#1037264: cksum crashes intermittently with "Illegal instruction" on some Xen DomU

[Markus Gschwendt]

Hi!

I have this issue with cron-apt:

8<
/etc/cron.daily/apt-compat:
Illegal instruction
R: 
/etc/cron.daily/apt-compat: 44: arithmetic expression: expecting
primary: "  % 32767 "
run-parts: /etc/cron.daily/apt-compat exited with return code 2
>8


A change in the config file of the domU did solve this problem (not
really a solution to the problem but maybe a useful hint):

old domU.cfg:
kernel  = '/usr/lib/grub-xen/grub-x86_64-xen.bin'
extra   = 'elevator=noop'

new domU.cfg:
type= 'pvh'
kernel  = '/usr/lib/grub-xen/grub-i386-xen_pvh.bin'
extra   = 'elevator=noop'

And i get a different output from `cpuid -1` for these configs.

Markus

Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE

[Timo Röhling]

Hi Adam,

On Sat, 15 Jul 2023 18:27:24 +0200 Adam Borowski  wrote:

Packages built in an usrmerged chroot place such files under /usr while
built without usrmerge into whatever place they were installed to -- which
is a direct breach of the ruling.

Packages stage their files in debian/tmp or debian/PACKAGE, not in /
of the builder chroot, so the usr-merge state of the chroot has no
effect on the package file locations.


Cheers
Timo

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


signature.asc
Description: PGP signature

Bug#1041229: dependency problems prevent configuration of libltdl-dev

[Vincent Lefevre]

And "apt install -f" cannot fix the error.

I could downgrade the packages to testing (2.4.7-5), though.

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

Bug#1041091: python3-virtualenv: re-execution of virtualenv command removes python-debian's debian directory

[Stefano Rivera]

Control: reassign -1 setuptools
Control: found -1 setuptools/51.3.3-1
Control: affects -1 virtualenv
Control: tag -1 + patch

Hi Michael (2023.07.14_19:18:51_+)

This is a subtle bug. I can reproduce it from upstream sources, from
https://github.com/pypa/virtualenv/commit/b4564569171628ee839e14853a00f296686cae6a
to
https://github.com/pypa/virtualenv/commit/94f3cf581bc00eae81eca8bfd545fc3bec6d4bb6

The issue is with re-installing setuptools. It seems that:
setuptools-*.dist-info/top_level.txt contains "debian".

That started to happen around setuptools 51.3.0, with this commit:
https://github.com/pypa/setuptools/commit/0df40810ec54590c888ae0e4073d73f731c91f4a
And the solution is to exclude "debian*" from options.packages.find

Trivial workaround: build the virtualenv with --no-setuptools. That's
the future, anyway.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272
Exclude "debian" from top_level.txt.
It gets discovered because it's a top-level directory in the source tree, but it isn't a module we install.

Author: Stefano Rivera 
Bug-Debian: https://bugs.debian.org/1041091
Forwarded: not-needed
--- a/setup.cfg
+++ b/setup.cfg
@@ -35,6 +35,7 @@
 	*.tests
 	*.tests.*
 	tools*
+	debian*
 
 [options.extras_require]
 testing = 

Bug#1041229: dependency problems prevent configuration of libltdl-dev

[Vincent Lefevre]

Package: libltdl-dev
Version: 2.4.7-6
Severity: grave
Justification: renders package unusable

When upgrading, I got:

E: Sub-process /usr/bin/dpkg returned an error code (1)
dpkg: dependency problems prevent configuration of libltdl-dev:amd64:
 libltdl-dev:i386 (2.4.7-6) breaks libltdl3-dev and is unpacked but not 
configured.
  libltdl-dev:amd64 (2.4.7-6) provides libltdl3-dev.

dpkg: error processing package libltdl-dev:amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of libltdl-dev:i386:
 libltdl-dev:amd64 (2.4.7-6) breaks libltdl3-dev and is unpacked but not 
configured.
  libltdl-dev:i386 (2.4.7-6) provides libltdl3-dev.

dpkg: error processing package libltdl-dev:i386 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 libltdl-dev:amd64
 libltdl-dev:i386

In the /var/log/dpkg.log file, about libltdl*:

2023-07-16 00:13:59 upgrade libltdl-dev:i386 2.4.7-5 2.4.7-6
2023-07-16 00:13:59 status half-configured libltdl-dev:i386 2.4.7-5
2023-07-16 00:13:59 status unpacked libltdl-dev:i386 2.4.7-5
2023-07-16 00:13:59 status half-configured libltdl-dev:amd64 2.4.7-5
2023-07-16 00:13:59 status half-installed libltdl-dev:i386 2.4.7-5
2023-07-16 00:13:59 status unpacked libltdl-dev:i386 2.4.7-6
2023-07-16 00:13:59 upgrade libltdl-dev:amd64 2.4.7-5 2.4.7-6
2023-07-16 00:13:59 status unpacked libltdl-dev:amd64 2.4.7-5
2023-07-16 00:13:59 status half-installed libltdl-dev:amd64 2.4.7-5
2023-07-16 00:14:00 status unpacked libltdl-dev:amd64 2.4.7-6
2023-07-16 00:14:00 upgrade libltdl7:amd64 2.4.7-5 2.4.7-6
2023-07-16 00:14:00 status half-configured libltdl7:amd64 2.4.7-5
2023-07-16 00:14:00 status unpacked libltdl7:amd64 2.4.7-5
2023-07-16 00:14:00 status half-configured libltdl7:i386 2.4.7-5
2023-07-16 00:14:00 status half-installed libltdl7:amd64 2.4.7-5
2023-07-16 00:14:00 status unpacked libltdl7:amd64 2.4.7-6
2023-07-16 00:14:00 upgrade libltdl7:i386 2.4.7-5 2.4.7-6
2023-07-16 00:14:00 status unpacked libltdl7:i386 2.4.7-5
2023-07-16 00:14:00 status half-installed libltdl7:i386 2.4.7-5
2023-07-16 00:14:00 status unpacked libltdl7:i386 2.4.7-6
[...]
2023-07-16 00:14:23 configure libltdl7:amd64 2.4.7-6 
2023-07-16 00:14:23 status unpacked libltdl7:amd64 2.4.7-6
2023-07-16 00:14:23 status half-configured libltdl7:amd64 2.4.7-6
2023-07-16 00:14:23 status installed libltdl7:amd64 2.4.7-6
2023-07-16 00:14:23 configure libltdl7:i386 2.4.7-6 
2023-07-16 00:14:23 status unpacked libltdl7:i386 2.4.7-6
2023-07-16 00:14:23 status half-configured libltdl7:i386 2.4.7-6
2023-07-16 00:14:23 status installed libltdl7:i386 2.4.7-6

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

Kernel: Linux 6.3.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 libltdl-dev:amd64 depends on:
ii  automake [automake-1.16]  1:1.16.5-1.3
ii  libltdl7  2.4.7-6

Versions of packages libltdl-dev:amd64 recommends:
ii  libtool  2.4.7-6

Versions of packages libltdl-dev:amd64 suggests:
ii  libtool-doc  2.4.7-6

-- no debconf information

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

Bug#1041159: dh_installsystemd: doesn't handle units installed in /usr/lib/systemd (vs. /lib/systemd)

[Romain Francoise]

Hi,

On Sat, Jul 15, 2023 at 9:38 PM Niels Thykier  wrote:
> This is #1031695, which was closed and archived (marking it hard for
> people to see this is a known item). [...]

Thank you. I was unaware of the previous discussion, and my favorite
search engine was as well.

I'll forcemerge this bug with the original one.

Cheers,
-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1041074: bookworm-pu: package cpp-httplib/0.11.4+ds-1+deb12u1

[Andrea Pappacoda]

Il giorno sab 15 lug 2023 alle 16:35:01 +01:00:00, Adam D. Barratt 
 ha scritto:

Please go ahead.


Uploaded and accepted, thanks!

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Ben Hutchings]

On Fri, 2023-07-14 at 22:08 +, Thorsten Glaser wrote:
> Michael Tokarev dixit:
> 
> > > 
> > > From the comment, it reserves 16 MiB after the main executable.
> > > 
> > > In klibc/armhf, however, the main executable starts around
> > > 0x0001 whereas the interpreter starts after that, around
> > > 0x0038…
> > 
> > Aren't it happens on all architectures, not just armhf?
> 
> bullseye/amd64:
> 
> 0x0020 interp
> 0x0040 main executable
> 
> So no, this applies only to some architectures, but not because…
> 
> > I had an impression it is not arch-specific. $subject
> 
> … it’s arch-specific but because klibc memory map is, so the
> effect only occurs on those arches where klibc puts the interp
> before the main executable.

You mean after, but it's more specific than that in practice.

> This is unfortunately hard to grep for, because…
> 
> usr/klibc/arch/arm/MCONFIG:KLIBCSHAREDFLAGS = $(LD_IMAGE_BASE_OPT) 0x38
> 
> … this applies to the interp, but for the main executables
> it uses the linker’s default AFAICT.
> 
> There is…
> 
> usr/klibc/arch/arm64/MCONFIG:KLIBCLDFLAGS  = $(LD_IMAGE_BASE_OPT) 0x0040
> usr/klibc/arch/arm64/MCONFIG:KLIBCSHAREDFLAGS = $(LD_IMAGE_BASE_OPT) 0x020
> 
> … which does transfer to main at 0040 interp at 0020 respectively,
> but only arm64 and “x32”, which really builds as amd64, do that.
> 
> And Itanic uses a linker script, putting the interp at
> 0x2000 (which seems to be standard for ia64).
> 0x41c8 is the beginning of the main executable
> there, from analysing the built binaries.
> 
> It would be more robust if klibc always specified both.
[...]

It would be a little more robust, and certainly easier to understand.

Here's what we have now:

Architecture  klibc base (hex)  Exec base (hex) Offset (MiB)
-
alpha1_c0001_2000* -2_560
arm [THUMB=y]38 1**-3
arm [THUMB=n]   180 1**   -24
arm642040   2
i386600   800* 32
ia64  2000_ 4000_** 2_199_023_255_552
loongarch64  1_27E01_2000*   -126
m68k   b000  8000*   -768
mips 2040*  2
mips64   1_2FE01_2000*   -254
parisc 40001000 1**-1_024
ppc f80  1000*  8
ppc64   f00  1000* 16
riscv64  20 1* -2
s390   400040**-1_020
s390x  4000   100**-1_008
sh   2040*  2
sparc  4000 1* -1_024
sparc64800010* -2_047
x86_64   2040   2

* Assumption commented in MCONFIG.
** Observed with objdump.

In 12 cases (a majority), the offset between klibc.so and the
executable is negative.  However, only riscv64 and arm with THUMB=y
have such small negative offsets (-2 and -3.4375 MiB respectively)
which I suppose puts them more at risk from this bug.

The Debian package is built with THUMB=y for armhf but not armel, which
seems like a mistake because the Arm EABI requires Thumb support.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
   - Robert Coveyou



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

Bug#1040925: bookworm-pu: package ca-certificates-java/20230103+x

[Andreas Beckmann]

Followup-For: Bug #1040925
Control: retitle -1 bookworm-pu: package ca-certificates-java/20230620~deb12u1

my suggestion: rebuild the 20230620 package from sid


Andreas
diff --git a/debian/ca-certificates-java.postinst 
b/debian/ca-certificates-java.postinst
index 94c6c03..963e248 100644
--- a/debian/ca-certificates-java.postinst
+++ b/debian/ca-certificates-java.postinst
@@ -31,6 +31,13 @@ setup_path()
if [ -x /usr/lib/jvm/$jvm/bin/java ]; then
export JAVA_HOME=/usr/lib/jvm/$jvm
PATH=$JAVA_HOME/bin:$PATH
+   # copy java.security to allow import to function
+   
security_conf=/etc/java-${version}-openjdk/security
+   if [ -f ${security_conf}/java.security.dpkg-new 
] \
+   && [ ! -f 
${security_conf}/java.security ]; then
+   cp 
${security_conf}/java.security.dpkg-new \
+   
${security_conf}/java.security
+   fi
break 2
fi
done
diff --git a/debian/changelog b/debian/changelog
index c316775..4feceba 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,20 @@
+ca-certificates-java (20230620~deb12u1) bookworm; urgency=medium
+
+  * Rebuild for bookworm.  (Closes: #1039472)
+
+ -- Andreas Beckmann   Sat, 15 Jul 2023 23:23:25 +0200
+
+ca-certificates-java (20230620) unstable; urgency=medium
+
+  [ Matthias Klose ]
+  * Bump standards version.
+  * Build-depend on default-jdk-headless instead of default-jdk.
+
+  [ Vladimir Petko ]
+  * d/ca-certificates-java.postinst: Work-around not yet configured jre.
+
+ -- Matthias Klose   Tue, 20 Jun 2023 06:09:44 +0200
+
 ca-certificates-java (20230103) unstable; urgency=medium
 
   * Promote again the JRE recommendation to a dependency. Otherwise
diff --git a/debian/control b/debian/control
index 87cfc5f..88c04e9 100644
--- a/debian/control
+++ b/debian/control
@@ -7,10 +7,10 @@ Uploaders: Matthias Klose ,
 Build-Depends:
  debhelper-compat (= 13),
  dh-sequence-javahelper,
- default-jdk,
+ default-jdk-headless,
  junit4,
 Rules-Requires-Root: no
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
 Vcs-Git: https://salsa.debian.org/java-team/ca-certificates-java.git
 Vcs-Browser: https://salsa.debian.org/java-team/ca-certificates-java
 

Bug#1041228: policykit-1: Polkit fails if more than one rule is defined in /usr/local/share/polkit-1

[Stepan Novotny]

Package: polkitd
Version: 122-3
Severity: important
X-Debbugs-Cc: snovot...@gmail.com

Dear Maintainer,

   * What led up to the situation?
I created /etc/polkit-1/rules.d/99-shutdown.rules and this worked fine:
polkit.addRule(function(action, subject) {
   if (action.id == 'org.freedesktop.login1.power-off-multiple-sessions' &&  
subject.isInGroup('Debian-gdm'))
   return polkit.Result.YES; else return polkit.Result.NOT_HANDLED;
});

Then I added a second file /etc/polkit-1/rules.d/99-power-off.rules and both 
failed to work:
polkit.addRule(function(action, subject) {
   if (action.id == 'org.freedesktop.login1.reboot-multiple-sessions' &&  
subject.isInGroup('Debian-gdm'))
   return polkit.Result.YES; else return polkit.Result.NOT_HANDLED;
});

I found that either one of the above files by itself works fine, but it fails 
if both files are present.

   * What exactly did you do (or not do) that was effective (or ineffective)?
I also found that combining my two files into a single file as shown below, 
does not work either, but that the syntax of my files is acceptable in 
accordance with other example found by Google.
polkit.addRule(function(action, subject) {
if ((action.id == 'org.freedesktop.login1.reboot-multiple-sessions' ||
   action.id == 'org.freedesktop.login1.power-off-multiple-sessions' ||
   action.id == 'org.freedesktop.login1.hibernate-multiple-sessions' ||
   action.id == 'org.freedesktop.login1.suspend-multiple-sessions') &&
   subject.isInGroup('Debian-gdm'))
   return polkit.Result.NO; else return polkit.Result.NOT_HANDLED;
});


   * What was the outcome of this action?
I am currently running only one of my two files, and await a fix.

   * What outcome did you expect instead?
I await a fixed policykit-1 package, and will try again when available.

-- System Information:
Debian Release: 12.0
  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=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages policykit-1 depends on:
ii  pkexec   122-3
ii  polkitd  122-3

Versions of packages policykit-1 recommends:
ii  polkitd-pkla  122-3

policykit-1 suggests no packages.

Versions of packages polkitd depends on:
ii  adduser 3.134
ii  dbus [default-dbus-system-bus]  1.14.6-1
ii  libc6   2.36-9
ii  libduktape207   2.7.0-2
ii  libexpat1   2.5.0-1
ii  libglib2.0-02.74.6-2
ii  libpam-systemd [logind] 252.6-1
ii  libpam0g1.5.2-6
ii  libpolkit-agent-1-0 122-3
ii  libpolkit-gobject-1-0   122-3
ii  libsystemd0 252.6-1
ii  systemd [systemd-sysusers]  252.6-1
ii  xml-core0.18+nmu1

Versions of packages polkitd suggests:
ii  polkitd-pkla  122-3

-- no debconf information

Bug#1041227: transition: suitesparse

[Sébastien Villemot]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: suitespa...@packages.debian.org
Control: affects -1 + src:suitesparse
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-suitesparse.html
Control: block -1 by 1041059 1037905 1037622 1040694 1041225 1037858

Dear Release Team,

Please schedule a transition for suitesparse 7, which currently sits in
experimental.

In this new major release, the SOVERSION of all libraries has been bumped,
because some integer types part of the API have been redefined; however, this
redefinition does not change anything on our release architectures.

There are also a couple of other changes in headers that impact three reverse
dependencies: libdogleg, siconos and octave. A fix is available for the three
of them, and I stand ready to upload as needed.

Four other reverse dependencies (yade, dolfin, openturns, sight) currently
FTBFS for unrelated reasons. As a consequence, I could not verify that they
build correctly against suitesparse 7 (but if they don’t, I’m fairly confident
that they can be adapted).

Thanks,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org

Bug#1041226: ranger: manpage is missing NAME

[spsiml+cz96ht04a07n8]

Package: ranger
Version: 1.9.3-5
Severity: normal

Dear Maintainer,

`man ranger` should begin with:

NAME
ranger - visual file manager

But it is currently missing NAME so it begins with:

ranger - visual file manager

It means that the manpage is incorrectly formatted. For example, if you try to 
regenerate the man database using `mandb --create`, it will issue warnings:

"Updating index cache for path `/usr/share/man/man1'. Wait...mandb: warning: 
/usr/share/man/man1/ranger.1.gz: whatis parse for ranger(1) failed"

And it means that commands like `whatis ranger` report:

"ranger: nothing appropriate."

Instead of the correct:

ranger (1)   - visual file manager

Please forward this bug upstream. Thank you.



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

Kernel: Linux 6.1.0-9-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ranger depends on:
ii  python3 3.11.2-1+b1
ii  sensible-utils  0.0.17+nmu1

Versions of packages ranger recommends:
ii  file 1:5.44-3
ii  less 590-2
ii  python3-chardet  5.1.0+dfsg-2
pn  w3m-img  

Versions of packages ranger suggests:
pn  atool  
pn  caca-utils 
pn  elinks | elinks-lite | lynx | w3m  
pn  highlight | python3-pygments   
pn  mediainfo | exiftool   
pn  poppler-utils | mupdf-tools
ii  sudo   1.9.13p3-1
pn  unoconv

-- no debconf information

Bug#1041168: Installation of GRUB failed

[Pascal Hambourg]

On 15/07/2023 at 21:17, Christof B. wrote:

Am 15.07.23 um 21:07 schrieb Pascal Hambourg:
If you are willing to test, I can provide patched files which replace 
the original ones in a running d-i.


Yes, I am willing to test this. If it can be patched by replacing some 
files at runtime (and not compiling some binaries or images), please 
provide me the files with a hint at where (path) and when (at which step 
of the installation process) to put them into place.


Replacing /lib/partman/init.d/50efi with either attached 50efi.1 or 
50efi.2 as 50efi should fix the issue in guided partitioning with 
encrypted LVM.


  cp /50efi.1 /lib/partman/init.d/50efi
or
  cp /50efi.2 /lib/partman/init.d/50efi

Fixing the issue in guided partitioning with unencrypted LVM also 
requires replacing /bin/autopartition-lvm with the attached 
autopartition-lvm.


  cp /autopartition-lvm /bin/autopartition-lvm

The files can be replaced after "Load installer components" and before 
"Partition disks".#!/bin/sh

# This script sets method "efi" for all fat16/fat32 partitions that
# have the bootable flag set.

ARCH="$(archdetect)"

# Prod the kernel to load EFI stuff and mount the efivarfs fs if
# needed
modprobe efivarfs >/dev/null 2>&1 || true
mount -t efivarfs none /sys/firmware/efi/efivars 2>&1 || true

in_efi_mode() {
[ -d /sys/firmware/efi ]
}

if in_efi_mode; then
> /var/lib/partman/efi
else
case $ARCH in
i386/mac|amd64/mac)
# Intel Macs have an EFI partition, regardless of
# whether we're currently booted using BIOS
# compatibility or not (if we are, we won't be able to
# talk to EFI directly).
> /var/lib/partman/efi
;;
*)
rm -f /var/lib/partman/efi
exit 0
;;
esac
fi

. /lib/partman/lib/base.sh

gpt_efi_type=c12a7328-f81f-11d2-ba4b-00a0c93ec93b
gpt_bios_boot_type=21686148-6449-6e6f-744e-656564454649
msdos_efi_type=0xef

NUM_ESP=0
NUM_NOT_ESP=0

for dev in /var/lib/partman/devices/*; do
[ -d "$dev" ] || continue
cd $dev

open_dialog GET_LABEL_TYPE
read_line label_type
close_dialog

if [ "$label_type" = msdos ]; then
DISK_BIOS_BOOT=yes
else
DISK_BIOS_BOOT=no
fi

NON_EFI_THIS_DISK=0
partitions=
open_dialog PARTITIONS
while { read_line num id size type fs path name; [ "$id" ]; }; do
# Build a list of partitions that:
# 1. Will *not* be bios-bootable (e.g. ESP)
# 2. Might be bios-bootable (~anything that's not
#"free space"
if [ "$fs" = fat16 ]; then
partitions="$partitions $id"
elif [ "$fs" = fat32 ] && echo "$name" |
 grep -i "^EFI System Partition" >/dev/null; then
partitions="$partitions $id"
elif [ "$label_type" = msdos ] && \
 [ "$(blkid -o value -s PART_ENTRY_TYPE -p "$path" 
2>/dev/null)" = "$msdos_efi_type" ]; then
partitions="$partitions $id"
elif [ "$label_type" = gpt ] && \
 [ "$(blkid -o value -s PART_ENTRY_TYPE -p "$path" 
2>/dev/null)" = "$gpt_efi_type" ]; then
partitions="$partitions $id"
elif [ "$label_type" = gpt ] && \
 [ "$(blkid -o value -s PART_ENTRY_TYPE -p "$path" 
2>/dev/null)" = "$gpt_bios_boot_type" ]; then
# We have a GPT disk with a "BIOS BOOT"
# partition included, so this disk might be
# set up for BIOS boot.
DISK_BIOS_BOOT=yes
log "Disk $dev contains a BIOS boot partition"
partitions="$partitions $id"
else
if [ "$fs" != "free" ]; then
log "Partition $path might be bios-bootable, 
checking further"
partitions="$partitions $id"
fi
fi
done
close_dialog

# Now look for more details on each of those partitions
for id in $partitions; do
efi=no

open_dialog GET_FLAGS $id
# cannot break here until we've hit close_dialog below
while { read_line flag; [ "$flag" ]; }; do
log "$dev $id has $flag flag"
if [ "$flag" = boot ] && [ "$label_type" = gpt ]; then
efi=yes
elif [ "$flag" = esp ]; then
efi=yes
fi
done
close_dialog

if [ "$efi" = yes ]; then
# An ESP is clearly 

Bug#1021894: openjfx: FTBFS on arm64 and armhf

[tony mancill]

Hi Wookey,

Thank you for the investigation and the patch!

I intend to build and upload in the next few days, but you are welcome
to NMU if you would prefer.

Cheers,
tony

On Fri, Jul 14, 2023 at 02:28:14PM +0100, Wookey wrote:
> Source: openjfx
> Followup-For: Bug #1021894
> 
> I was surprised to find that this package was missing on arm64 (making josm 
> uninstallable) so I investigated. 
> 
> 11.0.11+0-1 built OK on 2021-02-03. But 11.0.11+1-3 FTBFS.
> 
> 11.0.11+0-1 no longer builds either. Failing in:
> Execution failed for task ':media:buildAVPlugin'
> ../../../plugins/av/decoder.c:79:5: error: implicit declaration of function 
> 'avcodec_register_all'
> which seems to be a problem with ffmpeg, but lets ignore that for now - it 
> seems to be fixed with a patch in +1-3
> 
> 11.0.11+1-3 fails with:
> [ 28%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o
>   Gradle is still running, please be patient...
> In file included from 
> /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssemblerARM64.h:30,
>  from 
> /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssembler.h:46,
>  from 
> /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/GPRInfo.h:28,
>  from 
> /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ArithProfile.h:28,
>  from 
> /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:28:
> /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:
>  In static member function ‘static void 
> JSC::ARM64Assembler::replaceWithJump(void*, void*)’:
> /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:2576:51:
>  error: ‘class JSC::ExecutableAllocator’ has no member named ‘getJumpIslandTo’
>  2576 | to = 
> ExecutableAllocator::singleton().getJumpIslandTo(where, to);
>   |   ^~~
> /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:
>  In static member function ‘static void* 
> JSC::ARM64Assembler::prepareForAtomicRelinkJumpConcurrently(void*, void*)’:
> /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:2781:49:
>  error: ‘class JSC::ExecutableAllocator’ has no member named 
> ‘getJumpIslandToConcurrently’
>  2781 | return 
> ExecutableAllocator::singleton().getJumpIslandToConcurrently(from, to);
>   | 
> ^~~
> /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:
>  In static member function ‘static void 
> JSC::ARM64Assembler::linkJumpOrCall(int*, const int*, void*)’:
> /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:3024:51:
>  error: ‘class JSC::ExecutableAllocator’ has no member named ‘getJumpIslandTo’
>  3024 | to = 
> ExecutableAllocator::singleton().getJumpIslandTo(bitwise_cast(fromInstruction),
>  to);
>   |   ^~~
> 
> (Which is actually a different failure point from the one Sebastian posted in 
> this bug)
> 
> So all this jumpisland stuff comes from webkit's JavaScript JIT.
> 
> It turns out that this upstream Webkit bug explains what's going on:
> https://bugs.webkit.org/show_bug.cgi?id=217079
> jumpislands allow +-128MB jumps to get to the whole 1GB executable space by 
> having a particular memory layout.
> And the build should use _either_ the JIT or 'CLOOP', but not both.
> 
> Applying the patch in that bug (which gates JUMP_ISLANDS on the JIT
> being enabled, and avoids compiling in a call to dumpJITMemory if JIT
> is disabled) allows everything to get compiled. However it then fails
> to link:
>  
> [100%] Linking CXX shared library ../../lib/libjfxwebkit.so
> /usr/include/c++/11/ext/new_allocator.h:116: error: undefined reference to 
> 'std::__throw_bad_array_new_length()'
> collect2: error: ld returned 1 exit status
> gmake[4]: *** 
> [Source/WebKitLegacy/CMakeFiles/WebKitLegacy.dir/build.make:2237: 
> lib/libjfxwebkit.so] Error 1
> 
> Which seems to be a problem with compiling with gcc11/12, but then trying
> to link to the gcc-libstd++ from gcc10.  Removing all the gcc-10
> packages from the build environment fixed this. I think this means
> the package should get a build-conflict on libstdc++-10-dev
> 
> Also the discussion in the above bug suggests that the JIT should in fact be 
> enabled on debian arm64.
> It only needs to be turned off on iOS and 64k aarch64 kernel (RHEL). I will 
> test that next.
> 
> Attached is the debdiff that at least makes the build work again for now. 
> Happy to do an NMU if that's helpful

> diff -Nru openjfx-11.0.11+1/debian/changelog 
> 

Bug#1040694: Proposing a way to solve #1040694

[Pierre Gruet]

Hello Julien,

I am writing to you in addition to the sole bug report as you are the 
uploader of coinor-cbc.


Because we saw an ABI breakage between versions 2.10.8 and 2.10.10 which 
affects rdeps, I propose to:
- Revert the version in unstable to 2.10.8, with upstream version number 
being 2.10.10+really2.10.8+ds1;
- Upload 2.10.10+really2.10.10+ds1 (containing upstream 2.10.10) to 
experimental with a SOVERSION raised to 3.1 and renaming the shared lib 
package to coinor-libcbc3.1, hereby using a SOVERSION higher than the 
upstream one but still being lower than the "4" they could adopt in the 
future;

- Lead a classic library transition so that rdeps are rebuilt.

I volunteer to do this if you want, as this is a blocker for my workflows.

Please kindly raise concerns if you need to :)

Cheers,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041225: FTBFS against suitesparse 7

[Sébastien Villemot]

Source: siconos
Version: 4.4.0+dfsg-2
Severity: important
Tags: ftbfs sid trixie patch
User: sebast...@debian.org
Usertags: suitesparse7

Dear Maintainer,

siconos fails to build against suitesparse 7, which is currently available in
experimental.

A patch is attached.

Cheers,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org
Description: Fix FTBFS against suitesparse 7
 In SuiteSparse 7.1.0, CXSparse now unconditionally enables the complex number
 support. In particular, cs.h now unconditonally includes .
 But "I" is a preprocessor macro when  is included, and this
 conflicts with names used inside siconos and boost. So undefine that macro.
Author: Sébastien Villemot 
Bug-Debian: https://bugs.debian.org/
Forwarded: no
Last-Update: 2023-07-15
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/numerics/src/tools/CSparseMatrix_internal.h
+++ b/numerics/src/tools/CSparseMatrix_internal.h
@@ -45,6 +45,7 @@
 #define NCOMPLEX
 
 #include "cs.h"
+#undef I
 
 #include "CSparseMatrix.h"
 

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Nicholas D Steeves]

Hi Alexandru,

Alexandru Mihail  writes:

> After a bit more research into how other projects treat NCSA bits I'd
> propose something along the lines of:
>
> debian/copyright:
> Files: htpasswd.c

Yes, and htpasswd.1.

> Copyright: 1993-1994 Rob McCool 
> Copyright: 1997 Jef Poskanzer  ?

Yes, and you would know the years better than I!  Also, you'll need to
say a few words about how you established copyright--a very short too
long didn't read version of this thread.  Find out how to do this at
§5.1 of the following (read the short list of fields, and you'll see
which one it is):

  https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#file-syntax

> License: NCSA
>  
>
> License: NCSA
> This code is in the public domain. Specifically, we give to the public
> domain all rights for future licensing of the source code, all resale
> rights, and all publishing rights.
>
> We ask, but do not require, that the following message be included in
> all derived works:
>
> Portions developed at the National Center for Supercomputing
> Applications at the University of Illinois at Urbana-Champaign.
>
> THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED,
> FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT
> LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A
> PARTICULAR PURPOSE.

Looks good to me.

> Also, looking into your concerns about public domain in other countries
> (specifically referring to NCSA's :"This code is in the public
> domain"):
>
> Excerpt from https://wiki.debian.org/DFSGLicenses#Public_Domain :
[snip]

Thank you for looking into this, and for sharing this information.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1041161: dkms autopkg test fails on arm64

[Andreas Beckmann]

On 15/07/2023 12.00, Matthias Klose wrote:

179s The following packages have unmet dependencies:
179s  libhwasan0 : Depends: gcc-13-base (= 13.1.0-8) but 13.1.0-6 is to 
be installed

179s E: Unable to correct problems, you have held broken packages.
179s E: Linux headers failed to install.

there seems to be something wrong with the setup of the test. why isn't 
the same version taken for the two packages?


My guess is that is on the autopkgtest side ...

This is a test in testing with --pin-packages=unstable=src:gcc-11
dkms-autopkgtest does
  apt-get install linux-headers-6.3.0-1-arm64 \
linux-headers-6.3.0-1-cloud-arm64 \
linux-headers-6.3.0-1-rt-arm64
(these are from testing) - why does that want to install libhwasan0 from 
sid?


Andreas

Bug#1041224: RFS: wmbusmeters/1.13.1-3 - read wireless and wired M-Bus (EN13757 OMS) telegrams from utility meters

[Fredrik Öhrström]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "wmbusmeters":

 * Package name : wmbusmeters
   Version  : 1.13.1-3
   Upstream contact : oehrstr...@gmail.com
 * URL  : https://github.com/wmbusmeters/wmbusmeters
 * License  : GPLv3
 * Vcs  : https://salsa.debian.org/weetmuts/package-wmbusmeters
   Section  : experimental

The source builds the following binary packages:

  wmbusmeters - read wireless and wired M-Bus (EN13757 OMS) telegrams
from utility meters

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/wmbusmeters/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/w/wmbusmeters/wmbusmeters_1.13.1-3.dsc

Changes since the last upload:

  * Update build dependencies.
  (This is done to build on more debian platforms.)

Regards,

Fredrik Öhrström

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Nicholas D Steeves]

Hellow Alexandru,

Alexandru Mihail  writes:

> Hello Nicholas,
>>That's ok, you don't need to find the original version.  Remember
>>that
>>it's a fork and child relationship,
>
> Yes, I'm terribly sorry, I'm familiar with the fork-child relationship
> but I still found your analogy very helpful and concise, I might
> present it to my interns (if that's O.K), thanks a lot for the
> reminder. I was extremely tired when I wrote the last e-mail.

No worries, and yes, go ahead and use that analogy :)  If you feel like
citing/attributing it to me, I'd appreciate it, but this isn't required.

> In short, considering debian-legal's input, should I mention the NCSA
> copyright notice in debian/copyright for Files: htpasswd.c, adding a
> separate License: NCSA field to clarify the provenance of said source ?

Yes, and if I remember correctly, you had figured this out by your next
email (once again, sorry for my delays in replying).

> I will fix the /patches issues  we discussed in a later commit and
> would also like to propose a mechanism for integrating PAM (Pluggable
> Authentication Modules) into mini-httpd. I am currently in the
> negotiation phase  with my employer to grant an exception for this
> particular patch in order for it to be upstreamed into debian/patches
> (since, remember, we're the de-facto upstream here) and for my code to
> become GPL licensed). PAM support (which would be toggled via a
> Makefile parameter) could provide tangible improvements for the  users
> of mini-httpd and might even increase the server's popularity. The AUTH
> mechanism in mini-httpd is arguably heavily antiquated and prone to
> DDos attacks, MitM, scalability issues, etc. PAM would also enable AAA
> solutions to interoperate with mini-httpd almost seamlessly (such as
> Radius, TACACS+) which is becoming increasingly relevant in today's
> SSO/IoT central trust-based use cases.

Wow, that's wonderful (and unexpected) news!  I hope negotiations go well.

>>P.S. Please acknowledge: Have you read the DFSG yet, and do you
>>understand why it's important?
> Yes I have and yes I do, it is one of the main reasons I decided to
> start contributing to DebianWiki (and now mini-httpd) to begin with. :)

Thanks, much appreciated, and cool story!

>>I confirm receipt of your mail, and I see an attached signature. 
>>Where
>>can I download your public key?
>
> I'd like to ask you the same question, since I'd like to add your
> address to my keyring. I've read a bit of documentation which suggests
> using Ubuntu's HKP which seems a bit off-axis. I understand that the
> Debian Public Key Server is for DDs and DMs only (I am not yet a DM).
> I could perhaps use my DebianWiki personal page to link to my public
> key, but I do not know if that solution would be accepted or would
> sound absurd. I should find a better solution after some research.

My key is on both the Debian keyring and public servers

  https://wiki.debian.org/DebianKeyring
  https://keys.openpgp.org/
  and maybe also here
  http://pgp.mit.edu/

I haven't checked if pgp.mit.edu auto-updated from keys.openpgp.org how
it used to work with the old SKS network.

P.S. Please make create key revocation certificates for the cases:
no-longer-used, superceded, and compromised, and store them someplace
safe.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1037904: Xournal++ GCC 13 FTBFS fixed upstream

[John Scott]

Control: forwarded -1 
https://github.com/xournalpp/xournalpp/commit/9172ee831f4dfbb88dfeb13b66862e80e64a0d3f
Control: tags -1 fixed-upstream

It looks like this has been fixed upstream, so I'm setting the bug metadata as 
such.


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


smime.p7s
Description: S/MIME cryptographic signature

Bug#1041163: crowdsec 1.4.6-6~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1041163 = 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: crowdsec
Version: 1.4.6-6~deb12u1

Explanation: fix default acquis.yaml to also include the journalctl datasource, 
limited to the ssh.service unit, making sure acquisition works even without the 
traditional auth.log file; make sure an invalid datasource doesn't make the 
engine error out

Bug#1041160: linux-image-6.3.0-2-amd64: no pairing with 6.3.0.1 possible

[Dietmar Czekay]

I can do certain tests after the weekend.

I  switched on the bootmenue grub between the different kernel versions. 
so same Firmware, just different kernel


firmware is rtw_8821ce :03:00.0: Firmware version 24.11.0, H2C 
version 12


Dietmar

Bug#1041158: perl: pod2man propagates duplicate space in the man page

[Russ Allbery]

Vincent Lefevre  writes:

> pod2man propagates duplicate space in the man page (contrary to
> pod2text).

> For instance, /usr/sbin/pam_getenv contains

> This tool  will print out the value [...]

> with 2 space characters between "tool" and "will" (this is probably
> unwanted, but this shouldn't yield inconsistencies in their handling).

> The pod2text utility generates only one space:

> zira:~> pod2text /usr/sbin/pam_getenv | grep tool
> This tool will print out the value of *env_var* from /etc/environment.

> but pod2man keeps both spaces, so that one gets them in the man page:
> "pod2man /usr/sbin/pam_getenv | man -l -" gives

> [...]
> DESCRIPTION
>This tool  will print out the value of env_var from /etc/environment.
> [...]

The thing that's surprising to me in this is that *roff doesn't collapse
the spaces.  I feel like this is changed behavior and it used to do so,
although I'm not sure.

The root underlying issue here is unfortunately quite complex, and it's
very easy to break things in this area while trying to fix unfortunate
rendering such as that.  See the discussion in the Pod::Man manual page
under CAVEATS in the current version (which I think may only be in
experimental at this point):

  Sentence spacing
Pod::Man copies the input spacing verbatim to the output *roff document.
This means your output will be affected by how nroff generally handles
sentence spacing.

nroff dates from an era in which it was standard to use two spaces after
sentences, and will always add two spaces after a line-ending period (or
similar punctuation) when reflowing text. For example, the following
input:

=pod

One sentence.
Another sentence.

will result in two spaces after the period when the text is reflowed. If
you use two spaces after sentences anyway, this will be consistent,
although you will have to be careful to not end a line with an
abbreviation such as "e.g." or "Ms.". Output will also be consistent if
you use the *roff style guide (and XKCD 1285 )
recommendation of putting a line break after each sentence, although
that will consistently produce two spaces after each sentence, which may
not be what you want.

If you prefer one space after sentences (which is the more modern
style), you will unfortunately need to ensure that no line in the middle
of a paragraph ends in a period or similar sentence-ending paragraph.
Otherwise, nroff will add a two spaces after that sentence when
reflowing, and your output document will have inconsistent spacing.

For various historical reasons, Pod::Text defaults to collapsing all
spacing to single spaces and you have to set the sentence option (the -s
flag) to get more equivalent behavior.  If you run pod2text -s on that
same man page, you will see the same problem.

The difference in defaults is partly historical accident and backwards
compatibility, but the more defensible justification is that *roff has its
own opinions about whitespace formatting and prefers two spaces after
periods, so it's much easier to get consistent output from *roff if
pod2man doesn't try to second-guess one space vs. two spaces.
(Determining whether a given double space is at the end of a sentence in a
way compatible with multiple languages is incredibly hard to do and is not
something I'm very enthused about trying to tackle in a Perl core module.)

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

Bug#1041168: Installation of GRUB failed

[Christof B.]

Am 15.07.23 um 21:07 schrieb Pascal Hambourg:
If you are willing to test, I can provide patched files which replace the 
original ones in a running d-i.


Yes, I am willing to test this. If it can be patched by replacing some 
files at runtime (and not compiling some binaries or images), please 
provide me the files with a hint at where (path) and when (at which step 
of the installation process) to put them into place.


If technically feasible (if all files can be replaced at once) a tarball 
would be best.


Thanks and cheers
Christof

Bug#1041222:

[Andreas Hasenack]

Salsa PR at https://salsa.debian.org/ruby-team/unicorn/-/merge_requests/1

Bug#1041168: Installation of GRUB failed

[Pascal Hambourg]

On 15/07/2023 at 19:50, Christof B. wrote:


Am 15.07.23 um 18:35 schrieb Pascal Hambourg:


It looks like bug #1034812 (patches available).


Are there any (nightly) d-i images available to test these patches,
If you are willing to test, I can provide patched files which replace 
the original ones in a running d-i.

Bug#1041223: src:icingaweb2-module-graphite: fails to migrate to testing for too long: unresolved issues

[Paul Gevers]

Source: icingaweb2-module-graphite
Version: 1.2.2-1
Severity: serious
Control: close -1 1.2.2-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1038929

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:icingaweb2-module-graphite has been trying 
to migrate for 31 days [2]. Hence, I am filing this bug. The version of 
this package in unstable has installability issues as reported in bug 
1038929.


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=icingaweb2-module-graphite



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041221: lsm: Please package upstream version 1.0.24

[Daniel Gröber]

Source: lsm
Severity: wishlist
X-Debbugs-Cc: d...@darkboxed.org

Hi Lucas,

it looks like there haven't been any uploads of lsm since 2020. The
version we currently have in Debian is 1.0.4 but upstream has been
busy and is at version 1.0.24.

Unfortunately it's unclear what changes have been made upstream since
neither a changelog nor a git repo are provided. Still it's best to
keep packages up-to-date.

If you're not interested in maintaining lsm anymore I might be
interested in taking over, though I'm evaluating if lsm covers my
use-case :)

Thanks,
--Daniel

Bug#1041220: src:libgitlab-api-v4-perl: fails to migrate to testing for too long: triggers autopkgtest regression in devscripts

[Paul Gevers]

Source: libgitlab-api-v4-perl
Version: 0.26-3
Severity: serious
Control: close -1 0.27-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1038486

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:libgitlab-api-v4-perl has been trying to 
migrate for 32 days [2]. Hence, I am filing this bug. The package in 
unstable triggers an autopkgtest issue in devscripts, which is reported 
in bug 1038486.


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=libgitlab-api-v4-perl



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041219: src:basilisk2: fails to migrate to testing for too long: FTBFS on arm*

[Paul Gevers]

Source: basilisk2
Version: 0.9.20220710-1
Severity: serious
Control: close -1 0.9.20230516-1
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:basilisk2 has been trying to migrate for 
32 days [2]. Hence, I am filing this bug. The package in unstable fails 
to build on arm64, armel and armhf, while it built there successfully in 
the past.


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=basilisk2



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041218: src:ardour: fails to migrate to testing for too long: FTBFS on mips*el

[Paul Gevers]

Source: ardour
Version: 1:7.3.0+ds0-1
Severity: serious
Control: close -1 1:7.4.0+ds-1
Tags: sid trixie ftbfs
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:ardour has been trying to migrate for 32 
days [2]. Hence, I am filing this bug. The package in unstable fails to 
build on mips64el and mipsel, while it built there successfully in the past.


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=ardour



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1038258: pylint: Regression with tomlkit 0.11.8, Fixed in 2.17.4

[Paul Gevers]

Control: severity -1 serious

Hi,

On Fri, 16 Jun 2023 15:37:39 -0400 Scott Kitterman 
 wrote:

Please upgrade pylint to the current upstream version (2.17.4).  The
pylint current in unstable is not compatible with the tomlkit in
unstable and it's reported fixed upstream.


This is blocking migration of tomlkit, which is considered an RC issue 
in tomlkit [1]. Hence this bug is RC too.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041217: src:node-chart.js: fails to migrate to testing for too long: autopkgtest failure

[Paul Gevers]

Source: node-chart.js
Version: 3.9.1+~0.2.1-2
Severity: serious
Control: close -1 3.9.1+~cs3.1.2-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1039918

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:node-chart.js has been trying to migrate 
for 32 days [2]. Hence, I am filing this bug. The version of this 
package in unstable has issues with its autopkgtest as reported in bug 
1039918.


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=node-chart.js



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041216: src:ruby-sidekiq: fails to migrate to testing for too long: autopkgtest failure

[Paul Gevers]

Source: ruby-sidekiq
Version: 6.4.1+dfsg-1
Severity: serious
Control: close -1 6.5.7+dfsg3-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: tags -1 by 1039921

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:ruby-sidekiq has been trying to migrate 
for 32 days [2]. Hence, I am filing this bug. The version of this 
package in unstable has issues with its autopkgtest as reported in bug 
1039921.


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=ruby-sidekiq



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041215: src:squeekboard: fails to migrate to testing for too long: FTBFS on mipsel

[Paul Gevers]

Source: squeekboard
Version: 1.21.0-1
Severity: serious
Control: close -1 1.22.0-3
Tags: sid trixie ftbfs
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:squeekboard has been trying to migrate for 
32 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build on mipsel while if built there successfully in the past.


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=squeekboard



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041214: src:mesa: fails to migrate to testing for too long: causes autopkgtest regression

[Paul Gevers]

Source: mesa
Version: 22.3.6-1+deb12u1
Severity: serious
Control: close -1 23.1.3-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1039922

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:mesa has been trying to migrate for 33 
days [2]. Hence, I am filing this bug. The version in testing causes an 
autopkgtest regression as reported in bug 1039922.


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=mesa



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027414: luit: broken apt install xorg from a debootstrap installed environment

[Thomas Dickey]

On Sat, Jul 15, 2023 at 08:13:19AM -0400, Thomas Dickey wrote:
> On Sat, Jul 15, 2023 at 10:16:22AM +, David Roderick wrote:
> > Package: luit
> > Version: 2.0.20221028-1
> > Followup-For: Bug #1027414
> > X-Debbugs-Cc: I have been told to report this by #debian on libera irc, 
> > dmr...@inspirondebian.home
> > 
> > Breaks: x11-utils (<<7.7+6) but bookworm contains x11-utils (7.7+5)
> 
> I'd expect that this is a problem to be resolved by releasing x11-utils
> (recall that Brendan's updates to disentangle luit were in January 2022)
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=x11-utils
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003021
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006193
> 
> There are several packages which depend upon x11-utils; probably only
> xterm uses luit, so releasing the update should not cause problems.

For instance, I've seen occasional mention that luit is useful with emacs.
But its source-code doesn't mention luit.

Actually (for better maintenance), the rest of x11-utils should be split up
because its upstream is a collection of tar-balls which introduce dependencies
unwanted by most users.  In particular, this doesn't belong:

/usr/bin/xdriinfo

Since it's actually a problem with x11-utils, this bug should be reassigned.

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1041213: src:python-xarray: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: python-xarray
Version: 2023.01.0-1.1
Severity: serious
Control: close -1 2023.06.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1039871

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:python-xarray has been trying to migrate 
for 34 days [2]. Hence, I am filing this bug. The package fails to build 
from source as reported in bug 1039871.


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=python-xarray



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041168: Installation of GRUB failed

[Cyril Brulebois]

Christof B.  (2023-07-15):
> Probably this is a duplicate.
> Are there any (nightly) d-i images available to test these patches,
> because otherwise (i. e. building d-i myself) this is over my head.

Not yet. Speaking only for myself, I'm still in dire need of rest
after the whole Bookworm release marathon over the last few months,
and I haven't been able to dive into those patches just yet.

They're on my list of things to look into on the short term though,
including considering them for some point release.


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


signature.asc
Description: PGP signature

Bug#1020471: Interest in patch?

[Sébastien Villemot]

Hi Soren,

Le samedi 15 juillet 2023 à 10:51 -0700, Soren Stoutner a écrit :
> Would you be interested in a patch implementing this functionality?

In principle I would be interested in a patch.

But actually I’m considering the possibility of removing src:hunspell-
fr and having its binary packages taken over by src:grammalecte. So I
don’t know if it’s the right time to implement such a change. And I 
can’t guarantee that your patch will apply as-is in the new setup.

Best wishes,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#1041212: When ausweisapp2 is running, clicking on notifications for other apps always opens the ausweisapp2 window

[Dirk Heinrichs]

Package: ausweisapp2
Version: 1.26.4-1
Severity: normal



-- System Information:
Debian Release: 12.0
  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)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_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)

Versions of packages ausweisapp2 depends on:
ii  libc6   2.36-9
ii  libhttp-parser2.9   2.9.4-5
ii  libpcsclite11.9.9-2
ii  libqt6core6 6.4.2+dfsg-10
ii  libqt6gui6  6.4.2+dfsg-10
ii  libqt6network6  6.4.2+dfsg-10
ii  libqt6qml6  6.4.2+dfsg-1
ii  libqt6quick66.4.2+dfsg-1
ii  libqt6quickcontrols2-6  6.4.2+dfsg-1
ii  libqt6statemachine6 6.4.2-2
ii  libqt6svg6  6.4.2-2
ii  libqt6websockets6 [qt6-websockets-abi]  6.4.2-1
ii  libqt6widgets6  6.4.2+dfsg-10
ii  libssl3 3.0.9-1
ii  libstdc++6  12.2.0-14
ii  libudev1252.6-1
ii  qml6-module-qt-labs-platform6.4.2+dfsg-1
ii  qml6-module-qtqml   6.4.2+dfsg-1
ii  qml6-module-qtqml-models6.4.2+dfsg-1
ii  qml6-module-qtqml-statemachine  6.4.2-2
ii  qml6-module-qtqml-workerscript  6.4.2+dfsg-1
ii  qml6-module-qtquick-controls6.4.2+dfsg-1
ii  qml6-module-qtquick-layouts 6.4.2+dfsg-1
ii  qml6-module-qtquick-templates   6.4.2+dfsg-1
ii  qml6-module-qtquick-window  6.4.2+dfsg-1

Versions of packages ausweisapp2 recommends:
ii  pcsc-tools  1.6.2-1
ii  pcscd   1.9.9-2

ausweisapp2 suggests no packages.

-- no debconf information

Bug#1041193: Acknowledgement (vtun segfaulting on tunnel initialization)

[Tom Noonan II]

Changing the encryption setting from blowfish to aes allowed the tunnel
to start.  This can probably be downgraded from important.  Thanks.


On Sat, 15 Jul 2023 14:33:04 +
"Debian Bug Tracking System"  wrote:

> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 1041193:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041193.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> As you requested using X-Debbugs-CC, your message was also forwarded
> to t...@tjnii.com
> (after having been given a Bug report number, if it did not have one).
> 
> Your message has been sent to the package maintainer(s):
>  Rodrigo Carvalho 
> 
> If you wish to submit further information on this problem, please
> send it to 1041...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 

Bug#1041168: Installation of GRUB failed

[Christof B.]

Hi!

Am 15.07.23 um 18:35 schrieb Pascal Hambourg:

Hello,

On 15/07/2023 at 15:28, Christof B. wrote:


Filesystem   1K-blocks  Used Available Use% Mounted on
/dev/mapper/debian--vg-root
  120469224   1379448 112924068   1% /target
/dev/sdb2   466026 88234    352807  20% /target/boot
/dev/sda2 5062  5062 0 100% /target/boot/efi

(...)
Although I chose sdb as installation target, somehow d-i uses /dev/sda2 
instead of /dev/sdb2 as EFI partition.


You mean /dev/sdb1. /dev/sdb2 is the /boot partition.


Yes.



It looks like bug #1034812 (patches available).



Probably this is a duplicate.
Are there any (nightly) d-i images available to test these patches, 
because otherwise (i. e. building d-i myself) this is over my head.


Cheers,
Christof

Bug#1041211: libsdl-perl: FTBFS and autopkgtest failure with sdl12-compat, especially on 32-bit

[Simon McVittie]

Source: libsdl-perl, sdl12-compat
Control: found -1 libsdl-perl/2.548-3
Control: found -1 sdl12-compat/1.2.64-5
Control: block 1039911 by -1
Severity: serious
Tags: trixie sid ftbfs
User: debian...@lists.debian.org
Usertags: breaks needs-update

Since sdl12-compat took over the libsdl1.2debian and libsdl1.2-dev
packages from the old libsdl1.2, the test suite from libsdl-perl is
sometimes crashing in t/core_video.t. It seems to be failing consistently
on 32-bit architectures, and intermittently on some 64-bit architectures
(arm64 and s390x). I didn't see this before starting the transition
because I had used amd64 for my test-rebuilds, and amd64 seems to be
consistently unaffected.

I originally saw this in the autopkgtest runs on ci.debian.net, but I was
able to reproduce a similar failure during build-time testing on i386.
I didn't see a similar crash when testing real games, so I don't know
whether this is a crash that can affect games in practice, or just a
test issue.

It is not yet clear to me whether this is a libsdl-perl bug or a
sdl12-compat bug, so for now the bug is reported as affecting both
packages. It can be reassigned to either libsdl-perl or sdl12-compat
when a root cause is found.

In the cases where it fails, there are two failure modes that I've seen.
One failure mode is that t/core_video.t crashes with signal 11 (SIGSEGV)
during testing, usually (perhaps always?) after test point 65, for
example in
:


147s t/core_video.t ..
147s ok 1 - SDL::Video->can(...)
147s ok 2 - SDL_SWSURFACE should be imported

...

147s ok 63 - '[get_video_surface] Checking if we get a surface ref back' isa 
'SDL::Surface'
147s ok 64 - [video_driver_name] This is your driver name: dummy
147s ok 65 - [video_mode_ok] Checking if an integer was return
147s All 65 subtests passed
147s(2 TODO tests unexpectedly succeeded)

...

289s t/core_video.t(Wstat: 11 (Signal: SEGV) Tests: 65 Failed: 
0)
289s   TODO passed:   57, 59
289s   Non-zero wait status: 11
289s   Parse errors: No plan found in TAP output


The other failure mode is that t/core_video.t completes testing and calls
done_testing(), but then crashes with SIGSEGV during exit, for example in
:


369s t/core_video.t ..
369s ok 1 - SDL::Video->can(...)
369s ok 2 - SDL_SWSURFACE should be imported
...
369s ok 108 # skip No window manager available
369s ok 109 # skip No window manager available
369s ok 110 - Are we still alive? Checking for segfaults
369s 1..110
369s All 110 subtests passed
369s(less 39 skipped subtests: 71 okay)
369s(2 TODO tests unexpectedly succeeded)

...

499s t/core_video.t(Wstat: 11 (Signal: SEGV) Tests: 110 Failed: 
0)
499s   TODO passed:   57, 59
499s   Non-zero wait status: 11


In the s390x log

we can also see an error message from glibc's malloc implementation
indicating memory corruption, perhaps a double-free or something like
that:


130s ok 64 - [video_driver_name] This is your driver name: dummy
130s ok 65 - [video_mode_ok] Checking if an integer was return
130s corrupted size vs. prev_size


This is blocking migration of sdl12-compat to testing (#1039911).

smcv

Bug#1041210: dpkg: vendor information should be read from /usr, not from /etc/dpkg/origins/

[Gioele Barabucci]

Package: dpkg
Version: 1.21.22
Usertags: conffiles-reduction

Dear dpkg maintainer,

currently files under /etc/dpkg/origin/ are used to store information 
about the distro vendor, for example its homepage or the URL of the bug 
tracker.


It doesn't make sense for this information to be configurable by the end 
user. This information should thus be read from from `/usr` (for example 
`/usr/share/dpkg/origins/`) instead of `/etc/dpkg/origins/`. (Or in 
addition to, using the classic stateless logic.)


This would also remove the need to ship an additional needless conffile 
in `base-files` (`/usr/share/dpkg/origins/debian` would then be shipped 
as a normal package file).


Regards,

--
Gioele Barabucci

Bug#1041196: marco: Window title disappears when the first character is Chinese

[Wenbin Lv]

Control: found -1 1.26.1-3+deb12u1
Control: tags -1 + upstream
Control: forwarded -1 https://github.com/mate-desktop/marco/issues/757

Confirmed this bug affects 1.26.1-3+deb12u1. So the aforementioned commit
caused the problem.

Most Chinese characters are 3 bytes long under UTF-8, and UTF-8 characters
can be as long as 4 bytes. So "g_utf8_strlen (title, 2) < 1" will be true
if the first character is Chinese.

Bug#1041209: kakasi: endless loop with certain input

[Marc Lehmann]

Package: kakasi
Version: 2.3.6-4.1
Severity: normal

Dear Maintainer,

when running kakasi -i utf8 -w, this input:

   ～ｳﾞｨｰﾊﾞﾃﾞヲﾝｻﾞﾋﾞｰ～

results in an endless loop and infinite output. reproducer:

   perl -e 'print pack "H*", 
"efbd9eefbdb3efbe9eefbda8efbdb0efbe8aefbe9eefbe83efbe9ee383b2efbe9defbdbbefbe9eefbe8befbe9eefbdb0efbd9e"'|kakasi
 -i utf8 -w

-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (500, 
'unstable-debug'), (500, 'testing-debug'), (500, 'oldstable-debug'), (500, 
'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 6.1.37-schmorp (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 kakasi depends on:
ii  kakasi-dic  2.3.6-4.1
ii  libc6   2.36-9

kakasi recommends no packages.

kakasi suggests no packages.

-- no debconf information

Bug#1041168: Installation of GRUB failed

[Pascal Hambourg]

Hello,

On 15/07/2023 at 15:28, Christof B. wrote:


Filesystem   1K-blocks  Used Available Use% Mounted on
/dev/mapper/debian--vg-root
  120469224   1379448 112924068   1% /target
/dev/sdb2   466026 88234    352807  20% /target/boot
/dev/sda2 5062  5062 0 100% /target/boot/efi

(...)
Although I chose sdb as installation target, somehow d-i uses /dev/sda2 
instead of /dev/sdb2 as EFI partition.


You mean /dev/sdb1. /dev/sdb2 is the /boot partition.

It looks like bug #1034812 (patches available).

Bug#1041039: nvidia-open-gpu-kernel-modules 525.125.06-1~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1041039 = 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: nvidia-open-gpu-kernel-modules
Version: 525.125.06-1~deb12u1

Explanation: new upstream stable release; security fixes [CVE-2023-25515 
CVE-2023-25516]

Bug#1040938: nvidia-graphics-drivers-tesla 525.125.06-1~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1040938 = 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: nvidia-graphics-drivers-tesla
Version: 525.125.06-1~deb12u1

Explanation: new upstream stable release; security fixes [CVE-2023-25515 
CVE-2023-25516]

Bug#1040932: nvidia-graphics-drivers 525.125.06-1~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1040932 = 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: nvidia-graphics-drivers
Version: 525.125.06-1~deb12u1

Explanation: new upstream stable release; security fixes [CVE-2023-25515 
CVE-2023-25516]

Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE

[Adam Borowski]

Package: debootstrap
Version: 1.0.128+nmu3
Severity: grave

bluca's NMU on 2023-07-15 makes debootstrap produce chroots using the
aliased-dirs scheme.  While it's currently the default scheme for non-buildd
systems, it is both not supported by dpkg (with no solution in sight), but
is also likely to produce packages that are explicitely forbidden by a
recent CTTE ruling that disallows moving files between directories aliased
by the current usrmerge scheme.

Quoting the still unsolving issues is pointless (you can read about them
in massive threads in a number of places) as bluca seems to be ignoring
them completely.

But, what matters here is the CTTE ruling in #1035831 -- for the time being,
packages must not move files between locations affected by the aliasing.

Packages built in an usrmerged chroot place such files under /usr while
built without usrmerge into whatever place they were installed to -- which
is a direct breach of the ruling.

Thus, that change needs to be reverted for now, and all packages built
with 1.0.128+nmu3 need to be either rebuilt or at least checked for such
a violation (as most are unaffected).


Meow!
-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-rc1-00036-gc493f11e457d (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages debootstrap depends on:
ii  wget  1.21.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.21-1
ii  debian-archive-keyring  2023.3
ii  gnupg   2.2.40-1.1

Versions of packages debootstrap suggests:
ii  binutils 2.40.90.20230705-1
pn  squid-deb-proxy-client   
ii  ubuntu-archive-keyring   2020.06.17.1-1
ii  ubuntu-keyring [ubuntu-archive-keyring]  2020.06.17.1-1
ii  xz-utils 5.4.1-0.2
ii  zstd 1.5.5+dfsg2-1

-- no debconf information

Bug#1037603: marked as done (civetweb: ftbfs with GCC-13)

[Andreas Tille]

Hi Sebastien,

seems you closed the wrong bug with your upload.  The package you
uploaded is orthanc-postgresql but the bug concerns civetweb.

Kind regards
Andreas.

Am Sat, Jul 15, 2023 at 12:09:18PM + schrieb Debian Bug Tracking System:
> Your message dated Sat, 15 Jul 2023 12:07:17 +
> with message-id 
> and subject line Bug#1037603: fixed in orthanc-postgresql 5.0+dfsg-1
> has caused the Debian Bug report #1037603,
> regarding civetweb: ftbfs with GCC-13
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
> 
> 
> -- 
> 1037603: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037603
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Wed, 14 Jun 2023 09:22:26 +
> From: Matthias Klose 
> To: mainto...@bugs.debian.org
> Subject: civetweb: ftbfs with GCC-13
> 
> Package: src:civetweb
> Version: 1.15+dfsg-4
> Severity: normal
> Tags: sid trixie
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-13
> 
> [This bug is targeted to the upcoming trixie release]
> 
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
> 
> 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/civetweb_1.15+dfsg-4_unstable_gccexp.log
> The last lines of the build log are at the end of this report.
> 
> To build with GCC 13, either set CC=gcc-13 CXX=g++-13 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
> 
>   apt-get -t=experimental install g++ 
> 
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++ related build failures see the porting guide at
> http://gcc.gnu.org/gcc-13/porting_to.html
> 
> [...]
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/civetweb/civetweb-targets.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/civetweb/civetweb-targets-none.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/civetweb/civetweb-config.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/civetweb/civetweb-config-version.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/civetweb/FindLibDl.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/civetweb/FindLibRt.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/civetweb/FindWinSock.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libcivetweb.so.1.15.0
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libcivetweb.so.1
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libcivetweb.so
> -- Installing: /<>/debian/tmp/usr/include/civetweb.h
> -- Installing: /<>/debian/tmp/usr/bin/civetweb
> -- Set runtime path of "/<>/debian/tmp/usr/bin/civetweb" to ""
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libcivetweb-cpp.so.1.15.0
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libcivetweb-cpp.so.1
> -- Set runtime path of 
> "/<>/debian/tmp/usr/lib/x86_64-linux-gnu/libcivetweb-cpp.so.1.15.0"
>  to ""
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libcivetweb-cpp.so
> -- Installing: /<>/debian/tmp/usr/include/CivetServer.h
> make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
>dh_install -O--buildsystem=cmake
>dh_installdocs -O--buildsystem=cmake
>dh_installchangelogs -O--buildsystem=cmake
>dh_installman -O--buildsystem=cmake
>dh_installsystemduser -O--buildsystem=cmake
>dh_perl -O--buildsystem=cmake
>dh_link -O--buildsystem=cmake
>dh_strip_nondeterminism -O--buildsystem=cmake
>dh_compress -O--buildsystem=cmake
>dh_fixperms -O--buildsystem=cmake
>dh_missing -O--buildsystem=cmake
>dh_dwz -a -O--buildsystem=cmake
> dwz: debian/libcivetweb1/usr/lib/x86_64-linux-gnu/libcivetweb.so.1.15.0: 
> DWARF compression not beneficial - old size 164499 new size 167095
> dwz: debian/libcivetweb1/usr/lib/x86_64-linux-gnu/libcivetweb-cpp.so.1.15.0: 
> DWARF compression not beneficial - old size 297647 new size 300459
>dh_strip -a -O--buildsystem=cmake
>dh_makeshlibs -a -O--buildsystem=cmake
> 

Bug#1041206: python-clickhouse-driver: FTBFS if source is included: aborting due to unexpected upstream changes

[Adam Borowski]

Source: python-clickhouse-driver
Version: 0.2.5-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi!
With any build type that includes the source, your package fails with:

dpkg-source: info: local changes detected, the modified files are:
 python-clickhouse-driver-0.2.5/clickhouse_driver/bufferedreader.c
 python-clickhouse-driver-0.2.5/clickhouse_driver/bufferedwriter.c
 python-clickhouse-driver-0.2.5/clickhouse_driver/columns/largeint.c
 python-clickhouse-driver-0.2.5/clickhouse_driver/varint.c
dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/python-clickhouse-driver_0.2.5-1.diff.aYpmik
dpkg-source: info: Hint: make sure the version in debian/changelog matches the 
unpacked source tree


Full build log attached.


Meow!
-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-rc1-00036-gc493f11e457d (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
sbuild (Debian sbuild) 0.85.2 (11 March 2023) on valinor.angband.pl

+==+
| python-clickhouse-driver (amd64) Sat, 15 Jul 2023 16:07:40 + |
+==+

Package: python-clickhouse-driver
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-2168482a-634b-4d8e-b5d4-42b1136edf8b'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/python-clickhouse-driver-QFihkK/resolver-njOJ3X' with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Check APT
-

Checking available source versions...

Download source files with APT
--

Reading package lists...
NOTICE: 'python-clickhouse-driver' packaging is maintained in the 'Git' version 
control system at:
https://salsa.debian.org/debian/python-clickhouse-driver.git
Please use:
git clone https://salsa.debian.org/debian/python-clickhouse-driver.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 297 kB of source archives.
Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main 
python-clickhouse-driver 0.2.5-1 (dsc) [2200 B]
Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main 
python-clickhouse-driver 0.2.5-1 (tar) [292 kB]
Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main 
python-clickhouse-driver 0.2.5-1 (diff) [3228 B]
Fetched 297 kB in 0s (4024 kB/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 
'build/python-clickhouse-driver-QFihkK/python-clickhouse-driver-0.2.5' with 
'<>'
I: NOTICE: Log filtering will replace 'build/python-clickhouse-driver-QFihkK' 
with '<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 13), dh-python, cython3, 
python3-all-dev, python3-setuptools, python3-sphinx, python3-tzlocal, 
build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 13), dh-python, cython3, 
python3-all-dev, python3-setuptools, python3-sphinx, python3-tzlocal, 
build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [609 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [707 B]
Get:5 copy:/<>/apt_archive ./ Packages [739 B]
Fetched 2055 B in 0s (0 B/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)

Bug#1030121: rust-once-cell: please provide feature atomic-polyfill

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2023-01-31 12:25:46)
> Please provide feature atomic-polyfill, currently patched away.

Six months have passed, without even a comment on this bugreport.

Please share your plans for adding back the patched-away feature, or at
least reveal your reasons for avoiding it.

Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1041204: dhcpcd-base: dhcpcd -T wlp3s0 produces Segmentation fault

[Ingo Wichmann]

Package: dhcpcd-base
Version: 9.4.1-22
Severity: normal
X-Debbugs-Cc: iw-deb...@linuxhotel.de

Dear Maintainer,

I tried out 
  dhcpcd -T wlp3s0
to fetch information from my local dhcp-server. After some lines of output the
programm stops with 'Segmentation fault'. 

Here is the output I get:

# dhcpcd -T wlp3s0
dhcpcd-9.4.1 starting
DUID 00:04:94:6e:66:81:53:aa:11:cb:b0:9f:c5:e1:3e:11:82:a0
wlp3s0: IAID 31:5f:29:a8
wlp3s0: soliciting an IPv6 router
wlp3s0: soliciting a DHCP lease
wlp3s0: offered 192.168.1.119 from 192.168.1.2
interface='wlp3s0'
pid='5687'
protocol='dhcp'
reason='TEST'
ifcarrier='up'
ifflags='69699'
ifmetric='3003'
ifmtu='1500'
ifssid='linuxhotel'
ifwireless='1'
new_broadcast_address='192.168.1.255'
new_dhcp_lease_time='1800'
new_dhcp_message_type='2'
new_dhcp_server_identifier='192.168.1.2'
new_domain_name='linuxhotel.de'
new_domain_name_servers='192.168.1.5'
new_ip_address='192.168.1.119'
new_network_number='192.168.1.0'
new_routers='192.168.1.5'
new_subnet_cidr='24'
new_subnet_mask='2

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024357 is a similar bug that 
has been closed upstream with 
https://github.com/NetworkConfiguration/dhcpcd/issues/156 and seems to have 
been fixed in testing or sid. 

-- System Information:
Debian Release: 12.0
  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_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 dhcpcd-base depends on:
ii  adduser   3.134
ii  libc6 2.36-9
ii  libudev1  252.6-1

Versions of packages dhcpcd-base recommends:
ii  wpasupplicant  2:2.10-12

Versions of packages dhcpcd-base suggests:
pn  resolvconf | openresolv | systemd-resolved  

-- no debconf information

Bug#1041163: bookworm-pu: package crowdsec/1.4.6-6~deb12u1

[Cyril Brulebois]

Adam D. Barratt  (2023-07-15):
> Please go ahead.

Uploaded; and thanks for the quick approval to a very late request…


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1041203: FTBFS: InvalidRequirement: Expected end or semicolon

[Adam Borowski]

Source: macs
Version: 2.2.7.1-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi!
I'm afraid your package fails to build, with:
pkg_resources.extern.packaging._tokenizer.ParserSyntaxError: Expected end or 
semicolon (after name and no valid version specifier)
numpy>=>=1.17

Full log attached.


Meow!
-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-rc1-00036-gc493f11e457d (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
sbuild (Debian sbuild) 0.85.2 (11 March 2023) on valinor.angband.pl

+==+
| macs (amd64) Sat, 15 Jul 2023 15:59:52 + |
+==+

Package: macs
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-6c3ec2b5-ebd2-4821-9c2c-b590aa40ebd9'
 with '<>'
I: NOTICE: Log filtering will replace 'build/macs-QwMUa0/resolver-kV6wWG' with 
'<>'

+--+
| Update chroot|
+--+

Get:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease [199 kB]
Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main Sources.diff/Index 
[63.6 kB]
Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 
Packages.diff/Index [63.6 kB]
Get:4 http://apt-rosy.angband.pl:3142/debian unstable/main Sources 
T-2023-07-15-1409.27-F-2023-07-15-1409.27.pdiff [38.2 kB]
Get:4 http://apt-rosy.angband.pl:3142/debian unstable/main Sources 
T-2023-07-15-1409.27-F-2023-07-15-1409.27.pdiff [38.2 kB]
Get:5 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 Packages 
T-2023-07-15-1409.27-F-2023-07-15-1409.27.pdiff [14.4 kB]
Get:5 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 Packages 
T-2023-07-15-1409.27-F-2023-07-15-1409.27.pdiff [14.4 kB]
Fetched 379 kB in 1s (275 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  libtool
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 517 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 libtool all 
2.4.7-6 [517 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 517 kB in 0s (16.6 MB/s)
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 14595 files and directories currently installed.)
Preparing to unpack .../libtool_2.4.7-6_all.deb ...
Unpacking libtool (2.4.7-6) over (2.4.7-5) ...
Setting up libtool (2.4.7-6) ...
Processing triggers for man-db (2.11.2-2) ...

+--+
| Fetch source files   |
+--+


Check APT
-

Checking available source versions...

Download source files with APT
--

Reading package lists...
NOTICE: 'macs' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/med-team/macs.git
Please use:
git clone https://salsa.debian.org/med-team/macs.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 136 MB of source archives.
Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main macs 2.2.7.1-6 (dsc) 
[2102 B]
Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main macs 2.2.7.1-6 (tar) 
[135 MB]
Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main macs 2.2.7.1-6 
(diff) [1268 kB]
Fetched 136 MB in 0s (336 MB/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 

Bug#1017619: nautilus-wipe not present in bookworm

[Fabio Follin]

Dear nautilus-wipe maintainers and uploaders,

I recently upgraded my system to debian 12 and I was surprised that
nautilus-wipe was not present in bookworm and not even in testing.

It is planned to add it back in testing from sid and maybe also add it
to bookworm-backports?

Thanks a lot for your work.
Best regards,
Fabio Follin

Bug#1041202: flang-16: flang fails to compile: missing libraries

[Alastair McKinstry]

Package: flang-16
Version: 16.0.6-4
Severity: normal

flang-new fails to compile a hello world program:

alastair@debian:/tmp$ flang-new-16 -o foo hello.f90
/usr/bin/ld: cannot find -lFortran_main: No such file or directory
/usr/bin/ld: cannot find -lFortranRuntime: No such file or directory
/usr/bin/ld: cannot find -lFortranDecimal: No such file or directory
flang-new: error: linker command failed with exit code 1 (use -v to see 
invocation)

regards
Alastair



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

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

Bug#1041163: bookworm-pu: package crowdsec/1.4.6-6~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2023-07-15 at 12:18 +0200, Cyril Brulebois wrote:
> I'd like to fix serious bug #1040976 in bookworm. In a nutshell, both
> upstream and I missed the fact Debian 12 comes without rsyslog by
> default now, meaning /var/log/auth.log stays empty and the detection
> of
> failed SSH logins is ineffective.
> 

Please go ahead.

Regards,

Adam

Bug#1041074: bookworm-pu: package cpp-httplib/0.11.4+ds-1+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2023-07-14 at 18:59 +0200, Andrea Pappacoda wrote:
> [ Reason ]
> This fixes a security vulnerability (CRLF Injection).
> 

Please go ahead.

Regards,

Adam

Bug#1040939: bookworm-pu: package rmlint/2.9.0-2.3+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2023-07-12 at 17:50 +0100, Julian Gilbey wrote:
> This bug has been present for a long time but only just stumbled
> upon.  rmlint-gui installs a Python package with an invalid version
> number, causing other packages to mysteriously break when rmlint-gui
> is installed.  Only spyder has been reported to be affected so far,
> but I expect others to be equally impacted.
> 
> [ Impact ]
> Some other unrelated packages will continue to break in strange ways.
> It may well also cause headaches to maintainers of those packages.
> 

Please go ahead.

Regards,

Adam

Bug#1041200: chromium: Uses deprecated Python distutils

[Soren Stoutner]

Package: chromium
Version: 114.0.5735.198-1
Severity: minor
Tags: upstream

There are a number of files that depend on Python's deprecated distutils.

>From 
>https://udd.debian.org/lintian/?=chromium=html_information=on

build/win/message_compiler.py:11
chrome/updater/test/service/win/run_command_as_standard_user.py:24
third_party/angle/src/tests/capture_replay_tests.py:26
third_party/depot_tools/external_bin/gsutil/gsutil_4.68/gsutil/third_party/crcmod/setup.py:1
third_party/depot_tools/external_bin/gsutil/gsutil_4.68/gsutil/third_party/crcmod/setup.py:2
third_party/depot_tools/fetch.py:34
third_party/depot_tools/scm.py:7
third_party/depot_tools/testing_support/coverage_utils.py:7
third_party/depot_tools/tests/fetch_test.py:17
third_party/grpc/src/setup.py:22
third_party/grpc/src/setup.py:27
third_party/grpc/src/setup.py:28
third_party/grpc/src/setup.py:29
third_party/grpc/src/src/python/grpcio/_parallel_compile_patch.py:20
third_party/grpc/src/src/python/grpcio/_spawn_patch.py:21
third_party/grpc/src/src/python/grpcio/support.py:15
third_party/grpc/src/src/python/grpcio_tests/commands.py:16
third_party/grpc/src/src/python/grpcio_tests/tests/protoc_plugin/_python_plugin_test.py:17
third_party/grpc/src/tools/distrib/python/grpcio_tools/_parallel_compile_patch.py:20
third_party/grpc/src/tools/distrib/python/grpcio_tools/setup.py:15
third_party/grpc/src/tools/distrib/python/grpcio_tools/setup.py:16
third_party/grpc/src/tools/distrib/python/grpcio_tools/setup.py:17
third_party/logilab/logilab/astroid/modutils.py:36
third_party/logilab/logilab/astroid/modutils.py:37
third_party/logilab/logilab/common/modutils.py:37
third_party/logilab/logilab/common/modutils.py:38
third_party/perfetto/python/setup.py:1
third_party/protobuf/python/protobuf_distutils/protobuf_distutils/generate_py_protobufs.py:38
third_party/protobuf/python/protobuf_distutils/protobuf_distutils/generate_py_protobufs.py:39
third_party/protobuf/python/protobuf_distutils/protobuf_distutils/generate_py_protobufs.py:40
third_party/protobuf/python/setup.py:24
third_party/protobuf/python/setup.py:25
third_party/protobuf/python/setup.py:26
third_party/protobuf/python/setup.py:27
third_party/protobuf/python/setup.py:7
third_party/pycoverage/setup.py:46
third_party/pycoverage/setup.py:47
third_party/pycoverage/setup.py:48
third_party/skia/infra/bots/assets/skp/create.py:14
third_party/tflite/src/tensorflow/api_template.__init__.py:29
third_party/tflite/src/tensorflow/api_template_v1.__init__.py:17
third_party/tflite/src/tensorflow/lite/python/convert.py:17
third_party/tflite/src/tensorflow/python/ops/math_ops_linspace_test.py:19
third_party/tflite/src/tensorflow/python/tpu/profiler/capture_tpu_profile.py:22
third_party/vulkan-deps/glslang/src/update_glslang_sources.py:24
third_party/webdriver/pylib/setup.py:18
third_party/wpt_tools/wpt/tools/wpt/browser.py:11
third_party/wpt_tools/wpt/tools/wptrunner/wptrunner/browsers/safari.py:5
third_party/wpt_tools/wpt/tools/wptrunner/wptrunner/browsers/safari.py:6
third_party/wpt_tools/wpt/tools/wptrunner/wptrunner/wptcommandline.py:7
third_party/wpt_tools/wpt/tools/wpt/run.py:7
third_party/wpt_tools/wpt/tools/wpt/virtualenv.py:7
tools/binary_size/libsupersize/main.py:9
tools/bisect-builds.py:97
tools/ipc_fuzzer/scripts/cf_package_builder.py:12
tools/real_world_impact/real_world_impact.py:26
tools/valgrind/asan/third_party/asan_symbolize.py:31
v8/tools/release/common_includes.py:31


The description of this lintian tag reads as follows:

This package uses the Python distutils module.

In Python 3.10 and 3.11, distutils has been formally marked as deprecated.
Code that imports distutils will no longer work from Python 3.12.

Please prepare for this deprecation and migrate away from the Python
distutils module.

See-Also: https://peps.python.org/pep-0632


Python 3.12 is already in Debian and, presumably, at some point soon will 
become the default.

https://tracker.debian.org/pkg/python3.12


This problem also affects qtwebengine-opensource-src and qt6-webengine, 
although the list of affected files is different.

Does anyone know if upstream is working on removing the distutils dependency?

Bug#1041199: qt6-webengine: Uses deprecated Python distutils

[Soren Stoutner]

Source: qt6-webengine
Version: 6.4.2-final+dfsg-5
Severity: minor
Tags: upstream

There are a number of files that depend on Python's deprecated distutils.

>From 
>https://udd.debian.org/lintian/?=qt6-webengine=html_information=on

src/3rdparty/chromium/third_party/vulkan-deps/glslang/src/update_glslang_sources.py:24
src/3rdparty/chromium/third_party/webdriver/pylib/selenium/webdriver/firefox/firefox_profile.py:26
src/3rdparty/chromium/third_party/wpt_tools/wpt/tools/wpt/browser.py:10
src/3rdparty/chromium/third_party/wpt_tools/wpt/tools/wptrunner/wptrunner/browsers/safari.py:3
src/3rdparty/chromium/third_party/wpt_tools/wpt/tools/wptrunner/wptrunner/browsers/safari.py:4
src/3rdparty/chromium/third_party/wpt_tools/wpt/tools/wptrunner/wptrunner/wptcommandline.py:5
src/3rdparty/chromium/third_party/wpt_tools/wpt/tools/wpt/run.py:5
src/3rdparty/chromium/third_party/wpt_tools/wpt/tools/wpt/virtualenv.py:5
src/3rdparty/chromium/tools/binary_size/libsupersize/main.py:9
src/3rdparty/chromium/tools/bisect-builds.py:93
src/3rdparty/chromium/tools/ipc_fuzzer/scripts/cf_package_builder.py:12
src/3rdparty/chromium/tools/real_world_impact/real_world_impact.py:26
src/3rdparty/chromium/tools/valgrind/asan/third_party/asan_symbolize.py:31
src/3rdparty/chromium/v8/tools/release/common_includes.py:31
tools/scripts/take_snapshot.py:13
src/3rdparty/chromium/build/toolchain/win/midl.py:10
src/3rdparty/chromium/build/win/message_compiler.py:12
src/3rdparty/chromium/third_party/pdfium/testing/tools/pngdiffer.py:8
src/3rdparty/chromium/third_party/perfetto/python/setup.py:1
src/3rdparty/chromium/third_party/protobuf/python/compatibility_tests/v2.5.0/setup.py:16
src/3rdparty/chromium/third_party/protobuf/python/protobuf_distutils/protobuf_distutils/generate_py_protobufs.py:38
src/3rdparty/chromium/third_party/protobuf/python/protobuf_distutils/protobuf_distutils/generate_py_protobufs.py:39
src/3rdparty/chromium/third_party/protobuf/python/protobuf_distutils/protobuf_distutils/generate_py_protobufs.py:40
src/3rdparty/chromium/third_party/protobuf/python/setup.py:19
src/3rdparty/chromium/third_party/protobuf/python/setup.py:20
src/3rdparty/chromium/third_party/protobuf/python/setup.py:21
src/3rdparty/chromium/third_party/protobuf/python/setup.py:4
src/3rdparty/chromium/third_party/pycoverage/setup.py:46
src/3rdparty/chromium/third_party/pycoverage/setup.py:47
src/3rdparty/chromium/third_party/pycoverage/setup.py:48
src/3rdparty/chromium/third_party/pyelftools/setup.py:10
src/3rdparty/chromium/third_party/tflite/src/tensorflow/api_template.__init__.py:29
src/3rdparty/chromium/third_party/tflite/src/tensorflow/api_template_v1.__init__.py:17
src/3rdparty/chromium/third_party/tflite/src/tensorflow/lite/python/convert.py:17
src/3rdparty/chromium/third_party/tflite/src/tensorflow/python/compiler/tensorrt/utils.py:17
src/3rdparty/chromium/third_party/tflite/src/tensorflow/python/ops/math_ops_linspace_test.py:19
src/3rdparty/chromium/third_party/tflite/src/tensorflow/python/tpu/profiler/capture_tpu_profile.py:22
src/3rdparty/chromium/third_party/tflite/src/tensorflow/tools/docs/base_dir.py:16
src/3rdparty/chromium/third_party/tflite/src/tensorflow/tools/docs/generate2.py:28


The description of this lintian tag reads as follows:

This package uses the Python distutils module.

In Python 3.10 and 3.11, distutils has been formally marked as deprecated.
Code that imports distutils will no longer work from Python 3.12.

Please prepare for this deprecation and migrate away from the Python
distutils module.

See-Also: https://peps.python.org/pep-0632


Python 3.12 is already in Debian and, presumably, at some point soon will 
become the default.

https://tracker.debian.org/pkg/python3.12


This problem also affects qtwebengine-opensource-src and chromium, although the 
list of affected files is different.

Does anyone know if upstream is working on removing the distutils dependency?

Bug#1041198: qtwebengine-opensource-src: Uses deprecated Python distutils

[Soren Stoutner]

Source: qtwebengine-opensource-src
Version: 5.15.13+dfsg-1~deb12u1
Severity: minor
Tags: upstream

There are a number of packages that depend on Python's deprecated distutils.

>From 
>https://udd.debian.org/lintian/?=qtwebengine-opensource-src=html_information=on

src/3rdparty/chromium/third_party/protobuf/python/setup.py:4
src/3rdparty/chromium/third_party/pycoverage/setup.py:46
src/3rdparty/chromium/third_party/pycoverage/setup.py:47
src/3rdparty/chromium/third_party/pycoverage/setup.py:48
src/3rdparty/chromium/third_party/pyelftools/setup.py:10
src/3rdparty/chromium/third_party/tlslite/setup.py:6
src/3rdparty/chromium/third_party/webdriver/pylib/selenium/webdriver/firefox/firefox_profile.py:26
src/3rdparty/chromium/third_party/webrtc/tools_webrtc/ios/build_ios_libs.py:17
src/3rdparty/chromium/tools/binary_size/diagnose_bloat.py:17
src/3rdparty/chromium/tools/binary_size/libsupersize/main.py:11
src/3rdparty/chromium/tools/binary_size/libsupersize/path_util.py:8
src/3rdparty/chromium/tools/ipc_fuzzer/scripts/cf_package_builder.py:12
src/3rdparty/chromium/tools/bisect-builds.py:90
src/3rdparty/chromium/tools/real_world_impact/real_world_impact.py:26
tools/scripts/take_snapshot.py:39
src/3rdparty/chromium/build/android/gyp/compile_java.py:7
src/3rdparty/chromium/build/toolchain/win/midl.py:10
src/3rdparty/chromium/build/win/message_compiler.py:12
src/3rdparty/chromium/third_party/angle/third_party/vulkan-loader/src/scripts/update_deps.py:245
src/3rdparty/chromium/third_party/angle/third_party/vulkan-tools/src/scripts/update_deps.py:245
src/3rdparty/chromium/third_party/blink/tools/blinkpy/third_party/wpt/wpt/tools/wpt/browser.py:10
src/3rdparty/chromium/third_party/blink/tools/blinkpy/third_party/wpt/wpt/tools/wpt/run.py:5
src/3rdparty/chromium/third_party/blink/tools/blinkpy/third_party/wpt/wpt/tools/wpt/virtualenv.py:5
src/3rdparty/chromium/third_party/glslang/src/update_glslang_sources.py:24
src/3rdparty/chromium/third_party/pdfium/testing/tools/pngdiffer.py:6
src/3rdparty/chromium/third_party/perfetto/src/trace_processor/python/setup.py:1
src/3rdparty/chromium/third_party/protobuf/python/compatibility_tests/v2.5.0/setup.py:16
src/3rdparty/chromium/third_party/protobuf/python/setup.py:18
src/3rdparty/chromium/third_party/protobuf/python/setup.py:19
src/3rdparty/chromium/third_party/protobuf/python/setup.py:20


The description of this lintian tag reads as follows:

This package uses the Python distutils module.

In Python 3.10 and 3.11, distutils has been formally marked as deprecated.
Code that imports distutils will no longer work from Python 3.12.

Please prepare for this deprecation and migrate away from the Python
distutils module.

See-Also: https://peps.python.org/pep-0632


Python 3.12 is already in Debian and, presumably, at some point soon will 
become the default.

https://tracker.debian.org/pkg/python3.12


This problem also affects qt6-webengine and chromium, although the list of 
affected files is different.

Does anyone know if upstream is working on removing the distutils dependency?

Bug#1041197: "ata2.00: supports DRM functions and may not be fully accessible" and ACPI commands filtered out or rejected

[AlMa]

Package: linux-image-6.1.0-10-amd64
Version: 6.1.37-1

In the depths of my journal I discover the following two warnings 
(“ata2.00: supports DRM functions and may not be fully accessible” are 
marked orange):


$ grep -i ata2 -C 1 /tmp/j.log
Jul 15 15:21:43 AnonymizedMachineName kernel: ata1: SATA max UDMA/133 
abar m2048@0xf7f36000 port 0xf7f36100 irq 28
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2: SATA max UDMA/133 
abar m2048@0xf7f36000 port 0xf7f36180 irq 28
Jul 15 15:21:43 AnonymizedMachineName kernel: ata3: SATA max UDMA/133 
abar m2048@0xf7f36000 port 0xf7f36200 irq 28

--
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 3-1.8: New USB device 
found, idVendor=0a5c, idProduct=5801, bcdDevice= 1.01
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2: SATA link up 6.0 
Gbps (SStatus 133 SControl 300)
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 3-1.8: New USB device 
strings: Mfr=1, Product=2, SerialNumber=3
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: ACPI cmd 
f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out

Jul 15 15:21:43 AnonymizedMachineName kernel: usb 3-1.8: Product: 5880
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: ACPI cmd 
b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 3-1.8: Manufacturer: 
Broadcom Corp
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: ACPI cmd 
00/00:00:00:00:00:a0(NOP) rejected by device (Stat=0x51 Err=0x04)
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 3-1.8: SerialNumber: 
0123456789ABCD
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 3-1.8: config 0 
descriptor??
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: supports DRM 
functions and may not be fully accessible
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: ATA-11: Samsung 
SSD 860 PRO 1TB, RVM01B6Q, max UDMA/133
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: 2000409264 
sectors, multi 1: LBA48 NCQ (depth 32), AA
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: Features: Trust 
Dev-Sleep NCQ-sndrcv
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: ACPI cmd 
f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: ACPI cmd 
b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: ACPI cmd 
00/00:00:00:00:00:a0(NOP) rejected by device (Stat=0x51 Err=0x04)
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: supports DRM 
functions and may not be fully accessible
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: configured for 
UDMA/133
Jul 15 15:21:43 AnonymizedMachineName kernel: scsi 1:0:0:0: 
Direct-Access ATA  Samsung SSD 860  1B6Q PQ: 0 ANSI: 5

--
Jul 15 15:21:43 AnonymizedMachineName kernel: ata3.00: Enabling 
discard_zeroes_data
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: Enabling 
discard_zeroes_data
Jul 15 15:21:43 AnonymizedMachineName kernel: sd 2:0:0:0: [sdb] 
1953525168 512-byte logical blocks: (1.00 TB/932 GiB)

--
Jul 15 15:21:43 AnonymizedMachineName kernel: sd 1:0:0:0: [sdc] 
Preferred minimum I/O size 512 bytes
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: Enabling 
discard_zeroes_data

Jul 15 15:21:43 AnonymizedMachineName kernel:  sdc: sdc1 sdc2

In plain English, what do the two warnings “ata2.00: supports DRM 
functions and may not be fully accessible” tell us?  What does DRM stand 
for in this context?  There are also rejected ACPI commands and ACPI-cmd 
errors marked as non-errors (i.e., in usual, maintext gray-white), e.g., 
“ACPI cmd 00/00:00:00:00:00:a0(NOP) rejected by device (Stat=0x51 
Err=0x04)”.  Is there a configuration issue; do we have to worry about 
these warnings and errors?  The machine is a Dell Mobile Precision 
M6700; ata2 most likely refers to an internal 2.5-inch SATA SSD.  The 
machine has problems later during boot, so it's important for us to know 
the extent and the implications of the warnings and errors here.


Gratefully,
AlMa

Bug#1040837: [Pkg-rust-maintainers] Bug#1040837: rust-log: breaks API without coordination

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2023-07-15 09:55:04)
> Quoting Fabian Grünbichler (2023-07-12 19:53:08)
> > The feature in question is probably not a good candidate for packaging
> > though, given the lack of stability guarantees provided by upstream[0]:
> > 
> > > This module is unstable and breaking changes may be made at any time.
> > > See the tracking issue for more details.
> > 
> > The referenced tracking issue can be found here[1].
> > 
> > While the required crates (multiple ones from sval-rs/value-bag) are
> > being packaged (mostly done, pending a re-upload to NEW and review
> > there), I wonder whether enabling the feature was not a
> > mistake/premature in the first place.
> > 
> > I did a quick test with ratt with the attached diff applied, and except
> > for rust-sequoia-net (which fails for other reasons which are already
> > fixed in experimental and just need a re-upload of the version there to
> > unstable), building at least worked fine. I am not too familiar with
> > either async-std, nor the kv feature of log to say whether this approach
> > would be feasible - I'd be happy to hear your thoughts though! IMHO
> > keeping this unstable aspect out of the archive for the time being would
> > save us all from periodic breakage, with log itself (without the KV
> > feature) being rather widely used.
> 
> Makes sense.
> 
> I will go through those of the reverse dependencies that I am involved
> in maintaining, to see if th unstable feature can be avoided - and might
> reach out for help if I cannot figure it out on my own.

While I appreciate your suggested patch for rust-async-std, the main
obstacle to getting rid of the feature seems to not be rust-async-std
but instead rust-kv-log-macro which has 19 reverse dependencies:

aardvark-dns
rust-ahash
rust-ahash-0.7
rust-ashpd
rust-async-attributes
rust-async-std
rust-async-std-resolver
rust-async-tar
rust-erbium
rust-femme
rust-flume
rust-futures-timer
rust-oxilangtag
rust-oxiri
rust-rustls
rust-sequoia-net
rust-trust-dns-client
rust-trust-dns-resolver
rust-trust-dns-server

I am not happy to create Debian-specific patches to somehow replace
rust-kv-log-macro, and even if you were kind enough to initially create
such patches there is still the headache of maintaining them.

If the feature in rust-log really is considered too unstable for use in
Debian, then it seems to me that we need to convince upstream projects
to acknowledge that and themselves avoid the feature.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1041196: marco: Window title disappears when the first character is Chinese

[Wenbin Lv]

Package: marco
Version: 1.26.2-1
Severity: normal

Dear developers,

After upgrading to marco 1.26.2-1, a window's title is not displayed if
the first character of it is Chinese. Downgrading to 1.26.1-3 fixes the
problem.

The bug seems to be caused by the upstream fix to #1040752:
https://github.com/mate-desktop/marco/commit/730ed9dc454e97f569df8a92ac065a1afcc05baa

Thanks,
Wenbin Lv

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

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

Versions of packages marco depends on:
ii  libc62.37-6
ii  libcairo21.16.0-7
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  libmarco-private21.26.2-1
ii  libpango-1.0-0   1.50.14+ds-1
ii  libx11-6 2:1.8.6-1
ii  marco-common 1.26.2-1
ii  mate-desktop-common  1.26.1-1
ii  zenity   3.44.0-3

marco recommends no packages.

marco suggests no packages.

-- no debconf information

Bug#1041195: resource sanity check: requesting [mem …-…], which spans more than PCI Bus 0000:00 [mem …-… window]

[AlMa]

Package: linux-image-6.1.0-10-amd64
Version: 6.1.37-1

In the depths of my journal I discover the following two warnings (last 
two lines are marked orange):


Jul 15 15:21:43 AnonymizedMachineName kernel: radeon :01:00.0: 
vgaarb: deactivate vga console
Jul 15 15:21:43 AnonymizedMachineName kernel: sd 2:0:0:0: [sdb] Attached 
SCSI disk
Jul 15 15:21:43 AnonymizedMachineName kernel: [drm] initializing kernel 
modesetting (VERDE 0x1002:0x6825 0x1028:0x053F 0x00).
Jul 15 15:21:43 AnonymizedMachineName kernel: resource sanity check: 
requesting [mem 0x000c-0x000d], which spans more than PCI Bus 
:00 [mem 0x000d4000-0x000e7fff window]
Jul 15 15:21:43 AnonymizedMachineName kernel: caller 
pci_map_rom+0x65/0x180 mapping multiple BARs



lspci tells us this (hopefully this is the right place to look):

00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM 
Controller (rev 09)

Subsystem: Dell 3rd Gen Core processor DRAM Controller
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Latency: 0
IOMMU group: 0
Capabilities: [e0] Vendor Specific Information: Len=0c 
Kernel driver in use: ivb_uncore

What are the extent and the implications of the warnings "resource 
sanity check: requesting …, which spans more than PCI Bus :00 …" and 
“caller pci_map_rom+0x65/0x180 mapping multiple BARs”?  Any 
misconfiguration? Any adjustment options the kernel might need?  The 
machine is a Dell Mobile Precision M6700 with the processor Intel Core 
i7-3720QM, 32 GB RAM, and AMD FirePro M6000 Mobility Pro graphic chip 
with 2GB GDDR5.


Gratefully,
AlMa

Bug#1041194: ace-of-penguins: Merlin fails with X error

[Parodper]

Package: ace-of-penguins
Version: 1.5~rc2-5
Severity: normal

Dear Maintainer,

ace-merlin fails with the following error on start:

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  73 (X_GetImage)
  Serial number of failed request:  25
  Current serial number in output stream:  25

I think I've managed to trace the issue to a race condition at the call 
to XGetImage on line 819 of lib/xwin.c. If I add a delay (sleep(1);) 
before that call the game launches and works.


-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-10-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_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 ace-of-penguins depends on:
ii  libc62.36-9
ii  libpng16-16  1.6.39-2
ii  libx11-6 2:1.8.4-2+deb12u1

Versions of packages ace-of-penguins recommends:
ii  xfonts-100dpi  1:1.0.5

ace-of-penguins suggests no packages.

-- no debconf information

Bug#1041193: vtun segfaulting on tunnel initialization

[Tom Noonan II]

Package: vtun
Version: 3.0.4-2+b1
Severity: important
X-Debbugs-Cc: t...@tjnii.com

After upgrading from Stretch to Bookworm I'm seeing segfaults when my vtun 
tunnels attempt to come up.
The following is logged:

2023-07-15T00:56:46.225321+00:00 ip-10-70-1-71 kernel: [33828.222048] 
vtund[116824]: segfault at 78 ip 7fa445e08462 sp 7fff510d04c0 error 4 
in libcrypto.so.3[7fa445cc5000+278000] likely on CPU 0 (core 0, socket 0)

The other end of the tunnel (running an old version) shows the tunnel being 
initialized and encryption initialized, and then the tunnel closing.

Jul 15 10:24:35 hstnc-3 vtund[12196]: Use SSL-aware challenge/response
Jul 15 10:24:35 hstnc-3 vtund[12196]: Remote Server sends #012.
Jul 15 10:24:35 hstnc-3 vtund[12196]: Session [Snip ID/IP] opened
Jul 15 10:24:35 hstnc-3 vtund[12196]: Blowfish-256-ECB encryption initialized
Jul 15 10:24:35 hstnc-3 vtund[12196]: Session [Snip ID/IP] closed

This is a snippit of the server side config where the segfaults are happening.  
The omitted config is routing and non-shareable config options like auth.

device  tun1;
typetun;
proto   tcp;
encrypt blowfish256ecb;
keepalive   yes;
speed   0;

This could be related to the old client that's trying to connect, but I'd 
expect an error and not a segfault.
This could also be related to using blowfish256ecb, but per 'man vtund.conf' 
this config is still supported.

Thanks for maintaining this.

--Tom Noonan II

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/2 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 vtun depends on:
ii  libc6  2.36-9
ii  liblzo2-2  2.10-2
ii  libssl33.0.9-1
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4
ii  udev   252.6-1
ii  zlib1g 1:1.2.13.dfsg-1

vtun recommends no packages.

vtun suggests no packages.

-- Configuration Files:
/etc/vtund.conf changed [not included]

-- no debconf information

Bug#1041192: Recommends: exuberant-ctags, not ctags?

[T. Joseph Carter]

Package: seascope
Version: 0.9+8a669e0e-3
Severity: normal

I've noted that seascope Recommends: exuberant-ctags which for the
longest time was the only form of ctags in Debian. universal-ctags now
exists as an alternative. Might any ctags be used for seascope or is
there a particular reason to prefer exuberant-ctags?


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

Kernel: Linux 6.3.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages seascope depends on:
ii  python3  3.11.4-3
ii  python3-pyqt55.15.9+dfsg-1
ii  python3-pyqt5.qsci   2.13.3+dfsg-3
ii  python3-pyqt5.qtsvg  5.15.9+dfsg-1

Versions of packages seascope recommends:
ii  cscope   15.9-1
pn  exuberant-ctags  
ii  id-utils 4.6.28-20200521ss15dab+b1

seascope suggests no packages.

-- no debconf information

Bug#1031553: Processed: found 1031553 in 3.8.0+git20230713-1

[Andreas Metzler]

On 2023-07-15 Debian Bug Tracking System  wrote:
> Processing commands for cont...@bugs.debian.org:

> > found 1031553 3.8.0+git20230713-1

For the time being I have switched back to datefudge:
8X--
Switch back to datefudge. faketime using fork() instead of exex() breaks
the cleanup scripting in the testsuite. This together with upstream
changes Closes: #1037917
Most tests do not rely on datefudge/faketime anymore but use -attime so
we would still have meaningful testsuite coverage without datefudge.
8X--

As a plan B (if/when faketime's #1032177 is fixed while datefudge's
#1028587 is still open), we could use a gnutls-private wrapper script,
like this:

8X===
#!/bin/sh
if [ "${DEB_BUILD_MULTIARCH}" != "${DEB_HOST_MULTIARCH}" ] ; then
exit 77
fi

if [ "$1" != "-f" ] ; then
export FAKETIME_DONT_RESET=1
else
shift
fi

export FAKETIME="$1"
shift
if [ "x${LD_PRELOAD}" = "x" ] ;then 
export LD_PRELOAD="/usr/lib/${DEB_HOST_MULTIARCH}/libfaketime.so.1"
else
export 
LD_PRELOAD="${LD_PRELOAD}:/usr/lib/${DEB_HOST_MULTIARCH}/libfaketime.so.1"
exec "$@"
8X===

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

Bug#931205: chkrootkit: Honor Single Unix Specification (SUS) by allowing multiple arguments to be grouped behind single `-`

[Richard Lewis]

On Fri, 28 Jun 2019 13:39:46 +0530 Avinash Sonawane 
wrote:

> As per SUS Utility syntax guideline 5[0], command-line utility should
allow
> multiple arguments to be grouped behind single `-` delimiter.

This is a valid request and would be reasonably straightforward for someone
to implement. The only complication is that Debian has added at least one
option over the years ( -s) so implementing this will require changes to
several other patches: it cant just be a simple patch to chkrootkit but
needs to update any existing patch that touches options.

So im not personally going to work on this any time soon. But patches are
welcome.

Bug#1039472: ca-certificates-java: openjdk-17 update caused install regressions

[some]

Package: ca-certificates-java
Followup-For: Bug #1039472
Control: severity -1 critical

This makes unrelated software on the system break, making unrelated packages 
unusable without guidance on how to fix it.

Bug#1041191: “invalid interface number” on Broadcom Corp. BCM5880 Secure Applications Processor with fingerprint swipe sensor

[AlMa]

Package: linux-image-6.1.0-10-amd64
Version: 6.1.37-1

The journal shows several warnings (orange texts “usb 3-1.8: config 0 
has an invalid interface number: 3 but max is 2”, “config 0 has no 
interface number 2”, and “usb 3-1.8: config 0 descriptor??”):



Jul 15 15:21:43 AnonymizedMachineName kernel: usb 3-1.8: new full-speed 
USB device number 4 using ehci-pci
Jul 15 15:21:43 AnonymizedMachineName kernel: scsi 0:0:0:0: 
Direct-Access ATA  SAMSUNG SSD PM83 3D1Q PQ: 0 ANSI: 5
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 1-1.5: New USB device 
found, idVendor=0c45, idProduct=643f, bcdDevice=28.06
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 1-1.5: New USB device 
strings: Mfr=2, Product=1, SerialNumber=0
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 1-1.5: Product: 
Laptop_Integrated_Webcam_E4HD
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 1-1.5: Manufacturer: 
CN0Y4TWT72487279AAYJA00
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 3-1.8: config 0 has an 
invalid interface number: 3 but max is 2
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 3-1.8: config 0 has no 
interface number 2
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 3-1.8: New USB device 
found, idVendor=0a5c, idProduct=5801, bcdDevice= 1.01
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2: SATA link up 6.0 
Gbps (SStatus 133 SControl 300)
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 3-1.8: New USB device 
strings: Mfr=1, Product=2, SerialNumber=3
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: ACPI cmd 
f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out

Jul 15 15:21:43 AnonymizedMachineName kernel: usb 3-1.8: Product: 5880
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: ACPI cmd 
b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 3-1.8: Manufacturer: 
Broadcom Corp
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: ACPI cmd 
00/00:00:00:00:00:a0(NOP) rejected by device (Stat=0x51 Err=0x04)
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 3-1.8: SerialNumber: 
0123456789ABCD
Jul 15 15:21:43 AnonymizedMachineName kernel: usb 3-1.8: config 0 
descriptor??
Jul 15 15:21:43 AnonymizedMachineName kernel: ata2.00: supports DRM 
functions and may not be fully accessible

…
Jul 15 15:21:44 AnonymizedMachineName systemd[1]: Starting 
systemd-udevd.service - Rule-based Manager for Device Events and Files...
Jul 15 15:21:46 AnonymizedMachineName mtp-probe[408]: checking bus 3, 
device 4: "/sys/devices/pci:00/:00:1d.0/usb3/3-1/3-1.8"



`lsusb -v` shows that they belong to the fingerprint sensor:

Bus 003 Device 004: ID 0a5c:5801 Broadcom Corp. BCM5880 Secure 
Applications Processor with fingerprint swipe sensor

Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x0a5c Broadcom Corp.
  idProduct  0x5801 BCM5880 Secure Applications Processor with 
fingerprint swipe sensor

  bcdDevice1.01
  iManufacturer   1 Broadcom Corp
  iProduct2 5880
  iSerial 3 0123456789ABCD
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x00ab
bNumInterfaces  3
bConfigurationValue 0
iConfiguration  0
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   254 Application Specific Interface
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  4 Broadcom USH w/swipe sensor
  ** UNRECOGNIZED:  10 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85  EP 5 IN
bmAttributes3
  Transfer TypeInterrupt

Bug#1039607: libjansi-java: causes maven to always output escape character

[Emmanuel Bourg]

On 08/07/2023 20:22, tony mancill wrote:


Emmanuel, do you recall what prompted the change?


I think the issue is that when Maven runs in pbuilder, the TTY isn't 
detected and colors get disabled (batch mode isn't used for Debian 
builds though). If anything is changed please ensure that building with 
pdebuild preserves the colors.


Emmanuel Bourg

Bug#1004232: chkrootkit: overzealous Linux.Xor.DDoS warnings

[Richard Lewis]

On Sun, 23 Jan 2022 10:27:26 +0100 Samuel Thibault  wrote:

> chkrootkit reports this:
>
> Searching for Linux.Xor.DDoS ...INFECTED: 
> Possible Malicious Linux.Xor.DDoS installed
> /tmp/lynx-2.9.0dev.10/configure
> /tmp/lynx-2.9.0dev.10/.pc/30_build_path_in_binary.diff/scripts/cfg_defs.sh
> /tmp/lynx-2.9.0dev.10/.pc/21_do_not_strip_-g.diff/configure
> /tmp/lynx-2.9.0dev.10/debian/rules
> /tmp/lynx-2.9.0dev.10/install-sh
> /tmp/lynx-2.9.0dev.10/config.sub
> /tmp/lynx-2.9.0dev.10/scripts/cfg_defs.sh
> [...]
>
> The source code of chkrootkit says:
>
> files="`${find} ${ROOTDIR}tmp/ ${findargs} -executable -type f 2> /dev/null`"
>
> Well, yes, I do have executable files in /tmp: whenever I use "apt
> source" there there is at least debian/rules, and ./configure, etc.
>
> This looks like an overzealous check, and copying the result to
> /var/log/chkrootkit/log.expected won't fly of course.

This is a classic example of a false positive: the test chkrootkit is
designed to report when executable are found in /tmp because (as i
understand the comments in upstream's file), many rootkits leave
executables there, and so can often be a sign of something
bad/unintended happening on the system. Of course, just because an
automated script tells you something is there, doesnt mean it is a
rootkit - human judgement is always needed for that

An automated check like this is never going to be precise, but it is
operating as intended: I dont realistically see any way chkrootkit can
determine  when executables came from apt source. Personally, i would
simply accept that such reports are going to happen, and take it as a
reminder to clean up the temporary files created by apt source.

But you _could_ try and:
- use the FILTER option in /etc/chkrootkit/chkrootkit.conf to delete
any line ending in 'configure' or 'debian/rules' -- this works with or
without diff_mode.
- tell systemd to run chkrootkit at a different time, to minimise the
chance of it running when you are in the middle of using 'apt source'
(and make sure you clean up anything left in /tmp)
- (I wonder if there is an option to tell 'apt source' to use a
different location, perhaps by setting TMPDIR?)

What we should do is document 'apt source' in
/usr/share/doc/chkrootkit/README.FALSE-POSITIVES --- other suggestions
welcome of course, but i dont see what action can really be taken to
fix this 'issue'.

Bug#1040163: yajl: CVE-2017-16516 CVE-2022-24795

[Tobias Frost]

ontrol: severity 1040163 grave
Control: tags 1040163 security

I've re-checked the status on xqilla:

It embedds a very old yajl library, (older than 0.4.0), which is not affected 
by the mentioned CVE's, 
however, it is very likely affected by other problems, for example:

https://github.com/lloyd/yajl/issues/206 (double free)
https://github.com/lloyd/yajl/issues/204 (Uninitialized memory reads and 
out-of-bound)

I'm going to close this bug, but will raise the severity of #1040163, as this 
needs to
be investigated before trixie.

-- 
tobi

Bug#1041168: Installation of GRUB failed

[Christof B.]

Salut Cyril,

thanks for your quick reply!

Am 15.07.23 um 14:09 schrieb Cyril Brulebois:


Thanks for sharing all those logs in advance. syslog has:

 Jul 15 11:00:47 grub-installer: grub-install: error: cannot copy 
`/usr/lib/shim/shimx64.efi.signed' to `/boot/efi/EFI/debian/shimx64.efi': No 
space left on device.

And the ESP is close to 500M, so ENOSPC is very surprising. Any chance
you could check what's inside/what filled it?


I hat a look at the disk, but the ESP partition was completely empty. I 
redid the whole installation (with the same error) to get runtime 
information about what is going on.


Et voilà - df:

Filesystem   1K-blocks  Used Available Use% Mounted on
tmpfs   391488   136391352   0% /run
devtmpfs   1933492 0   1933492   0% /dev
/dev/mapper/debian--vg-root
 120469224   1379448 112924068   1% /target
/dev/sdb2   466026 88234352807  20% /target/boot
/dev/sda2 5062  5062 0 100% /target/boot/efi
/dev/mapper/debian--vg-root
 120469224   1379448 112924068   1% /dev/.static/dev
devtmpfs   1933492 0   1933492   0% /target/dev
tmpfs   391488   136391352   0% /target/run
/dev/sdc1  3906068  1200   3904868   0% /mnt/s

Although I chose sdb as installation target, somehow d-i uses /dev/sda2 
instead of /dev/sdb2 as EFI partition. I have no clue why.

For further investigation I added the lastest syslog as well.

Thanks in advance for your efforts!

Cheers,
Christof[1:0:0:0]   diskATA SAMSUNG SSD PM872D0Q
[2:0:0:0]   (5) PLDSDVD+-RW DS-8ABSHLD11
[7:0:0:0]   disktakeMS  Mem-drive EasyII1100
[0:0:0:0]   diskUSB Flash Disk  2.00


syslog.gz
Description: application/gzip
lrwxrwxrwx1 root root 9 Jul 15 12:49 
ata-PLDS_DVD+_-RW_DS-8ABSH_23HW6736395B764G9A03 -> ../../sr0
lrwxrwxrwx1 root root 9 Jul 15 13:05 
ata-SAMSUNG_SSD_PM871_2.5_7mm_128GB_S1ZUNXAG629418 -> ../../sdb
lrwxrwxrwx1 root root10 Jul 15 13:05 
ata-SAMSUNG_SSD_PM871_2.5_7mm_128GB_S1ZUNXAG629418-part1 -> ../../sdb1
lrwxrwxrwx1 root root10 Jul 15 13:05 
ata-SAMSUNG_SSD_PM871_2.5_7mm_128GB_S1ZUNXAG629418-part2 -> ../../sdb2
lrwxrwxrwx1 root root10 Jul 15 13:05 
ata-SAMSUNG_SSD_PM871_2.5_7mm_128GB_S1ZUNXAG629418-part3 -> ../../sdb3
lrwxrwxrwx1 root root 9 Jul 15 13:05 
usb-USB_Flash_Disk_080D7F461819660-0:0 -> ../../sda
lrwxrwxrwx1 root root10 Jul 15 13:05 
usb-USB_Flash_Disk_080D7F461819660-0:0-part1 -> ../../sda1
lrwxrwxrwx1 root root10 Jul 15 13:05 
usb-USB_Flash_Disk_080D7F461819660-0:0-part2 -> ../../sda2
lrwxrwxrwx1 root root10 Jul 15 13:05 
usb-USB_Flash_Disk_080D7F461819660-0:0-part3 -> ../../sda3
lrwxrwxrwx1 root root 9 Jul 15 13:05 
usb-takeMS_Mem-drive_EasyII_AA04012700049230-0:0 -> ../../sdc
lrwxrwxrwx1 root root10 Jul 15 13:05 
usb-takeMS_Mem-drive_EasyII_AA04012700049230-0:0-part1 -> ../../sdc1
lrwxrwxrwx1 root root 9 Jul 15 13:05 wwn-0x5002538d401cb207 
-> ../../sdb
lrwxrwxrwx1 root root10 Jul 15 13:05 
wwn-0x5002538d401cb207-part1 -> ../../sdb1
lrwxrwxrwx1 root root10 Jul 15 13:05 
wwn-0x5002538d401cb207-part2 -> ../../sdb2
lrwxrwxrwx1 root root10 Jul 15 13:05 
wwn-0x5002538d401cb207-part3 -> ../../sdb3

Bug#1041190: nut.conf: MODE=none prevents system from booting, shuts down in middle of boot by UPS

[js]

Package: nut
Version: 2.8.0-7
Severity: important

Dear Maintainer,



   * What led up to the situation?
 /etc/nut.conf had MODE=none with 2 UPS connected to PC by USB cable
 and monitored by it. During reboot, the UPS clicked and powered
 down the PC (this happened twice).

   * What exactly did you do (or not do) that was effective (or ineffective)?
 To restore a working system I unplugged the USB cables to the UPS
 and rebooted, no problems encountered.

 Then I changed MODE=standalone and rebooted with USB cables plugged in
 and no other configuration changes at all, rebooted with no problem and
 was able to monitor both UPS devices. This seems to have fixed the issue.

   * What outcome did you expect instead?
 I would expect that regardless of the configuration in
 /etc/nut/nut.conf, the system will boot normally.

 UPS actions are for extreme situations like a major power loss and
 should not be invoked for a simple configuration error. Some
 message in syslog or other notification to root would have been
 more appropriate.

 Details:
 UPS-pc:  device.mfr: American Power Conversion device.model: Back-UPS 
RS 1500MS2
 UPS-network: device.mfr: American Power Conversion device.model: Back-UPS 
XS 1500M

 These lines from journalctl --system seem relevant during the aborted 
reboot:

Jul 14 16:39:57 MY_SYSTEM systemd[1]: Starting 
nut-driver-enumerator.service - Network UPS Tools - enumeration of 
configure-file devices into systemd unit instances...
Jul 14 16:39:57 MY_SYSTEM systemd[1]: Starting 
nut-driver@UPS-network.service - Network UPS Tools - device driver for NUT 
device 'UPS-network'...
Jul 14 16:39:57 MY_SYSTEM systemd[1]: Starting 
nut-driver@UPS-pc.service - Network UPS Tools - device driver for NUT device 
'UPS-pc'...
Jul 14 16:40:03 MY_SYSTEM nut-driver-enumerator[1032]: Fri Jul 14 
08:40:03 PM UTC 2023 : OK: No changes to reconcile between systemd service 
instances and device configurations in '/etc/nut/ups.conf'
Jul 14 16:40:03 MY_SYSTEM systemd[1]: nut-driver-enumerator.service: 
Deactivated successfully.
Jul 14 16:40:03 MY_SYSTEM systemd[1]: Finished 
nut-driver-enumerator.service - Network UPS Tools - enumeration of 
configure-file devices into systemd unit instances.
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-pc[1384]: Network UPS Tools - 
Generic HID driver 0.47 (2.8.0)
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-pc[1384]: USB communication 
driver (libusb 1.0) 0.43
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-pc[1384]: libusb1: Could not 
open any HID devices: insufficient permissions on everything
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-pc[1384]: No matching HID UPS 
found
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-pc[1275]: Driver failed to 
start (exit status=1)
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-pc[1275]: Network UPS Tools - 
UPS driver controller 2.8.0
Jul 14 16:40:06 MY_SYSTEM systemd[1]: nut-driver@UPS-pc.service: 
Control process exited, code=exited, status=1/FAILURE
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-network[1383]: Using 
subdriver: APC HID 0.98
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-network[1383]: Network UPS 
Tools - Generic HID driver 0.47 (2.8.0)
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-network[1383]: USB 
communication driver (libusb 1.0) 0.43
Jul 14 16:40:06 MY_SYSTEM systemd[1]: nut-driver@UPS-pc.service: Failed 
with result 'exit-code'.
Jul 14 16:40:06 MY_SYSTEM systemd[1]: Failed to start 
nut-driver@UPS-pc.service - Network UPS Tools - device driver for NUT device 
'UPS-pc'.
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-network[1383]: ups_status_set: 
seems that UPS [UPS-network] is in OL+DISCHRG state now. Is it calibrating or 
do you perhaps want to set 'onlinedischarge' option? Some UPS models (e.g. 
CyberPower UT series) emit OL+DISCHRG when offline.
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-network[1383]: using 
'battery.charge' to set battery low state
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-network[1383]: using 
'battery.runtime' to set battery low state
Jul 14 16:40:06 MY_SYSTEM usbhid-ups[1383]: ups_status_set: seems that 
UPS [UPS-network] is in OL+DISCHRG state now. Is it calibrating or do you 
perhaps want to set 'onlinedischarge' option? Some UPS models (e.g. CyberPower 
UT series) emit OL+DISCHRG when offline.
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-network[1276]: Network UPS 
Tools - UPS driver controller 2.8.0
Jul 14 16:40:06 MY_SYSTEM systemd[1]: Started 
nut-driver@UPS-network.service - Network UPS Tools - device driver for NUT 
device 'UPS-network'.
Jul 14 16:40:06 MY_SYSTEM systemd[1]: Reached target nut-driver.target 
- Network UPS Tools - target for power device drivers on 

Bug#1037765: maildir-utils: ftbfs with GCC-13

[Jeremy Sowden]

On 2023-07-15, at 12:19:47 +0100, Jeremy Sowden wrote:
> On 2023-07-15, at 07:29:54 -0300, David Bremner wrote:
> > Matthias Klose writes:
> > > Package: src:maildir-utils
> > > Version: 1.8.14-1
> > > Severity: normal
> > > Tags: sid trixie
> > > User: debian-...@lists.debian.org
> > > Usertags: ftbfs-gcc-13
> > >
> > > [This bug is targeted to the upcoming trixie release]
> > >
> > > Please keep this issue open in the bug tracker for the package it
> > > was filed for.  If a fix in another package is required, please
> > > file a bug for the other package (or clone), and add a block in
> > > this package. Please keep the issue open until the package can be
> > > built in a follow-up test rebuild.
> > 
> > I suspect we should probably move to a new upstream version rather
> > than adding yet another patch.
> 
> I did start looking at what would be involved and the new upstream
> version 1.10 has removed the deprecated autootools-based
> [build-system] which is used in the 1.8 package, so I decided to leave
> alone. :)
> 
> > However, if for some reason we want to stay with 1.8.14, it looks
> > like this specific issue is fixed by upstream commit
> > 
> >ce9446465260bd108bcf554cf503f72304f4276b
> 
> The diff in that commit is:
> 
>   diff --git a/lib/utils/mu-error.hh b/lib/utils/mu-error.hh
>   index 55a8002c71e2..6472ce83b4d4 100644
>   --- a/lib/utils/mu-error.hh
>   +++ b/lib/utils/mu-error.hh
>   @@ -22,6 +22,7 @@
>
>#include 
>#include 
>   +#include 
>
>#include "mu-utils-format.hh"
>#include 
>   
> which is all that is needed to fix the FTBFS.
> 
> > I attach a version with conflicts resolved (although I don't know the
> > codebase well enough to say if my resolution is correct). With that
> > patch the code builds, but the build still fails with mu4e.info and
> > mu4e-guile.info not being installed.
> > 
> > dh_missing: warning: usr/share/info/mu-guile.info exists in debian/tmp 
> > but is not installed to anywhere 
> > dh_missing: warning: usr/share/info/mu4e.info exists in debian/tmp but 
> > is not installed to anywhere 
> > dh_missing: error: missing files, aborting
> > The following debhelper tools have reported what they installed 
> > (with files per package)
> >  * dh_elpa: maildir-utils (0), mu4e (25)
> >  * dh_install: maildir-utils (6), mu4e (0)
> >  * dh_installdocs: maildir-utils (3), mu4e (0)
> >  * dh_installman: maildir-utils (0), mu4e (0)
> 
> The source package in the archive contains a couple of files which are
> missing from the Salsa repo:
> 
>   [azazel@ulthar:/space/azazel/tmp/maildir-utils-1.8.14] $ cat 
> debian/maildir-utils.info 
>   usr/share/info/mu-*
>   [azazel@ulthar:/space/azazel/tmp/maildir-utils-1.8.14] $ cat 
> debian/mu4e.info 
>   usr/share/info/mu4e*
> 
> I'll create a PR to add a patch and the missing .info files.

https://salsa.debian.org/emacsen-team/maildir-utils/-/merge_requests/2

J.


signature.asc
Description: PGP signature

Bug#1027414: luit: broken apt install xorg from a debootstrap installed environment

[Thomas Dickey]

On Sat, Jul 15, 2023 at 10:16:22AM +, David Roderick wrote:
> Package: luit
> Version: 2.0.20221028-1
> Followup-For: Bug #1027414
> X-Debbugs-Cc: I have been told to report this by #debian on libera irc, 
> dmr...@inspirondebian.home
> 
> Breaks: x11-utils (<<7.7+6) but bookworm contains x11-utils (7.7+5)

I'd expect that this is a problem to be resolved by releasing x11-utils
(recall that Brendan's updates to disentangle luit were in January 2022)

https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=x11-utils
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003021
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006193

There are several packages which depend upon x11-utils; probably only
xterm uses luit, so releasing the update should not cause problems.

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature