Bug#1043686: Please provide a proper download location for beads

[Andreas Tille]

Hi Filippo,

ping again.  The currently packaged beads is not at the location
you wrote.  Please fix the watch file to report latest version.

Thanks a lot
   Andreas.

Am Sat, Mar 30, 2024 at 09:41:40PM +0100 schrieb Andreas Tille:
> Ping?
> 
> Am Thu, Jan 25, 2024 at 12:46:17PM +0100 schrieb Andreas Tille:
> > Hi Filippo,
> > 
> > I intended to have a look at bug #1043686 noticing that beads is
> > shipping a copy of cimg (which is packaged and should probably be
> > excluded from upstream source in favour of the packaged code).
> > When checking the download locations mentioned in d/watch I realised
> > that the last two packaged versions are not available for download.
> > 
> > It would be great if you could point the watch file to some place
> > where the latest tags could be found.
> > 
> > Kind regards
> > Andras.
> > 
> > -- 
> > http://fam-tille.de
> > 
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> > 
> 
> -- 
> https://fam-tille.de
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
https://fam-tille.de

Bug#1065973: kmod: FTBFS due to time64 transition

[Jochen Sprickerhof]

Hi Marco,

last week you offered in #debian-devel to upload kmod with tests 
disabled for 32 bit arm to work around the current situation. Could you 
please do that?


Cheers Jochen

* Simon McVittie  [2024-03-21 12:23]:

On Thu, 21 Mar 2024 at 15:45:13 +0500, Andrey Rakhmatullin wrote:

On Wed, Mar 13, 2024 at 08:23:07AM +0100, Helge Deller wrote:
> The patch below builds for me on the hppa platform.
Unfortunately tests fail here with it in an armhf chroot, I don't know if
it's generic or because the chroot is a qemu-based one on amd64.


I think the root cause (both for needing to unset _FILE_OFFSET_BITS, and
for the tests failing) is that kmod's test suite is interposing
mock/wrapped versions of the stat() family.

With the transition to 64-bit time_t, there are new members of the stat()
family that will also need interposing on 32-bit architectures:
__lstat64_time64() is the replacement for lstat(), and __stat64_time64()
for stat().

There are also __fstat64_time64() and __fstatat64_time64(), but kmod
doesn't seem to interpose fstat() or fstatat(), so those are probably
unnecessary in this case.

fakeroot, fakechroot and other LD_PRELOAD modules that interpose stat()
will already be doing something similar, and might provide a useful
reference for what is needed. Here's the equivalent in fakechroot:
https://github.com/dex4er/fakechroot/pull/104/commits/dac74cd68cfb6eeaae9cd13bdc48737a44980df9

   smcv


signature.asc
Description: PGP signature

Bug#1071592: fails to enable LVM on crypt during boot, rendering the system unbootable

[Benjamin Lee]

On Wed, 22 May 2024 00:51:22 +0100 Luca Boccassi  wrote:

Control: reassign -1 dracut 060+5-1

On Tue, 21 May 2024 21:47:37 +0200 Evgeni Golov 
wrote:
> Package: systemd
> Version: 256~rc2-3
> Severity: important
> 
> Ohai,
> 
> I am filing this against systemd, as that's the package that triggers

> the issue when upgraded, but it very well might be in dracut, so
please
> re-assign as you see fit.
> Also filing this "only" as important, as it's breaking a non-default
> setup and I did not verify this on any other system.
> 
> My laptop is running sid with / on LVM on crypt. I am using dracut

for
> initrd generation.
> 
> With the upgrade to systemd 256 (from 255.5) it fails to boot:

> 1. asks for my passphrase
> 2. systemd-cryptsetup@.service starts
> 3. dev-mapper--.device runs forever, never reaching
completion
> 
> I can get it to boot by:

> 1. rd.break=pre-mount in the bootloader to interrupt dracut
> 2. lvm lvchange -ae / in the dracut shell
> 
> I am aware of #1071278 but I do have dracut 060+5-8 which is supposed

to
> have all the required fixes.
> 
> Downgrading systemd to 255.5-1 and regenerating the initrd fixes the

> boot process.

It's probably the same issue with missing libraries, but I do not use
either dracut nor LVM so I cannot help, reassigning to dracut so that
you might get some help with debugging and finding out what the actual
issue is


It seems like the issue is that systemd 256 now makes /usr read-only in the
initrd environment, but dracut depends on writing to /usr.

One workaround is to set ProtectSystem=no in the initrd, so that /usr is
writable again.  I got my system (also LVM on LUKS) booting with a dracut
module to write system.conf:

blee@r8 /usr/lib/dracut/modules.d/99local $ cat module-setup.sh
#!/bin/bash

# called by dracut
install() {
printf "[Manager]\nProtectSystem=no\n" >> 
"${initdir}/etc/systemd/system.conf"
}

Bug#1071601: python3-setuptools: Prefix is not exactly honored when installing with --prefix

[Marco Trevisan]

Oh, actually an even more conservative approach can be by also honoring
the DEB_PYTHON_INSTALL_LAYOUT env variable, because if that is set it
should have the priority so that `lib/python3/dist-packages` is used
instead of `lib/python3.XX/site-packages`

setuptools-support-explicit-setup-install-v2.patch
Description: Binary data

Bug#1071200: git-buildpackage: gbp import-orig: support filtering based on debian/clean

[Daniel Kahn Gillmor]

On Sun 2024-05-19 20:43:58 +0200, Guido Günther wrote:
> But you'd break that when filtering out files? I think what keeps me
> confused: the tarball uploaded to Debian is the filtered one and hence
> has a different checksum, no? 

hm, i don't think so, because we use
import-orig.filter-pristine-tar=False.  This lets me preserve both the
upstream signature and the git history, and to compare the upstream
tarball with the git tag using git as well.  In the gnupg2 package, we
currently have this in debian/gbp.conf:

-
[DEFAULT]
debian-branch = debian/unstable
upstream-branch = upstream-2.2
pristine-tar = True
upstream-vcs-tag = gnupg-%(version)s

[import-orig]
filter = [
 'aclocal.m4',
 'build-aux/compile',
 'build-aux/config.rpath',
 'build-aux/depcomp',
 'build-aux/install-sh',
 'build-aux/missing',
 'build-aux/mkinstalldirs',
 'build-aux/texinfo.tex',
 'ChangeLog',
 'config.h.in',
 'configure',
 'doc/gnupg.info*',
 'doc/*.pdf',
 'doc/*.png',
 'INSTALL',
 'm4/iconv.m4',
 'm4/intdiv0.m4',
 'm4/intl.m4',
 'm4/lock.m4',
 'm4/printf-posix.m4',
 'm4/size_max.m4',
 'm4/uintmax_t.m4',
 'm4/wint_t.m4',
 '*/*/Makefile.in',
 '*/Makefile.in',
 'Makefile.in',
 'po/*.gmo',
 'po/Makefile.in.in',
 'po/stamp-po',
 'regexp/_unicode_mapping.c',
 'regexp/UnicodeData.txt',
 'common/audit-events.h',
 'common/status-codes.h',
 'ChangeLog-2011',
 '*/ChangeLog-2011',
 'tests/*/ChangeLog-2011',
 ]
filter-pristine-tar = False
-


So what i'm asking is to be able replace that big import-orig.filter
array with something that knows how we do cleaning, so that when i
improve our cleaning, it improves the filter for the next import as
well.

> It would also have the upside that packages invoking `dh_clean … path1
> path2` would still work.
>
> Another reason to not parse debian/clean verbatim is that we'd also need
> to support dh's substitution variables and would forever need to follow
> what dh does (and we might even need to pay attention to the dh compat
> level of the package) as otherwise things would break on people.

you've convinced me that running the clean target is better than trying
to parse debian/clean :)

>> whether the packaging used debhelper or not.  Does that seem like a
>> plausible way to operate gbp import-orig?
>
> That would be an approach. Implementation wise the "tricky" bit is
> that you don't have debian/ on the upstream branch you want to filter so
> dh_clean or `debian/rules clean` won't work as is . So we'd need to
> overlay that (which is certainly doable, just wanted to point it out).

ah, yes, i see the complication here.

> So that's a lot of effort for s.th. that can already be done via either
> gbp.conf or FilesExcluded. I'm not against it, just looking at the pros
> and cons.

right, i see tradeoff you're describing, and if you decide this is too
much complication for gbp, i'm willing to just keep the two lists
(debian/clean and debian/gbp.conf's import-orig.filter) in sync more or
less manually.

But i thought it wouldn't hurt to ask -- it'd certainly be nice for
anyone working on the GnuPG packaging (or any other packaging which
covers a similar upstream) to have a simpler packaging maintenance
workflow.

Thanks for thinking this all through with me here, Guido!

   --dkg


signature.asc
Description: PGP signature

Bug#1071202: [pkg-gnupg-maint] Bug#1071202: src:gnupg2: upstream tarball ships files not in upstream revision control

[Daniel Kahn Gillmor]

Hi gniibe--

Thanks for this additional info!

On Fri 2024-05-17 09:02:40 +0900, NIIBE Yutaka wrote:
> The regexp subdirectory was introduced to support POSIX regexp functions
> on Windows.  The intention is providing same behavior among GnuPG on
> different Operating Systems.  Historically, regexp in OpenPGP had been
> not supported by Windows versions of GnuPG; In the past, when a user
> switched his Operating System from common POSIX one to Windows, it
> stopped working.
>
> If it is only for Debian, possibly, we can simply use POSIX regexp
> functions in the C library, perhaps.

If GnuPG doesn't use this regexp dir when building on Debian, that
sounds fine to me :)  Then we definitely don't need to use or ship that
mapping file!  

> There are corner cases for regexp matching among different regexp
> functions support and Unicode versions.

yes, the regexp support in the standard is ill-specified in a lot of
ways, and most implementations struggle to implement it properly, for
all kinds of reasons.

We don't have good interop tests for it yet because we haven't extended
sop into certificate management.  I should probably try to get that
under way. :/

> Strictly speaking about a data specification, it would be more acculate
> to specify exact Unicode version explicitly in the OpenPGP standard.

Unicode is supposed to evolve in a stable and sane way.  I think tying
OpenPGP to a specific version of Unicode would be a mistake; it's hard
enough to upgrade OpenPGP as it is, without having to coordinate across
versions of unicode in the first place.

 --dkg


signature.asc
Description: PGP signature

Bug#1071601: (no subject)

[Marco Trevisan]

Control: tags 1071601 patch

Adding a patch that fixes this issue by using the `posix_prefix` schema
when the install prefix is explicitly requested


setuptools-support-explicit-setup-install.patch
Description: Binary data

Bug#1071601: python3-setuptools: Prefix is not exactly honored when installing with --prefix

[Marco Trevisan]

Package: python3-setuptools
Version: 68.1.2-2
Severity: important
X-Debbugs-Cc: none, ma...@ubuntu.com

Dear Maintainer,

In a simple distutils project:

$ cat hello
#!/usr/bin/env python3 print("Hello world")

$ cat setup.py
from distutils.core import setup
setup(name='hello', scripts=['hello'])

Installing it with --prefix is not fully honored, as "local" is always
added (--root is optional, used just to make the reproducer easier):

$ python3 setup.py install --root=/tmp/py-root --prefix=/opt/py-prefix

$ find /tmp/py-root/
/tmp/py-root/
/tmp/py-root/opt
/tmp/py-root/opt/py-prefix
/tmp/py-root/opt/py-prefix/local
/tmp/py-root/opt/py-prefix/local/bin
/tmp/py-root/opt/py-prefix/local/bin/hello
/tmp/py-root/opt/py-prefix/local/lib
/tmp/py-root/opt/py-prefix/local/lib/python3.12
/tmp/py-root/opt/py-prefix/local/lib/python3.12/dist-packages
/tmp/py-root/opt/py-prefix/local/lib/python3.12/dist-packages/hello-0.0.0-py3.12.egg-info
/tmp/py-root/opt/py-prefix/local/lib/python3.12/dist-packages/hello-0.0.0-py3.12.egg-info/dependency_links.txt
/tmp/py-root/opt/py-prefix/local/lib/python3.12/dist-packages/hello-0.0.0-py3.12.egg-info/SOURCES.txt
/tmp/py-root/opt/py-prefix/local/lib/python3.12/dist-packages/hello-0.0.0-py3.12.egg-info/top_level.txt
/tmp/py-root/opt/py-prefix/local/lib/python3.12/dist-packages/hello-0.0.0-py3.12.egg-info/PKG-INFO

In fact in such case everything should be installed in
/tmp/py-root/opt/py-prefix prefix and not
/tmp/py-root/opt/py-prefix/local since a prefix is explicitly defined
and so there's no point to add an extra "/local" subpath.

---

In between the others, this breaks jhbuild builds as a test fails for
this specific reason (see bug #1054720 where the missing file is due to
the fact that it gets installed to $PREFIX/local/bin instead of $PREFIX/bin).

---

After some debugging of it, this related to the default scheme change
happened with python3.10 [1] which meant to always use /usr/local as
default and ensure that one should explicitly require for /usr prefix,
but in the case that --prefix= is used, the user request is now ignored because:

 - /usr/lib/python3.*/_distutils_system_mod.py:
   1. Selects the scheme `posix_prefix` since we've requested a prefix 
explicitly

 - /usr/lib/python3/dist-packages/setuptools/_distutils/command/install.py
   1. Calls sysconfig.get_preferred_scheme("prefix") that now as per the said
  change would return by default `posix_local` unless we're building a
  debian package.
   2. Replaces the variables to use the `posix_local` scheme

So, in order to fix this we may in theory change python3 packages to
make 1. to select another defined prefix say `posix_explicitprefix`, and
then making `sysconfig.get_preferred_scheme("explicitprefix")` to
instead return `posix_prefix`, but that would not be correct, because
being that a public API it should only support the allowed input
arguments for it ("prefix", "home" or "user").

As per this, I feel the best way to handle this is instead in the
setuptools module so that we can check once again if --prefix has been
used and react accordingly.

[1] https://lists.debian.org/debian-python/2022/03/msg00039.html
[2] https://bugs.launchpad.net/ubuntu/+source/python3.10/+bug/1967920

Bug#1071576: bugs.debian.org: bug subscription no longer possible: no "Please confirm subscription" e-mail

[Don Armstrong]

On Wed, 22 May 2024, Vincent Lefevre wrote:
> On 2024-05-21 14:45:02 -0400, David Mandelberg wrote:
> > I'm having the same problem. Could it be related to #1071469 which also
> > involves mail issues around the same time?
> 
> At https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071469
> Louis-Philippe Véronneau says
> 
> "It seems that a debian.org mail infrastructure breakage happened 
> sometime between 2024-05-17 and 2024-05-18"
> 
> and
> 
> "I dug a little bit more and it seems the outage happened between
> 2024-05-17 ~2200 and and 2024-05-18 0110UTC."
> 
> But since the outage ended on 2024-05-18 (and the issue with bug
> subscription seemed to have started before the outage), this seems
> to be a different problem... unless someone did a series of changes
> in the mail config on 2024-05-17 and early 2024-05-18.

Thanks for the reports; I note that around this time the systems were
upgraded. It's possible that this finally broke bug mail, which was
using a totally unsupported out of date version of EOC.

Not sure what the right path forward is to fix that without totally
re-implementing bug mailing lists (which probably needs to happen
anyway).

-- 
Don Armstrong  https://www.donarmstrong.com

He quite enjoyed the time by himself in the mornings. The day was too
early to have started going really wrong.
  -- Terry Pratchet _Only You Can Save Mankind_ p133

Bug#1068632: dh-exec still broken

[Kip Warner]

On Mon, 2024-05-20 at 21:28 +1000, Craig Small wrote:
> OK, that's a start I guess.
> To debug this further, I'm going to need some sort of test setup.
> 
> You can see my test package
> at https://salsa.debian.org/csmall/test-dh-exec
> Obviously its a simple package but it does have a file that is
> created in the build phase and
> renamed in the install phase.
> 
> Could you have a look at it and see what differences there could be?
> I'm not seeing any errors with that example.

Hey Craig,

I'm afraid I'm not able to reproduce the issue with your minimal and
your patch to dh-exec-install-rename. It seemed to work fine.

My project's build environment is a lot more complicated and it would
be difficult to reduce down to a minimal.

Perhaps something to try is adding more debugging dh-exec output while
my package is building somehow?

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1071220: netplan.io: autopkgtest fails with systemd 256

[Luca Boccassi]

Control: tags -1 pending

On Thu, 16 May 2024 13:13:12 +0100 Luca Boccassi 
wrote:
> Source: netplan.io
> Version: 1.0-2
> Severity: serious
> Justification: breaks another package's migration
> X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org
> 
> Hi,
> 
> Netplan's autopkgtest are failing on all architectures with the
newest
> systemd from unstable in the ethernets test:
> 
> 1095s
==
> 1095s FAIL: test_link_offloading
(__main__.TestNetworkManager.test_link_offloading)
> 1095s ---
---
> 1095s Traceback (most recent call last):
> 1095s   File "/tmp/autopkgtest-
lxc.r1eokuuo/downtmp/build.bnO/src/tests/integration/ethernets.py",
line 286, in test_link_offloading
> 1095s self.assertIn(b'rx-checksumming: off', out)
> 1095s AssertionError: b'rx-checksumming: off' not found in b'Features
for eth42:\nrx-checksumming: on\ntx-checksumming: on\n\ttx-checksum-
ipv4: off [fixed]\n\ttx-checksum-ip-generic: on\n\ttx-checksum-ipv6:
off [fixed]\n\ttx-checksum-fcoe-crc: off [fixed]\n\ttx-checksum-sctp:
on\nscatter-gather: on\n\ttx-scatter-gather: on\n\ttx-scatter-gather-
fraglist: on\ntcp-segmentation-offload: on\n\ttx-tcp-segmentation:
on\n\ttx-tcp-ecn-segmentation: on\n\ttx-tcp-mangleid-segmentation:
on\n\ttx-tcp6-segmentation: on\ngeneric-segmentation-offload:
on\ngeneric-receive-offload: off\nlarge-receive-offload: off
[fixed]\nrx-vlan-offload: on\ntx-vlan-offload: on\nntuple-filters: off
[fixed]\nreceive-hashing: off [fixed]\nhighdma: on\nrx-vlan-filter: off
[fixed]\nvlan-challenged: off [fixed]\ntx-lockless: on [fixed]\nnetns-
local: off [fixed]\ntx-gso-robust: off [fixed]\ntx-fcoe-segmentation:
off [fixed]\ntx-gre-segmentation: on\ntx-gre-csum-segmentation: on\ntx-
ipxip4-segmentation: on\ntx-ipxip6-segmentation: on\ntx-udp_tnl-
segmentation: on\ntx-udp_tnl-csum-segmentation: on\ntx-gso-partial: off
[fixed]\ntx-tunnel-remcsum-segmentation: off [fixed]\ntx-sctp-
segmentation: on\ntx-esp-segmentation: off [fixed]\ntx-udp-
segmentation: on\ntx-gso-list: on\nfcoe-mtu: off [fixed]\ntx-nocache-
copy: off\nloopback: off [fixed]\nrx-fcs: off [fixed]\nrx-all: off
[fixed]\ntx-vlan-stag-hw-insert: on\nrx-vlan-stag-hw-parse: on\nrx-
vlan-stag-filter: off [fixed]\nl2-fwd-offload: off [fixed]\nhw-tc-
offload: off [fixed]\nesp-hw-offload: off [fixed]\nesp-tx-csum-hw-
offload: off [fixed]\nrx-udp_tunnel-port-offload: off [fixed]\ntls-hw-
tx-offload: off [fixed]\ntls-hw-rx-offload: off [fixed]\nrx-gro-hw: off
[fixed]\ntls-hw-record: off [fixed]\nrx-gro-list: off\nmacsec-hw-
offload: off [fixed]\nrx-udp-gro-forwarding: off\nhsr-tag-ins-offload:
off [fixed]\nhsr-tag-rm-offload: off [fixed]\nhsr-fwd-offload: off
[fixed]\nhsr-dup-offload: off [fixed]\n'
> 1095s 
> 1095s
==
> 1095s FAIL: test_link_offloading
(__main__.TestNetworkd.test_link_offloading)
> 1095s ---
---
> 1095s Traceback (most recent call last):
> 1095s   File "/tmp/autopkgtest-
lxc.r1eokuuo/downtmp/build.bnO/src/tests/integration/ethernets.py",
line 286, in test_link_offloading
> 1095s self.assertIn(b'rx-checksumming: off', out)
> 1095s AssertionError: b'rx-checksumming: off' not found in b'Features
for eth42:\nrx-checksumming: on\ntx-checksumming: on\n\ttx-checksum-
ipv4: off [fixed]\n\ttx-checksum-ip-generic: on\n\ttx-checksum-ipv6:
off [fixed]\n\ttx-checksum-fcoe-crc: off [fixed]\n\ttx-checksum-sctp:
on\nscatter-gather: on\n\ttx-scatter-gather: on\n\ttx-scatter-gather-
fraglist: on\ntcp-segmentation-offload: on\n\ttx-tcp-segmentation:
on\n\ttx-tcp-ecn-segmentation: on\n\ttx-tcp-mangleid-segmentation:
on\n\ttx-tcp6-segmentation: on\ngeneric-segmentation-offload:
on\ngeneric-receive-offload: off\nlarge-receive-offload: off
[fixed]\nrx-vlan-offload: on\ntx-vlan-offload: on\nntuple-filters: off
[fixed]\nreceive-hashing: off [fixed]\nhighdma: on\nrx-vlan-filter: off
[fixed]\nvlan-challenged: off [fixed]\ntx-lockless: on [fixed]\nnetns-
local: off [fixed]\ntx-gso-robust: off [fixed]\ntx-fcoe-segmentation:
off [fixed]\ntx-gre-segmentation: on\ntx-gre-csum-segmentation: on\ntx-
ipxip4-segmentation: on\ntx-ipxip6-segmentation: on\ntx-udp_tnl-
segmentation: on\ntx-udp_tnl-csum-segmentation: on\ntx-gso-partial: off
[fixed]\ntx-tunnel-remcsum-segmentation: off [fixed]\ntx-sctp-
segmentation: on\ntx-esp-segmentation: off [fixed]\ntx-udp-
segmentation: on\ntx-gso-list: on\nfcoe-mtu: off [fixed]\ntx-nocache-
copy: off\nloopback: off [fixed]\nrx-fcs: off [fixed]\nrx-all: off
[fixed]\ntx-vlan-stag-hw-insert: on\nrx-vlan-stag-hw-parse: on\nrx-
vlan-stag-filter: off [fixed]\nl2-fwd-offload: off [fixed]\nhw-tc-
offload: off [fixed]\nesp-hw-offload: off [fixed]\nesp-tx-csum-hw-
offload: off [fixed]\nrx-udp_tunnel-port-offload: off [fixed]\ntls-hw-
tx-offload: off [fixed]\ntls-hw-rx-offload: off 

Bug#1071600: libkf6textaddons-data: missing Breaks+Replaces: libkf5textaddons-data (<< 1.5.4)

[Andreas Beckmann]

Package: libkf6textaddons-data
Version: 1.5.4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict

Hi,

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

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

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

  Preparing to unpack .../libkf6textaddons-data_1.5.4-1_all.deb ...
  Unpacking libkf6textaddons-data (1.5.4-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libkf6textaddons-data_1.5.4-1_all.deb (--unpack):
   trying to overwrite 
'/usr/share/locale/ar/LC_MESSAGES/libtextautocorrection.mo', which is also in 
package libkf5textaddons-data 1.5.2-2.1
  Errors were encountered while processing:
   /var/cache/apt/archives/libkf6textaddons-data_1.5.4-1_all.deb


cheers,

Andreas


libkf5textaddons-data=1.5.2-2.1_libkf6textaddons-data=1.5.4-1.log.gz
Description: application/gzip

Bug#1071599: netplan.io: nocheck profile FTBFS

[Luca Boccassi]

Source: netplan.io
Severity: important

Trying a build with the nocheck profile+option fails as meson expects
pytest to be present:

Program pytest-3 pytest3 found: NO

../meson.build:28:9: ERROR: Program 'pytest-3 pytest3' not found or not
executable

-- 
Kind regards,
Luca Boccassi


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

Bug#1071592: fails to enable LVM on crypt during boot, rendering the system unbootable

[Luca Boccassi]

Control: reassign -1 dracut 060+5-1

On Tue, 21 May 2024 21:47:37 +0200 Evgeni Golov 
wrote:
> Package: systemd
> Version: 256~rc2-3
> Severity: important
> 
> Ohai,
> 
> I am filing this against systemd, as that's the package that triggers
> the issue when upgraded, but it very well might be in dracut, so
please
> re-assign as you see fit.
> Also filing this "only" as important, as it's breaking a non-default
> setup and I did not verify this on any other system.
> 
> My laptop is running sid with / on LVM on crypt. I am using dracut
for
> initrd generation.
> 
> With the upgrade to systemd 256 (from 255.5) it fails to boot:
> 1. asks for my passphrase
> 2. systemd-cryptsetup@.service starts
> 3. dev-mapper--.device runs forever, never reaching
completion
> 
> I can get it to boot by:
> 1. rd.break=pre-mount in the bootloader to interrupt dracut
> 2. lvm lvchange -ae / in the dracut shell
> 
> I am aware of #1071278 but I do have dracut 060+5-8 which is supposed
to
> have all the required fixes.
> 
> Downgrading systemd to 255.5-1 and regenerating the initrd fixes the
> boot process.

It's probably the same issue with missing libraries, but I do not use
either dracut nor LVM so I cannot help, reassigning to dracut so that
you might get some help with debugging and finding out what the actual
issue is

-- 
Kind regards,
Luca Boccassi


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

Bug#1071576: bugs.debian.org: bug subscription no longer possible: no "Please confirm subscription" e-mail

[Vincent Lefevre]

On 2024-05-21 14:45:02 -0400, David Mandelberg wrote:
> I'm having the same problem. Could it be related to #1071469 which also
> involves mail issues around the same time?

At https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071469
Louis-Philippe Véronneau says

"It seems that a debian.org mail infrastructure breakage happened 
sometime between 2024-05-17 and 2024-05-18"

and

"I dug a little bit more and it seems the outage happened between
2024-05-17 ~2200 and and 2024-05-18 0110UTC."

But since the outage ended on 2024-05-18 (and the issue with bug
subscription seemed to have started before the outage), this seems
to be a different problem... unless someone did a series of changes
in the mail config on 2024-05-17 and early 2024-05-18.

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

Bug#1071598: hunspell.1: some remarks and editorial changes for this man page

[Bjarni Ingi Gislason]

Package: hunspell
Version: 1.7.2+really1.7.2-10+b2
Severity: minor
Tags: patch

Dear Maintainer,

  here are some notes and editorial fixes for the manual.

The patch is in the attachment.

-.-

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "

instead of "nroff -man"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint hunspell.1": (possibly shortened list)

mandoc: hunspell.1:2:2: ERROR: skipping unknown macro: .LO 1
mandoc: hunspell.1:6:211: STYLE: input text line longer than 80 bytes: hunspell 
[\-1aDGHhLl...
mandoc: hunspell.1:11:70: STYLE: whitespace at end of input line
mandoc: hunspell.1:32:82: STYLE: input text line longer than 80 bytes: will 
display each wo...
mandoc: hunspell.1:89:58: STYLE: whitespace at end of input line
mandoc: hunspell.1:235:2: STYLE: fill mode already enabled, skipping: fi
mandoc: hunspell.1:269:13: STYLE: whitespace at end of input line
mandoc: hunspell.1:271:13: STYLE: whitespace at end of input line
mandoc: hunspell.1:274:62: STYLE: whitespace at end of input line
mandoc: hunspell.1:378:2: WARNING: line scope broken: SH breaks TP
mandoc: hunspell.1:382:11: STYLE: whitespace at end of input line
mandoc: hunspell.1:383:9: STYLE: whitespace at end of input line
mandoc: hunspell.1:389:14: STYLE: whitespace at end of input line
mandoc: hunspell.1:409:90: STYLE: input text line longer than 80 bytes: Author 
of Hunspell e...

-.-.

Remove space characters at the end of lines.

Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".

11:program.  The most common usage is "hunspell" or "hunspell filename". 
89:then the line contains a '+', a space, and the root word. 
269:.PP  
271:.PP  
274:En_geo, en_med, de_med are special dictionaries: dictionaries 
382:Similar to 
383:.I \-d. 
389:Equivalent to 

-.-.

Use the correct macro for the font change of a single argument or
split the argument into two.

330:.BR $HOME/.hunspell_dicname
397:.BI /usr/share/myspell/default.aff
400:.BI /usr/share/myspell/default.dic

-.-.

Use the word (in)valid instead of (il)legal,
if not related to legal matters.
See "www.gnu.org/prep/standards".
Think about translations into other languages!

hunspell.1:105:word unless such capitalization is illegal;

-.-.

Change a HYPHEN-MINUS (code 0x2D) to a minus(-dash) (\-),
if it
is in front of a name for an option,
is a symbol for standard input,
is a single character used to indicate an option,
or is in the NAME section (man-pages(7)).
N.B. - (0x2D), processed as a UTF-8 file, is changed to a hyphen
(0x2010, groff \[u2010] or \[hy]) in the output.

18:$ hunspell -d en_US
25:Correct words signed with an '*', '+' or '-', unrecognized
146:without -a, too).
374:.B hunspell -p unrecognized_but_good *.odt

-.-.

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

41:suggested words. Commands are single characters as follows
275:without affix file. Special dictionaries are optional extension
277:terms. There is no naming convention for special dictionaries,
280:order of the parameter list needs for good suggestions). First
304:morphological analysis). Without dictionary morphological data,
320:The default dictionary depends on the locale settings. The
322:LC_MESSAGES, and LANG. If none are set then the default personal
337:stemming). It depends from the dictionary data.
392:The default dictionary depends on the locale settings. The
394:LC_MESSAGES, and LANG. If none are set then the following
398:Path of default affix file. See hunspell(5).
409:Author of Hunspell executable is László Németh. For Hunspell library,
412:This manual based on Ispell's manual. See ispell(1).

-.-.

Split lines longer than 80 characters into two or more lines.
Appropriate break points are the end of a 

Bug#1071482: compress.1: some remarks and editorial changes for this man page

[Kenneth Pronovici]

On Sun, May 19, 2024 at 8:51 PM Bjarni Ingi Gislason  wrote:
> Dear Maintainer,
>
>   here are some notes and editorial fixes for the manual.
>
> The patch is in the attachment.

I'll upload 5.0-2 containing these changes later today.

For future reference, this patch would have been easier to deal with
if it was against the upstream compress.1 (the version in the Git
codebase on salsa) instead of against the installed compress.1 file
that is part of the .deb package.  The patch only applies cleanly if
uncompress-real.patch has already been applied, which was fairly
confusing until I figured out what was going on.

Thanks for the improvements.

KEN

Bug#1070184: Acknowledgement (gnome-maps: Unable to start gnome-maps)

[Cesar Enrique Garcia Dabo]

I see that gnome-maps is now in version 46.11 in testing. I have tried 
that version and the bug is now fixed.


So as far as I am concern this bug can be closed.

Thank you!

Bug#1071597: rust-laurel - autopkgtest failure on s390x

[Peter Green]

Package: rust-laurel
Version: 0.6.2-1
Severity: serious

rust-laurel's autopkgtest fails on s390x. I belive the patch
skip-parse_syslog-on-big-endian.patch should be reinstated
but I do not want to get into a revert war with the
maintainer.

So I feel I need to lay out, in more detail than
is visible in the changelog and git history, what I have
done regarding this package and why.

My main role in the rust team has been trying to keep the
"greater whole" of rust packages in a consistent state and
moving forward. Since upstream rust dependencies tend to be
pessimistic and Debian frowns upon packaging multiple
versions of the same software, this inevitablly involves
patching a bunch of packages.

I use autopkgtests as a tool to help minimize the chances
that these changes cause undetected breakage. As such when
bumping a dependency in a package that has no functional
autopkgtests, I will usually try to get at least some test
coverage.

Regarding rust-laurel specifically, up to version 0.5.6-1,
the tests were skipped.

In version 0.5.6-2, as part of preparing for the nix 0.27
update, I patched rust-laurel to get tests running. The
tests passed in my local tests on amd64 and so I uploaded
it.

Tests on debci revealed some failures though, there was
a test failure on 32-bit systems due to an integer
overflow in some time calculation code, and a failure
on s390x architectures which I determined to be down
to endian-specific test date in the test.

I prepared a fix for the time calculation code, which I
also posted upstreamed.

I decided that fixing the test data would probablly not
have a positive effort/benefit ratio and therefore added
a patch to skip the test on big-endian architectures. This
was still an improvement over the prior situation
where no tests were being run at all.

I uploaded these changes as 0.5.6-2.

The time overflow issue was fixed upstream in versions
0.6.0 and later. When Hilko uploaded version 0.6.1-1
he dropped my patches. The time overflow issue was fixed
upstream, so this made sense but nothing had been done
upstream to address the big endian issue. So this lead
to the tests once again failing on s390x.

I figured that this was a mistake, that Hilko had
incorrectly assumed that the big endian issue had been
taken care of upstream and after nearly a month of the
package sitting unable to migrate to testing, I
reinstated the patch and tweaked it to apply to the
new upstream version.

I made further uploads of 0.6.1 to address issues
related to the time64 and nix transitions.

When preparing the upload of 0.6.2-1, Hilko once again
dropped the patch with a changelog entry of
"Drop unneeded patches".

So that brings us to where we are now, the package
fails it's autopkgtests on s390x and I do not feel
it's appropriate to reinstate the patch for the second
time without first trying to get some feedback from
the maintainer.

Bug#1071426: logcheck-database: smartd: Match nvme lines too

[Stefanos Harhalakis]

Hi,

Indeed. This bugreport was queued on my system for some time. I think that
your new rules catch all of them.

These are some sample nvme lines:

X Device: /dev/nvme0, state read from
/var/lib/smartmontools/smartd.CT1000P3SSD8-2330E860.nvme.state
X Device: /dev/nvme0, state read from
/var/lib/smartmontools/smartd.SAMSUNG_MZVLB1T0HBLR_000L7-S4EMNF0MB0.nvme.state
X Device: /dev/nvme0, state written to
/var/lib/smartmontools/smartd.CT1000P3SSD8-2330E860.nvme.state
X Device: /dev/nvme0, state written to
/var/lib/smartmontools/smartd.SAMSUNG_MZVLB1T0HBLR_000L7-S4EMNF0MB0.nvme.state
X Device: /dev/nvme1, state read from
/var/lib/smartmontools/smartd.SAMSUNG_MZVLB1T0HBLR_000L7-S4EMNF0MB0.nvme.state
X Device: /dev/nvme1, state written to
/var/lib/smartmontools/smartd.SAMSUNG_MZVLB1T0HBLR_000L7-S4EMNF0MB0.nvme.state

Compared to sata:

X Device: /dev/sda [SAT], state read from
/var/lib/smartmontools/smartd.CT250MX500SSD1-21132DE0.ata.state
X Device: /dev/sda [SAT], state read from
/var/lib/smartmontools/smartd.Samsung_SSD_750_EVO_250GB-S33SNWDH500.ata.state
X Device: /dev/sda [SAT], state read from
/var/lib/smartmontools/smartd.Samsung_SSD_750_EVO_250GB-S33SNWDH510.ata.state
X Device: /dev/sda [SAT], state read from
/var/lib/smartmontools/smartd.WDC_WD30EFRX_68EUZN0-WD_WMC4N280.ata.state
X Device: /dev/sda [SAT], state read from
/var/lib/smartmontools/smartd.WDC_WD40EFZX_68AWUN0-WD_WX52DC10.ata.state
X Device: /dev/sda [SAT], state written to
/var/lib/smartmontools/smartd.CT250MX500SSD1-21132DE0.ata.state

Also:

X Monitoring 2 ATA/SATA, 0 SCSI/SAS and 1 NVMe devices
X Monitoring 2 ATA/SATA, 0 SCSI/SAS and 2 NVMe devices
X Monitoring 4 ATA/SATA, 0 SCSI/SAS and 1 NVMe devices
X Monitoring 6 ATA/SATA, 0 SCSI/SAS and 0 NVMe devices




On Mon, 20 May 2024 at 20:04, Richard Lewis <
richard.lewis.deb...@googlemail.com> wrote:

> On Sun, 19 May 2024 at 05:06, Stefanos Harhalakis  wrote:
>
> > See attached patch for matching NVMe devices too in smartd logs
>
> Thanks - yes i'd noticed that the rules for smartd need an update and
> this is on the radar - however, the
> update to the names of the .state files i was not aware of!
>
> I think the first part of the patch is  not quite right, per the code
> i think it should be:
>
> # from
> https://sources.debian.org/src/smartmontools/7.4-2/smartd.cpp/#L5829
> ... Monitoring [[:digit:]]+ ATA/SATA, [[:digit:]]+ SCSI/SAS and
> [[:digit:]]+ NVMe devices
>
> It would be really helpful if you could:
>
> 1/ send some sample log output logs,
>
> something like:
> journalctl -t smartd | awk '{$1=$2=$3=$4="";$5="X";print}' | sort -u
>
> would be helpful
>
> I'm especially unsure about the bits of rules that start "Device:" as
> i could not work out what format is expected -- the current rules have
> Device: /dev/[^[:space:]]+( \[[_/[:alnum:][:space:]]+\])?( \[SAT\])?
> but im not sure if the optional groups are up-to-date, -- i couldnt
> find what bit of code determines those.
>
> 2/ the attached rules (untested) are what i'm wokring on for smartd -
> any testing of these would be great
> (I generalised the name of the .state file - again i dont know where
> smartd sets this bit, so hard to know what is expected!)
> (these are completely untested, so may be completely broken)
>

Bug#1071596: apache2: envvars evaluates string in conditional instead of testing for empty string

[Mark Hedges]

Package: apache2
Version: 2.4.59-1~deb12u1
Severity: normal

Dear Maintainer,

`envvars` evaluates string in conditional instead of testing for empty string.

`apachectl` calls `envvars` which shows a syntax error despite working:

 root@nodeo:/etc/letsencrypt# apachectl configtest
 /usr/sbin/apachectl: 6: [: /etc/apache2: unexpected operator
 Syntax OK

If I change this line in `envvars`:

 if [ "${APACHE_CONFDIR}" == "" ]; then
 export APACHE_CONFDIR=/etc/apache2
 fi

to this:

 if [ -z ${APACHE_CONFDIR} ]; then
 export APACHE_CONFDIR=/etc/apache2
 fi

... then it works.

It's trying to evaluate `/etc/apache2` as a command?  Weird.

PATH seems totally normal.

Mark

-- Package-specific info:

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

Kernel: Linux 6.1.0-21-amd64 (SMP w/1 CPU thread; 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 apache2 depends on:
ii  apache2-bin2.4.59-1~deb12u1
ii  apache2-data   2.4.59-1~deb12u1
ii  apache2-utils  2.4.59-1~deb12u1
ii  init-system-helpers1.65.2
ii  lsb-base   11.6
ii  media-types10.0.0
ii  perl   5.36.0-7+deb12u1
ii  procps 2:4.0.2-3
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages apache2 recommends:
ii  ssl-cert  1.1.2

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  chromium [www-browser]   125.0.6422.60-1~deb12u1

Versions of packages apache2-bin depends on:
ii  libapr1  1.7.2-3
ii  libaprutil1  1.6.3-1
ii  libaprutil1-dbd-sqlite3  1.6.3-1
ii  libaprutil1-ldap 1.6.3-1
ii  libbrotli1   1.0.9-2+b6
ii  libc62.36-9+deb12u7
ii  libcrypt11:4.4.33-2
ii  libcurl4 7.88.1-10+deb12u5
ii  libjansson4  2.14-2
ii  libldap-2.5-02.5.13+dfsg-5
ii  liblua5.3-0  5.3.6-2
ii  libnghttp2-141.52.0-1+deb12u1
ii  libpcre2-8-0 10.42-1
ii  libssl3  3.0.11-1~deb12u2
ii  libxml2  2.9.14+dfsg-1.3~deb12u1
ii  perl 5.36.0-7+deb12u1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  chromium [www-browser]   125.0.6422.60-1~deb12u1

Versions of packages apache2 is related to:
ii  apache2  2.4.59-1~deb12u1
ii  apache2-bin  2.4.59-1~deb12u1

-- Configuration Files:
/etc/apache2/apache2.conf changed:
DefaultRuntimeDir ${APACHE_RUN_DIR}
PidFile ${APACHE_PID_FILE}
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
HostnameLookups Off
ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf
Include ports.conf

Options FollowSymLinks
AllowOverride None
Require all denied


AllowOverride None
Require all granted


Options Indexes FollowSymLinks
AllowOverride None
Require all granted

AccessFileName .htaccess

Require all denied

LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" 
vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" 
combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
IncludeOptional conf-enabled/*.conf
IncludeOptional sites-enabled/*.conf

/etc/apache2/envvars changed:
unset HOME
if [ -z "${APACHE_CONFDIR}" ]; then
export APACHE_CONFDIR=/etc/apache2
fi
if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
SUFFIX="-${APACHE_CONFDIR##/etc/apache2-}"
else
SUFFIX=
fi
export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data
export APACHE_PID_FILE=/var/run/apache2$SUFFIX/apache2.pid
export APACHE_RUN_DIR=/var/run/apache2$SUFFIX
export APACHE_LOCK_DIR=/var/lock/apache2$SUFFIX
export APACHE_LOG_DIR=/var/log/apache2$SUFFIX
export LANG=C
export LANG


-- no debconf information

Bug#1071595: cups: contortions needed to use duplex printing on HP Laserjet M402dn

[Sanjoy Mahajan]

Package: cups
Version: 2.4.7-1.2+b1
Severity: normal
X-Debbugs-Cc: none, Sanjoy Mahajan 

When using CUPS (lp), I couldn't get duplex printing to work on the
newly arrived (used) HP Laserjet M402dn.  The documents come out single
sided even though I had (1) set the print queue's default options to
include two-sided-long-edge (via the web interface on port 631), (2) had
specified sides=two-sided-long-edge on the command line, and (3) had set
the printer's default (via the EWS) to duplex (long edge).

Meanwhile, the printer hardware works fine: My wife's Mac, also running
CUPS, prints duplex with no problem, and sending a PDF directly to the
printer using netcat gives duplex output too.

The problem seems to be the following, from the cups error_log (see
attached 1.log for the full output for that job):

D [21/May/2024:20:53:32 +0200] [Job 12731]  unsupported-attributes-tag 
D [21/May/2024:20:53:32 +0200] [Job 12731] sides keyword two-sided-long-edge
D [21/May/2024:20:53:32 +0200] [Job 12731]  end-of-attributes-tag 
D [21/May/2024:20:53:32 +0200] [Job 12731] Unable to do two-sided printing, 
setting sides to \'one-sided\'.

However, the printer itself knows it can do two-sided printing.  Also
from the error_log:

D [21/May/2024:20:53:32 +0200] [Job 12731] media-col-supported 1setOf keyword 
media-size,media-top-margin,media-left-margin,media-right-margin,media-bottom-margin,media-type,media-source,media-source-properties,duplex-supported

And I've attached the result of running ipptool to get the printer attributes:

$ ipptool -tv ipp://NPI4CFED8.lan:631/ipp/print get-printer-attributes.test > 
attributes.txt

It contains

media-col-supported (1setOf keyword) = 
media-size,media-top-margin,media-left-margin,media-right-margin,media-bottom-margin,media-type,media-source,media-source-properties,duplex-supported

I've worked around the problem by setting the following default options
(from /etc/cups/lpoptions):

Default lj402 sides=DuplexNoTumble

This new setting of the "sides" keyword seems to confuse cups enough
that it doesn't bother to forcibly revert to one-sided output.  And the
printer hardware's configuration of printing duplex now takes over.

For reference ,here are the printer's lpoptions:

$ lpoptions -l
PageSize/Media Size: 100x150mm 184x260mm 195x270mm 4x6 5x8 *A4 A5 A6 B5 B6 
DoublePostcardRotated Env10 EnvC5 EnvDL EnvMonarch Executive FanFoldGermanLegal 
ISOB5 Legal Letter Oficio Postcard Statement roc16k Custom.WIDTHxHEIGHT
InputSlot/Media Source: *Auto Manual Tray1 Tray2
MediaType/Media Type: *Stationery StationeryLightweight ExtraLight Intermediate 
Midweight StationeryHeavyweight ExtraHeavy Transparency Labels 
StationeryLetterhead Envelope StationeryPreprinted StationeryPrepunched 
StationeryColored StationeryBond Recycled Rough
cupsPrintQuality/cupsPrintQuality: Draft *Normal
ColorModel/Output Mode: *Gray
Duplex/Duplex: None *DuplexNoTumble DuplexTumble
OutputBin/OutputBin: *FaceDown



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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 cups depends on:
ii  cups-client2.4.7-1.2+b1
ii  cups-common2.4.7-1.2
ii  cups-core-drivers  2.4.7-1.2+b1
ii  cups-daemon2.4.7-1.2+b1
ii  cups-filters   1.28.17-4
ii  cups-ppdc  2.4.7-1.2+b1
ii  cups-server-common 2.4.7-1.2
ii  debconf [debconf-2.0]  1.5.86
ii  ghostscript10.03.1~dfsg~git20240518-1
ii  libavahi-client3   0.8-13+b2
ii  libavahi-common3   0.8-13+b2
ii  libc6  2.38-11
ii  libcups2t642.4.7-1.2+b1
ii  libgcc-s1  14.1.0-1
ii  libstdc++6 14.1.0-1
ii  libusb-1.0-0   2:1.0.27-1
ii  poppler-utils  24.02.0-5
ii  procps 2:4.0.4-4

Versions of packages cups recommends:
ii  avahi-daemon  0.8-13+b2
ii  colord1.4.7-1+b1

Versions of packages cups suggests:
ii  cups-bsd2.4.7-1.2+b1
ii  foomatic-db 20230202-1
ii  printer-driver-cups-pdf [cups-pdf]  3.0.1-15
ii  smbclient   2:4.20.1+dfsg-1
ii  udev256~rc2-3

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: lpd, socket, usb, snmp, dnssd

-- 
-Sanjoy

"An error can never become true however many times you repeat it.
 The truth can never be wrong, even if no one ever hears about it."
 --Mahatma Gandhi

"Not to know is bad.  Not to wish to 

Bug#1071594: debhelper: fails to start openssh-server after creating host keys due to systemd 255 change

[Lucas Nussbaum]

Package: debhelper
Version: 13.15.3
Severity: normal

Hi,

I maintain the Debian Vagrant boxes. Recently, booting the 'testing'
image started to fail randomly.
The Debian Vagrant images ship without SSH host keys. A systemd service
is responsible for triggering a 'dpkg-reconfigure openssh-server' that
will generate the ssh keys and then start ssh.

Until systemd v254.5-1, that worked fine:
ssh.service was started but fails to start;
we get the 'ssh.service: Start request repeated too quickly.' error;
dpkg-reconfigure openssh-server creates the key and starts ssh.service
successfully.

With v255.2-1, that no longer works.
If ssh.service reached the 'Start request repeated too quickly.' state,
dpkg-reconfigure openssh-server is no longer able to start it.

The following code is in charge of starting ssh.service:


# Automatically added by dh_installsystemd/13.15.3
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = 
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
if [ -d /run/systemd/system ]; then
systemctl --system daemon-reload >/dev/null || true
if [ -n "$2" ]; then
_dh_action=restart
else
_dh_action=start
fi
deb-systemd-invoke $_dh_action 'ssh.service' >/dev/null || true
fi
fi
# End automatically added section


A MWE to reproduce is:

systemctl stop ssh
rm /etc/ssh/ssh_host_*
for i in $(seq 1 10); do systemctl start ssh ; done
systemctl status ssh
dpkg-reconfigure openssh-server
systemctl status ssh


I tried to identify when and why it was changed in systemd, but failed.
It could be argued that this is a regression in systemd.

Lucas

Bug#1071593: requests: CVE-2024-35195

[Salvatore Bonaccorso]

Source: requests
Version: 2.31.0+dfsg-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/psf/requests/pull/6655
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for requests.

CVE-2024-35195[0]:
| Requests is a HTTP library. Prior to 2.32.0, when making requests
| through a Requests `Session`, if the first request is made with
| `verify=False` to disable cert verification, all subsequent requests
| to the same host will continue to ignore cert verification
| regardless of changes to the value of `verify`. This behavior will
| continue for the lifecycle of the connection in the connection pool.
| This vulnerability is fixed in 2.32.0.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-35195
https://www.cve.org/CVERecord?id=CVE-2024-35195
[1] https://github.com/psf/requests/security/advisories/GHSA-9wx4-h78v-vm56
[2] https://github.com/psf/requests/pull/6655
[3] 
https://github.com/psf/requests/commit/c0813a2d910ea6b4f8438b91d315b8d181302356

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1071591: CantPackException: bad DT_HASH nbucket=0x7

[Martin Dosch]

Package: upx-ucl
Version: 4.2.2-3
Severity: normal

Dear Maintainer,

When trying to compress a golang linux/amd64 binary I get `CantPackException: 
bad DT_HASH nbucket=0x7  len=0xc6960`, see 
[here](https://salsa.debian.org/mdosch/go-sendxmpp/-/jobs/5756033#L53).
This happens with bookworm-backports (see linked CI job) as well as with 
sid. Binary to reproduce: 
https://salsa.debian.org/mdosch/go-sendxmpp/-/jobs/5756033/artifacts/raw/linux-amd64/go-sendxmpp?inline=false

Best regards,
Martin

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

Kernel: Linux 6.8.9-amd64 (SMP w/8 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 upx-ucl depends on:
ii  libc6   2.38-11
ii  libgcc-s1   14.1.0-1
ii  libstdc++6  14.1.0-1

upx-ucl recommends no packages.

upx-ucl suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1017558: boost1.74: diff for NMU version 1.74.0+ds1-21.1

[Anton Gladky]

Dear Elisei,

thanks for your effort and patch!

boost1.74 will not be released with trixie (see #1060102
) as it has been
superseded by 1.83. Removal from testing is scheduled on 05 of June.

So, I do not see too much reasons for the NMU.

Thanks again and best regards


Anton

Bug#1071581: dialog: stop using libtool-bin

[Thomas Dickey]

On Tue, May 21, 2024 at 04:00:56PM +0200, Helmut Grohne wrote:
> Source: dialog
> Version: 1.3-20240307-2
> Severity: normal
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: cross-satisfiability
> 
> Hi Santiago,
> 
> we want to remove the package libtool-bin from the archive, because any
> attempt of using it breaks cross compilation. The dialog package is a
> bit strange in this regard. It's autoconf stuff attempts to detect
> whether there is a libtool.m4 and when there isn't attempts to use a
> pre-configured libtool (the one from libtool-bin). Unfortunately, last
> time it was autoreconf'ed, that happened without libtool.m4. So
> basically, making libtool-bin go away here amounts to autoreconfing
> dialog after libtoolizing it. And that's pretty much what I did in the
> attached patch. The dialog binary and libdialog.la are bit-identical
> with this change.

hmm - there are two sets of changes - I don't see a reason for the
change to the curses function checks.

(as for libtool - I recall commenting on that, recently)

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


signature.asc
Description: PGP signature

Bug#1051534: analizo: Test failure in t/features.t during build and autopkgtests

[Étienne Mollier]

Control: tags -1 + confirmed patch pending upstream

Hi,

gregor herrmann, on 2023-09-09:
> # Failed test 'Then analizo must report that the project has 
> total_abstract_classes = 1'
> # at t/features/metrics/abstract_classes.feature line 19.
> #   in step at t/features/metrics/abstract_classes.feature line 19.
> # not ok
> # #   Failed test at 
> /build/analizo-1.25.4/t/features/step_definitions/analizo_steps.pl line 143.
> # #  got: 2
> # # expected: 1

Looking at t/features/metrics/abstract_classes.feature, ther is
a curious discrepancy between the csharp and the other
languages in terms of expected number of abstract classes:

  Scenario: "Animals" project
Given I am in t/samples/animals/
When I run "analizo metrics ."
Then analizo must report that the project has total_abstract_classes = 

Examples:
  | language | total_abstract_classes |
  | cpp  | 2  |
  | java | 2  |
  | csharp   | 1  |

Looking at the sample code which is under test, there does seem
to be two abstract classes for csharp samples:

$ grep 'abstract class' t/samples/animals/csharp/*
t/samples/animals/csharp/Animal.cs:public abstract class Animal {
t/samples/animals/csharp/Mammal.cs:public abstract class Mammal : 
Animal {

Looking upstream, I ran into the commit introducing the csharp
support[1], which suggest there was something off at the time of
the introduction of the test with Doxygen:

>> doxyparse doesn't identify all abstract C# classes, the Mammal abstract
>> class defined in animals sample (below) wasn't identified:
>> 
>>   // Mammal.cs:
>>   public abstract class Mammal : Animal {
>> public virtual void close() {}
>>   }

This suggests the issue has been resolved with the recent upload
of doxygen that is currently staging in unstable.  Therefore, I
believe it should be safe to update the test item so analizo is
expected to capture 2 abstract classes in csharp as well as the
other languages.  I am preparing an upload to resolve that.

[1]: 
https://github.com/analizo/analizo/commit/6cdd646d723106bddc4f9f01cbbbf9370e347925

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/3, please excuse my verbosity
   `-on air: Pendragon - The Edge Of The World


signature.asc
Description: PGP signature

Bug#1071576: bugs.debian.org: bug subscription no longer possible: no "Please confirm subscription" e-mail

[David Mandelberg]

I'm having the same problem. Could it be related to #1071469 which also 
involves mail issues around the same time?

Bug#1071590: linux-image-6.1.0-21-amd64: Kernel werning in unmap_page_range()

[Logan Gunthorpe]

Package: src:linux
Version: 6.1.90-1
Severity: normal

Dear Maintainer,

   I recently upgraded a machine from bullseye to bookworm. While this was
   successful, I started noticing a kernel warning a few hours after every boot.
   The kernel warning happens only once per-boot. Seems to be an issue with a 
bind9
   process (isc-net-). This was the first 6.1 kernel on this machine so I 
don't
   know which versions have the problem or not.

   I have another, very similar machine, which also runs bind and the same 
kernel,
   but has never hit the warning.

-- Package-specific info:
** Version:
Linux version 6.1.0-21-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03)

** Command line:
root=UUID=744e1ad4-2d7a-4ee8-a078-a34a255a8a51 ro quiet

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
[7.498136] systemd[1]: Finished modprobe@configfs.service - Load Kernel 
Module configfs.
[7.499099] systemd[1]: modprobe@efi_pstore.service: Deactivated 
successfully.
[7.499502] systemd[1]: Finished modprobe@efi_pstore.service - Load Kernel 
Module efi_pstore.
[7.503590] systemd[1]: Mounting sys-kernel-config.mount - Kernel 
Configuration File System...
[7.509953] loop: module loaded
[7.513703] systemd[1]: modprobe@loop.service: Deactivated successfully.
[7.514201] systemd[1]: Finished modprobe@loop.service - Load Kernel Module 
loop.
[7.514887] systemd[1]: Mounted sys-kernel-config.mount - Kernel 
Configuration File System.
[7.524965] fuse: init (API version 7.37)
[7.527159] systemd[1]: modprobe@fuse.service: Deactivated successfully.
[7.527524] systemd[1]: Finished modprobe@fuse.service - Load Kernel Module 
fuse.
[7.532762] systemd[1]: Mounting sys-fs-fuse-connections.mount - FUSE 
Control File System...
[7.537138] device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. 
Duplicate IMA measurements will not be recorded in the IMA log.
[7.537217] device-mapper: uevent: version 1.0.3
[7.537332] device-mapper: ioctl: 4.47.0-ioctl (2022-07-28) initialised: 
dm-de...@redhat.com
[7.538973] systemd[1]: modprobe@dm_mod.service: Deactivated successfully.
[7.539317] systemd[1]: Finished modprobe@dm_mod.service - Load Kernel 
Module dm_mod.
[7.540631] systemd[1]: Mounted sys-fs-fuse-connections.mount - FUSE Control 
File System.
[7.540962] systemd[1]: systemd-repart.service - Repartition Root Disk was 
skipped because no trigger condition checks were met.
[7.582060] systemd[1]: Started systemd-journald.service - Journal Service.
[7.612989] EXT4-fs (xvda): re-mounted. Quota mode: none.
[7.732271] systemd-journald[232]: Received client request to flush runtime 
journal.
[7.746542] lp: driver loaded but no devices found
[7.755019] ppdev: user-space parallel port driver
[9.620575] input: PC Speaker as /devices/platform/pcspkr/input/input0
[   10.450818] Adding 8388604k swap on /dev/xvdb.  Priority:-2 extents:1 
across:8388604k SSFS
[   12.883148] EXT4-fs (xvdc): barriers disabled
[   12.903173] EXT4-fs (xvdc): mounted filesystem with ordered data mode. Quota 
mode: none.
[   14.672597] audit: type=1400 audit(1715718337.874:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="tcpdump" pid=326 
comm="apparmor_parser"
[   14.709567] audit: type=1400 audit(1715718337.910:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=325 
comm="apparmor_parser"
[   14.709581] audit: type=1400 audit(1715718337.910:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=325 
comm="apparmor_parser"
[   14.709587] audit: type=1400 audit(1715718337.910:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=325 
comm="apparmor_parser"
[   14.766342] audit: type=1400 audit(1715718337.966:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/freshclam" pid=324 
comm="apparmor_parser"
[   14.783948] audit: type=1400 audit(1715718337.982:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=323 
comm="apparmor_parser"
[   14.783960] audit: type=1400 audit(1715718337.982:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=323 comm="apparmor_parser"
[   14.787738] audit: type=1400 audit(1715718337.986:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=322 
comm="apparmor_parser"
[   14.805238] audit: type=1400 audit(1715718338.006:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="named" pid=331 
comm="apparmor_parser"
[   14.810506] audit: type=1400 audit(1715718338.010:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/clamd" pid=327 
comm="apparmor_parser"
[   27.204462] 

Bug#1071589: RFS: radsecproxy/1.10.1-1 -- RADIUS protocol proxy supporting RadSec

[Sven Hartge]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : radsecproxy
   Version  : 1.10.1-1
   Upstream contact : Fabian Mauchle 
 * URL  : https://radsecproxy.github.io/
 * License  : BSD-3-clause
 * Vcs  : https://salsa.debian.org/debian/radsecproxy
   Section  : net

The source builds the following binary packages:

  radsecproxy - RADIUS protocol proxy supporting RadSec

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/radsecproxy/radsecproxy_1.10.1-1.dsc

Changes since the last upload:

 radsecproxy (1.10.1-1) unstable; urgency=medium
 .
   * New upstream version 1.10.1
   * Drop patches applied upstream
   * Update copyright years
   * Declare conformance to Policy 4.7.0, no changes needed.

Grüße,
Sven.

Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Guilherme Puida Moreira]

On Tue, May 21, 2024 at 06:13:21PM +0200, Andrej Shadura wrote:
> In fact, having checked the source code, it’s one way only, and after
> all it’s also someone else’s quick hack. Maybe someone should write
> a robust tool to support all formats and directions and package *that*
> for Debian? :)

I think dasel might be what you want :^)

Select, put and delete data from JSON, TOML, YAML, XML and CSV files
with a single tool. Supports conversion between formats and can be used
as a Go package.

https://github.com/tomwright/dasel
https://tracker.debian.org/pkg/dasel

--puida

Bug#1071588: [URGENT] Outdated package report - gradle

[Mcgiwer]

Package: gradle
version: 4.4.1-18

The Gradle version in Debian repository is outdated (obsolete). The latest one 
is 8.7


Please urgently update it and all it's dependencies.

publickey - mcgiwer@proton.me - 0xD936838D.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#1071587: libapache2-mod-php: Default php.conf serves php in userdirs as plaintext (potentially exposing passwords)

[Theral Mackey]

Package: libapache2-mod-php
Version: 2:8.2+93
Severity: normal
Tags: patch security
X-Debbugs-Cc: tma...@gmail.com, Debian Security Team 

This applies to all currently available versions (goes back to initial commit
 of php.conf).

The php.conf distributed disables the php engine for userdirs, but does not 
block php files from being served from them. This causes a default install to
serve the php source as plaintext. Since many common php webapps still keep
passwords in *.inc.php config files inside web accessible dirs, this allows 
those passwords and other config data to be accessed by anyone requesting
the proper url. This happened to me while doing a debootsrap upgrade/install
to a chroot lvm: my previously working php app started up in the new version
serving plaintext php source from apps in my userdir, while non-userdir php
was working as before. I consider this a bug since this package intentionally
changes the otherwise configured state as a "security" issue to prevent rogue
php run in userdirs, while in the same file preventing raw php source from
being served (line 8). There are very few reasons to directly serve php files
as plaintext. A simple fix is to add a filesmatch directive to the existing
directory directive to block serving the files the directive has changed 
handling of. Patch below is also applied to the debian/main/7.2 branch of
the fork in salsa/git I created (should work for all versions since the file
has no changes up to current): https://salsa.debian.org/tmack0/php.git

PATCH:

diff --git a/debian/php.conf b/debian/php.conf
index d4df3e5f7..df24ab139 100644
--- a/debian/php.conf
+++ b/debian/php.conf
@@ -17,9 +17,16 @@
 # 
 # To re-enable PHP in user directories comment the following lines
 # (from  to .) Do NOT set it to On as it
-# prevents .htaccess files from disabling it.
+# prevents .htaccess files from disabling it. This also disables
+# serving the files, as the webserver would otherwise serve them
+# as plaintext, and many software packages still put passwords in
+# .php files. Comment out or remove the FilesMatch directive if
+# you really want to serve php as plaintext from user dirs.
 
 
 php_admin_flag engine Off
+
+Require all denied
+
 
 


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

Kernel: Linux 6.1.0-18-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 libapache2-mod-php depends on:
ii  libapache2-mod-php8.2  8.2.7-1~deb12u1

libapache2-mod-php recommends no packages.

libapache2-mod-php suggests no packages.

-- no debconf information

Bug#1050256: AppArmor breaks locking non-fs Unix sockets

[Luca Boccassi]

On Sun, 28 Jan 2024 10:57:03 +0100 Salvatore Bonaccorso
 wrote:
> Hi John,
> 
> On Sun, Jan 28, 2024 at 12:43:33AM -0800, John Johansen wrote:
> > On 12/30/23 20:24, Mathias Gibbens wrote:
> > > On Sat, 2023-12-30 at 16:44 +0100, Salvatore Bonaccorso wrote:
> > > > John, did you had a chance to work on this backport for 6.1.y
stable
> > > > upstream so we could pick it downstream in Debian in one of the
next
> > > > stable imports? Cherry-picking 1cf26c3d2c4c ("apparmor: fix
apparmor
> > > > mediating locking non-fs unix sockets") does not work, if not
> > > > havinging the work around e2967ede2297 ("apparmor: compute
policydb
> > > > permission on profile load") AFAICS, so that needs a 6.1.y
specific
> > > > backport submitted to sta...@vger.kernel.org ?
> > > > 
> > > > I think we could have people from this bug as well providing a
> > > > Tested-by when necessary. I'm not feeling confident enough to
be able
> > > > to provide myself such a patch to sent to stable (and you only
giving
> > > > an Acked-by/Reviewed-by), so if you can help out here with your
> > > > upstream hat on that would be more than appreciated and welcome
:)
> > > > 
> > > > Thanks a lot for your work!
> > > 
> > >    I played around with this a bit the past week as well, and
came to
> > > the same conclusion as Salvatore did that commits e2967ede2297
and
> > > 1cf26c3d2c4c need to be cherry-picked back to the 6.1 stable
tree.
> > > 
> > >    I've attached the two commits rebased onto 6.1.y as patches to
this
> > > message. Commit e2967ede2297 needed a little bit of touchup to
apply
> > > cleanly, and 1cf26c3d2c4c just needed adjustments for line number
> > > changes. I included some comments at the top of each patch.
> > > 
> > >    With these two commits cherry-picked on top of the 6.1.69
kernel, I
> > > can boot a bookworm system and successfully start a service
within a
> > > container that utilizes `PrivateNetwork=yes`. Rebooting back into
an
> > > unpatched vanilla 6.1.69 kernel continues to show the problem.
> > > 
> > >    While I didn't see any immediate issues (ie, `aa-status` and
log
> > > files looked OK), I don't understand the changes in the first
commit
> > > well enough to be confident in sending these patches for
inclusion in
> > > the upstream stable tree on my own.
> > > 
> > > Mathias
> > 
> > Your backports look good to me, and you can stick my acked-by on
them.
> > The changes are strictly more than necessary for the fix. They are
> > part of a larger change set that is trying to cleanup the runtime
> > code by changing the permission mapping from a runtime operation
> > to something that is done only at policy load/unpack time.
> > 
> > The advantage of this approach is that while it is a larger change
> > than strictly necessary. It is backporting patches that are already
> > upstream, keep the code closer and making backports easier.
> > 
> > Georgia did a minimal backport fix by keeping the version as part
> > of policy and doing the permission mapping at runtime. I have
> > included that patch below. Its advantage is it is a minimal
> > change to fix the issue.
> > 
> > I am happy with either version going into stable. Do you want to
> > send them or do you want me to do it?
> Thanks a lot, that is *really* much appreicated!
> 
> if you can send them that would be great, because think then they
> come
> directly from you, the trust from Greg or Sasha is higher. otherwise
> I
> think they will then explicitly want an ack on that submission thread
> from you (or pointing to this Debian downstream bug).
> 
> Greg will probably want the backport apporach of the two commits if
> it
> feasible and we do not expect regression from it. But you are
> definitively in a better position to judge this :)
> 
> Thanks again!
> 
> Regards,
> Salvatore
> 
> p.s.: feel free to CC us as well in the upstream stable submission.

Hi John,

Is there any update on this? As far as I am aware this patch has not
been sent for backporting yet, so apparmor in 6.1 is still borken, and
the CI still fails because of it.

Is there any chance you could please take care of that, so that we can
finally fix this issue?

Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#1071574: bookworm-pu: package netcfg/1.187+deb12u1

[Colin Watson]

On Tue, May 21, 2024 at 03:20:52PM +0200, Cyril Brulebois wrote:
> Colin Watson  (2024-05-21):
> > I've just fixed this in unstable, but it would be helpful to have it
> > in place for installs of bookworm too.
> 
> ACK on principle; you'll want a dch -r though.

Indeed, I usually just leave that until after approval in case any
last-minute changes are needed.  Uploaded now, thanks.

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

Bug#1071586: kicad: bookworm-backports requires update to 8.x

[Charlemagne Lasse]

Package: kicad
Version: 7.0.11+dfsg-1~bpo12+1
Severity: wishlist

Backports is expected to track the version in testing. But at the
moment, it is unfortunately from an older version. It would be nice to
have an upload to bookworm-backports which updates it to the "same"
version. If there are any blockers then it would also be nice to just
hear about them.

(btw. thanks for all the work. I just got curious and took this as an
opportunity to create this ticket to track the state).

Bug#1071585: libsingular4m3n0t64: SONAME change w/o package rename

[David Bremner]

Package: libsingular4m3n0t64
Version: 1:4.4.0+ds-1
Severity: serious
Justification: Policy 8.1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

According to policy 8.1

"The run-time shared library must be placed in a package whose name
changes whenever the SONAME of the shared library changes."

The most recent upload of singular (4.4.0+ds-1) bumped the SONAME but
did not rename the shared library package or otherwise do a transition.

This broke at least polymake at run time.

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

Kernel: Linux 6.6.15-amd64 (SMP w/20 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 libsingular4m3n0t64 depends on:
ii  libc62.38-11
ii  libflint19   3.1.2-1
ii  libgmp10 2:6.3.0+dfsg-2+b1
ii  libntl44 11.5.1-1+b2
ii  libreadline8t64  8.2-4
ii  libstdc++6   14-20240330-1

libsingular4m3n0t64 recommends no packages.

libsingular4m3n0t64 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmZMyK0ACgkQA0U5G1Wq
FSG2gQ//QmM6pmFe/VFcB94PRKvyMRd153JwHmaw1HJ8XQi/+8UTa+43/gQxg+sL
KQ1ydhXHZeWGtRBW9Vb/iG/fGQtU8Si0NZ2385o5IP/CPpu06ZlhL59vkj/xx/pt
4c0knwl/5dSM46V8sbaHUdEqKUIerJek5R4Pc4EzcwNtTIubLQYyUv1ho/Xkf/3A
ZyhwBlerM0XOge1UICG3RMfNLVRkJdRWtsx/LpRDFa4gu1UYRSCEv4TUA+ZFB9xd
PCcDaKfqcqa/sBhbFbtGvU1Vc/jyCj46weiJg9VIKXxorEyj4udfDYsp0MfHqFC7
VKtQvSK0zwa8TQ8TDRTILpL2Ht6W2YKQ9+2Pnxw1NvyQma3X1+mFwZJUU/6RgWpG
9+K7iKWfllgO2DlJYoJXgZCzViPG1tXwAQ0k0zIolrgMcyOs1/ke46vAmI3XSpQ4
rGOb4XMNuF3ehFRRziHApPvKKD/wF2GcJyiPJJ1jEQ0yo+dcC3m1V7aHYmzUJJIt
maSxVZlfIsEJdQq1r+L2QMOjO8QmXDhTjqGX9YXoM8flGywUz3+pkyVh02KjCMHu
R6/QAvsDTCIOuCw/H1+JzEy0vvCOg/vg+dX93BW/9t2JEyu/dkeo5TTcbloQ12D0
65akpFKjsaiNtZao96AaOPvzFBmNeWZ/9O9rlW64cQUstptSpoQ=
=dlC5
-END PGP SIGNATURE-

Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Andrej Shadura]

Hi again,

On Tue, 21 May 2024, at 17:59, Andrej Shadura wrote:
> On Tue, 21 May 2024, at 17:17, Facundo Gaich wrote:
>> Well I ended packaging this, it's waiting in debcargo-conf at
>> https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/653
> 
> If the Rust impl of toml2json works better than one written in Python 
> (reserialize), I’m more than happy that you take over the binary package. I’m 
> almost certain it does, given that the Python package is basically someone’s 
> script I packaged and patched over and over again.

In fact, having checked the source code, it’s one way only, and after all it’s 
also someone else’s quick hack. Maybe someone should write a robust tool to 
support all formats and directions and package *that* for Debian? :)

-- 
Cheers,
  Andrej

Bug#1071584: linux-image-6.1.0-21-amd64: power cycle on hypervisor Hyper-V (2016) during bootup

[m0x7e]

Package: src:linux
Version: 6.1.90-1
Severity: normal
X-Debbugs-Cc: xm0...@gmail.com

Dear Maintainer,

I've installed Debian 12.5.0 via net-install on a Hyper-V 2016 (2024/05 updates 
installed) machine. The installation went well, but as soon as the machine 
tried to boot up with the 6.1.0-21 kernel, it always was resetting after 
starting the initramfs sequence.

Unfortunately all debug options (debug=, debug, removing quiet/splash) didn't 
work out to get ANY useful log. Interesting side note: after 2-3 retries the 
boot is sometimes successful and the OS seems to be stable up (at least 2-3 
hours as far as I tested).

The fall-back Kernel 6.1.0-18 works fine. Coming up all the time with each 
retry.

Here I've recorded a sample: https://www.youtube.com/watch?v=jE53r7ulTKw

I've seen that there were others reporting issues with 6.1.0-20/21 kernel, but 
the focus there seems to be 3rd party software or hardware related.

A possibly related bug is #1071378 while adding the parameter earlyprintk=vga 
didn't change anything.

-- Package-specific info:
** Version:
Linux version 6.1.0-21-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-21-amd64 
root=UUID=db4a3fee-0b7b-4120-b0fb-9e87c31c4f6b ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Microsoft Corporation
product_name: Virtual Machine
product_version: Hyper-V UEFI Release v1.0
chassis_vendor: Microsoft Corporation
chassis_version: Hyper-V UEFI Release v1.0
bios_vendor: Microsoft Corporation
bios_version: Hyper-V UEFI Release v1.0
board_vendor: Microsoft Corporation
board_name: Virtual Machine
board_version: Hyper-V UEFI Release v1.0

** Loaded modules:
tls
binfmt_misc
nls_ascii
nls_cp437
vfat
fat
intel_rapl_msr
intel_rapl_common
ghash_clmulni_intel
sha512_ssse3
sha512_generic
sha256_ssse3
sha1_ssse3
aesni_intel
crypto_simd
cryptd
rapl
hyperv_drm
serio_raw
drm_shmem_helper
pcspkr
drm_kms_helper
hv_balloon
hyperv_keyboard
hv_utils
evdev
sg
joydev
drm
fuse
loop
dm_mod
efi_pstore
configfs
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
sd_mod
t10_pi
sr_mod
crc64_rocksoft
cdrom
crc64
crc_t10dif
crct10dif_generic
hv_storvsc
scsi_transport_fc
hid_generic
scsi_mod
hid_hyperv
hid
hv_netvsc
scsi_common
crct10dif_pclmul
crct10dif_common
crc32_pclmul
crc32c_intel
hv_vmbus

** PCI devices:

** USB devices:
not available


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

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

Versions of packages linux-image-6.1.0-21-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20221128-1
ii  linux-base  4.9

Versions of packages linux-image-6.1.0-21-amd64 recommends:
ii  apparmor 3.0.8-3
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.1.0-21-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi-amd64  2.06-13+deb12u1
pn  linux-doc-6.1   

Versions of packages linux-image-6.1.0-21-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Andrej Shadura]

Hi,

On Tue, 21 May 2024, at 17:17, Facundo Gaich wrote:
> On Thu, Feb 22, 2024 at 1:39 PM Jonas Smedegaard  wrote:
>> Quoting Facundo Gaich (2024-02-22 17:12:22)
>> > I can work on packaging this if you're still interested, I'd need a 
>> > sponsor.
>> > 
>> > I've already done some preliminary work on this, in particular I renamed
>> > the bin to "rust-toml2json" but maybe you've got a better idea?
>> 
>> If the command-line tool does somewhat the same as the existing one, I
>> suggest to rename it with the deviating part as the end instead, so that
>> users TAB-completing would easier notice the alternative:
>> toml2json-rust. 
> 
> Well I ended packaging this, it's waiting in debcargo-conf at
> https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/653

If the Rust impl of toml2json works better than one written in Python 
(reserialize), I’m more than happy that you take over the binary package. I’m 
almost certain it does, given that the Python package is basically someone’s 
script I packaged and patched over and over again.

-- 
Cheers,
  Andrej

Bug#1071161: glib2.0 2.66.8-1+deb11u4 flagged for acceptance

[Adam D. Barratt]

On Tue, 2024-05-21 at 11:23 +0100, Simon McVittie wrote:
> On Mon, 20 May 2024 at 20:12:24 +, Adam D Barratt wrote:
> > The upload referenced by this bug report has been flagged for
> > acceptance
> > into the proposed-updates queue for Debian bullseye.
> ...
> > Package: glib2.0
> > Version: 2.66.8-1+deb11u4
> > Explanation: fix a (rare) memory leak
> 
> Thanks for reviewing this change. Please consider also accepting
> #1071159 into bookworm-p-u (same change, different base version) to
> preserve the property that bookworm has no regressions when compared
> with bullseye, which I assume is something we want to be able to
> treat as an invariant.

Yep, that's the plan. I just ran out of time on yesterday's run through
the queues before I got to handling the bookworm upload.

Regards,

Adam

Bug#1071582: ip: Poor color choice for dark background

[Luca Boccassi]

On Tue, 21 May 2024 at 16:41, Diederik de Haas  wrote:
>
> On Tuesday, 21 May 2024 16:57:40 CEST Gedalya wrote:
> > On 5/21/24 10:55 PM, Luca Boccassi wrote:
> > > This has always been enabled by default, even in stable.
> >
> > What is the meaning of this line in the changelog for 6.9.0-1, and why does
> > it correlate with an actual change in behavior?
> >
> > Quote:
> >   * Enable output with colors on terminals
>
> Can confirm that the output changed significantly.
> Previously it was all gray-ish (on black) and after the upgrade it got all
> colorful.
> The (color) output I got when ssh-ed into another machine was (significantly)
> different then on my local PC. And the blue of the IPv6 addresses is indeed
> very hard to read.
>
> Took some screenshots to show it.

If you don't like the default settings, please send a patch upstream
to change them. I am not going to patch downstream (nor disable it)
for personal preferences, so reporting it here is just a waste of
time.

Bug#1070965: rtorrent: does not start due to soname update

[Chris Lamb]

Liam Stitt wrote:

> libxmlrpc-core-c3t64 has bumped that soname to .4, so presumably a rebuild 
> will
> fix this.

A rebuild will indeed fix this, or at least rebuilding rtorrent
locally fixes this for me.

Can the maintainer therefore please request a binNMU?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1071583: ITP: bluetooth-sensor-state-data -- Models for storing and converting Bluetooth Sensor State Data

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: bluetooth-sensor-state-data
  Version : 1.6.2
  Upstream Author : J. Nick Koston 
* URL : 
https://github.com/bluetooth-devices/bluetooth-sensor-state-data
* License : Apache-2.0
  Programming Lang: Python
  Description : Models for storing and converting Bluetooth Sensor State 
Data

  This library is designed to facilitate the handling of Bluetooth sensor data
  by offering standardized models that can be easily integrated into various
  applications.
  .
  Key features include:
   * Storage models for Bluetooth sensor state data.
   * Conversion tools to interpret and transform sensor data.
   * Support for various Bluetooth sensor types.
  .
  This package is particularly useful for developers working on applications
  that need to process and manage data from Bluetooth sensors efficiently. It is
  built with ease of use and integration in mind, making it a valuable tool for
  handling Bluetooth sensor data in Python projects.

I plan to maintain this package as part of the Python team.

Bug#1069904: Autopkgtests failed

[Jochen Sprickerhof]

Hi Elena,

I have opened a MR to fix this:

https://salsa.debian.org/python-team/packages/python-gnupg/-/merge_requests/1

Due to #1071561 I will not do more but it would be great if we could get 
this fixed.


Cheers Jochen

* Andrey Rakhmatullin  [2024-04-27 00:32]:

Package: python3-gnupg
Version: 0.5.2-1
Severity: serious

https://ci.debian.net/packages/p/python-gnupg/unstable/amd64/45884087/

277s + python3.11 test_gnupg.py
493s ...F...
493s ==
493s FAIL: test_search_keys (__main__.GPGTestCase.test_search_keys)
493s Test that searching for keys works
493s --
493s Traceback (most recent call last):
493s   File "/tmp/autopkgtest-
lxc.s9943af9/downtmp/build.Ev1/src/test_gnupg.py", line 1252, in
test_search_keys
493s self.assertEqual(0, r.returncode, 'Non-zero return code')
493s AssertionError: 0 != 2 : Non-zero return code


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

Kernel: Linux 6.7.9-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 python3-gnupg depends on:
ii  gnupg2.2.40-3
ii  python3  3.11.8-1

python3-gnupg recommends no packages.

python3-gnupg suggests no packages.


signature.asc
Description: PGP signature

Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Facundo Gaich]

Control: retitle -1 ITP: rust-toml2json -- A very small CLI for converting
TOML to JSON
Control: owner -1 !

Well I ended packaging this, it's waiting in debcargo-conf at
https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/653

Best,
Facundo

On Thu, Feb 22, 2024 at 1:39 PM Jonas Smedegaard  wrote:

> Quoting Facundo Gaich (2024-02-22 17:12:22)
> > I can work on packaging this if you're still interested, I'd need a
> sponsor.
> >
> > I've already done some preliminary work on this, in particular I renamed
> > the bin to "rust-toml2json" but maybe you've got a better idea?
>
> If the command-line tool does somewhat the same as the existing one, I
> suggest to rename it with the deviating part as the end instead, so that
> users TAB-completing would easier notice the alternative:
> toml2json-rust.
>
>  - 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

Bug#1071582: ip: Poor color choice for dark background

[Gedalya]

On 5/21/24 10:55 PM, Luca Boccassi wrote:
> This has always been enabled by default, even in stable.

What is the meaning of this line in the changelog for 6.9.0-1, and why does it 
correlate with an actual change in behavior?

Quote:
  * Enable output with colors on terminals

Bug#1071582: ip: Poor color choice for dark background

[Luca Boccassi]

Control: close -1 wontfix
Control: close -1

On Tue, 21 May 2024 at 15:51, Gedalya  wrote:
>
> Package: iproute2
> Version: 6.9.0-1
> Severity: minor
>
> Hello,
>
> The newly enabled colored output is rather hard to read on dark backgrounds, 
> especially the deep blue color used for IPv6 addresses.
>
> Setting COLORFGBG=";0" as the manpage suggests helps a lot.
>
> Consider a scenario when this command is used under stress to manually bring 
> up networking from a VT. It's a rather basic command that would typically run 
> on a dark background and it's important for it to be accessible by default 
> without fiddling around too much.

This has always been enabled by default, even in stable. As per
manpage, you can disable it if you don't want it.

Bug#1071495: closed by Colin Watson (Re: Bug#1071495: debbugs: Please enable Salsa-CI in Salsa repository)

[Otto Kekäläinen]

For the record,
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 was
not merged fully and the Salsa-CI is not yet passing, so I filed
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/20
which you can see in the MR status as CI passing.

Bug#1071582: ip: Poor color choice for dark background

[Gedalya]

Package: iproute2
Version: 6.9.0-1
Severity: minor

Hello,

The newly enabled colored output is rather hard to read on dark backgrounds, 
especially the deep blue color used for IPv6 addresses.

Setting COLORFGBG=";0" as the manpage suggests helps a lot.

Consider a scenario when this command is used under stress to manually bring up 
networking from a VT. It's a rather basic command that would typically run on a 
dark background and it's important for it to be accessible by default without 
fiddling around too much.

Thanks!

Bug#985478: [v2 PATCH] options: Always reset OPTIND in getoptsreset

[наб]

On Sun, May 19, 2024 at 10:21:42PM +0800, Herbert Xu wrote:
> Always reset OPTIND if it is modified by the user, regardless of
> its value.
I disagree in principle, but I think this is basically fine actually;
strictly, we are allowed to do this
  98842  If the application sets OPTIND to the value 1, a new set of parameters 
can be used: either the
  98843  current positional parameters or new arg values. Any other attempt to 
invoke getopts multiple
  98844  times in a single shell execution environment with parameters 
(positional parameters or arg
  98845  operands) that are not the same in all invocations, or with an OPTIND 
value modified to be a
  98846  value other than 1, produces unspecified results.
but I cannot prove this breaks existing code in the wild.

I mean such code most likely definitely exists,
but I cannot prove this; but even if it does,
it relies on "unspecified" behaviour, which means it
"cannot be assured to be portable across conforming implementations"
such as dash 1 and dash 2.
I still think it should keep working, since it had worked.

While I found at least one changelog entry in DCS saying
"remove unset OPTIND to work around broken dash shell"
by searching for "unset.*OPTIND\b",
searching "OPTIND=[^01]" gives me heaps of OPTIND=digit
and OPTIND=expression users, but most of them are explicit bash users;
the first one with /bin/sh is

https://sources.debian.org/src/sptk/3.9-3/debian/scripts/raw2wav/?hl=74#L74
reading
OPTIND=0
OPT=""
for i in "$@"
do
OPTIND=`expr $OPTIND + 1`
if [ "$OPT" = "" ]
then
OPTARG=""
but this program doesn't use getopts.

This turns "unset OPTIND must work but doesn't"
 + "OPTIND=asd is invalid but probably shouldn't be"
 + "OPTIND=3 makes getopts parse the third argument (as a happy 
accident)"
into "unset OPTIND works"
   + "OPTIND=asd works (and restarts getopts as a happy accident)"
   + "OPTIND=3 restarts getopts (as a happy accident)".

So, overall, reasonable, if a tad solomonic.


signature.asc
Description: PGP signature

Bug#1070957: nghttp3: Stable backports for nghttp3 and ngtcp2

[Sakirnth Nagarasa]

Hello Samuel

On Sat, 11 May 2024 22:04:35 +0100 Samuel Henrique 
 wrote:

I would like to upload the current packages we have on testing (for both
nghttp3 and ngtcp2) to stable-bpo, so they can clear the NEW queue (it might
take a while). Then once the updated packages hit testing, I can update them on
bpo and unblock http3 for curl there.

Do you see any issues with this or have a preference on not following this
approach?


The version in testing and experimental have different sonames, 
therefore different binary package names. So it has through NEW queue 
two times this way. I would wait until we upload the new versions from 
experimental to unstable.


Moreover I have read the contribute page for Debian backports. There is 
a statement that we should upload only packages with notable user base 
[1]. IMHO the nghttp3 and ngtcp2 do not fulfill this criteria yet.
Since libnghttp3* has one reverse dependency excluding ngtcp2 and 
nghttp3 binary packages and libngtcp2* has no reverse dependency in 
stable that can be seen as a indicator. Also every upload to testing 
should be uploaded to stable backports [2]. With the high frequency of 
nghttp3 and ngtcp2 releases and soname changes I would recommend to wait 
for the normal Debian stable release. What do you think?


[1] https://backports.debian.org/Contribute/
[2] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-often-shall-one-upload-to-stable-backports


Kind Regards
Saki

Bug#1065553: marked as done (fonts-jetbrains-mono: Jetbrains-Mono 2.304 broken in Gnome Terminal)

[Jeremy Bícha]

> Tried again, and the problem goes away if I close all open gnome-terminals, 
> so this bug can be closed.
> I guess it's a problem in gnome-terminal that doesn't detect the font file 
> changed, and tries accessing glyphs in wrong locations in the font file 
> (based on the older file).

There is a longstanding bug where apps need to be restarted to make
use of updated fonts. A particularly serious report of this is
https://bugs.debian.org/788791 which is mitigated because the
Cantarell font (the default UI font for Debian's GNOME Shell) is only
updated rarely.

Thank you,
Jeremy Bícha

Bug#1071581: dialog: stop using libtool-bin

[Helmut Grohne]

Source: dialog
Version: 1.3-20240307-2
Severity: normal
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

Hi Santiago,

we want to remove the package libtool-bin from the archive, because any
attempt of using it breaks cross compilation. The dialog package is a
bit strange in this regard. It's autoconf stuff attempts to detect
whether there is a libtool.m4 and when there isn't attempts to use a
pre-configured libtool (the one from libtool-bin). Unfortunately, last
time it was autoreconf'ed, that happened without libtool.m4. So
basically, making libtool-bin go away here amounts to autoreconfing
dialog after libtoolizing it. And that's pretty much what I did in the
attached patch. The dialog binary and libdialog.la are bit-identical
with this change.

Helmut
diff -Nru dialog-1.3-20240307/debian/changelog 
dialog-1.3-20240307/debian/changelog
--- dialog-1.3-20240307/debian/changelog2024-04-08 12:40:00.0 
+0200
+++ dialog-1.3-20240307/debian/changelog2024-05-20 23:15:03.0 
+0200
@@ -1,3 +1,10 @@
+dialog (1.3-20240307-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Stop using libtool-bin by autoreconfing. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 20 May 2024 23:15:03 +0200
+
 dialog (1.3-20240307-2) unstable; urgency=medium
 
   * Fix Breaks and Replaces fields. Closes: #1068634.
diff -Nru dialog-1.3-20240307/debian/control dialog-1.3-20240307/debian/control
--- dialog-1.3-20240307/debian/control  2024-04-08 11:00:00.0 +0200
+++ dialog-1.3-20240307/debian/control  2024-05-20 23:15:03.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Santiago Vila 
 Standards-Version: 4.6.2
-Build-Depends: debhelper-compat (= 13), gettext, libncurses-dev (>= 5.3), 
libtool-bin
+Build-Depends: debhelper-compat (= 13), gettext, libncurses-dev (>= 5.3), 
libtool
 Homepage: https://invisible-island.net/dialog/dialog.html
 Rules-Requires-Root: no
 
diff -Nru dialog-1.3-20240307/debian/patches/libtool.patch 
dialog-1.3-20240307/debian/patches/libtool.patch
--- dialog-1.3-20240307/debian/patches/libtool.patch1970-01-01 
01:00:00.0 +0100
+++ dialog-1.3-20240307/debian/patches/libtool.patch2024-05-20 
23:15:03.0 +0200
@@ -0,0 +1,214 @@
+--- dialog-1.3-20240307.orig/configure.in
 dialog-1.3-20240307/configure.in
+@@ -29,6 +29,7 @@
+ dnl 
---
+ AC_PREREQ(2.52.20230114)
+ AC_INIT(dialog.h)
++AC_CONFIG_MACRO_DIRS([m4])
+ AC_CONFIG_HEADER(dlg_config.h:config.hin)
+ 
+ AC_ARG_PROGRAM
+@@ -229,26 +230,24 @@
+ mktime \
+ )
+ 
+-CF_CURSES_FUNCS(\
+-flushinp \
+-getattrs \
+-getbegx \
+-getbegy \
+-getbegyx \
+-getcurx \
+-getcury \
+-getmaxx \
+-getmaxy \
+-getmaxyx \
+-getparx \
+-getpary \
+-getparyx \
+-use_default_colors \
+-wchgat \
+-wcursyncup \
+-wget_wch \
+-wsyncup \
+-)
++CF_CURSES_FUNC(flushinp)
++CF_CURSES_FUNC(getattrs)
++CF_CURSES_FUNC(getbegx)
++CF_CURSES_FUNC(getbegy)
++CF_CURSES_FUNC(getbegyx)
++CF_CURSES_FUNC(getcurx)
++CF_CURSES_FUNC(getcury)
++CF_CURSES_FUNC(getmaxx)
++CF_CURSES_FUNC(getmaxy)
++CF_CURSES_FUNC(getmaxyx)
++CF_CURSES_FUNC(getparx)
++CF_CURSES_FUNC(getpary)
++CF_CURSES_FUNC(getparyx)
++CF_CURSES_FUNC(use_default_colors)
++CF_CURSES_FUNC(wchgat)
++CF_CURSES_FUNC(wcursyncup)
++CF_CURSES_FUNC(wget_wch)
++CF_CURSES_FUNC(wsyncup)
+ 
+ CF_CURSES_EXIT
+ 
+--- dialog-1.3-20240307.orig/aclocal.m4
 dialog-1.3-20240307/aclocal.m4
+@@ -1412,6 +1412,7 @@
+   AC_MSG_CHECKING(version of $LIBTOOL)
+   CF_LIBTOOL_VERSION
+   AC_MSG_RESULT($cf_cv_libtool_version)
++  ifdef([LT_PACKAGE_VERSION],,[
+   if test -n "$cf_cv_libtool_version"
+   then
+   cf_check_libtool_version=`$LIBTOOL --version 2>&1 | sed -e 
'/^$/d' -e 's,[[()]],...,g' -e 's,[[ ]],-,g' -e '2,$d'`
+@@ -1425,6 +1426,7 @@
+   else
+   AC_MSG_ERROR(No version found for $LIBTOOL)
+   fi
++  ])
+ else
+   AC_MSG_ERROR(GNU libtool has not been found)
+ fi
+@@ -1636,50 +1638,45 @@
+ dnl when switching to/from a debug-library.
+ AC_DEFUN([CF_CURSES_EXIT],
+ [
+-CF_CURSES_FUNCS(\
+-exit_curses \
+-_nc_free_and_exit \
+-)
++CF_CURSES_FUNC(exit_curses)
++CF_CURSES_FUNC(_nc_free_and_exit)
+ ])dnl
+ dnl 
---
+-dnl CF_CURSES_FUNCS version: 20 updated: 2020/12/31 20:19:42
++dnl CF_CURSES_FUNC version: 20 updated: 2020/12/31 20:19:42
+ dnl ---
+ dnl Curses-functions are a little complicated, since a lot of them are macros.
+-AC_DEFUN([CF_CURSES_FUNCS],
++AC_DEFUN([CF_CURSES_FUNC],
+ [
+ AC_REQUIRE([CF_CURSES_CPPFLAGS])dnl
+ AC_REQUIRE([CF_XOPEN_CURSES])
+ AC_REQUIRE([CF_CURSES_TERM_H])
+ AC_REQUIRE([CF_CURSES_UNCTRL_H])
+-for cf_func in $1
+-do
+-  CF_UPPER(cf_tr_func,$cf_func)
+-  AC_MSG_CHECKING(for ${cf_func})
+-  CF_MSG_LOG(${cf_func})
+-  AC_CACHE_VAL(cf_cv_func_$cf_func,[
+-  eval 

Bug#1071580: eog-plugin-picasa: Drop plugin for non-functional service

[Bastian Germann]

Package: eog-plugin-picasa
Severity: important

Please drop eog-plugin-picasa. The Picasa service was discontinued.

Bug#1069210: dh-elpa: Support nested directory in elpa installation

[Sean Whitton]

control: tag -1 + patch

Hello,

Thanks Xiyue.  I think that this is a clean way to improve upon the
current situation and I would be happy to upload this to experimental.

David, since you figured out the /usr/share/site-lisp/elpa layout to
begin with, do you have time to give any comments?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007213: please upgrade to Xpra 5

[Sergio Gelato]

control: retitle -1 please upgrade to Xpra 5

Xpra 3 and 4 are EOL (since August 2023); see 
https://github.com/Xpra-org/xpra/wiki/Versions

Bug#1071579: RFS: tla/1.3.5+dfsg1-5 [QA] [RC] -- GNU Arch revision control system

[Bo YU]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : tla
   Version  : 1.3.5+dfsg1-5
   Upstream contact : [fill in name and email of upstream]
 * URL  : http://savannah.gnu.org/projects/gnu-arch/
 * License  : [fill in]
 * Vcs  : https://salsa.debian.org/debian/tla
   Section  : vcs

The source builds the following binary packages:

  tla - GNU Arch revision control system
  tla-doc - GNU Arch revision control system (documentation)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/tla/tla_1.3.5+dfsg1-5.dsc

Changes since the last upload:

 tla (1.3.5+dfsg1-5) unstable; urgency=medium
 .
   * QA upload.
 .
   * Use dh_update_autotools_config/dh_autoreconf_clean to update config
 correctly. (Closes: #1071544)

-- 
Regards,
--
  Bo YU

diff -Nru tla-1.3.5+dfsg1/debian/changelog tla-1.3.5+dfsg1/debian/changelog
--- tla-1.3.5+dfsg1/debian/changelog2024-05-17 18:07:34.0 +0800
+++ tla-1.3.5+dfsg1/debian/changelog2024-05-21 17:49:51.0 +0800
@@ -1,3 +1,12 @@
+tla (1.3.5+dfsg1-5) unstable; urgency=medium
+
+  * QA upload.
+
+  * Use dh_update_autotools_config/dh_autoreconf_clean to update config
+correctly. (Closes: #1071544)
+
+ -- Bo YU   Tue, 21 May 2024 17:49:51 +0800
+
 tla (1.3.5+dfsg1-4) unstable; urgency=medium
 
   * QA upload.
diff -Nru tla-1.3.5+dfsg1/debian/rules tla-1.3.5+dfsg1/debian/rules
--- tla-1.3.5+dfsg1/debian/rules2024-05-17 16:57:58.0 +0800
+++ tla-1.3.5+dfsg1/debian/rules2024-05-21 17:47:05.0 +0800
@@ -19,6 +19,7 @@
 
 configure-stamp:
dh_testdir
+   dh_update_autotools_config
rm -rf debian/build
rm -rf src/expat/  # Let's play safe
rm -f src/libneon/PLUGIN/REQ
@@ -52,6 +53,7 @@
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
+   dh_autoreconf_clean
dh_clean
$(RM) -r debian/build
 


signature.asc
Description: PGP signature

Bug#1071578: browse-url silently fails on some wayland corner cases

[Antoine Beaupre]

Package: emacs-pgtk
Version: 1:29.3+1-2~bpo12+1
Severity: normal

After upgrading from Emacs 28 to 29 and switching from xorg to
wayland, I have noticed emacs sometimes fail to open URLs. It seems to
be an ordering issue in my session: it seems like Emacs sometimes
starts before Sway is fully setup and the environment properly
populated, which makes it use the incorrect WAYLAND_DISPLAY variable.

This, in itself, is a bug in my setup: Emacs should be started
properly.

*But* my bug here is this fails completely silently. No URL gets
opened at all, which is *really* disruptive because I can open a bunch
of URLs while reading my mail, then i go to my browser and nothing is
there and now I've lost data.

Instead, browse-url should fail noisily if it fails to load a URL. If
I look at the `browse-url' source, for example at the end we see this
kind of failure, which happens when no browser can be found at all:

(if (functionp function)
(apply function url args)
  (error "No suitable browser for URL %s" url

That is what I would expect the handler to do in this case, something
like "uh, we can't find your wayland display, so we're just dropping
this URL to the floor, sorry".

That function also has that mysterious blob:

  (progn
;; The `display' frame parameter is probably wrong.
;; See bug#53969 for some context.
;; (setenv "WAYLAND_DISPLAY" dpy)
)
(setenv "DISPLAY" dpy)))

... which refers to:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53969

... which I'm struggling to understand. If I uncomment that blob, the
bug, actually, just completely goes away which i find quite puzzling.

A.

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

Kernel: Linux 6.6.13+bpo-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 emacs-pgtk depends on:
ii  emacs-bin-common  1:29.3+1-2~bpo12+1
ii  emacs-common  1:29.3+1-2~bpo12+1
ii  libacl1   2.3.1-3
ii  libasound21.2.8-1+b1
ii  libc6 2.36-9+deb12u7
ii  libcairo2 1.16.0-7
ii  libdbus-1-3   1.14.10-1~deb12u1
ii  libfontconfig12.14.1-4
ii  libfreetype6  2.12.1+dfsg-5
ii  libgccjit012.2.0-14
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libgif7   5.2.1-2.5
ii  libglib2.0-0  2.74.6-2+deb12u2
ii  libgmp10  2:6.2.1+dfsg1-1.1
ii  libgnutls30   3.7.9-2+deb12u2
ii  libgpm2   1.20.7-10+b1
ii  libgtk-3-03.24.38-2~deb12u1
ii  libharfbuzz0b 6.0.0+dfsg-3
ii  libjansson4   2.14-2
ii  libjpeg62-turbo   1:2.1.5-2
ii  liblcms2-22.14-2
ii  libotf1   0.9.16-4
ii  libpango-1.0-01.50.12+ds-1
ii  libpng16-16t64 [libpng16-16]  1.6.43-5
ii  librsvg2-22.54.7+dfsg-1~deb12u1
ii  libselinux1   3.4-1+b6
ii  libsqlite3-0  3.40.1-2
ii  libsystemd0   252.22-1~deb12u1
ii  libtiff6  4.5.0-6+deb12u1
ii  libtinfo6 6.4-4
ii  libtree-sitter0   0.20.7-1
ii  libwebp7  1.2.4-0.2+deb12u1
ii  libwebpdemux2 1.2.4-0.2+deb12u1
ii  libxml2   2.9.14+dfsg-1.3~deb12u1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages emacs-pgtk recommends:
ii  fonts-noto-color-emoji  2.042-0+deb12u1

Versions of packages emacs-pgtk suggests:
ii  emacs-common-non-dfsg  1:28.2+1-2

-- no debconf information

Bug#1050633: wireshark: Downgrade to lua5.1

[Bálint Réczey]

Hi,

Wireshark 4.4 will require Lua 5.3/5.4 and is expected to be released
in October/November this year. Maybe a bit earlier.
Then this bug can be closed.

Cheers,
Balint

Bálint Réczey  ezt írta (időpont: 2023. nov.
26., V, 15:19):
>
> Bálint Réczey  ezt írta (időpont: 2023. nov.
> 17., P, 21:25):
> >
> ...
> > Please keep Lua 5.1 in the archive until Wireshark upstream moves to a
> > later version.
>
> I wanted to write please keep Lua 5.2 in the archive, because this is
> what is in use.

Bug#1071577: transition: libcamera 0.3.0

[Dylan Aïssi]

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

Dear Release Team,

Please schedule a transition slot for libcamera 0.3.0.

The auto-generated ben tracker looks good:
https://release.debian.org/transitions/html/auto-libcamera.html

The unique reverse dep (pipewire 1.0.6-1) builds fine with
libcamera 0.3.0 in experimental.

Thanks.

Best regards,
Dylan

Bug#1071574: bookworm-pu: package netcfg/1.187+deb12u1

[Cyril Brulebois]

Hi Colin,

Colin Watson  (2024-05-21):
> I've just fixed this in unstable, but it would be helpful to have it
> in place for installs of bookworm too.

ACK on principle; you'll want a dch -r though.
 

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


signature.asc
Description: PGP signature

Bug#1067842: transition: octave-9

[Sébastien Villemot]

Hi Graham,

Le lundi 20 mai 2024 à 11:25 +, Graham Inggs a écrit :
> octave-fits FTBFS on all architectures (#1070956),
> and octave-stk FTBFS on 32-bit architectures (#1069477),
> would you please take a look?

octave-fits has been autoremoved from testing because we requested its
removal from unstable (see #1070956).

octave-stk has been autoremoved from testing hence it is no longer a
blocker.

Additionally, there were 3 other packages which were posing a problem:
octave-ga, octave-queueing and octave-statistics. Those are arch:all
packages whose autopkgtests in testing were broken by the new octave
(but they have no dependency on octave-abi-*, since they are arch:all).
We made source uploads for the three of them, so they should be good.

I have a question: should we add a Breaks in octave against the old
versions of these 3 packages, in order to force the simultaneous
migration of all affected packages? I thought this was necessary, but
the excuses for octave no longer mention octave-ga and octave-queueing
(octave-statistics is still there because it has just been fixed). Note
that the updated packages have a Depends: octave (>= 9.1.0).

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



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

Bug#1071576: bugs.debian.org: bug subscription no longer possible: no "Please confirm subscription" e-mail

[Vincent Lefevre]

On 2024-05-21 15:04:44 +0200, Vincent Lefevre wrote:
> It is no longer possible to subscribe to bugs as
> "Please confirm subscription" e-mail messages are no longer sent.
> 
> On 2024-05-10, this was working, but since 2024-05-20 at least,
> this is no longer working. I had sent:
> 
> From: Vincent Lefevre 
> To: 1071372-subscr...@bugs.debian.org
> Subject: subscribe
> Date: Mon, 20 May 2024 00:56:07 +0200
> Message-ID: <20240519225607.ge2...@qaa.vinc17.org>
> 
> The issue remains with attempts today (2024-05-21) at 14:26:56 +0200
> and 14:47:15 +0200 for another bug.

Actually, after a look at the logs on my mail server, this was still
working at the following date:

2024-05-11T11:57:13.575225+02:00 joooj postfix/smtp[74387]: AB7C1812: 
to=<1070891-subscr...@bugs.debian.org>, 
relay=buxtehude.debian.org[2607:f8f0:614:1::1274:39]:25, delay=3.9, 
delays=0.04/0.11/2.8/0.89, dsn=2.0.0, status=sent (250 OK id=1s5jTe-00BPwE-Lt)

with a reply ("Please confirm subscription" e-mail):

2024-05-11T12:00:14.976146+02:00 joooj postfix/qmgr[70857]: E359C13E: 
from=<1070891-ign...@bugs.debian.org>, size=4289, nrcpt=1 (queue active)

But this was no longer working at the following date:

2024-05-17T15:51:22.974407+02:00 joooj postfix/smtp[164605]: 8556DACB: 
to=<1071274-subscr...@bugs.debian.org>, 
relay=buxtehude.debian.org[209.87.16.39]:25, delay=4.4, 
delays=0.03/0.04/3.4/0.94, dsn=2.0.0, status=sent (250 OK id=1s7xzY-00CaPs-2o)

(I did not get the reply).

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

Bug#1069509: r-cran-metamix: FTBFS on armhf: tests fail

[Graham Inggs]

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

While r-cran-metamix did fail on armhf [1] and i386 [2] around the
time of your bug report, it is passing now.


[1] 
https://tests.reproducible-builds.org/debian/history/armhf/r-cran-metamix.html
[2] 
https://tests.reproducible-builds.org/debian/history/i386/r-cran-metamix.html

Bug#1071576: bugs.debian.org: bug subscription no longer possible: no "Please confirm subscription" e-mail

[Vincent Lefevre]

Package: bugs.debian.org
Severity: important

It is no longer possible to subscribe to bugs as
"Please confirm subscription" e-mail messages are no longer sent.

On 2024-05-10, this was working, but since 2024-05-20 at least,
this is no longer working. I had sent:

From: Vincent Lefevre 
To: 1071372-subscr...@bugs.debian.org
Subject: subscribe
Date: Mon, 20 May 2024 00:56:07 +0200
Message-ID: <20240519225607.ge2...@qaa.vinc17.org>

The issue remains with attempts today (2024-05-21) at 14:26:56 +0200
and 14:47:15 +0200 for another bug.

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

Bug#1071575: dahdi-dkms: module fails to build for Linux 6.8.9: error: implicit declaration of function 'strlcpy'

[Andreas Beckmann]

Package: dahdi-dkms
Version: 1:3.1.0+git20230717~dfsg-5
Severity: serious

DKMS make.log for dahdi-3.1.0+git20230717 for kernel 6.8.9-amd64 (x86_64)
Sun May 19 19:55:53 UTC 2024
make -C /lib/modules/6.8.9-amd64/build 
KBUILD_EXTMOD=/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi 
DAHDI_INCLUDE=/var/lib/dkms/dahdi/3.1.0+git20230717/build/include 
DAHDI_MODULES_EXTRA="dahdi_dummy.o dahdi_echocan_oslec.o " HOTPLUG_FIRMWARE=yes 
m
odules DAHDI_BUILD_ALL=m
make[1]: Entering directory '/usr/src/linux-headers-6.8.9-amd64'
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/icE1usb/icE1usb.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_adpcm_chan.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_channel.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_chip_open.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_chip_stats.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_conf_bridge.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_debug.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_events.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_interrupts.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_memory.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_miscellaneous.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_mixer.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_phasing_tsst.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_playout_buf.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_remote_debug.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_tlv.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_tone_detection.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_tsi_cnct.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_tsst.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/apilib/bt/octapi_bt0.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/apilib/largmath/octapi_largmath.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/apilib/llman/octapi_llman.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/oct612x-user.o
  LD [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/oct612x/oct612x.o
  CC [M]  
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/wct4xxp/base.o
In file included from 
/usr/src/linux-headers-6.8.9-common/include/linux/srcu.h:21,
 from 
/usr/src/linux-headers-6.8.9-common/include/linux/notifier.h:16,
 from 
/usr/src/linux-headers-6.8.9-common/arch/x86/include/asm/uprobes.h:13,
 from 
/usr/src/linux-headers-6.8.9-common/include/linux/uprobes.h:49,
 from 
/usr/src/linux-headers-6.8.9-common/include/linux/mm_types.h:16,
 from 
/usr/src/linux-headers-6.8.9-common/include/linux/mmzone.h:22,
 from /usr/src/linux-headers-6.8.9-common/include/linux/gfp.h:7,
 from /usr/src/linux-headers-6.8.9-common/include/linux/umh.h:4,
 from 
/usr/src/linux-headers-6.8.9-common/include/linux/kmod.h:9,
 from 
/usr/src/linux-headers-6.8.9-common/include/linux/module.h:17,
 from 
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/wct4xxp/base.c:32:
/var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/wct4xxp/base.c: In 
function 'free_wc':
/usr/src/linux-headers-6.8.9-common/include/linux/workqueue.h:625:9: warning: 
call to '__warn_flushing_systemwide_wq' declared with attribute warning: Please 
avoid flushing system-wide workqueues. [-Wattribute-warning]
  625 | __warn_flushing_systemwide_wq();
\
  | ^~~

Bug#1071574: bookworm-pu: package netcfg/1.187+deb12u1

[Colin Watson]

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

[ Reason ]
Certain kinds of network architectures in Debian deployments (e.g.
https://phabricator.wikimedia.org/phame/post/view/312/ganeti_on_modern_network_design/,
https://blog.fhrnet.eu/2020/03/07/dhcp-server-on-a-32-subnet/) are
difficult because the installer doesn't support single-address netmasks
out of the box (https://bugs.debian.org/1064005).  You can sort of
handle this with point-to-point preseeding, but that isn't quite
identical and it doesn't work for IPv6.

I've just fixed this in unstable, but it would be helpful to have it in
place for installs of bookworm too.

[ Impact ]
It's possible to work around this without changing netcfg, but it
requires messy and fragile early_command preseeding to defeat netcfg's
behaviour (see #1064005).

[ Tests ]
The change includes automated tests for the changes to the gateway
reachability test.  For the changes to the routing table setup and to
confirm that no changes were needed to network configuration in the
installed system, I used libvirt machines with a DHCP server along the
lines of https://blog.fhrnet.eu/2020/03/07/dhcp-server-on-a-32-subnet/;
Wikimedia has also tested this using their own setup and confirmed that
it now works out of the box.

[ Risks ]
I've taken care that all the new code is guarded by interface->masklen
checks, so it should be obvious that it's a no-op on any system that
isn't using this unusual single-address netmask setup.

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

[ Changes ]
It turns out that fixing this is very straightforward: it's just a
matter of special-casing the gateway reachability test and then telling
the routing table to pretend that the gateway is directly attached to
the relevant link.  The installed system (ifupdown, NetworkManager)
already gets this right; it's just the installer that had trouble with
it.

[ Other info ]
This work was requested and sponsored by the Wikimedia Foundation.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]
diff -Nru netcfg-1.187/debian/changelog netcfg-1.187+deb12u1/debian/changelog
--- netcfg-1.187/debian/changelog   2023-05-23 19:24:01.0 +0100
+++ netcfg-1.187+deb12u1/debian/changelog   2024-05-14 11:27:14.0 
+0100
@@ -1,3 +1,9 @@
+netcfg (1.187+deb12u1) UNRELEASED; urgency=medium
+
+  * Handle routing for single-address netmasks (closes: #1064005).
+
+ -- Colin Watson   Tue, 14 May 2024 11:27:14 +0100
+
 netcfg (1.187) unstable; urgency=medium
 
   * Team upload
diff -Nru netcfg-1.187/netcfg-common.c netcfg-1.187+deb12u1/netcfg-common.c
--- netcfg-1.187/netcfg-common.c2022-06-03 19:25:43.0 +0100
+++ netcfg-1.187+deb12u1/netcfg-common.c2024-05-14 11:26:51.0 
+0100
@@ -1680,8 +1680,22 @@
 inet_pton(interface->address_family, interface->gateway, _addr);
 
 if (interface->address_family == AF_INET) {
+if (interface->masklen == 32) {
+/* Special case for single-address networks.  We'll handle
+ * routing manually in this case.
+ */
+return 1;
+}
+
 return (gw_addr.in4.s_addr && ((gw_addr.in4.s_addr & mask.in4.s_addr) 
== net.in4.s_addr));
 } else if (interface->address_family == AF_INET6) {
+if (interface->masklen == 128) {
+/* Special case for single-address networks.  We'll handle
+ * routing manually in this case.
+ */
+return 1;
+}
+
 if ((ntohs(gw_addr.in6.s6_addr16[0]) & 0xffc0) == (0xfe80 & 0xffc0)) {
 return 1;
 }
diff -Nru netcfg-1.187/static.c netcfg-1.187+deb12u1/static.c
--- netcfg-1.187/static.c   2021-09-22 19:07:01.0 +0100
+++ netcfg-1.187+deb12u1/static.c   2024-05-14 11:27:14.0 +0100
@@ -338,6 +338,12 @@
 di_snprintfcat(buf, sizeof(buf), "%s", interface->ipaddress);
 rv |= di_exec_shell_log(buf);
 } else if (!empty_str(interface->gateway)) {
+if (interface->masklen == 32) {
+snprintf(buf, sizeof(buf), "route add -interface %s %s", 
interface->gateway, interface->ipaddress);
+di_info("executing: %s", buf);
+rv |= di_exec_shell_log(buf);
+}
+
 snprintf(buf, sizeof(buf), "route add default %s", interface->gateway);
 rv |= di_exec_shell_log(buf);
 }
@@ -373,6 +379,8 @@
 }
 else if (!empty_str(interface->gateway)) {
 snprintf(buf, sizeof(buf), "ip route add default via %s", 
interface->gateway);
+if (interface->masklen == 32)
+di_snprintfcat(buf, sizeof(buf), " dev %s onlink", 
interface->name);
  

Bug#1071573: ITP: libnet-ssl-expiredate-perl -- obtain expiration date of certificate

[Andrius Merkys]

Package: wnpp
Owner: Mason James 
Severity: wishlist
Control: block 1036769 by -1
X-Debbugs-CC: m...@kohaaloha.com

* Package name: libnet-ssl-expiredate-perl
  Version : 1.24
  Upstream Author : Hirose Masaaki
* URL : https://metacpan.org/release/Net-SSL-ExpireDate
* License : Artistic
  Programming Lang: Perl
  Description : obtain expiration date of certificate

Net::SSL::ExpireDate get certificate from network (SSL) or local
file and obtain its expiration date.

This ITP is to document the fact that Net::SSL::ExpireDate is being 
packaged (by Mason James). I am interested in this package as means to 
implement #1036769 in lintian (certificate expiry check).


Remark: This package is to be maintained with Debian Perl Group at

https://salsa.debian.org/perl-team/modules/packages/libnet-ssl-expiredate-perl

Bug#1071572: neovim: New upstream version 0.10 available

[Bastian Venthur]

Package: neovim
Version: 0.9.5-7
Severity: wishlist
X-Debbugs-Cc: vent...@debian.org

Dear Maintainer,

a new upstream version of neovim is available.


Cheers,

Bastian

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

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

Versions of packages neovim depends on:
ii  libc62.38-11
ii  libluajit-5.1-2  2.1.0+openresty20231117-2
ii  libmsgpackc2 4.0.0-3+b1
ii  libtermkey1  0.22-2
ii  libtree-sitter0  0.20.8-2+b1
ii  libunibilium42.1.1-2
ii  libuv1t641.48.0-4
ii  libvterm00.3.3-3
ii  lua-luv  1.48.0-2-2
ii  neovim-runtime   0.9.5-7

Versions of packages neovim recommends:
ii  python3-pynvim  0.5.0-1
ii  wl-clipboard2.2.1-1
ii  xclip   0.13-4
ii  xsel1.2.1-1
ii  xxd 2:9.1.0377-1

Versions of packages neovim suggests:
ii  universal-ctags [ctags]  5.9.20210829.0-1
ii  vim-scripts  20210124.2

-- no debconf information

Bug#1071571: mdir: wrong byte count reported in summary

[g1]

Package: mtools
Version: 4.0.33-1+really4.0.32-1
Severity: normal
Tags: upstream patch

The overall byte count shown in the summary is truncated (from the left)
to ten effective digits, and is therefore wrong as soon as it reaches
10 GB (10^10 B):

$ mdir f:abc
 Volume in drive F has no label
 Volume Serial Number is 1234-5678
Directory for F:/abc

. 2024-05-21  13:32 
..2024-05-21  13:32 
f1  30 2024-05-21  13:32 
f2  30 2024-05-21  13:32 
f3  30 2024-05-21  13:32 
f4  30 2024-05-21  13:32 
6 files   2 000 000 000 bytes ** should be 12 000 000 000 **
 17 331 192 064 bytes free

I haven't the time to modify dotted_num() to prevent omission of the most
significant digits, but the following patch is a quick fix for sizes up
to 10 TB - 1.

Best regards,
g.b.

--- mdir.c.old  2021-07-15 14:28:53.0 +0200
+++ mdir.c  2024-05-21 13:18:25.079157668 +0200
@@ -229,8 +229,8 @@
putchar(' ');
else
putchar('s');
-   printf("   %s bytes\n",
-  dotted_num(bytes, 13, ));
+   printf("   %s bytes\n",
+  dotted_num(bytes, 17, ));
if(s1)
free(s1);
}

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

Kernel: Linux 6.1.0-21-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash

Versions of packages mtools depends on:
ii  libc6  2.36-9+deb12u7

mtools recommends no packages.

Versions of packages mtools suggests:
pn  floppyd  

-- no debconf information

Bug#1071561: python-gnupg: DPT as package maintainer?

[Elena ``of Valhalla'']

On 2024-05-21 at 11:39:25 +0200, Timo Röhling wrote:
> I noticed that your package uses the so-called "weak team maintainer" model, 
> [...]
> Is this a deliberate decision or merely an artifact of some packaging helper 
> tool [...]

Thanks for looking into this.

It is a deliberate decision: this package is somewhat quirky and in
the past I've had to say no to suggestions that would have fixed some
issue, but caused problems elsewhere, so I'd prefer to keep the weak
team maintainer model (as long as it is in a wide-scope team).

Of course the typical team-wide changes are much welcome, but those
usually don't trigger a new upload.

This should be the only package I maintain that uses the weak team
maintainer model, all of the other ones should be already using the team
as the Maintainer (if they don't, *that* is an artifact of something,
and if I'll notice it I'll fix it)

-- 
Elena ``of Valhalla''


signature.asc
Description: PGP signature

Bug#1071570: ITP: nemo-qml-plugin-contacts -- QML module providing access to QtPIM QtContacts

[Mike Gabriel]

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

* Package name: nemo-qml-plugin-contacts
  Version : 0.3.28
  Upstream Contact: https://sailfishos.org/contact/
* URL : https://github.com/sailfishos/nemo-qml-plugin-contacts.git
* License : BSD-3-clause
  Programming Lang: C++
  Description : QML module providing access to QtPIM QtContacts

 This QML module provides a high-level abstraction layer on top of the QtPIM
 QtContacts API with some improvements such as a data cache, localisation and
 internationalization enablers, and other utility capabilities.
 .
 This package is part of Lomiri's addressbook app stack and will be
 maintained by the Debian UBports Packaging Team.

Bug#1065456: python3.11: Please don't enable dtrace on hurd

[Samuel Thibault]

Hello,

Pinging on this?

Samuel

Samuel Thibault, le lun. 04 mars 2024 23:59:15 +0100, a ecrit:
> python3.11 currently fails to build on hurd-any because debian/rules
> enables dtrace, which is not available on hurd-any.
> 
> Could you apply the attached patch that fixes this, on python3.11 as
> well as on python3.12?
> 
> Thanks,
> Samuel
--- debian/rules.orig   2024-03-03 10:23:40.0 +0100
+++ debian/rules2024-03-04 23:54:06.808627222 +0100
@@ -441,7 +441,6 @@
--with-computed-gotos \
--without-ensurepip \
--with-system-expat \
-   --with-dtrace \
--with-ssl-default-suites=openssl \
--with-wheel-pkg-dir=/usr/share/python-wheels/ \
--with-ssl-default-suites=openssl \
@@ -453,6 +452,10 @@
   common_configure_args += --with-system-ffi
 endif
 
+ifeq (,$(filter $(DEB_HOST_ARCH_OS), hurd))
+  common_configure_args += --with-dtrace
+endif
+
 ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
   common_configure_args += --host=$(DEB_HOST_GNU_TYPE) 
--build=$(DEB_BUILD_GNU_TYPE)
   common_configure_args += --with-build-python

Bug#1071569: llvmlite:FTBFS:compile failed(test: plugin distutils failed with: exit code=134)

[Yue Gui]

Source: llvmlite
Version: 0.42.0-1
Severity: important
Tags: FTBFS, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear llvmlite Maintainer,
The llvmlite compile failed on riscv64 caused by auto-test failed.The
crucial buildd log below:
```

test_global_ctors_dtors
(llvmlite.tests.test_binding.TestGlobalConstructors.test_global_ctors_dtors)
... WARNING: This target JIT is not designed for the host you are
running.  If bad things happen, please choose a different -march
switch.
LLVM ERROR: Unsupported code model for lowering
Aborted
E: pybuild pybuild:391: test: plugin distutils failed with: exit
code=134: cd /<>/.pybuild/cpython3_3.12_llvmlite/build;
python3.12 -m unittest discover -v
I: pybuild base:305: cd
/<>/.pybuild/cpython3_3.11_llvmlite/build; python3.11 -m
unittest discover -v
test_function_cfg_on_llvm_value
(llvmlite.tests.test_binding.TestAnalysis.test_function_cfg_on_llvm_value)
... ok
test_get_function_cfg_on_ir
(llvmlite.tests.test_binding.TestAnalysis.test_get_function_cfg_on_ir)
... ok
test_linux (llvmlite.tests.test_binding.TestDependencies.test_linux)
... skipped 'Distribution-specific test'
test_bad_library (llvmlite.tests.test_binding.TestDylib.test_bad_library) ... ok
test_libm (llvmlite.tests.test_binding.TestDylib.test_libm) ... ok
test_close (llvmlite.tests.test_binding.TestFunctionPassManager.test_close)
... ok
test_initfini 
(llvmlite.tests.test_binding.TestFunctionPassManager.test_initfini)
... ok
test_run (llvmlite.tests.test_binding.TestFunctionPassManager.test_run) ... ok
test_run_with_remarks
(llvmlite.tests.test_binding.TestFunctionPassManager.test_run_with_remarks)
... ok
test_run_with_remarks_filter_in
(llvmlite.tests.test_binding.TestFunctionPassManager.test_run_with_remarks_filter_in)
... ok
test_run_with_remarks_filter_out
(llvmlite.tests.test_binding.TestFunctionPassManager.test_run_with_remarks_filter_out)
... ok
test_add_module
(llvmlite.tests.test_binding.TestGlobalConstructors.test_add_module)
... WARNING: This target JIT is not designed for the host you are
running.  If bad things happen, please choose a different -march
switch.
ok
test_add_module_lifetime
(llvmlite.tests.test_binding.TestGlobalConstructors.test_add_module_lifetime)
... WARNING: This target JIT is not designed for the host you are
running.  If bad things happen, please choose a different -march
switch.
ok
test_add_module_lifetime2
(llvmlite.tests.test_binding.TestGlobalConstructors.test_add_module_lifetime2)
... WARNING: This target JIT is not designed for the host you are
running.  If bad things happen, please choose a different -march
switch.
ok
test_close (llvmlite.tests.test_binding.TestGlobalConstructors.test_close)
... WARNING: This target JIT is not designed for the host you are
running.  If bad things happen, please choose a different -march
switch.
ok
test_emit_assembly
(llvmlite.tests.test_binding.TestGlobalConstructors.test_emit_assembly)
Test TargetMachineRef.emit_assembly() ... WARNING: This target JIT is
not designed for the host you are running.  If bad things happen,
please choose a different -march switch.
ok
test_emit_object
(llvmlite.tests.test_binding.TestGlobalConstructors.test_emit_object)
Test TargetMachineRef.emit_object() ... WARNING: This target JIT is
not designed for the host you are running.  If bad things happen,
please choose a different -march switch.
ok
test_global_ctors_dtors
(llvmlite.tests.test_binding.TestGlobalConstructors.test_global_ctors_dtors)
... WARNING: This target JIT is not designed for the host you are
running.  If bad things happen, please choose a different -march
switch.
LLVM ERROR: Unsupported code model for lowering
Aborted
E: pybuild pybuild:391: test: plugin distutils failed with: exit
code=134: cd /<>/.pybuild/cpython3_3.11_llvmlite/build;
python3.11 -m unittest discover -v
rm -fr -- /tmp/dh-xdg-rundir-O9hmzrPM
dh_auto_test: error: pybuild --test -i python{version} -p "3.12 3.11"
returned exit code 13
make[1]: *** [debian/rules:19: override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:12: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned
exit status 2

```
The full buildd log is here:
https://buildd.debian.org/status/fetch.php?pkg=llvmlite=riscv64=0.42.0-1=1709707882=0

My solution to this issue:
This problem is similar to issue #917252, so I can modify the file
debian/rules to view the auto-test as success. I have test this
modification in local, and it work effectively.Please let me know
wheather this patch can be accepted. The patch is in the attachment.
Gui-Yue
Best Regards


fix_build_failure_on_riscv.patch
Description: Binary data

Bug#1061627: jpeg-xl: 0.8 failing autopkgtest

[Mathieu Malaterre]

Control: tags -1 upstream patch fixed-upstream
Control: forwarded -1 https://github.com/libjxl/libjxl/issues/2391

On Sat, Jan 27, 2024 at 4:51 PM Jeremy Bícha  wrote:
[...]
> Test - Lossless Roundtrip
> JPEG XL encoder v0.8.2 [AVX2,SSE4,SSSE3,SSE2]
> ./lib/extras/dec/color_hints.cc:54: No color_space/icc_pathname given,
> assuming sRGB
> Read 320x320 image, 1228816 bytes, 814.0 MP/s
> Encoding [Modular, lossless, effort: 7],
> ./lib/jxl/encode.cc:263: Only JXL_BIT_DEPTH_FROM_PIXEL_FORMAT is
> implemented for float types.

I'll incorporate the changes.

Bug#1059616: "wc -l" gives "illegal instruction"

[Marc Haber]

On Fri, Dec 29, 2023 at 03:38:32PM +, Pádraig Brady wrote:
> On 29/12/2023 09:52, gates.ocarina...@icloud.com wrote:
> > When I run command wc -l, it gives “illegal instruction”.

I can confirm this for at least one of my machines.

> https://github.com/coreutils/coreutils/commit/91a74d361.patch
> https://github.com/coreutils/coreutils/commit/7814596fa.patch

I can confirm that those two patches fix the issue for me on Debian
bookworm. They don't apply cleanly to the sources in bookworm, but the
result is still fine. I'll attach the new quilt patch file.

Since I am not using Debian's default kernel and the issue only happens
on one of my machines, I won't raise the severity, but if this also
happens with a Debian kernel, this would be an RC bug for me and warrant
a bookworm point release upload.

Greetings
Marc

--- a/configure.ac
+++ b/configure.ac
@@ -544,27 +544,6 @@ CFLAGS=$ac_save_CFLAGS
 LDFLAGS=$ac_save_LDFLAGS
 ac_c_werror_flag=$cu_save_c_werror_flag
 
-AC_MSG_CHECKING([if __get_cpuid available])
-AC_LINK_IFELSE(
-  [AC_LANG_SOURCE([[
-#include 
-
-int
-main (void)
-{
-  unsigned int eax, ebx, ecx, edx;
-  __get_cpuid (1, , , , );
-  return 1;
-}
-  ]])
-  ],[
-AC_MSG_RESULT([yes])
-AC_DEFINE([HAVE_CPUID], [1], [__get_cpuid available])
-cpuid_exists=yes
-  ],[
-AC_MSG_RESULT([no])
-  ])
-
 ac_save_CFLAGS=$CFLAGS
 CFLAGS="-mavx -mpclmul $CFLAGS"
 AC_MSG_CHECKING([if pclmul intrinsic exists])
@@ -628,23 +607,20 @@ AC_COMPILE_IFELSE(
 {
   __m256i a, b;
   a = _mm256_sad_epu8 (a, b);
-  return 1;
+  return __builtin_cpu_supports ("avx2");
 }
   ]])
   ],[
-AC_MSG_RESULT([yes])
-AC_DEFINE([HAVE_AVX2_INTRINSIC], [1], [avx2 intrinsics exists])
 avx2_intrinsic_exists=yes
   ],[
-AC_MSG_RESULT([no])
+avx2_intrinsic_exists=no
   ])
-if test "x$get_cpuid_count_exists" = "xyes" &&
-   test "x$avx2_intrinsic_exists" = "xyes"; then
+AC_MSG_RESULT([$avx2_intrinsic_exists])
+if test $avx2_intrinsic_exists = yes; then
   AC_DEFINE([USE_AVX2_WC_LINECOUNT], [1], [Counting lines with AVX2 enabled])
 fi
 AM_CONDITIONAL([USE_AVX2_WC_LINECOUNT],
-   [test "x$get_cpuid_count_exists" = "xyes" &&
-test "x$avx2_intrinsic_exists" = "xyes"])
+   [test $avx2_intrinsic_exists = yes])
 
 CFLAGS=$ac_save_CFLAGS
 
--- a/NEWS
+++ b/NEWS
@@ -42,6 +42,9 @@ GNU coreutils NEWS
   for B when A is a directory, possibly inflooping.
   [bug introduced in coreutils-6.3]
 
+  'wc -l' no longer crashes on x86 Linux kernels that disable XSAVE YMM.
+  [bug introduced in coreutils-9.0]
+
 ** Changes in behavior
 
   cat now uses the copy_file_range syscall if available, when doing
--- a/src/cksum.c
+++ b/src/cksum.c
@@ -159,29 +159,16 @@ static bool
 pclmul_supported (void)
 {
 # if USE_PCLMUL_CRC32
-  unsigned int eax = 0;
-  unsigned int ebx = 0;
-  unsigned int ecx = 0;
-  unsigned int edx = 0;
-
-  if (! __get_cpuid (1, , , , ))
-{
-  if (cksum_debug)
-error (0, 0, "%s", _("failed to get cpuid"));
-  return false;
-}
-
-  if (! (ecx & bit_PCLMUL) || ! (ecx & bit_AVX))
-{
-  if (cksum_debug)
-error (0, 0, "%s", _("pclmul support not detected"));
-  return false;
-}
+  bool pclmul_enabled = (0 < __builtin_cpu_supports ("pclmul")
+ && 0 < __builtin_cpu_supports ("avx"));
 
   if (cksum_debug)
-error (0, 0, "%s", _("using pclmul hardware support"));
+error (0, 0, "%s",
+   (pclmul_enabled
+? _("using pclmul hardware support")
+: _("pclmul support not detected")));
 
-  return true;
+  return pclmul_enabled;
 # else
   if (cksum_debug)
 error (0, 0, "%s", _("using generic hardware support"));
--- a/src/wc.c
+++ b/src/wc.c
@@ -132,52 +132,14 @@ static struct option const longopts[] =
 static bool
 avx2_supported (void)
 {
-  unsigned int eax = 0;
-  unsigned int ebx = 0;
-  unsigned int ecx = 0;
-  unsigned int edx = 0;
-  bool getcpuid_ok = false;
-  bool avx_enabled = false;
+  bool avx_enabled = 0 < __builtin_cpu_supports ("avx2");
 
-  if (__get_cpuid (1, , , , ))
-{
-  getcpuid_ok = true;
-  if (ecx & bit_OSXSAVE)
-avx_enabled = true;  /* Support is not disabled.  */
-}
+  if (debug)
+error (0, 0, (avx_enabled
+  ? _("using avx2 hardware support")
+  : _("avx2 support not detected")));
 
-
-  if (avx_enabled)
-{
-  eax = ebx = ecx = edx = 0;
-  if (! __get_cpuid_count (7, 0, , , , ))
-getcpuid_ok = false;
-  else
-{
-  if (! (ebx & bit_AVX2))
-avx_enabled = false;  /* Hardware doesn't support it.  */
-}
-}
-
-
-  if (! getcpuid_ok)
-{
-  if (debug)
-error (0, 0, "%s", _("failed to get cpuid"));
-  return false;
-}
-  else if (! avx_enabled)
-{
-  if (debug)
-error (0, 0, "%s", _("avx2 support not detected"));
-  return false;
-  

Bug#1071565: autopkgtest: ERROR: cloud-efi.raw is too small: 131 MB. Should be greater 890 MB

[Thomas Lange]

The problem was, that a package could not be downloaded:

833s fai.log:W: Couldn't download package libip4tc2 (ver 1.8.9-2 arch
amd64) at
http://deb.debian.org/debian/pool/main/i/iptables/libip4tc2_1.8.9-2_amd64.deb

Another test run passed without any errors. See 46897030
https://ci.debian.net/packages/f/fai/testing/amd64/

Does this solve your problem? Can we close this bug now?


-- 
 Thomas

Bug#1017558: boost1.74: diff for NMU version 1.74.0+ds1-21.1

[Pogirneata Elisei]

Control: tags 1017558 + patch

Control: tags 1017558 + pending


Dear maintainer,

I've prepared a patch for boost1.74 (versioned as 1.74.0+ds1-21.1) that should 
close 1017558.

The patch fixes a bug with copy_file when copying between devices or 
filesystems by using the fallback copy_write implementation.

This issue has been fixed with >boost1.77 but this patch should fix the issue 
for current version of boost without the need to actually upgrade.


Regards,

Elisei
diff -Nru boost1.74-1.74.0+ds1/debian/changelog boost1.74-1.74.0+ds1/debian/changelog
--- boost1.74-1.74.0+ds1/debian/changelog	2023-05-19 09:24:56.0 +0200
+++ boost1.74-1.74.0+ds1/debian/changelog	2024-05-21 09:36:57.0 +0200
@@ -1,3 +1,11 @@
+boost1.74 (1.74.0+ds1-21.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fixed copy_file to fallback on copy_write if copy_file_range/sendfile fails.
+(Closes: #1017558)
+
+ -- Elisei Pogirneata   Tue, 21 May 2024 09:36:57 +0200
+
 boost1.74 (1.74.0+ds1-21) unstable; urgency=medium
 
   [ Andreas Beckmann ]
diff -Nru boost1.74-1.74.0+ds1/debian/patches/fix_copy_file.patch boost1.74-1.74.0+ds1/debian/patches/fix_copy_file.patch
--- boost1.74-1.74.0+ds1/debian/patches/fix_copy_file.patch	1970-01-01 01:00:00.0 +0100
+++ boost1.74-1.74.0+ds1/debian/patches/fix_copy_file.patch	2024-05-21 09:36:57.0 +0200
@@ -0,0 +1,43 @@
+Index: boost1.74-1.74.0+ds1/libs/filesystem/src/operations.cpp
+===
+--- boost1.74-1.74.0+ds1.orig/libs/filesystem/src/operations.cpp
 boost1.74-1.74.0+ds1/libs/filesystem/src/operations.cpp
+@@ -446,6 +446,14 @@ int copy_file_data_sendfile(int infile,
+   int err = errno;
+   if (err == EINTR)
+ continue;
++
++  if (offset == 0)
++  {
++// Fallback to read_write implementations if sendfile fails
++if (err == EINVAL || err == ENOSYS)
++  return copy_file_data_read_write(infile, from_stat, outfile, to_stat);
++  }
++
+   return err;
+ }
+ 
+@@ -481,6 +489,23 @@ int copy_file_data_copy_file_range(int i
+   int err = errno;
+   if (err == EINTR)
+ continue;
++
++if (offset == 0)
++{
++  // Use fallback implementations if copy_range fails with any of the errors:
++  if (   err == EINVAL
++  || err == EOPNOTSUPP
++  || err == EXDEV
++  || err == ENOSYS)
++  {
++#if defined(BOOST_FILESYSTEM_USE_SENDFILE)
++return copy_file_data_sendfile(infile, from_stat, outfile, to_stat);
++#else
++return copy_file_data_read_write(infile, from_stat, outfile, to_stat);
++#endif
++  }
++}
++
+   return err;
+ }
+ 
diff -Nru boost1.74-1.74.0+ds1/debian/patches/series boost1.74-1.74.0+ds1/debian/patches/series
--- boost1.74-1.74.0+ds1/debian/patches/series	2023-05-19 09:22:57.0 +0200
+++ boost1.74-1.74.0+ds1/debian/patches/series	2024-05-21 09:36:57.0 +0200
@@ -27,3 +27,4 @@
 74a94fe7f47b2e3f707cf4589fbb635a50f22ad2.patch
 15.patch
 python-enum.patch
+fix_copy_file.patch

Bug#1071568: nvidia-kernel-dkms: module (from backports) fails to build with 5.10.216-1 (ABI 29 kernel) in Debian bullseye

[Salvatore Bonaccorso]

Package: nvidia-kernel-dkms
Version: 525.147.05-7~deb12u1~bpo11+2
Severity: serious
Justification: FTBFS
X-Debbugs-Cc: car...@debian.org

Hi Andreas,

This is only for the bullseye-backports version of
525.147.05-7~deb12u1~bpo11+2 when building for 5.10.216-1 (ABI 29
kernel).

The build fails with:

make -f /usr/src/linux-headers-5.10.0-29-common/scripts/Makefile.modpost
  sed 's/ko$/o/' /var/lib/dkms/nvidia-current/525.147.05/build/modules.order | 
scripts/mod/modpost -m-o /var/lib/d
kms/nvidia-current/525.147.05/build/Module.symvers -e -i Module.symvers   -T -
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 
'rcu_read_unlock_strict'
make[3]: *** 
[/usr/src/linux-headers-5.10.0-29-common/scripts/Makefile.modpost:123: 
/var/lib/dkms/nvidia-current/525.147.05/build/Module.symvers] Error 1
make[2]: *** [/usr/src/linux-headers-5.10.0-29-common/Makefile:1783: modules] 
Error 2
make[2]: Leaving directory '/usr/src/linux-headers-5.10.0-29-amd64'
make[1]: *** [Makefile:192: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.10.0-29-common'
make: *** [Makefile:82: modules] Error 2

Regards,
Salvatore


make.log.gz
Description: application/gzip

Bug#1071567: libssh: ISC license missing

[Bastian Germann]

Source: libssh
Version: 0.9.5-1
Severity: serious

src/external/bcrypt_pbkdf.c is licensed under the ISC license, which is missing 
from debian/copyright.

Bug#1064340: Re: Bug#1064340: Re: Bug#1064340: RFS: kylin-nm/4.0.0.0-1 -- Gui Applet tool for display and edit network simply

[handsome_feng]

Got it. We will update the changelog as well as other Debian files.


Thanks!








在2024年05月21 17时47分，"Tobias Frost"写道：

On Tue, May 21, 2024 at 05:15:09PM +0800, handsome_feng wrote:
> Hi,
> 
> 
> > The NMU has not been incorporated.
> Sorry, I didn't quite understand this point. Did someone request an NMU?
I stand correctred, it was not a NMU, but the changelog entry for 3.0.3.1-1 was 
not in d/changelog.

Bug#1071566: libssh2: d/copyright misses info

[Bastian Germann]

Source: libssh2
Version: 1.11.0-1
Severity: serious

src/bcrypt_pbkdf.c is licensed under ISC. The license and the copyright info is 
missing in d/copyright.
src/blowfish.c has "Copyright 1997 Niels Provos 
", which is also missing.

Bug#1070079: nghttp3: Update to 1.1.0 or newer

[Sakirnth Nagarasa]

Hello Samuel

On Sat, 11 May 2024 21:25:37 +0100 Samuel Henrique 
 wrote:> > > Would you be interested in any kind 
of help for this?

>
> Thanks, I will let you know this weekend. Probably in testing the
> rebuild of Wireshark with the new version of nghttp3.

Sounds good, just let me know.


I tested the rebuild Wireshark from unstable version 4.2.5-1 with 
libnghttp3-dev version 1.3.0-1 it worked for amd64. I have to test that 
for the other release architectures before I can ask for a transition 
slot. But I can continue work on it starting in June.


If you could do it before me, could you do that? I would appreciate it.

Thanks and Greetings
Saki

Bug#1071565: autopkgtest: ERROR: cloud-efi.raw is too small: 131 MB. Should be greater 890 MB

[Michael Tokarev]

Source: fai
Severity: normal

See for example:

 https://ci.debian.net/packages/f/fai/testing/amd64/46884830/

This one is currently holding qemu transition.

Thanks,

/mjt

Bug#1071538: Acknowledgement (janus-demos: please support some admin customization of settings.js)

[David Bremner]

David Bremner  writes:
>
> The naive thing to do is to symlink to a file in /etc; perhaps there
> is a smarter way to override settings.js? Otherwise it seems the only
> way to use the installed version is editing files in /usr
>

I did a quick proof-of-concept update at

  https://salsa.debian.org/bremner/janus

A simpler fix might be just to add definitions for token and apisecret
to settings.js

var token ="";
var apisecret="";

Bug#1071564: bookworm-pu: package aide/0.18.3-1+deb12u3

[Marc Haber]

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

This upload fixes #1070805. The reporter, Hannes, is upstream and a DD,
and thinks the issue warrants a stable update.

[ Reason ]
aide 0.18 has introduced some concurrency in processing. There is a bug
that makes fail to concurrently read extended attributes (xattrs) due to
variables shared between worker threads.

[ Impact ]
Incomplete aide checks

[ Tests ]
The fix is in productive use (in a git snapshot of HEAD) at upstream and
the Debian maintainer.

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

[ Changes ]
Upstream patch 732e7e2e
diff -Nru aide-0.18.3/debian/changelog aide-0.18.3/debian/changelog
--- aide-0.18.3/debian/changelog2023-07-01 14:37:51.0 +0200
+++ aide-0.18.3/debian/changelog2024-05-16 13:32:11.0 +0200
@@ -1,3 +1,10 @@
+aide (0.18.3-1+deb12u3) bookworm; urgency=medium
+
+  * Upstream patch to fix concurrent reading of extended
+attributes (xattrs) (Closes: #1070805)
+
+ -- Marc Haber   Thu, 16 May 2024 13:32:11 
+0200
+
 aide (0.18.3-1+deb12u2) bookworm; urgency=medium
 
   * Upstream patch to fix child directory processing on equal match
diff -Nru aide-0.18.3/debian/patches/debian-bug-1070805 
aide-0.18.3/debian/patches/debian-bug-1070805
--- aide-0.18.3/debian/patches/debian-bug-1070805   1970-01-01 
01:00:00.0 +0100
+++ aide-0.18.3/debian/patches/debian-bug-1070805   2024-05-16 
13:32:11.0 +0200
@@ -0,0 +1,47 @@
+Description: Fix concurrent reading of extended attributes (xattrs)
+Author: Hannes von Haugwitz 
+Origin: 732e7e2e7dc91bb614c508518c0abc6cab85565c
+Date: Mon May 16 13:30:00 2024 +0200
+Forwarded: not-needed
+--- a/src/do_md.c
 b/src/do_md.c
+@@ -478,14 +478,13 @@ static void xattr_add(xattrs_type *xattr
+ void xattrs2line(db_line *line) {
+ /* get all generic user xattrs. */
+ xattrs_type *xattrs = NULL;
+-static ssize_t xsz = 1024;
+-static char *xatrs = NULL;
+ ssize_t xret = -1;
+ 
+ if (!(ATTR(attr_xattrs)>attr))
+ return;
+ 
+-if (!xatrs) xatrs = checked_malloc(xsz);
++ssize_t xsz = 1024;
++char *xatrs = xatrs = checked_malloc(xsz);
+ 
+ while (((xret = llistxattr(line->fullpath, xatrs, xsz)) == -1) && (errno 
== ERANGE)) {
+ xsz <<= 1;
+@@ -498,10 +497,8 @@ void xattrs2line(db_line *line) {
+ log_msg(LOG_LEVEL_WARNING, "listxattrs failed for %s:%s", 
line->fullpath, strerror(errno));
+ } else if (xret) {
+ const char *attr = xatrs;
+-static ssize_t asz = 1024;
+-static char *val = NULL;
+-
+-if (!val) val = checked_malloc(asz);
++ssize_t asz = 1024;
++char *val = checked_malloc(asz);
+ 
+ xattrs = xattr_new();
+ 
+@@ -529,7 +526,9 @@ next_attr:
+ attr += len + 1;
+ xret -= len + 1;
+ }
++free(val);
+ }
++free(xatrs);
+ 
+ line->xattrs = xattrs;
+ }
diff -Nru aide-0.18.3/debian/patches/series aide-0.18.3/debian/patches/series
--- aide-0.18.3/debian/patches/series   2023-07-01 14:37:51.0 +0200
+++ aide-0.18.3/debian/patches/series   2024-05-16 13:32:11.0 +0200
@@ -1,3 +1,4 @@
 debian-bug-1039936
 debian-bug-1037436
 compare-logs
+debian-bug-1070805

Bug#1071161: glib2.0 2.66.8-1+deb11u4 flagged for acceptance

[Simon McVittie]

On Mon, 20 May 2024 at 20:12:24 +, Adam D Barratt wrote:
> The upload referenced by this bug report has been flagged for acceptance
> into the proposed-updates queue for Debian bullseye.
...
> Package: glib2.0
> Version: 2.66.8-1+deb11u4
> Explanation: fix a (rare) memory leak

Thanks for reviewing this change. Please consider also accepting #1071159
into bookworm-p-u (same change, different base version) to preserve the
property that bookworm has no regressions when compared with bullseye,
which I assume is something we want to be able to treat as an invariant.

smcv

Bug#1071563: emacs: Don't let test suite failures block the build

[Sean Whitton]

Source: emacs
Version: 1:29.3+1-3

Hello,

I propose that we make test suite failures non-fatal to the build.

The test suite has got quite flaky in recent years, and uploading Emacs
often requires issuing several giveback requests for random failures.

Patching individual tests to mark them as flaky does not scale.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1071246: libglib2.0-dev's python3 dependency alternative is posing challenges to cross building

[Simon McVittie]

On Mon, 20 May 2024 at 19:45:53 +0200, Helmut Grohne wrote:
> On Fri, May 17, 2024 at 10:42:11AM +0100, Simon McVittie wrote:
> > If someone with more time available for cross-development
> > implemented the cross-exe-wrapper design that I sketched in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030223#37, then
> > gobject-introspection and libglib2.0-dev would be able to migrate to
> > depending on
> > 
> > cross-exe-wrapper | can-run-arch,
> > python3:any,
> > 
> > or for backwards-compat maybe
> > 
> > cross-exe-wrapper | can-run-arch | qemu-user | qemu-user-static,
> > python3:any,
> > 
> > and I think this would also solve the problem?
> 
> I think this is technically unsolvable on the package relation level.
> The "can-run-arch" property that you suggest here cannot technically be
> expressed by a dependency relation, because the answer depends on things
> apt doesn't know.

Oh, what I had assumed was that in most cases where there was any doubt,
the cross-exe-wrapper would have to depend on and run qemu-user (at least
after a runtime check for whether it can get away with avoiding qemu). The
cases where cross-exe-wrapper relied on direct execution instead of
qemu or equivalent would be build=foo, host=foo for all values of foo,
plus probably build=amd64, host=i386 as a common special case.

I'd been thinking of can-run-arch as an extension point that a sysadmin
could set up with equivs (for example to represent the use-case you
described where qemu-user-static is set up with binfmt_misc outside the
chroot), rather than something that would exist in the archive; I'd assumed
that cross-exe-wrapper would be the automatic interface.

Thinking more about this, though, I think the cross-exe-wrapper itself
could have the same problem that you've described in libglib2.0-dev:
on build=amd64 and (let's say) host=riscv64, if we had something like

Package: libglib2.0-dev
Architecture: riscv64
Multi-Arch: same
Depends: cross-exe-wrapper | can-run

Package: cross-exe-wrapper
Architecture: riscv64
Multi-Arch: same
Depends: cross-exe-wrapper-riscv64-linux-gnu

Package: cross-exe-wrapper-riscv64-linux-gnu
Architecture: riscv64
Multi-Arch: ???# no? foreign? allowed?
# trivial wrapper, runs binary directly

Package: cross-exe-wrapper-riscv64-linux-gnu
Architecture: amd64
Multi-Arch: foreign
Depends: qemu-user
# non-trivial wrapper, runs via qemu

then I think it would be valid (but definitely undesired!) for
apt to satisfy cross-exe-wrapper's dependency by installing
cross-exe-wrapper-riscv64-linux-gnu:riscv64, which of course we would
be unable to run. So this is another place where ideally we would like
to be able to depend on "cross-exe-wrapper-riscv64-linux-gnu:runnable"
or some similar syntax that doesn't yet exist.

>  * We cross build from amd64 to x32, but the kernel does not enable the
>x32 abi.

It's common to do that (and I believe x32 is runtime-disabled on Debian
kernels by default to limit attack surface), so I would have assumed
we'd want to make cross-exe-wrapper pull in qemu-user when build=amd64,
host=x32; but if it can avoid actually needing to run it, with a runtime
check like the ones in the cross g-i tools, then so much the better.

>  * We cross build from amd64 to m68k and have externally installed
>qemu-user-static as we mostly care about speeding up builds rather
>than doing "pure" cross builds.

In this case it would be harmless to install qemu-user into the chroot
(a bit of a waste of I/O but no real harm), and it hardly matters whether
we use the host system's qemu or the chroot's, as long as all the necessary
tools are runnable.

>  * We cross build for i386 from amd64 and disable the i386 kernel ABI
>via seccomp-bpf to simulate a QA cross build.

My inclination would be to say that's too artificial to be something
that we'd be willing to pay a price to support (the price is #1070773),
but you know better than I do.

>  * Some arm64 CPUs can run arm32, but not all.

As with x32 on amd64, the wrapper would have to pessimistically assume
that we do need qemu-user (optionally with a runtime check to shortcut
to running the binary directly if we can).

smcv

Bug#1071473: transition: opencascade

[Tobias Frost]

now, there is also a patch for freecad (#1071283)

Bug#1071519: apt: "--solver 3.0" does not want to upgrade some packages

[Julian Andres Klode]

Control: retitle -1 --solver 3.0 fails to select candidate for -t, --mark-auto 
request

On Mon, May 20, 2024 at 02:37:29PM +0200, Gábor Gombás wrote:
> Package: apt
> Version: 2.9.3
> Severity: normal
> 
> Hi,
> 
> Well, it's alpha, but still - using "--solver 3.0", I cannot upgrade some 
> packages to the version in sid:
> 
> # apt policy iproute2
> iproute2:
>   Installed: 6.8.0-1
>   Candidate: 6.8.0-1
>   Version table:
>  6.9.0-1 102
> 102 http://ftp.hu.debian.org/debian sid/main amd64 Packages
> 102 http://ftp.at.debian.org/debian sid/main amd64 Packages
>  *** 6.8.0-1 103
> 103 http://ftp.hu.debian.org/debian trixie/main amd64 Packages
> 103 http://ftp.at.debian.org/debian trixie/main amd64 Packages
> 100 /var/lib/dpkg/status
>  6.1.0-3 990
> 990 http://ftp.hu.debian.org/debian bookworm/main amd64 Packages
> 990 http://ftp.at.debian.org/debian bookworm/main amd64 Packages
> # apt install -t unstable --mark-auto --solver 3.0 iproute2
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 56
> 
> Without "--solver 3.0", it works:
> 
> # apt install -t unstable --mark-auto iproute2
> Upgrading:  
>   iproute2
> 
> Summary:
>   Upgrading: 1, Installing: 0, Removing: 0, Not Upgrading: 55
>   Download size: 1,064 kB
>   Space needed: 4,096 B / 99.1 GB available
> 
> Get:1 http://ftp.hu.debian.org/debian sid/main amd64 iproute2 amd64 6.9.0-1 
> [1,064 kB]
> Fetched 1,064 kB in 0s (15.7 MB/s) 
> Reading changelogs... Done
> apt-listchanges: Do you want to continue? [Y/n] n
> apt-listchanges: Aborting

It's not quite clear to me what goes on there, but this may get lost in
translation between the old solver and the new one.

If you can do so, please use -o Dir::Log::Solver=
to specify a file to dump the solver request to, and then compress and
attach it to the bug report (it might need --solver internal if you
default to 3.0, I need to check and eventually fix solver logging for
3.0 still).

It is possible that this is one of the weird cases where it would crash
with -o Debug::APT::Solver=1 (as that enables more assertions). I'm
currently in the process of getting the test suite to work, adjusting
the tests that can work in the first step, to then have a solid base to
check for regressions when making further changes.

It could also be that the reason is the --mark-auto. This marks the
request to install that specific version as automatic presumably, and
you are in an install request, so the solver will first try to satsify
dependencies, where it will see the installed iproute2 as the preferred
option (since it's not upgrading, it minimizes upgrades), and then later
it will try to install the chosen iproute2 but it's not possible anymore
so it backtracks a level and just skips the request since it is
optional. I think this can be fixed however, that's a problem of
translating the selection state to the solver problem (i.e. this package
is marked auto now; but we actually have requested it manually so it
should be executed).

It also turns out we sometimes lose unsatisfiable items when
backtracking. We did not lose the item here presumably, otherwise
iproute2 would have been removed, but not sure.

In any case, attaching an EDSP file is best so we can reproduce it;
running with -o Debug::APT::Solver={1,2,3} (depending on how much output is
needed) could also give you a good insight to the point you can just
tell me.

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

Bug#1064340: Re: Bug#1064340: RFS: kylin-nm/4.0.0.0-1 -- Gui Applet tool for display and edit network simply

[Tobias Frost]

On Tue, May 21, 2024 at 05:15:09PM +0800, handsome_feng wrote:
> Hi,
> 
> 
> > The NMU has not been incorporated.
> Sorry, I didn't quite understand this point. Did someone request an NMU?
I stand correctred, it was not a NMU, but the changelog entry for 3.0.3.1-1 was 
not in d/changelog.

Bug#1071562: nfsd blocks indefinitely in nfsd4_destroy_session

[Martin Svec]

Package: nfs-kernel-server
Version: 1:2.6.2-4

Package: linux-image-6.1.0-21-amd64
Version: 6.1.90-1

During our tests of Proxmox VE with Debian NFS server as a shared storage we've 
noticed
that nfsd sometimes becomes unresponsive and it's necessary to reboot the 
server.

Probably the same error is reported here:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2062568

NFS server:
* DELL PowerEdge R730xd, 2x 10C XEON E5-2640, Samsung SM863 SSDs, 8 GB RAM
* fresh installation of Debian Bookworm
* Linux 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03) 
x86_64 GNU/Linux
* connected using 10GE link
* nfsd.conf configured with nthreads=16 (also tested with 8 and 4), other 
options left on defaults
* XFS mount exported with options: 
rw,sync,no_root_squash,no_subtree_check,no_wdelay

NFS client:
* DELL PowerEdge FC630, 2x 14C Xeon E5-2680 v4, 256 GB RAM
* fresh installation of Proxmox VE 8.2
* Proxmox Linux 6.8.4-3-pve kernel
* connected using 10GE link
* nfs client mount options: 
rw,noatime,nodiratime,vers=4.2,rsize=1048576,wsize=1048576,
  
namlen=255,hard,proto=tcp,nconnect=8,max_connect=16,timeo=600,retrans=2,sec=sys,
  clientaddr=10.xx.xx.xx,local_lock=none,addr=10.xx.xx.xx

Dmesg on nfsd server side (repeats forever):

[ 3142.693181] INFO: task nfsd:1035 blocked for more than 120 seconds.
[ 3142.693217]   Not tainted 6.1.0-21-amd64 #1 Debian 6.1.90-1
[ 3142.693239] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3142.693264] task:nfsdstate:D stack:0 pid:1035  ppid:2  
flags:0x4000
[ 3142.693273] Call Trace:
[ 3142.693275]  
[ 3142.693279]  __schedule+0x34d/0x9e0
[ 3142.693288]  schedule+0x5a/0xd0
[ 3142.693294]  schedule_timeout+0x118/0x150
[ 3142.693301]  wait_for_completion+0x86/0x160
[ 3142.693307]  __flush_workqueue+0x152/0x420
[ 3142.693317]  nfsd4_destroy_session+0x1b6/0x250 [nfsd]
[ 3142.693379]  nfsd4_proc_compound+0x355/0x660 [nfsd]
[ 3142.693433]  nfsd_dispatch+0x1a1/0x2b0 [nfsd]
[ 3142.693478]  svc_process_common+0x289/0x5e0 [sunrpc]
[ 3142.693551]  ? svc_recv+0x4e5/0x890 [sunrpc]
[ 3142.693631]  ? nfsd_svc+0x360/0x360 [nfsd]
[ 3142.693676]  ? nfsd_shutdown_threads+0x90/0x90 [nfsd]
[ 3142.693720]  svc_process+0xad/0x100 [sunrpc]
[ 3142.693790]  nfsd+0xd5/0x190 [nfsd]
[ 3142.693836]  kthread+0xda/0x100
[ 3142.693843]  ? kthread_complete_and_exit+0x20/0x20
[ 3142.693849]  ret_from_fork+0x22/0x30
[ 3142.693858]  

Dump of nfsd threads:

/proc/1032/stack:
[<0>] svc_recv+0x7f3/0x890 [sunrpc]
[<0>] nfsd+0xc3/0x190 [nfsd]
[<0>] kthread+0xda/0x100
[<0>] ret_from_fork+0x22/0x30

/proc/1033/stack:
[<0>] svc_recv+0x7f3/0x890 [sunrpc]
[<0>] nfsd+0xc3/0x190 [nfsd]
[<0>] kthread+0xda/0x100
[<0>] ret_from_fork+0x22/0x30

/proc/1034/stack:
[<0>] svc_recv+0x7f3/0x890 [sunrpc]
[<0>] nfsd+0xc3/0x190 [nfsd]
[<0>] kthread+0xda/0x100
[<0>] ret_from_fork+0x22/0x30

/proc/1035/stack:
[<0>] __flush_workqueue+0x152/0x420
[<0>] nfsd4_destroy_session+0x1b6/0x250 [nfsd]
[<0>] nfsd4_proc_compound+0x355/0x660 [nfsd]
[<0>] nfsd_dispatch+0x1a1/0x2b0 [nfsd]
[<0>] svc_process_common+0x289/0x5e0 [sunrpc]
[<0>] svc_process+0xad/0x100 [sunrpc]
[<0>] nfsd+0xd5/0x190 [nfsd]
[<0>] kthread+0xda/0x100
[<0>] ret_from_fork+0x22/0x30

/proc/130/stack:
[<0>] rpc_shutdown_client+0xf2/0x150 [sunrpc]
[<0>] nfsd4_process_cb_update+0x4c/0x270 [nfsd]
[<0>] nfsd4_run_cb_work+0x9f/0x150 [nfsd]
[<0>] process_one_work+0x1c7/0x380
[<0>] worker_thread+0x4d/0x380
[<0>] kthread+0xda/0x100
[<0>] ret_from_fork+0x22/0x30

On NFS client side, there's a number of backchannel reply errors:

[78636.676789] RPC: Could not send backchannel reply error: -110
[78647.905675] RPC: Could not send backchannel reply error: -110
[78675.207201] RPC: Could not send backchannel reply error: -110
[78744.201603] RPC: Could not send backchannel reply error: -110
[78784.138769] RPC: Could not send backchannel reply error: -110

We're able to reproduce this bug quite often (several times a day) when
restoring a 500GB virtual machine image from Proxmox Backup Server to
NFS shared storage. On the other hand, we cannot trigger it by other
ways like random and/or sequential I/O fio stress tests. According to
iostat, the VM restore job writes to NFS server in 300-400 MiB batches
separated by 3-4 secs of inactivity.

Interestingly, this issue probably occurs only when using a recent kernel
on NFS client side. We're able to hit this bug only with Proxmox Linux
6.8.4-3-pve kernel on NFS client side. When using Proxmox 6.5.13-5-pve
kernel there're no client-side backchannel reply errors and nfsd server
runs without any hungs. It seems to me that changes in NFS client code
between 6.5.x and 6.8.x accidentally uncovered a race in nfsd server code.

Based on the bug report #2062568 in Ubuntu I assume this is not
a Proxmox-specific issue but Proxmox VM restore workload together
with our testing hardware setup makes it easier to hit.

Regards,
Martin

Bug#1071561: python-gnupg: DPT as package maintainer?

[Timo Röhling]

Source: python-gnupg
Version: 0.5.2-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

I noticed that your package uses the so-called "weak team maintainer" model, 
where the Debian Python Team is listed as uploader instead of as maintainer.
According to Team Policy, that means that other team members must not upload 
your package at all without asking you first, even for trivial changes.

Is this a deliberate decision or merely an artifact of some packaging helper 
tool such as py2dsc, which generated the initial d/control that way? If it is 
the latter, would you be willing to switch Maintainer and Uploader and thereby 
further open up your package for (reasonable) team uploads?

Thank you for considering this. Feel free to close the bug and/or tag it 
wontfix if you do not wish to apply this change.


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZMa8kACgkQzIxr3RQD
9MoQGxAAyR5fW+Z43OtucHXoZH255Hz0UkQ+4GzyjtyejBLQdsbPwJKA/2Oq+Evd
LtcDuE8Lgv2cNnHozJiYkgJDiMLc3alit7wEoqwhgmOwb2e99CO7Fb5jHnGY6Td8
8/Zhla0ioSTims93tv8t+J3yRNh+rzXu2R61k0dSiy2WjM1xOoN+hcKGmFkz0mkF
61Jad4tPmcKRSRWy9tqEVlFAgWakqnH82A0bfT2UO47VkvsXNmQdVi15YBAHUwR6
t1GaIsTWtkFgfeokHSmWabPFRqPei8xNAo4GenEKJ/3cVq+0fmyGjHImOLwGNqWn
Di3qnu1Au0PWkQ+g0H+zzKni8QVqItuMqMiqybGpJ3VBGaHFvjH2ndDBYXcKew3p
yJT1cAPm17wOHXIt6P/AwKnyb74iNUbByX7muGpS4MnGX8IE8+klYnGTD7G1/DC5
Y73bO4FgvVSRWJ6LWeC+4PRLcHhLHcw05QVOWzXtAQ9gcnnl7hZBCo5npXLuRp7L
k++mxXdwoVzN/jGXfAJ28tPabQz3PeoABXau85mCVVcCz/wOITr8GFOUE7Dk7GGl
vSiv7lT7EsS6TU7Q8tZQZzEOrwHvpQfuOBZdhGoTpfj7TODOC7LLHgVGXvmY7Rai
8X5cfyblNM2wTZ5UZm+jP8V/YlV89uiMEzew3Q3dMYL/4c8dvfk=
=W3vP
-END PGP SIGNATURE-

Bug#1071560: undeclared runtime library depencencies

[Michael Tokarev]

Package: gpu-burn
Version: 0+git20240115+ds-2
Severity: grave

gpu-burn package links with libcuda.so.1 and libcublas.so.11 but does not
list them in Depends.  This results in a broken, entirely unusable package
after install:

 gpu-burn: error while loading shared libraries: libcuda.so.1:
   cannot open shared object file: No such file or directory

It looks like dh_shlibdeps step is missing in the packaging.
The fact gpu-burn does not depend on any packages at all also suggests
that - at the very least it should depend on libc6.

Also, this thing seems to be NVidia-specific (it doesn't work on an AMD
GPU), but it's nowhere mentioned in the package description.  Nvidia is
definitely NOT all the graphics world.

Thanks,

/mjt
--
gpu-burn depends on no packages.

Versions of packages gpu-burn recommends:
pn  nvidia-smi  

gpu-burn suggests no packages.

-- no debconf information

Bug#1064340: Re: Bug#1064340: RFS: kylin-nm/4.0.0.0-1 -- Gui Applet tool for display and edit network simply

[handsome_feng]

Hi,


> The NMU has not been incorporated.
Sorry, I didn't quite understand this point. Did someone request an NMU?


> There are undocumented changes. Some are very confusing.
>  - Why the move from github to gitlab?
>  - Why the uploaders change? Is this authorized?
>  -  Upstream Contact Changed from a team email to your mail?
Due to significant changes from version 3.0 to 4.0 and the repository 
migration, some changes on debian/ were not consistent with the old version and 
were not well documented. We will correct these issues.


> There is neither a response for #1070113, nor has it been adressed.
I  fixed the bug and uploaded it just now.




> (It seems also that all documents moved aways from English to Chinese?)
We will communicate with the author and add the English manual in the future.


Thanks!
handsome_feng

Bug#1071420: linux-image-6.8.9-1-amd64: cannot mount btrfs root partition

[Thorsten Leemhuis]

TWIMC, the problem systemd is facing due to the removal of a obsolete
option (that might or might not lead to the problem this bug is about)
was finally properly reported upstream now – and from the first reply is
sounds like a workaround is likely to be expected:

https://lore.kernel.org/all/ZkxZT0J-z0GYvfy8@gardel-login/

Bug#1071559: linux-headers-6.8.9-amd64: error creating r8125 module with dkms

[Diederik de Haas]

Control: reassign -1 r8125-dkms

On Tuesday, 21 May 2024 10:41:54 CEST Pierpaolo Toniolo wrote:
> Was installing the linux-image-6.8.9-amd64 and it's fellow linux-
> headers-6.8.9-headers.
> At modules creation with dkms I got an error building module r8125 (package
> r8125-dkms)

Which is a problem of r8125-dkms, thus reassigning

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