Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2

[Sebastian Andrzej Siewior]

On 2024-03-11 21:23:03 [+], Amin Bandali wrote:
> Hi,
Hi,

> On Mon, Mar 11, 2024 at 05:55:31PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2024-03-11 00:05:54 [+], Amin Bandali wrote:
> > > Hi Sebastian, all,
> > Hi,
> > 
> > > Will this fix be enough for addressing all cases, though?
> > 
> > I think so. Do you have a test case for me to check?
> 
> Not about pristine-xz specifically; I meant more in the context of
> other devel tools like gbp et al.

ah okay. pristine-tar was the only tool that had CI failures during the
upload of new xz-utils to exp. I wouldn't know other tools that require
to recreate the same binary file.

> > Who is handling the compression in the first place here?
> 
> In the case of "gbp import-orig --uscan", gbp invokes uscan, part of
> the devscripts package which has several perl modules including
> Devscripts::Compression which is a sort of a wrapper around dpkg's
> Dpkg::Compression, which will ultimately run the 'xz' executable.
> 
> In some other cases like "gbp import-orig --filter" mentioned by
> Andrey, gbp does the compression itself.  Which is why I suggested
> that 'Opts' in gbp.pkg.compressor may need to be updated to add '-T1'
> for calls to 'xz'.

okay. I wouldn't recomment doing -T1. This forces xz doing a single
block and using a signle thread. The default (without passing the -T
argument) will allow xz to use multiple threads and compress into
multiple blocks which in turn can be decompressed using multiple
threads.
Forcing -T1 will force single threaded compression and decompression.
pristine-tar can handle both cases.

> > The idea is to pass -T1 to xz if nothing was recorded in pristine-tar's
> > delta information. If the -T argument then everything keeps working
> > as-is. If you use gbp to repack the tar archive then I would recommend
> > to no pass -T1 and to use multi-threaded compression. pristine-tar
> > will recongnise this and record this information.
> 
> Sorry I don't think I fully understood this bit.  Could you please
> explain again, perhaps a bit more verbosely?

If you do "pristine-tar gendelta" then pristine tar creates a .delta
file which is tar.gz file containing a few files including the actual
delta from `xdelta' and a file called `wrapper'. The `wrapper' file is
also a tar.gz file including files regarding the invocation of the
compressing tool which includes the arguments required to produce the
exact output of the resulting .xz (from the tar input). Prior 1.50+nmu1
pristine-tar didn't record here the -T argument unless multi-threaded
compression was used and pristine-tar used -Tcpus and recorded this.
Since 1.50+nmu1 I made pristine-tar to always record the -T argument in
the wrapper file, either -Tcpus in the multi threaded case as it did or
by using -T1 in the single threaded one block case.
That means the reproduce case has always the fitting -T argument. If you
get an older archive which lacks the -T argument, pristine-tar will
assume -T1 which was the old default.

> To clarify, the use-cases described earlier involving gbp and
> devscripts aren't necessarily related to pristine-xz, used for
> regenerating pristine xz files; rather, about the generation or
> repacking of xz files *before* they are handed to pristine-xz for
> processing and storage in the repo.  I was trying to imply that
> similarly to how you sent patches for pristine-tar to adapt it for
> changes in xz-utils, that similar patches are probably also needed
> for gbp and devscripts.  Does that make sense?

So gbp and descripts should be able to deal with xz as-is since they
don't have any expectation in the resulting binary file. They are happy
once the input compressed/ decompressed. pristine-tar is the only tool,
to my best knowledge, that requires binary identical output. Therefore I
would keep gbp and devscripts as-is and prefer the multi-threaded
compression & decompression.
dpkg uses multi-threaded compression since a while and decompression
since Bookworm.

> Thanks,
> -amin

Sebastian

Bug#1066079: RFS: ddclient/3.11.2-1 -- address updating utility for dynamic DNS services

[Richard Hansen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : ddclient
   Version  : 3.11.2-1
   Upstream contact : https://github.com/ddclient/ddclient
 * URL  : https://ddclient.net
 * License  : GPL-2.0+, Artistic or GPL-1+, Apache-2.0
 * Vcs  : https://salsa.debian.org/debian/ddclient
   Section  : net

The source builds the following binary packages:

  ddclient - address updating utility for dynamic DNS services

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/ddclient/ddclient_3.11.2-1.dsc


Changes since the last upload:

 ddclient (3.11.2-1) unstable; urgency=medium
 .
   * Add curl build dependency to enable the -curl argument
   * Suggest curl
   * Bump Standards-Version to 4.6.2 (no changes needed)
   * gbp.conf: Rename branches and tags to match current convention
   * gbp.conf: Set upstream-vcs-tag (for import-orig)
   * New upstream version 3.11.2
   * Refresh patches
   * Update dependencies
   * Use dh_installchangelogs to install ChangeLog.md
   * debian/copyright: Set Upstream-Contact to project URL
   * debian/copyright: Update copyright year for debian/*

Regards,


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051487: This not a double dependency

[Georges Khaznadar]

Hello Fabian,

I tried once again to understand the sense of your bug report,
"python3-reportlab: depends on T1 and TTF fallback fonts at the same
time"

The code you saw in file debian/patches/dejavu-font-default.diff is not
meany something like: "if Vera.t1 does not exist, take Vera.ttf".
It rather means: if some Foo.t1 font cannot be found, for any reason, take
another surely existing font as a default.

Would it be better to pick something like the font C059-Roman.t1,
by default?

Best regards,   Georges.
-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1066080: nvidia-driver (525.147.05-10) does not build against kernel 6.6.15-amd64 on Debian Sid

[JON Tauri]

Package: nvidia-driver
Version: 525.147.05-10

An attempt to upgrade nvidia-driver to current version (have retried this
after a purge remove in an attempt to restart from a clean slate) fails. I
did not have any issues with the previous version of the driver in Sid
(don't know the old version number), so this is not a hardware problem
(lspci output is included) but a driver problem.

However, this is not the first time nvidia-driver has broken with Sid
(which is fine - it is called unstable for a reason), but it has been 5-6
days already since this happened, I am not seeing any movement on the
package tracker. I was hoping that someone had reported this showstopper
already and a fix was on the way.

Details (following https://www.debian.org/Bugs/Reporting suggestions) are
below:

$ sudo apt-get install nvidia-driver firmware-misc-nonfree
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
firmware-misc-nonfree is already the newest version (20230625-2).

...

The following additional packages will be installed:
 curl firmware-nvidia-gsp glx-alternative-mesa glx-alternative-nvidia
glx-diversions libcuda1 libcurl4t64 libegl-nvidia0 libgl1-nvidia-glvnd-glx
libgles-nvidia1 libgles-nvidia2 libgles1 libglx-nvidia0 libnss-mymachines
libnss-systemd libnvcuvid1 libnvidia-allocator1 libnvidia-cfg1
libnvidia-egl-gbm1 libnvidia-egl-wayland1 libnvidia-eglcore
libnvidia-encode1 libnvidia-glcore libnvidia-glvkspirv libnvidia-ml1
libnvidia-ptxjitcompiler1 libnvidia-rtcore libpam-systemd libpsl5t64
libssh2-1t64 libsystemd-shared libsystemd0 nvidia-alternative
nvidia-driver-bin nvidia-driver-libs nvidia-egl-common nvidia-egl-icd
nvidia-installer-cleanup nvidia-kernel-common nvidia-kernel-dkms
nvidia-kernel-support nvidia-legacy-check nvidia-modprobe
nvidia-persistenced nvidia-settings nvidia-smi nvidia-support
nvidia-suspend-common nvidia-vdpau-driver nvidia-vulkan-common
nvidia-vulkan-icd systemd systemd-container systemd-coredump
systemd-timesyncd update-glx xserver-xorg-video-nvidia
Suggested packages:
 nvidia-cuda-mps vulkan-tools systemd-homed systemd-userdbd systemd-boot
systemd-resolved libtss2-mu-4.0.1-0 libtss2-rc0
Recommended packages:
 libcuda1:i386 nvidia-driver-libs:i386
The following packages will be REMOVED:
 libcurl4 libpsl5 libssh2-1
The following NEW packages will be installed:
 firmware-nvidia-gsp glx-alternative-mesa glx-alternative-nvidia
glx-diversions libcuda1 libcurl4t64 libegl-nvidia0 libgl1-nvidia-glvnd-glx
libgles-nvidia1 libgles-nvidia2 libgles1 libglx-nvidia0 libnvcuvid1
libnvidia-allocator1 libnvidia-cfg1 libnvidia-egl-gbm1
libnvidia-egl-wayland1 libnvidia-eglcore libnvidia-encode1 libnvidia-glcore
libnvidia-glvkspirv libnvidia-ml1 libnvidia-ptxjitcompiler1
libnvidia-rtcore libpsl5t64 libssh2-1t64 nvidia-alternative nvidia-driver
nvidia-driver-bin nvidia-driver-libs nvidia-egl-common nvidia-egl-icd
nvidia-installer-cleanup nvidia-kernel-common nvidia-kernel-dkms
nvidia-kernel-support nvidia-legacy-check nvidia-modprobe
nvidia-persistenced nvidia-settings nvidia-smi nvidia-support
nvidia-suspend-common nvidia-vdpau-driver nvidia-vulkan-common
nvidia-vulkan-icd update-glx xserver-xorg-video-nvidia
The following packages will be upgraded:
 curl libnss-mymachines libnss-systemd libpam-systemd libsystemd-shared
libsystemd0 systemd systemd-container systemd-coredump systemd-timesyncd
10 upgraded, 48 newly installed, 3 to remove and 264 not upgraded.

...
...

Setting up nvidia-kernel-dkms (525.147.05-10) ...
Loading new nvidia-current-525.147.05 DKMS files...
Building for 6.6.15-amd64
Building initial module for 6.6.15-amd64
Error! Bad return status for module build on kernel: 6.6.15-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/525.147.05/build/make.log for more
information.
dpkg: error processing package nvidia-kernel-dkms (--configure):
installed nvidia-kernel-dkms package post-installation script subprocess
returned error exit status 10
dpkg: dependency problems prevent configuration of nvidia-driver:
nvidia-driver depends on nvidia-kernel-dkms (= 525.147.05-10) |
nvidia-kernel-525.147.05 | nvidia-open-kernel-525.1
47.05; however:
 Package nvidia-kernel-dkms is not configured yet.
 Package nvidia-kernel-525.147.05 is not installed.
 Package nvidia-kernel-dkms which provides nvidia-kernel-525.147.05 is not
configured yet.
 Package nvidia-open-kernel-525.147.05 is not installed.

dpkg: error processing package nvidia-driver (--configure):
dependency problems - leaving unconfigured
...

Contents of the make.log:
DKMS make.log for nvidia-current-525.147.05 for kernel 6.6.15-amd64
(x86_64)
Tue Mar 12 12:26:40 PM IST 2024
make KBUILD_OUTPUT=/lib/modules/6.6.15-amd64/build V=1 -C
/lib/modules/6.6.15-amd64/source M=/var/lib/dkms/nvidia-cu
rrent/525.147.05/build ARCH=x86_64
NV_KERNEL_SOURCES=/lib/modules/6.6.15-amd64/source
NV_KERNEL_OUTPUT=/lib/modules/
6.6.15-amd64/build NV_KERNEL_MODULES="nvidia nvidia-uvm nvidia-modeset
nvidia-drm nvidia-peermem" INS

Bug#1059991: grub-installer: build loong64.udeb for loongarch64

[zhangdandan]

Hi Adrian,
> I don't think this is true since the grub2 source is actually not 
building
> any loong64 packages yet. We will need to change the grub2 source 
first to
> build at packages such as grub-efi-loong64 and so on similar to 
riscv64 [1].

>
> After that, loong64 can be added to grub-installer as it was be done for
> riscv64 [2] (except for the case for "riscv64/*)").

Thanks for your heads up.
I have updated the patch (Add support for loongarch64).
Please consider the patch I have attached.
Your suggestions are always welcome.

Thanks,
Dandan Zhang


diff -Nru grub-installer-1.200/debian/control 
grub-installer-1.200/debian/control
--- grub-installer-1.200/debian/control 2024-02-16 18:45:32.0 +
+++ grub-installer-1.200/debian/control 2024-02-16 19:25:38.0 +
@@ -8,7 +8,7 @@
 Vcs-Git: https://salsa.debian.org/installer-team/grub-installer.git
 
 Package: grub-installer
-Architecture: amd64 arm64 armhf i386 ia64 hurd-i386 hurd-amd64 kfreebsd-i386 
kfreebsd-amd64 mipsel powerpc ppc64 ppc64el riscv64 sparc sparc64
+Architecture: amd64 arm64 armhf i386 ia64 hurd-i386 hurd-amd64 kfreebsd-i386 
kfreebsd-amd64 loong64 mipsel powerpc ppc64 ppc64el riscv64 sparc sparc64
 XB-Subarchitecture: ${subarch}
 Provides: bootable-system
 Depends: ${shlibs:Depends}, ${misc:Depends}, kernel-installer, created-fstab, 
di-utils, di-utils-mapdevfs, os-prober, partman-utils
diff -Nru grub-installer-1.200/debian/isinstallable 
grub-installer-1.200/debian/isinstallable
--- grub-installer-1.200/debian/isinstallable   2024-02-16 18:45:32.0 
+
+++ grub-installer-1.200/debian/isinstallable   2024-02-16 19:25:38.0 
+
@@ -33,6 +33,12 @@
log "GRUB is only usable on EFI riscv64 systems, not $ARCH"
exit 1
;;
+loong64/efi)
+   ;;
+loong64/*)
+   log "GRUB is only usable on EFI loong64 systems, not $ARCH"
+   exit 1
+   ;;
 esac
 
 db_get grub-installer/skip
diff -Nru grub-installer-1.200/grub-installer 
grub-installer-1.200/grub-installer
--- grub-installer-1.200/grub-installer 2024-02-16 18:45:33.0 +
+++ grub-installer-1.200/grub-installer 2024-02-16 19:25:38.0 +
@@ -354,6 +354,9 @@
 ia64/*)
grub_package="grub-efi-ia64"
;;
+loong64/efi)
+   grub_package="grub-efi-loong64"
+   ;;
 powerpc/*|ppc64/*)
grub_package="grub-ieee1275"
;;

Bug#1065214: NMU iproute2

[Helmut Grohne]

Control: tags -1 + pending

Hi Luca,

this bug causes issues to /usr-move. iproute2 pulls libtirpc3 and
nothing pulls libtirpc3t64. Hence, the we still include libtirpc3, which
is aliased rather than libtirpc3t64, which is /usr-moved. To fix this,
I'd need a binNMU of iproute2, but this bug would cause that binNMU to
be broken. Hence, I rather fix this bug.

I used reproducible builds to see that iproute2 really only uses tirpc
and not nsl. Hence I'm uploading the simple fix of explicitly depending
on libtirpc-dev. NMU diff attached. No delay in accordance with DevRef
(rc bug older than 7 days with no maintainer activity).

Helmut
diff -Nru iproute2-6.7.0/debian/changelog iproute2-6.7.0/debian/changelog
--- iproute2-6.7.0/debian/changelog 2024-01-22 13:24:29.0 +0100
+++ iproute2-6.7.0/debian/changelog 2024-03-12 09:03:30.0 +0100
@@ -1,3 +1,10 @@
+iproute2 (6.7.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Explicitly depend on libtirpc-dev. (Closes: #1065214)
+
+ -- Helmut Grohne   Tue, 12 Mar 2024 09:03:30 +0100
+
 iproute2 (6.7.0-2) unstable; urgency=medium
 
   * Backport fix for 'ss' output
diff -Nru iproute2-6.7.0/debian/control iproute2-6.7.0/debian/control
--- iproute2-6.7.0/debian/control   2024-01-12 22:09:28.0 +0100
+++ iproute2-6.7.0/debian/control   2024-03-12 09:02:10.0 +0100
@@ -22,6 +22,7 @@
libelf-dev,
libmnl-dev,
libselinux1-dev,
+   libtirpc-dev,
linux-libc-dev,
pkg-config,
po-debconf,

Bug#1065312: Re: Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Martin-Éric Racine]

On Sun, 10 Mar 2024 15:27:21 + Scott Kitterman  wrote:
>
>
> On March 10, 2024 3:23:32 PM UTC, "Martin-Éric Racine" 
>  wrote:
> >On Sat, 2 Mar 2024 18:40:13 +0100 Chris Hofstaedtler  wrote:
> >> * Christoph Biedl  [240302 17:02]:
> >> > Chris Hofstaedtler wrote...
> >> >
> >> > > please remove deborphan. It is stuck, featurewise, in a very old time
> >> > > and does not support many currently available dpkg features properly
> >> > > (multi-arch, versioned provides, etc).
> >> >
> >> > FWIW, deborphan is part of my regular workflow, and while you claim
> >> > it has defects, it works for me pretty well.
> >>
> >> It works "well" if you use it in very limited usecases, yes (like I
> >> did). It doesn't seem to work well for a lot of people using more of
> >> the "features" it has.
> >
> >Just because it doesn't work for everyone is not a remotely good
> >enough reason to ask for its removal. It works for most people. don't
> >break it for them.
> >
> >> The t64 transition will apparently make deborphan mostly useless in
> >> trixie.
> >>
> >> > [..]
> >> > So: What are the alternatives? How do they work? Are they a drop-in
> >> > replacment or do they introduce new dependencies? Are there feature that
> >> > will be no longer supported?
> >>
> >> release-notes recommends:
> >> https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#removing-non-debian-packages
> >
> >Which has nothing to do with what was asked.
> >
> >> Some people seem to recommend debfoster.
> >
> >Which really doesn't provide similar functionality.
> >
> >> > Leaving users in the void about this is just bad style.
> >
> >I totally agree. Not wanting to maintain it is a shitty reason for
> >asking for its removal. If you don't wanna maintain is, just orphan
> >it.
>
>
> It's really a maintainer call if that's appropriate.  So far no one has 
> jumped up to ask if they can take over the package.

Please. It's not like anyone was ever given the opportunity by
noticing a recently orphaned package or a blog post about it either.

Martin-Éric

Bug#1059991: grub-installer: build loong64.udeb for loongarch64

[John Paul Adrian Glaubitz]

Hi Dandan,

On Tue, 2024-03-12 at 16:07 +0800, zhangdandan wrote:
>  Thanks for your heads up.
>  I have updated the patch (Add support for loongarch64).
>  Please consider the patch I have attached.
>  Your suggestions are always welcome.

I already made the changes before you sent this mail, so we're all good.

See: 
https://salsa.debian.org/installer-team/grub-installer/-/commit/0962896894d83716dec19a60ba9db94fdc807a1c

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1055342: RFA: kas -- Setup tool for bitbake based projects

[MOESSBAUER, Felix]

Hi Bastian,

yesterday kas 4.3 was released. I just adapted the packaging and
uploaded it to mentors [1]. Please check:

[1] https://mentors.debian.net/package/kas/

Best regards,
Felix

-- 
Siemens AG, Technology
Linux Expert Center

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Martin-Éric Racine]

On Mon, 11 Mar 2024 15:18:44 +0100 Chris Hofstaedtler  wrote:
> On Sat, Mar 02, 2024 at 03:16:22PM +0100, Chris Hofstaedtler wrote:
> > Given the C codebase and lack of any patches so far I do not see that
> > deborphan will ever get these features, and we have other tools
> > available that work, do not mess with dpkg internals and are actually
> > maintained.
>
> As people have asked so nicely, and not at all demanding, entitled
> or otherwise bossy in this bug report, I've checked around a bit how
> APT provides deborphan's functionality today.
>
> As you all know, apt keeps track of when a package was installed
> manually or automatically. This is mostly equivalent to manually
> maintaining a deborphan keep file, but automated. apt-mark can be
> used to manipulate the manually-installed state.
>
> On top of that, apt-patterns(7) documents how to select packages,
> including on sections, installed status, manually-installed status.
> It can also used to select based on package names and regexes.
>
> Thus, a good approximation of the default deborphan functionality
> (no additional options passed) is:
>
> $ apt-mark auto '~i !~M (~slibs|~soldlibs|~slibdevel|~sintrospection|~sdebug)'
> possibly followed by
> $ apt autoremove
>
> If you're using --guess- or --guess-section with
> deborphan, you can copy the regex lists from deborphans source. A
> lot of them are however outdated and wrong, so you were already in
> "living dangerously" territory there.
>
> And that's it. deborphan does not do any magic and you can do all of
> it with apt.

Thanks for making the effort to investigate possible substitutes.

However, those are all approximations, not a direct substitute. All of
these methods essentially require whitelisting, blacklisting or
auto-marking packages for future processing. Meanwhile, deborphan
makes good guesses on the fly. Yes, its methods are kinda outdated,
its misses support for some of the recent dpkg bells and whistles, but
it still does a good enough job for most cases, as attested by its
popularity contest rating just below 10k.

Sorry, I really think that the correct action is to orphan the
package, not remove it.

Martin-Éric

Bug#1066081: ntpsec: ntpd reports error about missing /var/log/ntpsec

[Felix Moessbauer]

Package: ntpsec
Version: 1.2.3+dfsg1-1
Severity: normal

Dear Maintainer,

the ntpd reports the following error when starting:
statistics directory /var/log/ntpsec/ does not exist or is unwriteable, error 
No such file or directory

While the service seems to be able to start, this directory is never
created and logs / statistics are not written.

Attached is a patch that creates this directory. Note, that we need to
use tmpfiles.d as this directory is on /var.

Best regards,
Felix Moessbauer
Siemens AG

-- 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.5.0-0.deb12.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 ntpsec depends on:
ii  adduser3.134
ii  init-system-helpers1.65.2
ii  libbsd00.11.7-2
ii  libc6  2.36-9+deb12u4
ii  libcap21:2.66-4
ii  libssl33.0.11-1~deb12u2
ii  netbase6.4
ii  python33.11.2-1+b1
pn  python3-ntp
ii  sysvinit-utils [lsb-base]  3.06-4
ii  tzdata 2024a-0+deb12u1

Versions of packages ntpsec recommends:
ii  cron [cron-daemon]  3.0pl1-162
ii  systemd 252.22-1~deb12u1

Versions of packages ntpsec suggests:
ii  apparmor   3.0.8-3
pn  certbot
pn  ntpsec-doc 
pn  ntpsec-ntpviz  
>From f1b9ac43a726f2e99addb616964ec9ef6e3c3341 Mon Sep 17 00:00:00 2001
From: Felix Moessbauer 
Date: Tue, 12 Mar 2024 09:07:51 +0100
Subject: [PATCH 1/1] fix(debian): create ntpsec logdir on var

ntpd writes logs and statistics to this directory, but does not create
it. As this dir is on /var, we use tmpdirs.d to create it if not
existing.

Signed-off-by: Felix Moessbauer 
---
 debian/ntpsec.tmpfiles | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 debian/ntpsec.tmpfiles

diff --git a/debian/ntpsec.tmpfiles b/debian/ntpsec.tmpfiles
new file mode 100644
index 0..9a8fab6e0
--- /dev/null
+++ b/debian/ntpsec.tmpfiles
@@ -0,0 +1 @@
+d /var/log/ntpsec 0700 ntpsec ntpsec -
-- 
2.39.2

Bug#1059991: grub-installer: build loong64.udeb for loongarch64

[zhangdandan]

On Tue, 12 Mar 2024 09:20:40 +0100 John Paul Adrian Glaubitz wrote:
> Hi Dandan,
>
> On Tue, 2024-03-12 at 16:07 +0800, zhangdandan wrote:
> >  Thanks for your heads up.
> >  I have updated the patch (Add support for loongarch64).
> >  Please consider the patch I have attached.
> >  Your suggestions are always welcome.
>
> I already made the changes before you sent this mail, so we're all good.
>
> See: 
https://salsa.debian.org/installer-team/grub-installer/-/commit/0962896894d83716dec19a60ba9db94fdc807a1c

>

Thanks.

Dandan

Bug#1065395: spirv-llvm-translator-14: autopkgtest on s390x uses huge amount of disk space

[Andreas Beckmann]

Hi Paul,

On 06/03/2024 06.20, Paul Gevers wrote:

Unfortunately the test still takes upto 33 GB at least (see below).


Did you have time to test the -12 version, yet?


Andreas

Bug#1063754:

[james]

stop

Bug#1066082: python-cpuinfo: Add support for loongarch64

[zhangdandan]

Source: python-cpuinfo
Version: 9.0.0-1
Severity: wishlist
Tags: ftbfs
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the python-cpuinfo successed for loong64 in the Debian Package 
Auto-Building environment.

But python-cpuinfo source package lacks LoongArch architecture support.

- Background information is provided below.
When I analyzed why python3-pandas-lib:loong64 was blocking the build of 
29 source packages, I found that the compilation dependency 
(python3-tables-lib:loong64) of pandas was not satisfied.
The reason is that pytables compilation failed, please check the 
following error log,

```
..
File "/usr/lib/python3/dist-packages/cpuinfo/cpuinfo.py", line 366, in 
_check_arch

    raise Exception("py-cpuinfo currently only works on X86 "
Exception: py-cpuinfo currently only works on X86 and some 
ARM/PPC/S390X/MIPS/RISCV CPUs.

..
```
The full build log of pytables, please see 
https://buildd.debian.org/status/logs.php?pkg=pytables&ver=3.9.2-1&arch=loong64.

In short, the chain of dependencies is as follows,
python3-pandas-lib(src:pandas) ——> python3-tables-lib(src:pytables) ——> 
python3-cpuinfo(src:python-cpuinfo)
The result is that python-cpuinfo lacks LoongArch support, even though 
it is a package for the all architecture.


- The support for LoongArch was added to python-cpuinfo upstream in Nov. 
2022.
The upstream link for python-cpuinfo is 
https://github.com/workhorsy/py-cpuinfo.


The end, could you add LoongArch support in the next upload?
Your suggestions are welcome.

Thanks,
Dandan Zhang

Bug#1065724: epics-base: FTBFS on amd64: Tests failed

[PICCA Frederic-Emmanuel]

Here an analyse of the FTBFS

On the amd64, I have two failures dureing the test

Test Summary Report
---
testPVAServer.t(Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
Files=6, Tests=129,  1 wallclock secs ( 0.05 usr  0.01 sys +  0.09 cusr  0.06 
csys =  0.21 CPU)
Result: FAIL
---

and

Test Summary Report
---
testInetAddressUtils.t (Wstat: 0 Tests: 65 Failed: 0)
  TODO passed:   64
testChannelAccess.t   (Wstat: 0 Tests: 152 Failed: 0)
  TODO passed:   45
testServerContext.t   (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
Files=12, Tests=6381, 27 wallclock secs ( 0.38 usr  0.03 sys +  0.42 cusr  0.18 
csys =  1.01 CPU)
Result: FAIL
---

on arm64, the first test seems to work...

testPVAServer.t ..
1..1
pvAccess Server v7.1.7
Active configuration (w/ defaults)
EPICS_PVAS_INTF_ADDR_LIST = 0.0.0.0:5075
EPICS_PVAS_BEACON_ADDR_LIST =
EPICS_PVAS_AUTO_BEACON_ADDR_LIST = YES
EPICS_PVAS_BEACON_PERIOD = 15
EPICS_PVAS_BROADCAST_PORT = 5076
EPICS_PVAS_SERVER_PORT = 5075
EPICS_PVAS_PROVIDER_NAMES = local
ok  1 - ctx.get()!=0
ok

I am wondering if this is not something related to the network configuration.


i386

Test Summary Report
---
printfTest.t  (Wstat: 256 (exited 1) Tests: 97 Failed: 1)
  Failed test:  70
  Non-zero exit status: 1
Files=22, Tests=5033, 29 wallclock secs ( 0.42 usr  0.04 sys +  1.74 cusr  0.34 
csys =  2.54 CPU)
Result: FAIL
---

Test Summary Report
---
testInetAddressUtils.t (Wstat: 0 Tests: 65 Failed: 0)
  TODO passed:   64
testChannelAccess.t   (Wstat: 0 Tests: 152 Failed: 0)
  TODO passed:   45
testServerContext.t   (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
Files=12, Tests=6381, 26 wallclock secs ( 0.42 usr  0.02 sys +  0.46 cusr  0.20 
csys =  1.10 CPU)
Result: FAIL
---

Test Summary Report
---
testPVAServer.t(Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
Files=6, Tests=129,  0 wallclock secs ( 0.08 usr  0.02 sys +  0.10 cusr  0.04 
csys =  0.24 CPU)
Result: FAIL
---


And there is a bunch of unsupported architectures.

/<>/src/tools/EpicsHostArch.pl: Architecture 
'mips64el-linux-gnuabi64-thread-multi' not recognized

/<>/src/tools/EpicsHostArch.pl: Architecture 
'powerpc64le-linux-gnu-thread-multi' not recognized

/<>/src/tools/EpicsHostArch.pl: Architecture 
'riscv64-linux-gnu-thread-multi' not recognized

/<>/src/tools/EpicsHostArch.pl: Architecture 
's390x-linux-gnu-thread-multi' not recognized

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Miguel Angel Rojas]

Control: retitle -1 apt upgrade : it removes packages when it
shouldn't.

The case you mentioned is a tricky one, yes: *apt upgrade foo+ bar-* (I
really don't know how apt handles it internally but having this option is
very useful. Of course, I wouldn't remove it).

I think it makes a lot of sense for "apt upgrade" to allow packages as
arguments. There should be a possibility to upgrade only a set of packages
and it comes in handy in some situations (i.e.: t64 upgrade). "apt upgrade"
also doesn't mark upgraded packages as manually installed (as expected).
But "apt install" does mark them as manually installed (as expected too).

Therefore, I see 2 options here:

a) Change apt documentation to include the current behaviour. But if so, it
should *NOT* remove any packages.
b) Remove the possibility to specify packages to upgrade as arguments
(which I don't really recommend for the reasons stated above).

Anyway, I think some clarification is needed from the developers to shed
some light on this.

Regards

On Tue, Mar 12, 2024 at 3:12 AM Wesley Schwengle 
wrote:

> On Mon, Mar 11, 2024 at 11:32:24PM +0100, Miguel Angel Rojas wrote:
> > > I see. It looks like `apt upgrade ' behaves as `apt install
> > > '. Which (to me) is unexpected behaviour, as the man page is
> > quite
> > >clear on its behaviour (man 8 apt-get):
> >
> > Well, clearly it shouldn’t. To begin with, “apt install” should mark a
> > package as manual installed while “apt upgrade” shouldn’t (my
> assumption).
> > And you’re right that “apt install” can remove a package if needed to
> > satisfy dependencies.
> >
> > On top of that, documentation clearly states that “apt upgrade” should
> not
> > remove any package, but it does when you specify an individual package to
> > upgrade.
> >
> > If this is not the expected behavior, maybe this is a bug (unless I am
> > missing something here).
>
> I do not know what the bug here is, it could be one of these options:
>
> 1) apt-get/apt upgrade accepts packages to upgrade where the docs state it
>doesn't. The behaviour needs to change to not accept packages.
>
> 2) apt-get/apt upgrade accepts packages and removes packages to satisfy
> deps
>where the docs state it doesn't. The behaviour need to change to not
> remove
>any packages. There is a small edge case where you can say: `apt
> upgrade foo
>bar-'. Technically, it shouldn't remove packages, yet you want and
> instruct
>it to remove bar.
>
> FWIW, aptitude does not remove packages where you call `aptitude
> safe-upgrade
> foo'. It does remove packages when you call `aptitude full-upgrade foo'. It
> also removes bar when you run `aptitude safe-upgrade foo bar-'.
>
> I'll leave this for the maintainers to answer.
>
> Cheers,
> Wesley
>
>

Bug#1038447: librsvg: FTBFS on big-endian architectures: multiple test regressions since September 2022

[Simon McVittie]

Control: tags -1 + fixed-upstream
Control: block -1 by 1061616
Control: retitle 1061616 pixman: New upstream version 0.43.4

On Mon, 29 Jan 2024 at 10:23:45 +, Simon McVittie wrote:
> On Mon, 29 Jan 2024 at 05:13:59 +, Gayathri Berli wrote:
> > we found out that while
> > upgrading libpixman (libpixman-1-0:s390x) package from version 0.40.0-1 to
> > version 0.42.2-1, the test suites failed in the librsvg.
...
> > There is one open issues in pixman regarding to this commit changes which
> > effecting the big-endian systems.

I've been told in private email that
https://gitlab.freedesktop.org/pixman/pixman/-/issues/78 was fixed in the
recent pixman 0.43.4 release.

As noted in https://bugs.debian.org/1061616, pixman upstream has stopped
using the odd/even minor version convention (as seen in GLib, dbus,
Flatpak, SDL, etc.) and switched to a versioning scheme where odd and
even minor versions are interchangeable, so 0.43.x is a stable relase
series even though 0.41.x was not.

pixman maintainers: please upgrade to 0.43.4 when it will not disrupt
the ongoing 64-bit time_t transition.

Thanks,
smcv

Bug#1066083: gnome-maps: please make the build reproducible

[Chris Lamb]

Source: gnome-maps
Version: 46~beta-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
gnome-maps could not be built reproducibly.

This is because it embedded the current build date in an XML file:

│ │ │ │ ├── ./usr/share/metainfo/org.gnome.Maps.appdata.xml
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │ -
│ │ │ │ │ +

Patch attached that updates the Meson build file to use the
SOURCE_DATE_EPOCH environment variable if it exists.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   ` a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2024-03-12 10:25:05.728519725 
+
@@ -0,0 +1,20 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-03-12
+
+--- gnome-maps-46~beta.orig/data/meson.build
 gnome-maps-46~beta/data/meson.build
+@@ -39,7 +39,12 @@ install_data(
+ today = 'unknown'
+ date = find_program('date', required: false)
+ if date.found()
+-  r = run_command(date, '-I')
++  cmd = run_command('sh', '-c', 'echo $SOURCE_DATE_EPOCH')
++  source_date_epoch = cmd.stdout().strip()
++  if source_date_epoch == ''
++source_date_epoch = run_command(date, '+%s').stdout().strip()
++  endif
++  r = run_command(date, '-u', '-d', '@' + source_date_epoch, '-I')
+   if r.returncode() == 0
+ today = r.stdout().strip()
+   endif
--- a/debian/patches/series 2024-03-12 10:05:04.804812036 +
--- b/debian/patches/series 2024-03-12 10:25:04.932516349 +
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#1065831: apt upgrade : it removes packages when it shouldn't.

[Miguel Angel Rojas]

Control: retitle -1 apt upgrade : it removes packages when it shouldn't.

Bug#1066084: tox: please make the build reproducible

[Chris Lamb]

Source: tox
Version: 4.13.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
tox could not be built reproducibly.

This is because the build system cannot find ~/.config/tox/config.ini
and a warning message to this effect is included in the documentation:

│ │ │ ├── ./usr/share/doc/tox/html/cli_interface.html
│ │ │ │ @@ -705,15 +705,15 @@
│ │ │ │ -config file ‘/nonexistent/first-build/.config/tox/config.ini’ missing 
(change via env var TOX_USER_CONFIG_FILE)
│ │ │ │ +config file ‘/nonexistent/second-build/.config/tox/config.ini’ missing 
(change via env var TOX_USER_CONFIG_FILE)
│ │ │ │  

Patch attached that makes the build system uses the empty (but very
determinstistic!) /dev/null as the config file.

 [0] https://reproducible-builds.org/


Regards,

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

--- a/debian/rules  2024-03-12 10:05:10.540815841 +
--- b/debian/rules  2024-03-12 10:25:47.884699097 +
@@ -10,6 +10,8 @@
 # through the git tag, and in turn writing it to version.py.
 export SETUPTOOLS_SCM_PRETEND_VERSION = $(DEB_VERSION_UPSTREAM)
 
+export TOX_USER_CONFIG_FILE = /dev/null
+
 %:
dh $@ --buildsystem=pybuild
 

Bug#1066051: openjdk-8: make package usable on systems without t64 packages

[fabstz-it]

 Thanks for the information.


 Le lundi 11 mars 2024 à 21:52:54 UTC+1, Thorsten Glaser  a 
écrit :  
 
 close 1066051
thanks

Fab Stz dixit:

>I usually install openjdk-8 from unstable on bookworm.

This has never been officially supported. I’ve had an entire
discussion around that last month, which I will quote parts
from below, for context.

>However this is not possible anymore because now it depends on t64 packages.

Yes, this is to be expected.

>Would it be possible to still install it on systems without t64 by
>updating the dependencies/build-depends?

No.

But (see the background information below) I’ll be making available
openjdk-8 packages built for bookworm in the “wtf-lts” extrepo soon
(with the next upload, which will be done once the t64 transition
has settled, i.e. in some days) if you don’t mind an inofficial repo
(though operated by the same person who uploads the package to Debian
proper so…), although for amd64 and i386 only at the moment, as I lack
hardware to build for other platforms (tell me if you need that).

The RSS feed for the wtf extrepo will tell you when. You can obtain that
at http://www.mirbsd.org/~tg/Debs/NEWS.rss (s/\.rss// for plaintext).

Quotes, some paraphrased, follow. Cc’ing the relevant bug for archival
and public readability.



OpenJDK 8 is included with Debian 9 (stretch) only, although it has
been retrofitted to Debian 8 (jessie) for ELTS as it still is actively
maintained, in contrast to jessie’s OpenJDK 7.

Debian 10 and 11 shipped OpenJDK 11, due to misalignment between
Debian’s and OpenJDK-LTS’ release cycles.

> (why does #989736 to keep OpenJDK out of testing and stable exist?)

The reason behind it is that every Debian release contains exactly
one, and only one, supported OpenJDK version; the security team does
not have resources for more (unlike commercial distributions, nobody
is paid for their work).

OpenJDK 8 had already been dropped from Debian, but I’ve resurrected
it and took over maintenance. We still use it in Debian proper for:

• staging new releases for ELTS (ELTS is not part of Debian proper
  but an external offering, although basically done by the same people)

• bootstrapping new environments (like Kotlin) that depend on JDK 8
  for their bootstrapping process

This is all done in “unstable”; Kotlin was only able to enter “testing”
once it met the release goals for the “next-stable”, that is to build
with that then-future release’s default JDK.

> There are a number of applications still depending on Java 8.

Most of these should still run with 11 at least, even if they can
only be built on 8 or with special options (I wrote a Maven parent POM
that manages this).

I know of exceptions that use undocumented/inofficial interfaces that
are not actually part of the JDK’s API. For these, it’s really SOL…

I personally don’t have a problem with making OpenJDK 8 releases
available for other Debian releases; this is in fact how my involvement
in this started (I did it for a customer but also made the results
publicly available). If you don’t mind external repositories, you can
use the builds from there.

I recently stopped making builds for Debian 7 (wheezy) even if that
is technically still feasible, because it is no longer supported by
even ELTS.

Debian 8 and 9 are provided OpenJDK 8 by Freexian ELTS.

I produce builds for Debian 10 and 11, amd64 and i386 only (I lack
the machines to do more currently).

I don’t provide these packages for Debian 12 because I do not use
the latter and have no way to test them and can so save time.

Given incentive (a nice offer) I might add more to this mix.

I also provide OpenJDK 8 for all *buntu LTS releases that Canonical
allows Launchpad to build for, for all architectures the respective
releases have, via a PPA.

> (would be convenient to add openjdk-8 to stable)

Once a Debian stable is released, packages aren’t added to it any
more, barring special cases in LTS/ELTS releases like the aforementioned
switching jessie from OpenJDK 7 to 8, or they all getting newer kernels.

> (does the bugreport mean it will forever be blocked from making it to stable?)

Yes, it blocks OpenJDK 8 from ever reaching testing, and a new stable
is made by copying a frozen testing at the point in time where the
release gets made.

This is, indeed, the purpose of that debbugs item. The “Outlook” and
the first message should have made that clear. (The latter also said
to contact me so all is fine.)

This is the compromise that allowed OpenJDK 8 to be kept in Debian
at all, i.e. in Debian unstable; otherwise the security team would
have veto’d this. There is no way for OpenJDK 8 to be supported in
a stable Debian release any more.

That doesn’t mean I desupport this in the package itself. While I
don’t build for or test on wheezy or precise any more, these two
and anything newer, up to the latest respective releases, should
work, and I occasionally do thi

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Julian Andres Klode]

Control: retitle -1 document package specifiers for `upgrade`

On Mon, Mar 11, 2024 at 10:12:33PM -0400, Wesley Schwengle wrote:
> On Mon, Mar 11, 2024 at 11:32:24PM +0100, Miguel Angel Rojas wrote:
> > > I see. It looks like `apt upgrade ' behaves as `apt install
> > > '. Which (to me) is unexpected behaviour, as the man page is
> > quite
> > >clear on its behaviour (man 8 apt-get):
> > 
> > Well, clearly it shouldn’t. To begin with, “apt install” should mark a
> > package as manual installed while “apt upgrade” shouldn’t (my assumption).
> > And you’re right that “apt install” can remove a package if needed to
> > satisfy dependencies.
> > 
> > On top of that, documentation clearly states that “apt upgrade” should not
> > remove any package, but it does when you specify an individual package to
> > upgrade.
> > 
> > If this is not the expected behavior, maybe this is a bug (unless I am
> > missing something here).
> 
> I do not know what the bug here is, it could be one of these options:
> 
> 1) apt-get/apt upgrade accepts packages to upgrade where the docs state it
>doesn't. The behaviour needs to change to not accept packages.
> 
> 2) apt-get/apt upgrade accepts packages and removes packages to satisfy deps
>where the docs state it doesn't. The behaviour need to change to not remove
>any packages. There is a small edge case where you can say: `apt upgrade 
> foo
>bar-'. Technically, it shouldn't remove packages, yet you want and instruct
>it to remove bar.

The behavior is correct if potentially unexpected, but it should be
documented better.

> 
> FWIW, aptitude does not remove packages where you call `aptitude safe-upgrade
> foo'. It does remove packages when you call `aptitude full-upgrade foo'. It
> also removes bar when you run `aptitude safe-upgrade foo bar-'. 

That is an entirely different command; `aptitude safe-upgrade foo`
upgrades (only) `foo`, whereas `apt upgrade foo` first does the normal
install argument handling and then runs an upgrade, so `foo` could also
be a new package that is not currently installed to hint the solver if
it is unable to find a solution.

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

Bug#1066085: q2cli: please make the build reproducible

[Chris Lamb]

Source: q2cli
Version: 2024.2.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
q2cli could not be built reproducibly.

This is because it ships nondeterminstic "parsl.log" files in the
binary package installed by the package's Python build system. A
patch is attached that deletes these files prior to creating the
.deb.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2024-03-12 10:05:22.980824959 +
--- b/debian/rules  2024-03-12 10:34:47.399635439 +
@@ -21,6 +21,7 @@
mkdir -p debian/$(DEB_SOURCE)/usr/share/bash-completion/completions
mv debian/$(DEB_SOURCE)/usr/bin/tab-qiime 
debian/$(DEB_SOURCE)/usr/share/bash-completion/completions/qiime
chmod -x 
debian/$(DEB_SOURCE)/usr/share/bash-completion/completions/qiime
+   find debian/$(DEB_SOURCE) -type f -name parsl.log -delete
 
 debian/control: debian/control.in
echo "# This file is autogenerated from control.in to update versioned 
dependencies" > $@

Bug#1065134: Packaging of pahole

[Domenico Andreoli]

Somehow this email did not reach the destinations, trying once more...

On Tue, Mar 05, 2024 at 06:04:37PM +0100, Domenico Andreoli wrote:
> Hi,
> 
>   I'm eventually acknowledging that I'm poorly suited as maintainer
> of the dwarves package. I don't follow its development and don't use
> it either.
> 
> Thomas as well is asking to be removed from the uploaders, pending
> signed request. [0]
> 
> Before opening an RFA, is this team interested in taking over the
> maintenance? I think it's mostly used by the kernel build, I'm not
> aware of any other users.
> 
> Regards,
> Domenico
> 
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065134#15

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05


signature.asc
Description: PGP signature

Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

[Vincent Lefevre]

The same problem occurred on another machine, with other packages:

dpkg: dependency problems prevent removal of libjte2:amd64:
 libisofs6t64:amd64 depends on libjte2.

dpkg: error processing package libjte2:amd64 (--purge):
 dependency problems - not removing
(Reading database ... 708510 files and directories currently installed.)
Purging configuration files for libts0:amd64 (1.22-1+b1) ...
dpkg: dependency problems prevent removal of libid3tag0:amd64:
 libimlib2t64:amd64 depends on libid3tag0 (>= 0.15.1b).

dpkg: error processing package libid3tag0:amd64 (--purge):
 dependency problems - not removing
Errors were encountered while processing:
 libjte2:amd64
 libid3tag0:amd64

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

Bug#1066049: stunnel4: please consider temporarily disabling tests on arm to unblock the t64 transition

[Simon McVittie]

On Mon, 11 Mar 2024 at 20:09:06 +, Simon McVittie wrote:
> Thanks for proposing this, but I think these should be ifneq instead
> of ifeq

Actually, this patch also still allowed dh_auto_test to run on the
time64-affected architectures, which would presumably fail because the
tests' dependencies weren't met.

I attach a tested patch based on Mattia's, also available from
. This seems
to have the desired results:

* amd64: tests are run, and pass; autopkgtests also pass
* i386: tests are run, and pass; autopkgtests still in progress at the
  time of writing
* armhf on a porterbox: tests are not run, package is buildable without
  having to wait for python3-cryptography

armhf and other affected architectures will still be tested via autopkgtest
after python3-cryptography becomes available.

I think this change might be a pragmatic way to shorten the critical
path for the time64 transition. Please consider applying it?

Thanks,
smcv
>From 93d5d5d18d916d7fda9dcd0298019f9e1c887133 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 12 Mar 2024 10:26:49 +
Subject: [PATCH 1/2] Don't run build-time tests on the 32-bit non-i386
 architectures

This allows libcurl to be rebuilt on the architectures affected by the
64-bit time_t transition, which unblocks rebuilding of a lot of the
C/C++ ecosystem without having to wait for rustc/cargo to be
re-bootstrapped (#1065787).

Closes: #1066049
Co-authored-by: Mattia Rizzolo 
Signed-off-by: Simon McVittie 
---
 debian/control | 10 +-
 debian/rules   |  5 +
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/debian/control b/debian/control
index f32dc6f..f34acbd 100644
--- a/debian/control
+++ b/debian/control
@@ -10,13 +10,13 @@ Build-Depends:
  libssl-dev,
  libsystemd-dev [linux-any],
  libwrap0-dev,
- net-tools ,
- netcat-openbsd ,
+ net-tools [!armel !armhf !hppa !m68k !powerpc !sh4] ,
+ netcat-openbsd [!armel !armhf !hppa !m68k !powerpc !sh4] ,
  openssl,
  pkgconf,
- procps ,
- python3 ,
- python3-cryptography ,
+ procps [!armel !armhf !hppa !m68k !powerpc !sh4] ,
+ python3 [!armel !armhf !hppa !m68k !powerpc !sh4] ,
+ python3-cryptography [!armel !armhf !hppa !m68k !powerpc !sh4] ,
 Maintainer: Peter Pentchev 
 Uploaders: Laszlo Boszormenyi (GCS) 
 Standards-Version: 4.6.2
diff --git a/debian/rules b/debian/rules
index 8801c88..d022647 100755
--- a/debian/rules
+++ b/debian/rules
@@ -30,6 +30,10 @@ override_dh_auto_configure:
 	sleep 1
 	touch src/dhparam.c
 
+ifeq ($(DEB_HOST_ARCH_BITS)$(filter i386,$(DEB_HOST_ARCH_CPU)),32)
+override_dh_auto_test:
+	: # Tests temporarily skipped for 64-bit time_t transition
+else
 execute_before_dh_auto_test:
 	env PYTHONPATH='$(CURDIR)/debian/tests/python' \
 		python3 -B -u -m struntime \
@@ -42,6 +46,7 @@ override_dh_auto_test:
 		find tests/logs/ -type f -name '*.log' -exec grep -EHe '^' -- '{}' + 1>&2; \
 		false; \
 	}
+endif
 
 override_dh_auto_install:
 	dh_auto_install -- -C src
-- 
2.43.0

>From ca30697de1fd1f034947dff786cca0f897fc2f03 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 12 Mar 2024 10:29:26 +
Subject: [PATCH 2/2] Update changelog

---
 debian/changelog | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 9f9ff57..90f0a3b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+stunnel4 (3:5.72-1.1) UNRELEASED; urgency=medium
+
+  * Don't run build-time tests on the 32-bit non-i386 architectures.
+This allows libcurl to be rebuilt on the architectures affected by the
+64-bit time_t transition, which unblocks rebuilding of a lot of the
+C/C++ ecosystem without having to wait for rustc/cargo to be
+re-bootstrapped (#1065787).
+Thanks to Mattia Rizzolo (Closes: #1066049)
+
+ -- Simon McVittie   Tue, 12 Mar 2024 10:28:55 +
+
 stunnel4 (3:5.72-1) unstable; urgency=medium
 
   * Minor improvements to the test suite for the autopkgtest suite:
-- 
2.43.0

Bug#1036884: transition: time64_t

[Simon McVittie]

Control: block -1 by 1065787 1066049

One dependency chain that is blocking a lot of rebuilds right now is
this one:

... => curl -> stunnel4 -> python-cryptography => cargo => ...

key: => mandatory dependency
 -> nocheck dependency

In the medium term, cargo needs re-bootstrapping on the affected
architectures (armel and armhf, plus a bunch of -ports architectures
where as far as I can see cargo was never available in the past) -
that's #1065787, and Steve already replied to that bug describing how
Ubuntu did this. Is there a porter who can take responsibility for that?

In the shorter term, I think it might be pragmatic to build either curl
or stunnel4 with tests disabled on the affected architectures, breaking
that dependency chain and allowing most C/C++ packages that are being held
up by curl to be rebuilt in parallel.

I think disabling tests in stunnel4 would have less impact on the rest
of Debian than disabling tests in curl if it results in an undetected
regression, so I'd suggest stunnel4 as the place to break that chain. I've
sent a proposed patch to #1066049.

On IRC, Michael Biebl suggested an alternative plan of configuring the
armel|armhf buildds to always build with the nocheck profile for the
duration of the transition (and presumably keep track of the affected
packages to be rebuilt with build-time tests afterwards), but as far as
I know that's not possible in our infrastructure?

Thanks,
smcv

Bug#1050125: [solved?] gnus: cannot read signature from fifo

[Kamil Jońca]

With
ii  emacs-lucid 1:29.2+1-2+b1  amd64GNU Emacs editor 
(with Lucid GUI support)
it seems to work correctly again, so I think we can close this.
KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/
Premature optimization is the root of all evil.
-- D. E. Knuth

Bug#1066083: gnome-maps: please make the build reproducible

[James Addison]

Source: gnome-maps
Followup-For: Bug #1066083
X-Debbugs-Cc: la...@debian.org

Please note: for some other GNOME appdata.xml files, upstream has preferred to
remove dynamic Meson release @date values entirely, which also achieves
reproducibility; that approach might be simpler and perhaps more aligned with
upstream.

Ref: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4077

Bug#1066076: Current loglevel in system.conf is too verbose by default

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Mon, 11 Mar 2024 23:58:34 -0400 Neal  wrote:
> Package: systemd
> Version: 255.4-1
> Severity: minor
> File: /etc/systemd/system.conf
> X-Debbugs-Cc: tombrown9...@gmail.com
> 
> Dear Maintainer,
> 
> Current kernel message verbosity during Debian boot significantly
hampers the
> ability to identify critical system alerts, with important messages
quickly
> lost in the noise. This situation presents challenges for both new
and
> experienced users; newcomers may find the volume of information
daunting and
> misinterpret its importance, while seasoned users may struggle to
quickly
> pinpoint vital warnings or errors. To address these concerns, it is
proposed
> that the default kernel log level be set to "Warning." This
adjustment will
> streamline the boot process, making critical messages more visible
and less
> likely to be overlooked. Such a change not only aids in diagnosing
and
> troubleshooting by highlighting essential alerts but also enhances
the boot
> experience for all users by focusing on the most pertinent
information.

The standard default is info so that there is a reasonable amount of
information included in bug reports.

It's just a default, and you can trivially override it on your machines
as you see fit if it doesn't work for you.

-- 
Kind regards,
Luca Boccassi


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

Bug#1065424: [Pkg-openssl-devel] Bug#1065424: Bug#1065424: Can't connect to Active Directory with openssl

[Maciej Bogucki]

Sebastian,

Thank You for You help. I added "-cipher DEFAULT:@SECLEVEL=0" and this 
resolved the case. 🙂


Pozdrawiam serdecznie
Maciej Bogucki

On 11.03.2024 18:23, Sebastian Andrzej Siewior wrote:

On 2024-03-11 13:29:10 [+0100], Maciej Bogucki wrote:

Hi,

Hi,


When I use stiati compiled openssl form different system I can have the
connection

root@nsd-sdproxy1:~# /tmp/openssl version
OpenSSL 1.0.1t  3 May 2016

that is stone age.


root@nsd-sdproxy1:~# /tmp/openssl  s_client -connect 192.168.92.95:636
-CAfile /etc/ssl/certs/ca-certificates.crt

What happens if you add
-cipher DEFAULT:@SECLEVEL=0


On teh remote side is Windows 2008 with Active Directory over SSL/TLS.

My condolences. If you can, get rid of it. It will haunt you!


Pozdrawiam serdecznie
Maciej Bogucki

Sebastian

Bug#1060318: Info received (silx: autopkgtest failure with Python 3.12)

[Andreas Beckmann]

On Sun, 10 Mar 2024 15:21:34 +0100 (CET) PICCA Frederic-Emmanuel 
 wrote:

Here a small script which trigger the error

Thanks. Works for me in a minimal sid chroot:

# apt-get install python3-silx
# python3 test.py
python3: ./lib/llvmopencl/Kernel.cc:129: pocl::ParallelRegion* 
pocl::Kernel::createParallelRegionBefore(llvm::BasicBlock*): Assertion 
`region_entry_barrier != NULL' failed.
Aborted

At least the assertion has been there from the beginning (0.9, first
Debian packaged version was 0.10-1).

With

export POCL_CACHE_DIR=$(mktemp -d -p $(pwd))
export POCL_LEAVE_KERNEL_COMPILER_TEMP_FILES=1

I could extract the failing .cl file
After installing libpocl-dev I could reproduce the failure on sid

sid# poclcc 1060318.cl
poclcc: ./lib/llvmopencl/Kernel.cc:129: pocl::ParallelRegion* 
pocl::Kernel::createParallelRegionBefore(llvm::BasicBlock*): Assertion 
`region_entry_barrier != NULL' failed.
Aborted

sid# POCL_WORK_GROUP_METHOD=cbs poclcc 1060318.cl
[SubCFG] Form SubCFGs in bsort_all
[SubCFG] Form SubCFGs in bsort_horizontal
[SubCFG] Form SubCFGs in bsort_vertical
[SubCFG] Form SubCFGs in bsort_book
[SubCFG] Form SubCFGs in bsort_file
[SubCFG] Form SubCFGs in medfilt2d
sid # ls -la 1060318.cl*
-rw-r--r-- 1 root root  48015 Mar 12 11:00 1060318.cl
-rw-r--r-- 1 root root 404138 Mar 12 11:18 1060318.cl.pocl

but not on bookworm:

bookworm# poclcc 1060318.cl
bookworm# ls -la 1060318.cl*
-rw-r--r-- 1 1001 1001  48015 Mar 12 11:08 1060318.cl
-rw-r--r-- 1 root root 971490 Mar 12 11:13 1060318.cl.pocl

Andreas

1060318.cl.xz
Description: application/xz

Bug#1063374: RFP: HTMX - high power tools for HTML

[Trent W. Buck]

Hi, attached is my first draft of packaging htmx.
I don't know js packaging at all, so I kinda guessed.


https://github.com/cyberitsolutions/bootstrap2020/tree/twb/debian-12-PrisonPC.packages/node-htmx.org/debian

Known issues:

  * Have to build with DEB_BUILD_OPTIONS=nocheck, because
some test-time dependencies are missing (not in Debian at all)!

  * puts files in /usr/share/nodejs, but
apache2 expects /usr/share/javascript!

  * creates a .min.js for the main file, but
not any of the auxiliary files!
(I think this is an upstream bug?)

  * in the 2.0.0~alpha1 package,
all the auxiliary files are completely missing!

  * Makes a connection to registry.npmjs.org during build.
I don't know why.  The attacker's command was:

perl -MDebian::PkgJs::SimpleAudit -e print advisories(".")

  * The upstream source tarball is 20MB, that seems *way* too big.
(Update: it seems most of this is the embedded copy of https://htmx.org 
website.)

Lintian complains about a bunch of embedded copies, too:

E: node-htmx.org source: source-is-missing 
[test/lib/handlebars-v4.7.6.js]
E: node-htmx.org source: source-is-missing [test/lib/morphdom-umd.js]
E: node-htmx.org source: source-is-missing 
[www/static/node_modules/chai/chai.js]
E: node-htmx.org source: source-is-missing 
[www/static/node_modules/mocha/mocha.js]
E: node-htmx.org source: source-is-missing 
[www/static/node_modules/sinon/pkg/sinon.js]
E: node-htmx.org source: source-is-missing 
[www/static/test/lib/handlebars-v4.7.6.js]
E: node-htmx.org source: source-is-missing 
[www/static/test/lib/morphdom-umd.js]
E: node-htmx.org source: source-is-missing 
[www/themes/htmx-theme/static/js/_hyperscript.js]


On Wed 07 Feb 2024 10:15:32 +0530, Joseph Nuthalapati wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: libjs-htmx
>   Version : 1.9.10
>   Upstream Authors : Big Sky Software
> * URL : https://github.com/bigskysoftware/htmx
> * License : 0BSD
>   Programming Lang: JavaScript
>   Description : A JavaScript library to enhance the features of HTML
> 
> HTML has only two elements that communicate with the server -  and .
> HTMX allows all elements to send AJAX requests to the server. It also allows 
> DOM
> manipulation by replacing HTML elements with the response from the server. 
> This
> can significantly enhance the user experience of traditional multi-page web
> applications.
> .
> htmx allows you to access AJAX, CSS Transitions, WebSockets and Server Sent
> Events directly in HTML, using attributes, so you can build modern user
> interfaces with the simplicity and power of hypertext.
> .
> htmx has no runtime dependencies. It can be used by web applications written 
> in
> any programming language. The license is Zero-Clause BSD.


node-htmx.org_1.9.10-0PrisonPC1.debian.tar.xz
Description: application/xz

Bug#1066003: libberkeleydb-perl: FTBFS on arm{el,hf}: Failed 1/35 test programs. 1/1861 subtests failed.

[Graham Inggs]

I think the actual error is:

# : BDB4015 library build did not include support for sequences

# Failed test (t/sequence.t at line 33)
# The object isn't defined
Can't call method "set_cachesize" on an undefined value at t/sequence.t line 35.
# Looks like you planned 13 tests but only ran 3.
# Looks like your test died just after 3.
t/sequence.t ...
1..13
ok 1
ok 2 - The object isa BerkeleyDB::Env
not ok 3 - The object isa BerkeleyDB::Sequence
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 11/13 subtests

Looking at recent build logs for db5.3 on armhf [1], the build log of
5.3.28+dfsg2-4.1 shows:

checking for 64-bit integral type support for sequences... no
checking for growing a file under an mmap region... no

Whereas the build logs of 5.3.28+dfsg2-4.1~exp1 and older show:

checking for 64-bit integral type support for sequences... yes
checking for growing a file under an mmap region... yes

Regards
Graham


[1] https://buildd.debian.org/status/logs.php?pkg=db5.3&arch=armhf

Bug#1066086: maxima-emacs: maxima-emacs again not installable with xemacs21

[Agustin Martin]

Package: maxima-emacs,xemacs21
Severity: normal

Dear Maintainers,

Seems that

[#969410] maxima-emacs: maxima-emacs 5.44 does not work with XEmacs
[#999626] maxima-emacs: fails to install with xemacs21

are back, since mmm-mode-el dropped xemacs21 support and no longer
provides cl-lib.

I am including xemacs1 package in case maintainer wants to add something.

I see some possible approaches,

1) Drop xemacs21 support from maxima-emacs. I proposed a patch in #999626,
   should need more test and should probably be updated.
2) Create something like a xemacs21-compat-el package containing cl-lib and
   may be other compatibility stuff.
3) Include cl-lib somewhere in Debian xemacs21 package as a Debian feature.
4) Include cl-lib in maxima-emacs for local use.

Opinions?

Regards,

-- 
Agustin

Bug#149583: Relationship

[NGE]

NGE
PARC D'ACTIVITE DE LAURADE
13103 SAINT-ETIENNE-DU-GRES
FRANCE

Hello,
I am Jean BERNADET General Manager and legal representative of the 
company NGE.

Our company would like to collaborate with you.
Please send us your catalog with the best price.
Your prompt reply will be highly appreciated.


Best regard
Jean Bernadet
General Manager
Phone :+33.01.76.27.66.56
Fax: +3317627
VAT: FR79504124801

Bug#1066080: nvidia-driver (525.147.05-10) does not build against kernel 6.6.15-amd64 on Debian Sid

[Andreas Beckmann]

On 12/03/2024 08.53, JON Tauri wrote:

Contents of the make.log:


Please send the complete make.log to the bug. The part you pasted only 
contained the secondary errors.



Andreas

Bug#1064707: devscripts: FTBFS: AssertionError: black found code that needs reformatting:

[Simon McVittie]

On Sun, 25 Feb 2024 at 20:36:58 +0100, Lucas Nussbaum wrote:
> > FAIL: test_black (devscripts.test.test_black.BlackTestCase.test_black)
> > Test: Run black code formatter on Python source code.

I think lint checks like this one should be run by contributors and CI
when targeting the main branch, but skipped when building or testing
a released, production-ready .deb package - they're just too fragile
against new versions of the lint tool that move the goalposts.

smcv

Bug#1066087: ITP: python-influxdb-client -- InfluxDB 2.0 Python client library

[Thomas Goirand]

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

* Package name: python-influxdb-client
  Version : 1.40.0
  Upstream Contact: InfluxData, Inc.
* URL : https://github.com/influxdata/influxdb-client-python
* License : Expat
  Programming Lang: Python
  Description : InfluxDB 2.0 Python client library

 Client library for use with InfluxDB 2.x and Flux. InfluxDB 3.x users should
 instead use the lightweight v3 client library (influxdb3-python). InfluxDB 1.x
 users should use the v1 client library (influxdb-python). For ease of
 migration and a consistent query and write experience, v2 users should
 consider using InfluxQL and the v1 client library (influxdb-python).
 .
 The API of the influxdb-client is not the backwards-compatible with the old
 one influxdb-python.

Bug#1066080: nvidia-driver (525.147.05-10) does not build against kernel 6.6.15-amd64 on Debian Sid

[Andreas Beckmann]

That's the actual culprit:

On 12/03/2024 13.33, JON Tauri wrote:

# LD [M]  /var/lib/dkms/nvidia-current/525.147.05/build/nvidia-uvm.o
   ld -m elf_x86_64 -z noexecstack --no-warn-rwx-segments   -r -o
/var/lib/dkms/nvidia-current/525.147.05/build/nvidia-uvm.o
@/var/lib/dkms/nvidia-current/525.147.05/build/nvidia-uvm.mod  ;
./tools/objtool/objtool --hacks=jump_label --hacks=noinstr --hacks=skylake
--ibt --orc --retpoline --rethunk --sls --static-call --uaccess --prefix=16
  --link  --module /var/lib/dkms/nvidia-current/525.147.05/build/nvidia-uvm.o
./tools/objtool/objtool: error while loading shared libraries: libelf.so.1:
cannot open shared object file: No such file or directory
make[4]: ***
[/usr/src/linux-headers-6.6.15-common/scripts/Makefile.build:443:
/var/lib/dkms/nvidia-current/525.147.05/build/nvidia.o] Error 127
make[4]: *** Deleting file
'/var/lib/dkms/nvidia-current/525.147.05/build/nvidia.o'
make[4]: *** Waiting for unfinished jobs


This is not a bug in nvidia-kernel-dkms.
I assume this is a temporary breakage due to the ongoing 64-bit time_t 
transition which involves a huge amount of package renames.


I cannot reproduce it in an up-to-date sid chroot with 
linux-headers-6.6.15-amd64 installed (which has been superseded by 6.7.* 
btw).


Updating your system again should probably fix the issue.

In case it persists: Which variant and version of the libelf.so.1 
library do you have installed?


dpkg -l libelf1 libelf1t64


Andreas

Bug#1066088: koko-data: please make the build reproducible.

[James Addison]

Package: koko-data
Severity: wishlist
Tags: patch upstream
X-Debbugs-Cc: 
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

Dear Maintainer,

I'm an occasional volunteer contributor to the Reproducible Builds[1] project,
and noticed recently that the koko-data package failed some automated Debian
package reproducibility tests[2][3].

It looks like the cause of the non-reproducibility is that a zipfile extracted
by libarchive (as used internally by cmake) during the build is output with a
differing mtime based on the timezone that the build occurs in, since zipfiles
are written with file modification times based on the local system they were
created on.  Some discussion of this behaviour can be found[4] on the
libarchive bugtracker.

Please find attached a patch to temporarily use a fixed (UTC) timezone during
the relevant unzip step of the build process; I've confirmed that this results
in a fixed output mtime for the cities1000.txt file when building in different
timezones using dpkg-buildpackage on trixie.  I'll also offer this as a merge
request on Salsa.

Thank you,
James

[1] - https://reproducible-builds.org

[2] - 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/koko.html

[3] - https://salsa.debian.org/DebianOnMobile-team/koko/-/jobs/5423718

[4] - https://github.com/libarchive/libarchive/issues/945
From: James Addison 
Date: Tue, 12 Mar 2024 11:37:43 +
Subject: unzip the cities1000.zip file using a fixed timezone

Zipfiles are not timezone-aware; that is, files are typically written to a zip
archive with modification-times that are determined from the local system time.
.
That means that extracting the same zipfile in two different timezones may
produce different output file modification-times.  This occurs when libarchive
(as used by cmake) extracts the cities1000.zip file when building this package.
.
To build the package reproducibly, this patch temporarily configures a fixed
timezone of UTC during extraction of the cities1000.zip zipfile.
.
Ref: https://github.com/libarchive/libarchive/issues/945

---

--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -145,7 +145,7 @@ if (NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/cities1000.zip)
 endif()
 
 execute_process(
-COMMAND ${CMAKE_COMMAND} -E tar -xzf 
${CMAKE_CURRENT_BINARY_DIR}/cities1000.zip
+COMMAND env TZ=UTC ${CMAKE_COMMAND} -E tar -xzf 
${CMAKE_CURRENT_BINARY_DIR}/cities1000.zip
 WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
 )

Bug#1066089: ITP: python-reactivex -- asynchronous and event-based programs using observable collections

[Thomas Goirand]

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

* Package name: python-reactivex
  Version : 4.0.4
  Upstream Contact: Dag Brattli 
* URL : http://reactivex.io, https://github.com/ReactiveX/RxPY
* License : Expat
  Programming Lang: Python
  Description : asynchronous and event-based programs using observable 
collections

 This package provides a library for composing asynchronous and event-based
 programs using observable collections and query operator functions in Python.
 Using Rx, developers represent asynchronous data streams with Observables,
 query asynchronous data streams using operators, and parameterize concurrency
 in data/event streams using Schedulers.

Bug#1066077: usr-is-merged fails to install on a /usr-merged system

[Luca Boccassi]

Control: tags -1 moreinfo

On Tue, 12 Mar 2024 at 05:06, David W  wrote:
>
> Package: usr-is-merged
> Version: 39
>
> When attempting to install, I received the following message:
>
> **
> *
> * The usr-is-merged package cannot be installed because this system does
> * not have a merged /usr.
> *
> * Please install the usrmerge package to convert this system to merged-/usr.
> *
> * For more information please read https://wiki.debian.org/UsrMerge.
> *
> **
>
> This despite the fact that I have version 39 of usrmerge installed, and the 
> symlinks were indeed set up correctly.
>
> In the end, it turned out to be because /usr itself was a symlink, and 
> although this causes no issues for either the merging process or any running 
> software, since the check is using "readlink -f" it erroneously fails.

Why is /usr a symlink? How did you install your debian system?

Bug#1066090: psmisc: killall --older-than doesn't work as documented in a container

[Tim Connors]

Package: psmisc
Version: 23.6-1
Severity: normal

killall --older-than 30s restartx11vnc x11vnc vncserver x0tigervncserver 
websockify

doesn't kill any processes inside my container, whereas it always used
to work on a VM and on hardware.  Removing '--older-than 30s' kills
all such processes.  I strongly suspect the culprit is how
/proc/$pid/stat is interpreted:

--older-than case:

3921851 openat(AT_FDCWD, "/proc/3918880", O_RDONLY|O_DIRECTORY) = 3
3921851 openat(3, "stat", O_RDONLY) = 4
3921851 fcntl(4, F_GETFL)   = 0x8000 (flags O_RDONLY|O_LARGEFILE)
3921851 newfstatat(4, "", {st_mode=S_IFREG|0444, st_size=0, ...}, 
AT_EMPTY_PATH) = 0
3921851 read(4, "3918880 (x11vnc) S 3918875 39184"..., 1024) = 336
3921851 close(4)= 0
3921851 openat(AT_FDCWD, "/proc/uptime", O_RDONLY) = 4
3921851 newfstatat(4, "", {st_mode=S_IFREG|0444, st_size=23, ...}, 
AT_EMPTY_PATH) = 0
3921851 read(4, "82599.37 82599.37\n", 4096) = 18
3921851 close(4)= 0
3921851 close(3)= 0

no such flag:

3960244 openat(AT_FDCWD, "/proc/3918880", O_RDONLY|O_DIRECTORY) = 3
3960244 openat(3, "stat", O_RDONLY) = 4
3960244 fcntl(4, F_GETFL)   = 0x8000 (flags O_RDONLY|O_LARGEFILE)
3960244 newfstatat(4, "", {st_mode=S_IFREG|0444, st_size=0, ...}, 
AT_EMPTY_PATH) = 0
3960244 read(4, "3918880 (x11vnc) S 1 3918464 366"..., 1024) = 332
3960244 close(4)= 0
3960244 pidfd_send_signal(3, SIGTERM, NULL, 0) = 0
3960244 close(3)= 0


I'm guessing it's looking at field 22 starttime in /proc/$pid/stat?
starttime is seconds since boot.  Since the process exists in the
parent system as well, starttime will surely be seconds since host
boot?  But /proc/uptime is seconds since container boot.



-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 psmisc depends on:
ii  libc6  2.36-9+deb12u4
ii  libtinfo6  6.4-4

psmisc recommends no packages.

psmisc suggests no packages.

-- no debconf information

Bug#1051487: This not a double dependency

[fabian]

Hi Georges,

Am 12.03.2024 08:42, schrieb Georges Khaznadar:
It rather means: if some Foo.t1 font cannot be found, for any reason, 
take

another surely existing font as a default.


Yes, but by depending on the fonts-urw-base35 package you already _make 
sure_ that the T1 fonts can be found, so there is no need to also depend 
on the secondary order fallback fonts as well.



Would it be better to pick something like the font C059-Roman.t1,
by default?


Please choose default fonts that can be satisfied by only one package 
dependency.


 - Fabian

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Wesley Schwengle]

On Tue, Mar 12, 2024 at 11:40:01AM +0100, Julian Andres Klode wrote:

> On Mon, Mar 11, 2024 at 10:12:33PM -0400, Wesley Schwengle wrote:
> > I do not know what the bug here is, it could be one of these options:
> > 
> > 1) apt-get/apt upgrade accepts packages to upgrade where the docs state it
> >doesn't. The behaviour needs to change to not accept packages.
> > 
> > 2) apt-get/apt upgrade accepts packages and removes packages to satisfy deps
> >where the docs state it doesn't. The behaviour need to change to not 
> > remove
> >any packages. There is a small edge case where you can say: `apt upgrade 
> > foo
> >bar-'. Technically, it shouldn't remove packages, yet you want and 
> > instruct
> >it to remove bar.
> 
> The behavior is correct if potentially unexpected, but it should be
> documented better.

Thanks, it was option 3) Works as intended, documentation needs to be updated.

> > FWIW, aptitude does not remove packages where you call `aptitude 
> > safe-upgrade
> > foo'. It does remove packages when you call `aptitude full-upgrade foo'. It
> > also removes bar when you run `aptitude safe-upgrade foo bar-'. 
> 
> That is an entirely different command; `aptitude safe-upgrade foo`
> upgrades (only) `foo`, whereas `apt upgrade foo` first does the normal
> install argument handling and then runs an upgrade, so `foo` could also
> be a new package that is not currently installed to hint the solver if
> it is unable to find a solution.

Ahhh. I was under the impression that they had a similar intent.

On a related note: While debugging I also noticed apt's update and apt-get's
update are also slightly different. apt-get will not allow for new packages to
be installed whereas apt's version does allow this. You get apt's behaviour
with the --with-new-pkgs switch in apt-get's version of upgrade.

Cheers,
Wesley

Bug#1066091: debian-live: Please add systemd-timesyncd to the iso images

[Franco]

Package: debian-live
Severity: wishlist
X-Debbugs-Cc: martelli...@gmail.com

Dear Maintainer,

Is there a rationale behind the choice to exclude systemd-timesyncd from the 
iso images?
I'm using debian-live-12.5.0-amd64-kde.iso, systemd-timesyncd installation it 
takes 151 kB only:

~# apt-get install systemd-timesyncd
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  systemd-timesyncd
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 63.1 kB of archives.
After this operation, 151 kB of additional disk space will be used.
...

By doing so the user will have only to reconfigure tzdata in order to have the 
clock configured.
So please, consider to add systemd-timesyncd to the Debian-Live iso images.

Thanks in advance
-- 
Franco Martelli

Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2

[Jeremy Bícha]

On Sun, Mar 10, 2024 at 4:46 PM Sebastian Andrzej Siewior
 wrote:
> I've prepared an NMU for pristine-tar (versioned as 1.50+nmu2) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
>
> Could someone check this, please?

Did you try running autopkgtests on this version? The autopkgtests fail for me.

I assume that the largest use of pristine-tar in Debian is with
git-buildpackage. The 1.50+nmu1 upload **caused** pristine-tar to
break in many cases for me. If I revert back to 1.50, I no longer get
mismatched tarballs errors. Here are some test cases to demonstrate:

Test Case 1
==
gbp clone --add-upstream-vcs https://salsa.debian.org/jbicha/pangomm2.48

cd pangomm2.48

gbp import-orig --uscan

gbp buildpackage

What happens
--
The exact hashes will probably vary but I get an error like this:

gbp:error: Pristine-tar couldn't verify
"pangomm2.48_2.50.2.orig.tar.xz": pristine-tar:
/home/jeremy/build-area/pangomm2.48_2.50.2.orig.tar.xz does not match
stored hash (expected
e99b6a9c89e9c284bf44f5ae8125c06515d6ab8f8577d75d2887726dacb5a372, got
826ad52f53ac8e15c9ceba4dc6e616efddae5e089f36bf4e60081c177d80d4b6)

Other info
-
pangomm2.48 uses Files-Excluded in debian/copyright so uscan will
rebuild a tarball and its hash will vary depending on the time it was
created. (Perhaps the hash should be reproducible but that's not
relevant to this bug.)

Test Case 2
=
gbp clone https://salsa.debian.org/gnome-team/gtk4
cd gtk4
gbp buildpackage

What happens

gbp:error: Pristine-tar couldn't verify "gtk4_4.12.5+ds.orig.tar.xz":
pristine-tar: 
/home/jeremy/devel/pkg-gnome/temp/build-area/gtk4_4.12.5+ds.orig.tar.xz
does not match stored hash (expected
3338a691d774ae031af65299e9a1c6207f543f13b256539717a1970f752358cb, got
70ac33e0f37dc1b657d6560f1b8a40b3f4b67e956936633ced495d8b880d3fb0)

Other info

This pristine-tar tarball was committed January 19 so it did not use
either the new xz-utils or pristine-tar.

Test Case 3
=
gbp clone https://salsa.debian.org/gnome-team/pango
cd pango
gbp buildpackage

What happens
---
gbp:error: Pristine-tar couldn't verify
"pango1.0_1.52.1+ds.orig.tar.xz": pristine-tar:
/home/jeremy/devel/pkg-gnome/temp/build-area/pango1.0_1.52.1+ds.orig.tar.xz
does not match stored hash (expected
12d67d8182cbb2ae427406df9bab5ce2ff5619102bf2a0fc6331d80a9914b139, got
a641d29d2d7df7843e44762a0733987dc8220d238b697b382dd96fafe5fc890a)

Other info
-
This tarball was committed a few days ago with the new xz-utils and
pristine-tar 1.50+nmu1.
pango also uses Files-Excluded

Conclusion

Test cases 1, 2, and 3 pass with pristine-tar 1.50 but fail with
pristine-tar 1.50+nmu1

Thank you,
Jeremy Bícha

Bug#1066092: koko: please enable blhc-recommended build hardening.

[James Addison]

Source: koko
Version: 23.08.3+ds.1-2
Severity: wishlist

Dear Maintainer,

During filing of #1066088, some build failures of the 'blhc'[1] test utility
occurred on Salsa-CI[2].  These indicate that some compile-time security
hardening flags may not be enabled when the binary package is compiled (the
first failure mentioned in the logs relates to missing CPPFLAGS).

The Debian Wiki page[3] about package hardening includes some information
relating to packages that use CMake, and this could be worth checking for
guidance.

Thanks,
James

[1] - 
https://eriberto.pro.br/blog/2015/09/07/debian-how-to-use-blhc-to-solve-hardening-issues-when-packaging/

[2] - https://salsa.debian.org/jayaddison/koko/-/jobs/5435672

[3] - https://wiki.debian.org/Hardening#Notes_for_packages_using_CMake

Bug#902739: RFP: matlab-mode -- major mode for editing Matlab dot-m / .m files

[Sébastien Villemot]

Control: retitle -1 ITP: matlab-mode -- major mode for editing MATLAB .m files
Control: owner -1 !

On Sat, 30 Jun 2018 13:57:50 -0400 Nicholas D Steeves
 wrote:
> On Sat, Jun 30, 2018 at 07:55:30AM -0300, David Bremner wrote:
> > 
> > melpa is packaging
> > 
> >   https://git.code.sf.net/p/matlab-emacs/src
> > 
> > it seems to more up to date than either of the options you mention
> 
> That link seems to be dead.  Do you mean:
> 
> https://github.com/ayonga/matlab-emacs
> 
> ?

I intend to package the version in MELPA.
Homepage: https://matlab-emacs.sourceforge.net/
Git repository:
https://sourceforge.net/p/matlab-emacs/src/ci/master/tree/

It will be maintained under the umbrella of the Debian Emacsen team.

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



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

Bug#1066093: libglib2.0-bin: Dependencie issue with libglib2.0-0t64

[Ludogre]

Package: libglib2.0-bin
Version: 2.78.4-4
Severity: normal

Dear Maintainer,

Early morning, I made my debian upgrade and it remove lot of packages:
gdm3, gnome-shell… and libglib2-bin .

Gnome seems to need this package: libglib2.0-bin . But it is now
uninstall.

When I run those following command, I've got an error message due to a
dependencie issue:

> sudo apt install task-gnome-desktop 
> Lecture des listes de paquets... Fait
> Construction de l'arbre des dépendances... Fait
> Lecture des informations d'état... Fait  
> Certains paquets ne peuvent être installés. Ceci peut signifier
> que vous avez demandé l'impossible, ou bien, si vous utilisez
> la distribution unstable, que certains paquets n'ont pas encore
> été créés ou ne sont pas sortis d'Incoming.
> L'information suivante devrait vous aider à résoudre la situation : 
> 
> Les paquets suivants contiennent des dépendances non satisfaites :
>  gdm3 : Dépend: libglib2.0-bin (>= 2.35.0)
>  gnome-characters : Dépend: libglib2.0-bin
>  gnome-core : Dépend: libglib2.0-bin
>  gnome-shell : Dépend: libglib2.0-bin
>  gnome-software : Dépend: packagekit (>= 1.2.5)
>  gstreamer1.0-packagekit : Dépend: packagekit (= 1.2.8-2)
>  software-properties-common : Dépend: packagekit
>  tracker : Dépend: libglib2.0-bin
> E: Impossible de corriger les problèmes, des paquets défectueux sont en mode 
> « garder en l'état ».

> sudo apt install libglib2.0-bin
> Lecture des listes de paquets... Fait
> Construction de l'arbre des dépendances... Fait
> Lecture des informations d'état... Fait  
> Certains paquets ne peuvent être installés. Ceci peut signifier
> que vous avez demandé l'impossible, ou bien, si vous utilisez
> la distribution unstable, que certains paquets n'ont pas encore
> été créés ou ne sont pas sortis d'Incoming.
> L'information suivante devrait vous aider à résoudre la situation : 
> 
> Les paquets suivants contiennent des dépendances non satisfaites :
>  libglib2.0-0t64 : Casse: libglib2.0-0 (< 2.78.4-4)
> E: Erreur, pkgProblem::Resolve a généré des ruptures, ce qui a pu être causé 
> par les paquets devant être gardés en l'état.

Is there a way to resolve this issue or a workaround?

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

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

Versions of packages libglib2.0-bin depends on:
ii  libc6   2.37-15
ii  libelf1 0.190-1+b1
pn  libelf1t64  
ii  libglib2.0-0t64 [libglib2.0-0]  2.78.4-4
ii  libglib2.0-data 2.80.0-1

libglib2.0-bin recommends no packages.

libglib2.0-bin suggests no packages.

Bug#1066094: squidguard: Squidguard does not work with default squid apparmor profile

[Marco Gaiarin]

Package: squidguard
Version: 1.6.0-2
Severity: normal

Dear Maintainer,

i've tried to use as 'usual' squidguard in my squid configuration, but squid 
simply
start filling logs (syslog and squid's cache.log) with:

2024/03/01 14:22:59 kid1| Starting new helpers
2024/03/01 14:22:59 kid1| helperOpenServers: Starting 1/10 'squidGuard' 
processes
2024/03/01 14:22:59 kid2| ipcCreate: /usr/bin/squidGuard: (13) 
Permission denied
2024/03/01 14:22:59 kid2| WARNING: redirector #Hlpr175 exited

after fiddling a bit, i've found that the guilty is apparmor squid profile (so,
i've not clear if this is a squidguard or a squid bug, indeed ;-).


I've simply done:

aa-disable /etc/apparmor.d/usr.sbin.squid

and now squid (and squidguard) run as expected.


I've also looked around and seems that there's an ubuntu bug opened:

https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1787409


Thanks.

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

Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 squidguard depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u8
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libldap-2.4-2  2.4.57+dfsg-3+deb11u1

Versions of packages squidguard recommends:
ii  liburi-perl  5.08-1
ii  libwww-perl  6.52-1
ii  squid4.13-10+deb11u3

Versions of packages squidguard suggests:
pn  ldap-utils  
pn  squidguard-doc  

-- Configuration Files:
/etc/squidguard/squidGuard.conf.default [Errno 2] File o directory non 
esistente: '/etc/squidguard/squidGuard.conf.default'

-- debconf information:
  squidguard/dbreload: true

Bug#1066085: q2cli: please make the build reproducible

[Andreas Tille]

Control: tags -1 pending

Hi Chris,

thanks a lot for your patch which I commited to Git.  I did not
uploaded yet since a general refresh of q2* packages is pending
anyway.

Kind regards

  Andreas.

Am Tue, Mar 12, 2024 at 10:37:41AM + schrieb Chris Lamb:

> --- a/debian/rules2024-03-12 10:05:22.980824959 +
> --- b/debian/rules2024-03-12 10:34:47.399635439 +
> @@ -21,6 +21,7 @@
>   mkdir -p debian/$(DEB_SOURCE)/usr/share/bash-completion/completions
>   mv debian/$(DEB_SOURCE)/usr/bin/tab-qiime 
> debian/$(DEB_SOURCE)/usr/share/bash-completion/completions/qiime
>   chmod -x 
> debian/$(DEB_SOURCE)/usr/share/bash-completion/completions/qiime
> + find debian/$(DEB_SOURCE) -type f -name parsl.log -delete
>  
>  debian/control: debian/control.in
>   echo "# This file is autogenerated from control.in to update versioned 
> dependencies" > $@

> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Bug#1066080: nvidia-driver (525.147.05-10) does not build against kernel 6.6.15-amd64 on Debian Sid

[JON Tauri]

Thanks.

I have run updates multiple times a day for the past week hoping what you
are suggesting would transpire, but things are not getting fixed through a
simple update.

Here is the information requested:

$ dpkg -l libelf1 libelf1t64
dpkg-query: no packages found matching libelf1t64
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---===

ri  libelf1:amd64  0.190-1+b1   amd64library to read and write ELF
files

An attempt to install the 64 bit version of the library fails:

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

The following packages have unmet dependencies:
plasma-workspace : Depends: gdb-minimal but it is not going to be installed
or
gdb
   Recommends: qml-module-org-kde-pipewire but it is not
going to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused
by held packages.

Incidentally, I get the same error when I try to install the kernel headers
for kernel 6.7.7-amd64 (so I am not upgrading the kernel either). I was
trying that as a possible solution hoping that the newer kernel may have
fixed any problems of compatibility between nvidia-kernel and
linux-headers. No joy:

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

The following packages have unmet dependencies:
plasma-workspace : Depends: gdb-minimal but it is not going to be installed
or
gdb
   Recommends: qml-module-org-kde-pipewire but it is not
going to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused
by held packages.

The above error has also been persistent for the past 4-5 days.

Use of aptitude -f install for installation of kernel headers suggests that
I uninstall libelf:

The following actions will resolve these dependencies:

Keep the following packages at their current version:
1) linux-headers-6.7.7-amd64 [Not Installed]


Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

 Remove the following packages:
1)  libcurl3-gnutls [8.6.0-3 (now, unstable)]
2)  libdebuginfod1 [0.190-1+b1 (now, unstable)]
3)  libdw1 [0.190-1+b1 (now, unstable)]
4)  libelf1 [0.190-1+b1 (now, unstable)]
5)  libnettle8 [3.9.1-2+b1 (now, unstable)]

 Install the following packages:
6)  libcurl3t64-gnutls [8.6.0-3.2 (unstable)]
7)  libdebuginfod1t64 [0.190-1.1+b1 (unstable)]
8)  libdw1t64 [0.190-1.1+b1 (unstable)]
9)  libelf1t64 [0.190-1.1+b1 (unstable)]
10) libnettle8t64 [3.9.1-2.2 (unstable)]
11) linux-kbuild-6.7.7 [6.7.7-1 (unstable)]

Accept this solution? [Y/n/q/?]

So, I have a cluster of broken packages that are keeping me from fixing up
the situation through an update. From what you mention, maybe I have a
broken installation, but I have never seen a Debian installation break like
this through regular upgrades (I used to use Testing, but moved to Sid 3
years ago).



On Tue, Mar 12, 2024 at 6:31 PM Andreas Beckmann  wrote:

> That's the actual culprit:
>
> On 12/03/2024 13.33, JON Tauri wrote:
> > # LD [M]  /var/lib/dkms/nvidia-current/525.147.05/build/nvidia-uvm.o
> >ld -m elf_x86_64 -z noexecstack --no-warn-rwx-segments   -r -o
> > /var/lib/dkms/nvidia-current/525.147.05/build/nvidia-uvm.o
> > @/var/lib/dkms/nvidia-current/525.147.05/build/nvidia-uvm.mod  ;
> > ./tools/objtool/objtool --hacks=jump_label --hacks=noinstr
> --hacks=skylake
> > --ibt --orc --retpoline --rethunk --sls --static-call --uaccess
> --prefix=16
> >   --link  --module
> /var/lib/dkms/nvidia-current/525.147.05/build/nvidia-uvm.o
> > ./tools/objtool/objtool: error while loading shared libraries:
> libelf.so.1:
> > cannot open shared object file: No such file or directory
> > make[4]: ***
> > [/usr/src/linux-headers-6.6.15-common/scripts/Makefile.build:443:
> > /var/lib/dkms/nvidia-current/525.147.05/build/nvidia.o] Error 127
> > make[4]: *** Deleting file
> > '/var/lib/dkms/nvidia-current/525

Bug#1066095: llvm-18 is available in unstable, please also build spirv-llvm-translator-18 in unstable

[Matthias Klose]

Package: src:spirv-llvm-translator-18
Version: 18.~~+git20240215-1

llvm-18 is available in unstable, please also build 
spirv-llvm-translator-18 in unstable.

Bug#1066096: bookworm-pu: package libpod/4.3.1+ds1-8+deb12u1

[Jérôme Charaoui]

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

[ Reason ]

podman in bookworm suffers from a race condition which causes the 
"network ls" command to fail intermittently in certain scenarios


[ Impact ]

The issue is responsible for intermittent failures when using podman as 
a GitLab CI runner executor and the 'FF_NETWORK_PER_BUILD' runner flag 
is enabled. This bug has been reported on the BTS at #1059496.


[ Risk ]

Low, the patch is small (3 lines) and is strictly designed to gracefully 
handle the identified race condition.


[ Tests ]

Autopkgtests are passing, and we've deployed this package on a small 
fleet of GitLab CI runners for several weeks without issue of any kind, 
and confirming the failures caused by the race condition do not occur 
anymore.


[ 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 ]

The debdiff consists of the addition of a patch cherry-picked from 
upstream to gracefully handle a race condition in the "network ls" 
podman subcommand.


Thank you.

-- Jérôme
diff -Nru libpod-4.3.1+ds1/debian/changelog libpod-4.3.1+ds1/debian/changelog
--- libpod-4.3.1+ds1/debian/changelog   2023-04-30 08:19:54.0 -0400
+++ libpod-4.3.1+ds1/debian/changelog   2024-02-26 09:30:29.0 -0500
@@ -1,3 +1,10 @@
+libpod (4.3.1+ds1-8+deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * d/patches: backport fix for removed container handling
+
+ -- Jérôme Charaoui   Mon, 26 Feb 2024 09:30:29 -0500
+
 libpod (4.3.1+ds1-8) unstable; urgency=medium
 
   * [upstream] unbreak using docker as client
diff -Nru libpod-4.3.1+ds1/debian/patches/fix-removed-container-handling.patch 
libpod-4.3.1+ds1/debian/patches/fix-removed-container-handling.patch
--- libpod-4.3.1+ds1/debian/patches/fix-removed-container-handling.patch
1969-12-31 19:00:00.0 -0500
+++ libpod-4.3.1+ds1/debian/patches/fix-removed-container-handling.patch
2024-02-26 09:30:29.0 -0500
@@ -0,0 +1,28 @@
+From: Valentin Rothberg 
+Date: Mon, 6 Feb 2023 13:52:40 +0100
+Subject: [PATCH] network ls: handle removed container
+
+Handle a race condition in the REST API when listing networks.
+In between listing all containers and inspecting them, they may have
+already been removed, so handle this case gracefully.
+
+[NO NEW TESTS NEEDED] as it's a race condition.
+
+Fixes: #17341
+
+Forwarded: not-needed
+Origin: upstream, 
https://github.com/containers/podman/commit/ced934284058232c1c3d76956786106d64511f89
+diff --git a/pkg/api/handlers/compat/networks.go 
b/pkg/api/handlers/compat/networks.go
+index 704af4b0e427..587da14361eb 100644
+--- a/pkg/api/handlers/compat/networks.go
 b/pkg/api/handlers/compat/networks.go
+@@ -74,6 +74,9 @@ func convertLibpodNetworktoDockerNetwork(runtime 
*libpod.Runtime, network *netty
+   for _, con := range cons {
+   data, err := con.Inspect(false)
+   if err != nil {
++  if errors.Is(err, define.ErrNoSuchCtr) || 
errors.Is(err, define.ErrCtrRemoved) {
++  continue
++  }
+   return nil, err
+   }
+   if netData, ok := data.NetworkSettings.Networks[network.Name]; 
ok {
diff -Nru libpod-4.3.1+ds1/debian/patches/series 
libpod-4.3.1+ds1/debian/patches/series
--- libpod-4.3.1+ds1/debian/patches/series  2023-04-30 08:19:54.0 
-0400
+++ libpod-4.3.1+ds1/debian/patches/series  2024-02-26 09:30:29.0 
-0500
@@ -3,3 +3,4 @@
 CVE-2023-0778.patch
 fix-podman-client.patch
 show-graphroot-before-removal.patch
+fix-removed-container-handling.patch


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066080: nvidia-driver (525.147.05-10) does not build against kernel 6.6.15-amd64 on Debian Sid

[JON Tauri]

Replying to myself. Your statement about the ongoing 64 bit time_t
transition got me thinking. What if I have a problem there? So, I tried
installing the libelf t64 bit again:



$ sudo aptitude -f install libelf1t64
The following NEW packages will be installed:
 libelf1t64
The following packages will be REMOVED:
 libelf1{a} libgphoto2-l10n{u}
The following partially installed packages will be configured:
 nvidia-driver nvidia-kernel-dkms
0 packages upgraded, 1 newly installed, 2 to remove and 267 not upgraded.
Need to get 176 kB of archives. After unpacking 2,769 kB will be freed.
The following packages have unmet dependencies:
libdebuginfod1 : Depends: libelf1 (= 0.190-1+b1) but it is not going to be
installed
libdw1 : Depends: libelf1 (= 0.190-1+b1) but it is not going to be
installed
The following actions will resolve these dependencies:

Keep the following packages at their current version:
1) libelf1 [0.190-1+b1 (now, unstable)]
2) libelf1t64 [Not Installed]



Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

Remove the following packages:
1) libcurl3-gnutls [8.6.0-3 (now, unstable)]
2) libdebuginfod1 [0.190-1+b1 (now, unstable)]
3) libdw1 [0.190-1+b1 (now, unstable)]
4) libnettle8 [3.9.1-2+b1 (now, unstable)]

Install the following packages:
5) libcurl3t64-gnutls [8.6.0-3.2 (unstable)]
6) libdebuginfod1t64 [0.190-1.1+b1 (unstable)]
7) libdw1t64 [0.190-1.1+b1 (unstable)]
8) libnettle8t64 [3.9.1-2.2 (unstable)]

Rather neat, isn't it? Each library being replaced with the presumably
updated version. So, I said yes on a hunch.

Accept this solution? [Y/n/q/?] y
The following NEW packages will be installed:
 libcurl3t64-gnutls{a} libdebuginfod1t64{a} libdw1t64{a} libelf1t64
libnettle8t64{a}
The following packages will be REMOVED:
 libcurl3-gnutls{a} libdebuginfod1{a} libdw1{a} libelf1{a}
libgphoto2-l10n{u} libnettle8{a}
The following partially installed packages will be configured:
 nvidia-driver nvidia-kernel-dkms
0 packages upgraded, 5 newly installed, 6 to remove and 267 not upgraded.
Need to get 1,165 kB of archives. After unpacking 2,767 kB will be freed.
Do you want to continue? [Y/n/?] y
Get: 1 http://deb.debian.org/debian sid/main amd64 libnettle8t64 amd64
3.9.1-2.2 [296 kB]
Get: 2 http://deb.debian.org/debian sid/main amd64 libcurl3t64-gnutls amd64
8.6.0-3.2 [421 kB]
Get: 3 http://deb.debian.org/debian sid/main amd64 libdw1t64 amd64
0.190-1.1+b1 [243 kB]
Get: 4 http://deb.debian.org/debian sid/main amd64 libelf1t64 amd64
0.190-1.1+b1 [176 kB]
Get: 5 http://deb.debian.org/debian sid/main amd64 libdebuginfod1t64 amd64
0.190-1.1+b1 [28.4 kB]
Fetched 1,165 kB in 1s (963 kB/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
dpkg: libnettle8:amd64: dependency problems, but removing anyway as you
requested:
wget depends on libnettle8.
qemu-utils depends on libnettle8.
libsrt1.5-gnutls:amd64 depends on libnettle8.
librtmp1:amd64 depends on libnettle8.
libhogweed6:amd64 depends on libnettle8.
libgnutls30t64:amd64 depends on libnettle8 (>= 3.9~).
libcurl3-gnutls:amd64 depends on libnettle8.
libarchive13:amd64 depends on libnettle8.
gstreamer1.0-plugins-bad:amd64 depends on libnettle8 (>= 3).
dnsmasq-base depends on libnettle8 (>= 2.4-3).

(Reading database ... 415473 files and directories currently installed.)
Removing libnettle8:amd64 (3.9.1-2+b1) ...
Selecting previously unselected package libnettle8t64:amd64.
(Reading database ... 415465 files and directories currently installed.)
Preparing to unpack .../libnettle8t64_3.9.1-2.2_amd64.deb ...
Unpacking libnettle8t64:amd64 (3.9.1-2.2) ...
Setting up libnettle8t64:amd64 (3.9.1-2.2) ...
dpkg: libcurl3-gnutls:amd64: dependency problems, but removing anyway as
you requested:
qemu-block-extra depends on libcurl3-gnutls (>= 7.16.3).
python3-pycurl depends on libcurl3-gnutls (>= 8.6.0).
octave depends on libcurl3-gnutls (>= 7.16.2).
network-manager depends on libcurl3-gnutls (>= 7.24.0).
libxerces-c3.2:amd64 depends on libcurl3-gnutls (>= 7.16.2).
libvirt0:amd64 depends on libcurl3-gnutls (>= 7.28.0).
libsane1:amd64 depends on libcurl3-gnutls (>= 7.16.2).
libraptor2-0:amd64 depends on libcurl3-gnutls (>= 7.16.2).
libqalculate22:amd64 depends on libcurl3-gnutls (>= 7.16.2).
libproxy1v5:amd64 depends on libcurl3-gnutls (>= 7.16.2).
libkolabxml1v5:amd64 depends on libcurl3-gnutls (>= 7.16.2).
libdebuginfod1:amd64 depends on libcurl3-gnutls (>= 7.28.0).
libappstream5:amd64 depends on libcurl3-gnutls (>= 7.63.0).
gstreamer1.0-plugins-bad:amd64 depends on libcurl3-gnutls (>= 7.55.0).
git depends on libcurl3-gnutls (>= 7.56.1).

(Reading database ... 415473 files and directories currently installed.)
Removing libcurl3-gnutls:amd64 (8.6.0-3) ...
Selecting previously unselected package libcurl3t64-gnutls:amd64.
(Reading database ... 415466 files and directories currently installed.)
Preparing to unpack .../libcurl3t64-gnutls_8.6.0-3.2_amd64.deb ...
Unpacki

Bug#1066097: reportbug: xdg-desktop-portal-gnome does not allow write access to folders

[Rob Hall]

Package: xdg-desktop-portal-gnome
Version: 43.1-2
Severity: normal
X-Debbugs-Cc: robxnanoc...@outlook.com

Dear Maintainer,

Steps to reproduce:
1. Install HandBrake from Flatpak, or another application which makes use of
the portal to open a folder to write in.
2. Use `sudo flatpak override --nofilesystem=host fr.handbrake.ghb` to restrict
direct filesystem access.
3. Run HandBrake and select a video file.
4. Click the To: menu in the bottom right-hand corner, select Other... and
select a folder.

Result: HandBrake reports that the directory is not writable. There is no
option to make the folder writable, so the application is unable to save files.

The issue was reported upstream in https://gitlab.gnome.org/GNOME/xdg-desktop-
portal-gnome/-/issues/41 and resolved in xdg-desktop-portal-gnome 44 via
https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/38.


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

Kernel: Linux 6.1.0-18-amd64 (SMP w/8 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 xdg-desktop-portal-gnome depends on:
ii  dbus-user-session1.14.10-1~deb12u1
ii  dbus-x11 1.14.10-1~deb12u1
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gsettings-desktop-schemas43.0-1
ii  libadwaita-1-0   1.2.2-1
ii  libc62.36-9+deb12u4
ii  libcairo21.16.0-7
ii  libfontconfig1   2.14.1-4
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgnome-bg-4-2  43.2-2
ii  libgnome-desktop-4-2 43.2-2
ii  libgtk-4-1   4.8.3+ds-2+deb12u1
ii  libx11-6 2:1.8.4-2+deb12u2
ii  xdg-desktop-portal   1.16.0-2
ii  xdg-desktop-portal-gtk   1.14.1-1

Versions of packages xdg-desktop-portal-gnome recommends:
ii  gnome-settings-daemon  43.0-4
ii  gnome-shell43.9-0+deb12u1

Versions of packages xdg-desktop-portal-gnome suggests:
ii  accountsservice  22.08.8-6
ii  evince   43.1-2+b1

-- no debconf information

Bug#1000061: cfengine3: depends on obsolete pcre3 library

[Christoph Martin]

version 3.24.0 is not released yet but expected for mid 2024.

Am 18.12.23 um 15:14 schrieb Bastian Germann:

On Fri, 18 Aug 2023 12:01:17 +0200 Bastian Germann  wrote:

cfengine3 is a key package and requires pcre, so this has to be fixed.


Upstream claims that this is fixed with 3.24.0.



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066082: python-cpuinfo: Add support for loongarch64

[Boyuan Yang]

On Tue, 12 Mar 2024 17:38:16 +0800 zhangdandan  wrote:
> Source: python-cpuinfo
> Version: 9.0.0-1
> Severity: wishlist
> Tags: ftbfs
> User: debian-loonga...@lists.debian.org
> Usertags: loong64
> 
> Dear maintainers,
> 
> Compiling the python-cpuinfo successed for loong64 in the Debian Package 
> Auto-Building environment.
> But python-cpuinfo source package lacks LoongArch architecture support.
> 
> - Background information is provided below.
> When I analyzed why python3-pandas-lib:loong64 was blocking the build of 
> 29 source packages, I found that the compilation dependency 
> (python3-tables-lib:loong64) of pandas was not satisfied.
> The reason is that pytables compilation failed, please check the 
> following error log,
> ```
> ..
> File "/usr/lib/python3/dist-packages/cpuinfo/cpuinfo.py", line 366, in 
> _check_arch
>      raise Exception("py-cpuinfo currently only works on X86 "
> Exception: py-cpuinfo currently only works on X86 and some 
> ARM/PPC/S390X/MIPS/RISCV CPUs.
> ..
> ```
> The full build log of pytables, please see 
> https://buildd.debian.org/status/logs.php?pkg=pytables&ver=3.9.2-1&arch=loong64.
> In short, the chain of dependencies is as follows,
> python3-pandas-lib(src:pandas) ——> python3-tables-lib(src:pytables) ——> 
> python3-cpuinfo(src:python-cpuinfo)
> The result is that python-cpuinfo lacks LoongArch support, even though 
> it is a package for the all architecture.
> 
> - The support for LoongArch was added to python-cpuinfo upstream in Nov. 
> 2022.
> The upstream link for python-cpuinfo is 
> https://github.com/workhorsy/py-cpuinfo.
> 
> The end, could you add LoongArch support in the next upload?
> Your suggestions are welcome.

Thanks for the report. I am uploading a latest upstream git snapshot into
Debian archive, which should fix this issue.

Best,
Boyuan Yang


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

Bug#1065611: Additional support for SolidRun HoneyComb

[Josua Mayer]

Hi Diederik,

Thank you for taking care of this!
First the additional changes you found seem reasonable.

Regarding edac - I checked NXPs reference BSP for LX2160,
and their linux fork has the same status, driver can not be enabled on arm64.

However I also agree it should be enabled if it were possible.
The driver appears to setup ecc bit error interrupts so that hey can be 
reported by Linux.

Here is what other qoriq drivers do:
drivers/crypto/caam/Kconfig:    depends on FSL_SOC || ARCH_MXC || 
ARCH_LAYERSCAPE

I may have access to an lx2160a system with ecc memory within the coming week,
so I could test (on vendor kernel based on 5.10 only) whether any problems show 
up.
If not, perhaps a patch to the kernel is advisable.

Am 07.03.24 um 13:34 schrieb Diederik de Haas:

> Hi Josua,
>
> On Thursday, 18 January 2024 17:40:38 CET Josua Mayer wrote:
>> LX2160 SoC early silicon revisions have a pci-e generation 4 controller.
>> It requires a different driver from newer gen-3 silicon.
>>
>> This affects the SolidRun Honeycomb Workstation which
>> is otherwise fully supported in Debian.
> I cloned bug report #1061116 into #1065611 to discuss some additional support 
> for the SolidRun HoneyComb.
>
> I analyzed the HoneyComb dts file and the following included .dtsi files:
> - arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
> - arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
> - arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>
> If I exclude the kernel modules from 1061116 and 1061117, then I still have 
> the following list of additional modules to enable:
> - drivers/edac: Enable EDAC_MPC85XX
> - drivers/hwmon/pmbus: Enable PMBUS, SENSORS_PMBUS and
>   SENSORS_LTC2978 as modules
> - drivers/nvmem: Enable NVMEM_LAYERSCAPE_SFP as module
> - drivers/rtc: Enable RTC_DRV_FSL_FTM_ALARM as module
> - drivers/soc/fsl: Enable FSL_RCPM
>
> If you agree that this is a good list I can make a MR to get them enabled.
> A MR for 1061116 and 1061117 has just been merged in our 'master' branch.
>
> But I ran into an issue when looking at the ``EDAC_MPC85XX`` stanza 
> in``drivers/edac/Kconfig``:
> ``depends on FSL_SOC && EDAC=y``
>
> But ``FSL_SOC`` is (only) defined in ``arch/powerpc/Kconfig``, which means 
> ``EDAC_MPC85XX`` can not be enabled on ``arm64``. 
> That module was found based on ``compatible = 
> "fsl,qoriq-memory-controller"``, 
> which sounds like something you would want to have.
>
> Upstream commit ea2eb9a8b6207ee4 has the following commit message:
> ```
> EDAC, fsl-ddr: Separate FSL DDR driver from MPC85xx
> 
> The mpc85xx-compatible DDR controllers are used on ARM-based SoCs too.
> Carve out the DDR part from the mpc85xx EDAC driver in preparation to
> support both architectures.
> ```
> Which I interpret as all (?) the preparations for supporting both powerpc and 
> ARM were made, but they forgot to update the strict dependency of 
> ``EDAC_MPC85XX`` to powerpc to actually support both architectures?
>
> Can you shed some light on this?
>
> Cheers,
>   Diederik

Bug#1066095: llvm-18 is available in unstable, please also build spirv-llvm-translator-18 in unstable

[Andreas Beckmann]

Control: block -1 with 1065551
Control: severity 1065551 important

On 12/03/2024 15.20, Matthias Klose wrote:

Package: src:spirv-llvm-translator-18
Version: 18.~~+git20240215-1

llvm-18 is available in unstable, please also build 
spirv-llvm-translator-18 in unstable.


v18.1.0 has been tagged inbetween, but it requires newer spirv-headers 
to build.



Andreas

Bug#1066098: udns-utils: missing "A" in help output

[Christopher Bock]

Package: udns-utils
Version: 0.4-1+b1
Severity: normal
X-Debbugs-Cc: christop...@bocki.com

Dear Maintainer,

   * What led up to the situation?
   talk about dnsget in #debian-til

   after looking at the output of `dnsget -h` i was a bit confused:
   bash-5.2$ dnsget -h |grep type
-t type - set query type (A, AAA, PTR etc)

   it should be four A's :>

diff --git a/dnsget.c b/dnsget.c
index 417e8d9..1db79a8 100644
--- a/dnsget.c
+++ b/dnsget.c
@@ -636,7 +636,7 @@ int main(int argc, char **argv) {
 " -h - print this help and exit\n"
 " -v - be more verbose\n"
 " -q - be less verbose\n"
-" -t type - set query type (A, AAA, PTR etc)\n"
+" -t type - set query type (A, , PTR etc)\n"
 " -c class - set query class (IN (default), CH, HS, *)\n"
 " -a - equivalent to -t ANY -v\n"
 " -n ns - use given nameserver(s) instead of default\n"




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

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

Versions of packages udns-utils depends on:
ii  libc6 2.36-9+deb12u4
ii  libudns0  0.4-1+b1

udns-utils recommends no packages.

udns-utils suggests no packages.

-- no debconf information

Bug#1065611: Additional support for SolidRun HoneyComb

[Josua Mayer]

Hi Diederik,

I believe I found the answer:
EDAC_MPC85XX is for power-pc only,
EDAC_LAYERSCAPE is for arm (see drivers/edac/layerscape_edac.c).

br
Josua

Am 12.03.24 um 16:13 schrieb Josua Mayer:
> Hi Diederik,
>
> Thank you for taking care of this!
> First the additional changes you found seem reasonable.
>
> Regarding edac - I checked NXPs reference BSP for LX2160,
> and their linux fork has the same status, driver can not be enabled on arm64.
>
> However I also agree it should be enabled if it were possible.
> The driver appears to setup ecc bit error interrupts so that hey can be 
> reported by Linux.
>
> Here is what other qoriq drivers do:
> drivers/crypto/caam/Kconfig:    depends on FSL_SOC || ARCH_MXC || 
> ARCH_LAYERSCAPE
>
> I may have access to an lx2160a system with ecc memory within the coming week,
> so I could test (on vendor kernel based on 5.10 only) whether any problems 
> show up.
> If not, perhaps a patch to the kernel is advisable.
>
> Am 07.03.24 um 13:34 schrieb Diederik de Haas:
>
>> Hi Josua,
>>
>> On Thursday, 18 January 2024 17:40:38 CET Josua Mayer wrote:
>>> LX2160 SoC early silicon revisions have a pci-e generation 4 controller.
>>> It requires a different driver from newer gen-3 silicon.
>>>
>>> This affects the SolidRun Honeycomb Workstation which
>>> is otherwise fully supported in Debian.
>> I cloned bug report #1061116 into #1065611 to discuss some additional 
>> support 
>> for the SolidRun HoneyComb.
>>
>> I analyzed the HoneyComb dts file and the following included .dtsi files:
>> - arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
>> - arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
>> - arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>>
>> If I exclude the kernel modules from 1061116 and 1061117, then I still have 
>> the following list of additional modules to enable:
>> - drivers/edac: Enable EDAC_MPC85XX
>> - drivers/hwmon/pmbus: Enable PMBUS, SENSORS_PMBUS and
>>   SENSORS_LTC2978 as modules
>> - drivers/nvmem: Enable NVMEM_LAYERSCAPE_SFP as module
>> - drivers/rtc: Enable RTC_DRV_FSL_FTM_ALARM as module
>> - drivers/soc/fsl: Enable FSL_RCPM
>>
>> If you agree that this is a good list I can make a MR to get them enabled.
>> A MR for 1061116 and 1061117 has just been merged in our 'master' branch.
>>
>> But I ran into an issue when looking at the ``EDAC_MPC85XX`` stanza 
>> in``drivers/edac/Kconfig``:
>> ``depends on FSL_SOC && EDAC=y``
>>
>> But ``FSL_SOC`` is (only) defined in ``arch/powerpc/Kconfig``, which means 
>> ``EDAC_MPC85XX`` can not be enabled on ``arm64``. 
>> That module was found based on ``compatible = 
>> "fsl,qoriq-memory-controller"``, 
>> which sounds like something you would want to have.
>>
>> Upstream commit ea2eb9a8b6207ee4 has the following commit message:
>> ```
>> EDAC, fsl-ddr: Separate FSL DDR driver from MPC85xx
>> 
>> The mpc85xx-compatible DDR controllers are used on ARM-based SoCs too.
>> Carve out the DDR part from the mpc85xx EDAC driver in preparation to
>> support both architectures.
>> ```
>> Which I interpret as all (?) the preparations for supporting both powerpc 
>> and 
>> ARM were made, but they forgot to update the strict dependency of 
>> ``EDAC_MPC85XX`` to powerpc to actually support both architectures?
>>
>> Can you shed some light on this?
>>
>> Cheers,
>>   Diederik

Bug#883004: dh-python: pybuild autotest support for stestr, testrepository and ostestr

[James Page]

Afternoon

I had reason to come back to looking at this recently; I've reworked the
patch to just support stestr as the test execution system (the other two
seem much less common/unused directly now).

I tested this with the python-oslo.config package - albeit I did have to
strip down the rules file to remove alot of existing packaging scaffolding
using openstack-pkg-tools.
diff -Nru dh-python-6.20231223ubuntu2/dh/pybuild.pm dh-python-6.20231223ubuntu3/dh/pybuild.pm
--- dh-python-6.20231223ubuntu2/dh/pybuild.pm	2023-12-24 00:06:52.0 +
+++ dh-python-6.20231223ubuntu3/dh/pybuild.pm	2024-03-12 15:33:25.0 +
@@ -157,7 +157,8 @@
 $ENV{'PYBUILD_TEST_NOSE2'} ne '1' and
 $ENV{'PYBUILD_TEST_NOSE'} ne '1' and
 $ENV{'PYBUILD_TEST_CUSTOM'} ne '1' and
-$ENV{'PYBUILD_TEST_TOX'} ne '1') {
+$ENV{'PYBUILD_TEST_TOX'} ne '1' and
+$ENV{'PYBUILD_TEST_STESTR'} ne '1') {
 			if (grep {$_ eq 'tox'} @deps and $ENV{'PYBUILD_TEST_TOX'} ne '0') {
 push @py3opts, '--test-tox'}
 			elsif (grep {$_ eq 'python3-pytest'} @deps and $ENV{'PYBUILD_TEST_PYTEST'} ne '0') {
@@ -166,6 +167,8 @@
 push @py3opts, '--test-nose2'}
 			elsif (grep {$_ eq 'python3-nose'} @deps and $ENV{'PYBUILD_TEST_NOSE'} ne '0') {
 push @py3opts, '--test-nose'}
+			elsif (grep {$_ eq 'python3-stestr'} @deps and $ENV{'PYBUILD_TEST_STESTR'} ne '0') {
+   push @py3opts, '--test-stestr'}
 		}
 
 		my $py3all = 0;
diff -Nru dh-python-6.20231223ubuntu2/dhpython/build/base.py dh-python-6.20231223ubuntu3/dhpython/build/base.py
--- dh-python-6.20231223ubuntu2/dhpython/build/base.py	2023-12-24 00:06:52.0 +
+++ dh-python-6.20231223ubuntu3/dhpython/build/base.py	2024-03-12 15:33:25.0 +
@@ -273,6 +273,12 @@
 
 tox_cmd.append('{args}')
 return ' '.join(tox_cmd)
+elif self.cfg.test_stestr:
+return (
+'cd {build_dir};'
+'stestr --config {dir}/.stestr.conf init;'
+'PYTHON=python{version} stestr --config {dir}/.stestr.conf run'
+)
 elif self.cfg.test_custom:
 return 'cd {build_dir}; {args}'
 elif args['version'] == '2.7' or args['version'] >> '3.1' or args['interpreter'] == 'pypy':
diff -Nru dh-python-6.20231223ubuntu2/pybuild dh-python-6.20231223ubuntu3/pybuild
--- dh-python-6.20231223ubuntu2/pybuild	2023-12-24 00:06:52.0 +
+++ dh-python-6.20231223ubuntu3/pybuild	2024-03-12 15:32:49.0 +
@@ -524,6 +524,9 @@
 tests.add_argument('--test-tox', action='store_true',
default=environ.get('PYBUILD_TEST_TOX') == '1',
help='use tox in --test step')
+tests.add_argument('--test-stestr', action='store_true',
+   default=environ.get('PYBUILD_TEST_STESTR') == '1',
+   help='use stestr in --test step')
 tests.add_argument('--test-custom', action='store_true',
default=environ.get('PYBUILD_TEST_CUSTOM') == '1',
help='use custom command in --test step')
@@ -581,7 +584,7 @@
 args.versions = versions
 
 if args.test_nose or args.test_nose2 or args.test_pytest or args.test_tox\
-   or args.test_custom or args.system == 'custom':
+   or args.test_stestr or args.test_custom or args.system == 'custom':
 args.custom_tests = True
 else:
 args.custom_tests = False
diff -Nru dh-python-6.20231223ubuntu2/pybuild.rst dh-python-6.20231223ubuntu3/pybuild.rst
--- dh-python-6.20231223ubuntu2/pybuild.rst	2023-12-24 00:06:52.0 +
+++ dh-python-6.20231223ubuntu3/pybuild.rst	2024-03-12 15:33:22.0 +
@@ -101,6 +101,9 @@
 --test-tox
 use tox command in test step, remember to add tox
 to Build-Depends. Requires tox.ini file
+--test-stestr
+use stestr command in test step, remember to add python-stestr and/or
+python3-stestr to Build-Depends.
 --test-custom
 	use a custom command in the test step. The full test command is then
 	specified with `--test-args` or by setting the `PYBUILD_TEST_ARGS`

Bug#1064762: Works with vtk9.3 installed in venv via pip (was Re: dune-grid: FTBFS: make[1]: *** [/usr/share/dune/dune-debian.mk:39: override_dh_auto_test] Error 1)

[Markus Blatt]

Hi,

I did some further tests with the provided test case.

If I install vtk (latest version 9.3) with pip in a venve. The script also does
not report an error for the relative paths. Tested on stable and in a sid 
chroot.

Best,

Markus

Bug#1059479: r-b CI tests very slow

[Holger Levsen]

On Tue, Dec 26, 2023 at 05:50:47PM +, Holger Levsen wrote:
> packages tested on average per day in the last week   596 3484482 
> 348
> packages tested on average per day in the last 4 weeks774 4351
> 546 339
> packages tested on average per day in the last 3 months 1018  2987916 
> 359
> packages tested on average per day in the last year   144618621331
> 658

update from today, 12:04 UTC

packages tested yesterday (2024-03-11)  687 960 226 321
packages tested today (2024-03-12)  263 1524181 196
packages tested in the last 24h 633 1909339 451
packages tested on average per day in the last week 607 105274  
95
packages tested on average per day in the last 4 weeks  181 174888  
67
packages tested on average per day in the last 3 months 379 2282
296 217
packages tested on average per day in the last year 104918401036
523

update from today, 16:04 UTC

packages tested yesterday (2024-03-11)  689 961 226 321
packages tested today (2024-03-12)  368 2419299 248
packages tested in the last 24h 601 2721449 425
packages tested on average per day in the last week 625 120394  
103
packages tested on average per day in the last 4 weeks  183 176192  
68
packages tested on average per day in the last 3 months 380 2283
297 217
packages tested on average per day in the last year 104818421035
522

since Saturday we, mostly Mattia, made some relevant changes how we run our
build service (basically now >100 slices, compared to 1 before), so now oomd is
killing the build service and thus all builds several times a day. since 2h
all workers are enabled again, before we were running with less.

so let's revisit this in a week and in 4 weeks. :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

wirklicher reichtum ist nicht privatjet fliegen, sondern sich vor dem schützen
können, was privatjet fliegen auslöst." <3 böhmermann am 3.2.23


signature.asc
Description: PGP signature

Bug#1055016: override: tasksel-data:admin/optional

[Diederik de Haas]

On Sunday, 29 October 2023 12:54:13 CET Cyril Brulebois wrote:
> Daniel Lewart  (2023-10-29):
> > Package: ftp.debian.org
> > Severity: normal
> > User: ftp.debian@packages.debian.org
> > Usertags: override
> > X-Debbugs-Cc: task...@packages.debian.org, debian-b...@lists.debian.org,
> > 855...@bugs.debian.org, 954...@bugs.debian.org Control: affects -1 +
> > src:tasksel
> > 
> > FTP Team,
> > 
> > #855151 - tasksel: should not be Priority: important
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855151
> > 
> > #954090 - override: tasksel:admin/optional
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954090
> > 
> > However, tasksel is still installed by default because of the following:
> > $ apt-cache show tasksel-data | grep -E '^(Package|Depends|Priority)'
> > Package: tasksel-data
> > Depends: tasksel (= 3.73)
> > Priority: important
> > 
> > Please change tasksel-data from:
> > admin/important
> > 
> > to:
> > admin/optional
> 
> It's probably safe since pkgsel's postinst features:
> 
> if db_get pkgsel/run_tasksel && [ "$RET" = true ]; then
> log "starting tasksel"
> db_progress INFO pkgsel/progress/tasksel
> apt-install tasksel  # ensure tasksel is installed
> 

I just ran into this issue too wondering why tasksel-data (and its Depends/
Recommends) got installed.
So hereby a +1 on changing it to ``admin/optional``.

Cheers,
  Diederik

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

Bug#1065913: opm-common: Please drop dependencies on python3-distutils

[Markus Blatt]

Hi,

the dependency is alread gone  version 2023.10+ds-2 and later (unstable). We
just need to wait for their migration to testing.

Best,

Markus

Bug#1066081: ntpsec: ntpd reports error about missing /var/log/ntpsec

[Richard Laager]

Control: reopen -1

On 2024-03-12 11:10, MOESSBAUER, Felix wrote:

On Tue, 2024-03-12 at 10:33 -0500, Richard Laager wrote:

This is intentional. The logging is optional and whether the
directory
exists controls this.


Hi Richard,

that's a quite uncommon interface. Is this at least documented
somewhere?


ntp.conf


Also the "error" should be downgraded to a "warning" at
least.


Didn't I do that?

commit b06f1d8177a9b0a2593947a2ebefcb43e94ac281
Author: Santiago Vila 
Date:   Sun Dec 24 15:36:25 2023 -0600

Downgrade missing stats dir log severity

The Debian package does not create /var/log/ntpsec by default.  The
admin  is directed (by a comment in ntp.conf) to create it if and only
if they want logging.  However, upstream ntpsec logs an error message
if the log directory does not exist.

Closes: 1049424
Signed-off-by: Richard Laager 
[The commit message / patch description is my wording.]



One advantage of that is the ntpsec-ntpviz package can create that
directory to enable logging, which is required for ntpviz to be
useful.
Otherwise, it would have to edit the config file, which is riskier.


Well... for that conf.d style configs are usually used.


Yeah. ntpsec supports those _now_. (I don't know that it did at the 
time.) So maybe that's a better answer.


--
Richard



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053565: RFS: openvpn3-client/21+dfsg-1 [ITP] -- virtual private network daemon (version 3)

[Andrew Lee]

Package: sponsorship-requests
Followup-For: Bug #1053565
X-Debbugs-Cc: ajq...@debian.org

Hi Marc,

Thank you for your efforts in packaging this package into Debian.
I noticed that you conducted a thorough license check and
re-uploaded the package into mentors.

However, there are still some lintian warnings/errors present in
the `debian/copyright` file. Please ensure to check this on the
webpage after uploading, or preferably, run a local lintian check
before uploading or committing.

Additionally, Tobi suggested that the Python component might be
better suited in a dedicated Python module package. What are your
thoughts on this?

Best regards,
-Andrew

Bug#987124: console-setup not work properly with plymouth

[Vladimir K]

If plymouth password prompt is used during boot (i.e. root volume decryption 
from initramfs), just the patch above will not work, also need to add 
plymouth-quit.service to 'After' property in console-setup.service

Bug#1066081: ntpsec: ntpd reports error about missing /var/log/ntpsec

[MOESSBAUER, Felix]

On Tue, 2024-03-12 at 11:15 -0500, Richard Laager wrote:
> Control: reopen -1
> 
> On 2024-03-12 11:10, MOESSBAUER, Felix wrote:
> > On Tue, 2024-03-12 at 10:33 -0500, Richard Laager wrote:
> > > This is intentional. The logging is optional and whether the
> > > directory
> > > exists controls this.
> > 
> > Hi Richard,
> > 
> > that's a quite uncommon interface. Is this at least documented
> > somewhere?
> 
> ntp.conf

Okayy... I was just looking at the manpage.

> 
> > Also the "error" should be downgraded to a "warning" at
> > least.
> 
> Didn't I do that?

Right. I re-tested on a bookworm system where this issue first popped
up. Anyways, thanks for the pointer.

Felix
> > 

-- 
Siemens AG, Technology
Linux Expert Center

Bug#1066099: icingaweb2-module-map: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-map
Version: 1.1.0-4
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for icingaweb2-module-map
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers

icingaweb2-module-map_1.1.0-4_templates.pot.bz2
Description: application/bzip

Bug#1066100: freeciv: new cities unmanageable in a long game

[Giacomo Mulas]

Package: freeciv
Version: 3.1.0+ds-1
Severity: normal

Dear Maintainer,

in a long game with a huge map, I hit a weird bug. 
New cities are unmanageable, i.e. I cannot:
- change their production
- set them as "home" for any unit
- add settlers to them
etc.

I will send a saved game that shows this in an additional subsequent message to 
this bug report.

Bye, thanks in advance
Giacomo

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

Kernel: Linux 6.7.7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 freeciv depends on:
ii  freeciv-client-gtk3  3.1.0+ds-1
ii  freeciv-data 3.1.0+ds-1

freeciv recommends no packages.

freeciv suggests no packages.

-- no debconf information

Bug#1059331: spip: XSS issue fixed in 4.1.13 upstream

[Santiago Ruano Rincón]

Control: fixed -1 3.2.11-3+deb11u10

https://tracker.debian.org/news/1500839/accepted-spip-3211-3deb11u10-source-into-oldstable-proposed-updates/

On Fri, 22 Dec 2023 16:57:40 +0100 Salvatore Bonaccorso  
wrote:
> Source: spip
> Version: 4.1.12+dfsg-1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> Control: fixed -1 4.1.13+dfsg-1
> Control: found -1 4.1.9+dfsg-1+deb12u2
> Control: found -1 3.2.11-3+deb11u9
> 
> Filling a bug for tracking (as otherwise beeing a unspecified TEMP
> entry), as the issue has no CVE: 4.1.13 fixes an issue:
> 
>* fix: les modèles insérés dans un texte héritent automatiquement du
>  contexte, a l'insu des redacteurs. Securiser ce qui proviendrait de
>  variables envoyées par l'utilisateur
> 
> https://tracker.debian.org/news/1488834/accepted-spip-4113dfsg-1-source-into-unstable/
> 
> Regards,
> Salvatore


signature.asc
Description: PGP signature

Bug#1066081: ntpsec: ntpd reports error about missing /var/log/ntpsec

[Richard Laager]

(Replying via mobile, so non-Debian address.)

It should be reasonably possible to convert this to .d style. I will have to 
dig into this to fully consider all the implications, especially around 
handling upgrades. I think part of the issue here is that ntpd logs there by 
default. That is, you don’t turn on logging. I’m not sure if there is a way to 
turn off logging. But I have to check.

I want to maintain the same posture we have now:

- No logs by default. Most people don’t use them, so this is pointless I/O.
- People can enable logs reasonably easily.
- Installing ntpviz automatically enables logs.

For upgrades, I can use the presence or absence of the directory for most of 
the handling. I do need to think through what happens / what to do if someone 
has customized any of the other log settings.

-- 
Richard

Bug#1065764: libstb: diff for NMU version 0.0~git20230129.5736b15+ds-1.2

[Andrey Rakhmatullin]

Control: tags 1065764 + patch
Control: tags 1065764 + pending

Dear maintainer,

I've prepared an NMU for libstb (versioned as 0.0~git20230129.5736b15+ds-1.2) 
and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
WBR, wRAR
diff -Nru libstb-0.0~git20230129.5736b15+ds/debian/changelog libstb-0.0~git20230129.5736b15+ds/debian/changelog
--- libstb-0.0~git20230129.5736b15+ds/debian/changelog	2024-02-29 00:04:59.0 +0500
+++ libstb-0.0~git20230129.5736b15+ds/debian/changelog	2024-03-12 21:40:23.0 +0500
@@ -1,3 +1,10 @@
+libstb (0.0~git20230129.5736b15+ds-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with -Werror=implicit-function-declaration (Closes: #1065764).
+
+ -- Andrey Rakhmatullin   Tue, 12 Mar 2024 21:40:23 +0500
+
 libstb (0.0~git20230129.5736b15+ds-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libstb-0.0~git20230129.5736b15+ds/debian/patches/fix-implicit-function-declaration.patch libstb-0.0~git20230129.5736b15+ds/debian/patches/fix-implicit-function-declaration.patch
--- libstb-0.0~git20230129.5736b15+ds/debian/patches/fix-implicit-function-declaration.patch	1970-01-01 05:00:00.0 +0500
+++ libstb-0.0~git20230129.5736b15+ds/debian/patches/fix-implicit-function-declaration.patch	2024-03-12 21:40:23.0 +0500
@@ -0,0 +1,29 @@
+Description: Add missing header includes.
+Author: Andrey Rakhmatullin 
+Bug-Debian: https://bugs.debian.org/1065764
+Last-Update: 2024-03-12
+Index: libstb-0.0~git20230129.5736b15+ds/stb_divide.h
+===
+--- libstb-0.0~git20230129.5736b15+ds.orig/stb_divide.h
 libstb-0.0~git20230129.5736b15+ds/stb_divide.h
+@@ -102,6 +102,8 @@ extern int stb_mod_eucl (int value_to_be
+ }
+ #endif
+ 
++#include 
++
+ #ifdef STB_DIVIDE_IMPLEMENTATION
+ 
+ #if defined(__STDC_VERSION) && __STDC_VERSION__ >= 19901
+Index: libstb-0.0~git20230129.5736b15+ds/stb_dxt.h
+===
+--- libstb-0.0~git20230129.5736b15+ds.orig/stb_dxt.h
 libstb-0.0~git20230129.5736b15+ds/stb_dxt.h
+@@ -83,6 +83,7 @@ STBDDEF void stb_compress_bc5_block(unsi
+ // #define STB_DXT_USE_ROUNDING_BIAS
+ 
+ #include 
++#include 
+ 
+ #if !defined(STBD_FABS)
+ #include 
diff -Nru libstb-0.0~git20230129.5736b15+ds/debian/patches/series libstb-0.0~git20230129.5736b15+ds/debian/patches/series
--- libstb-0.0~git20230129.5736b15+ds/debian/patches/series	2023-02-08 08:28:47.0 +0500
+++ libstb-0.0~git20230129.5736b15+ds/debian/patches/series	2024-03-12 21:40:23.0 +0500
@@ -6,3 +6,4 @@
 0006-tests-Makefile-refactor.patch
 0007-tests-image_test.c-use-library.patch
 0008-tests-image_write_test.c-use-library.patch
+fix-implicit-function-declaration.patch


signature.asc
Description: PGP signature

Bug#895570: devscripts: wrap-and-sort should default to -ast (--wrap-always, --short-indent, --trailing-comma)

[Paride Legovini]

On 2024-03-12 00:33, Johannes Schauer Marin Rodrigues wrote:
> Hi,
> 
> On Wed, 6 Mar 2024 11:04:01 +0100 Paride Legovini  wrote:
>> On Sun, 03 Mar 2024 16:26:41 +0100 Benjamin Drung  wrote:
>>> Time to join this discussion. The current default was the preference of
>>> the author 14 years ago. My taste has change a bit since then. I am open
>>> to change the default. --trailing-comma for wrapped lines is a good
>>> idea, --short-indent is okay. I don't like --wrap-always in case there
>>> are only two or three entries.
>>>
>>> The new default should not only based on the preference, but also on
>>> what is used the most. Can someone collect the information: which teams
>>> use which options, how many packages use what?
>>
>> I did some unscientific research on codesearch looking for d/changelog 
>> entries
>> mentioning `wrap-and-sort -` (i.e. wrap-and-sort with some options). This is
>> the query:
>>
>> https://codesearch.debian.net/search?q=path%3Adebian%2Fchangelog+wrap-and-sort+-&literal=1
>>
>> Apparently -a is the single most used option, very often used together with
>> -s and -t. I found similar results by searching GitHub:
>>
>> https://github.com/search?q=path%3Adebian%2Fchangelog+%22wrap-and-sort+-%22&type=code
>>
>> Looks like salsa (GitLab Free) doesn't allow to do instance-wide code 
>> searches.
> 
> I disagree that the new default should be what is used the most. For example
> debhelper versions do not become the default only after they are used the 
> most.
> The thing that makes switching defaults easier for debhelper is the explicit
> opt-in for a new debhelper compat version which we don't have for 
> wrap-and-sort
> and I think it would very much be over-engineering to add such a feature for
> something that is, in my opinion, of very little consequence. Furthermore, I
> would not be surprised if many people using wrap-and-sort use the default
> expecting that this is what is most well-liked by the project (because why 
> else
> would it be the default?). The question was asked in this email sub-thread:
> 
> https://lists.debian.org/161289428547.4135738.4002254931040787...@auryn.jones.dk
> 
> In that thread, same as in this bug, -ast was proposed as the default and
> unless I missed something, there were no objections on debian-devel. Some even
> argued, to make -b the default as well. So instead of asking "what is used
> most" I'd like to ask, are there users of wrap-and-sort without -ast who would
> be strongly against having to pass -AST to overwrite a potential new default?
> 
> That being said, I downloaded all debian/control files for all 36832 source
> packages in Debian and ran the following shell script on them to figure out 
> how
> many source packages comply with which wrap-and-sort set of options:
> 
> for p in control/*; do
>   rm -f debian/control;
>   ln -s "../$p" debian/control;
>   for opt in "" -a -as -ast -astb -at -atb -ab -s -st -stb -sb -t -tb -b; 
> do
>   wrap-and-sort --dry-run --file=debian/control $opt \
>   | grep --quiet debian/control \
>   || echo $p >> w-a-s$opt;
>   done
> done
> 
> It's of course still not possible to say whether a control file adheres to a
> certain wrap-and-sort formatting style by accident or intentionally. Also,
> packages can easily fall in multiple categories at the same time, for example
> packages with only a single binary package which comply with -ast will
> automatically also comply with -astb. There are also packages which comply 
> with
> -ast as well as with no options at all simply because they have no
> Build-Depends nor Depends fields in debian/control. Here is the result sorted
> by popularity in ascending order:
> 
> 96 wrap-and-sort -st
> 96 wrap-and-sort -stb
>434 wrap-and-sort -as
>465 wrap-and-sort -tb
>489 wrap-and-sort -t
>579 wrap-and-sort -atb
>641 wrap-and-sort -at
>   1341 wrap-and-sort -sb
>   1405 wrap-and-sort -s
>   2381 wrap-and-sort -astb
>   2705 wrap-and-sort -ast
>   2732 wrap-and-sort -b
>   3020 wrap-and-sort
>   3950 wrap-and-sort -ab
>   4089 wrap-and-sort -a
> 
> So, wrap-and-sort -ast is very popular but it is not as popular as the current
> default.

Hi josch and thanks for this analysis. I'll try to recap where we are at this
point, focusing only on -ast (I'll ignore -bk here).

1. This bug (#895570) requests -ast to be the default. The proposal received
mostly positive feedback, however bdrung doesn't like -a in case there are
only two or three entries. He also thinks we should consider what is already
popular.

--> Looks like everybody likes (or is ok with) having -st by default.

2. Using codesearch I looked for what options are the most popular when
w-a-s is mentioned with options in d/changelog. Looks like the most
popular option is -a (often together with others).

3. josch checked how many src packages in the archive are already compliant
with a w-a-s option set, and found results which

Bug#1066101: icingaweb2-module-pnp: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-pnp
Version: 1.1.0-4
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for icingaweb2-module-pnp
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers

Bug#1036884: transition: time64_t

[Emanuele Rocca]

[ debian-rust added to CC ]

Hi,

On 2024-03-12 11:03, Simon McVittie wrote:
> In the medium term, cargo needs re-bootstrapping on the affected
> architectures (armel and armhf, plus a bunch of -ports architectures
> where as far as I can see cargo was never available in the past) -
> that's #1065787, and Steve already replied to that bug describing how
> Ubuntu did this.

I don't think Ubuntu actually fixed cargo yet, at least if the data in
UDD is reliable -- and if I'm looking in the right place. :-)

udd=> select source,version,date from ubuntu_upload_history where 
source='cargo' order by date desc limit 2;
 source |  version   |  date  
++
 cargo  | 0.67.1+ds0ubuntu0.libgit2-0ubuntu0.20.04.2 | 2023-07-05 09:36:28+00
 cargo  | 0.67.1+ds0ubuntu0.libgit2-0ubuntu0.22.04.2 | 2023-07-05 09:36:27+00
(2 rows)

Maybe when Steve mentioned the work done in Ubuntu on
https://bugs.debian.org/1065787#22 he meant other packages?

> Is there a porter who can take responsibility for that?

I did manage to get cargo to build in a armhf chroot by manually
installing the various deps, see the build artifacts at
https://people.debian.org/~ema/cargo/. I can work on armel next. The
tests are green but maybe there's some more meaningful validation we can
do before uploading? Anyone from debian-rust has ideas or comments?

Bug#1066103: icingaweb2-module-cube: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-cube
Version: 1.3.2-1
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for
icingaweb2-module-cube
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers

Bug#1066104: icingaweb2-module-graphite: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-graphite

Version: 1.2.2-3

Severity: wishlist

Tags: patch l10n



Please find the updated German po file translation for
icingaweb2-module-graphite

attached.



If you update your template, please use

'msgfmt --statistics '

to check the po-files for fuzzy or untranslated strings.



If there are such strings, please contact me so I can update the

German translation.



Yours

Hermann-Josef Beckers





icingaweb2-module-graphite_1.2.2-3_templates.pot.bz2
Description: application/bzip

Bug#1066105: icingaweb2-module-cube: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-cube
Version: 1.3.2-1
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for
icingaweb2-module-cube
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers


icingaweb2-module-cube_1.3.2-1_templates.pot.bz2
Description: application/bzip

Bug#1066106: icingaweb2-module-nagvis: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-nagvis
Version: 1.1.1-4
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for
icingaweb2-module-nagvis
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers


icingaweb2-module-nagvis_1.1.1-4_templates.pot.bz2
Description: application/bzip

Bug#1066107: icingaweb2-module-pnp: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-pnp
Version: 1.1.0-4
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for icingaweb2-module-pnp
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers

icingaweb2-module-pnp_1.1.0-4_templates.pot.bz2
Description: application/bzip

Bug#1063376: Create bugs against ftp.debian.org to enable removal of 32bit architectures for all r-bioc-rhtslib rdepends

[Andreas Tille]

clone 1063379 -1
block 1063376 by -1
retitle -1 RM: r-bioc-ballgown [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -1 + src:r-bioc-ballgown

clone 1063379 -2
block 1063376 by -2
retitle -2 RM: r-bioc-cner [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -2 + src:r-bioc-cner

clone 1063379 -3
block 1063376 by -3
retitle -3 RM: r-bioc-biovizbase [armel armhf i386 hppa m68k powerpc sh4] -- 
ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -3 + src:r-bioc-biovizbase

clone 1063379 -4
block 1063376 by -4
retitle -4 RM: r-bioc-bsseq [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -4 + src:r-bioc-bsseq

clone 1063379 -5
block 1063376 by -5
retitle -5 RM: r-bioc-cummerbund [armel armhf i386 hppa m68k powerpc sh4] -- 
ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -5 + src:r-bioc-cummerbund

clone 1063379 -6
block 1063376 by -6
retitle -6 RM: r-bioc-dada2 [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -6 + src:r-bioc-dada2

clone 1063379 -7
block 1063376 by -7
retitle -7 RM: r-bioc-dss [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -7 + src:r-bioc-dss

clone 1063379 -8
block 1063376 by -8
retitle -8 RM: r-bioc-dexseq [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -8 + src:r-bioc-dexseq

clone 1063379 -9
block 1063376 by -9
retitle -9 RM: r-bioc-degnorm [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -9 + src:r-bioc-degnorm

clone 1063379 -10
block 1063376 by -10
retitle -10 RM: r-bioc-demixt [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -10 + src:r-bioc-demixt

clone 1063379 -11
block 1063376 by -11
retitle -11 RM: r-bioc-genomicfiles [armel armhf i386 hppa m68k powerpc sh4] -- 
ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -11 + src:r-bioc-genomicfiles

clone 1063379 -12
block 1063376 by -12
retitle -12 RM: r-bioc-genelendatabase [armel armhf i386 hppa m68k powerpc sh4] 
-- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -12 + src:r-bioc-genelendatabase

clone 1063379 -13
block 1063376 by -13
retitle -13 RM: r-bioc-goseq [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -13 + src:r-bioc-goseq

clone 1063379 -14
block 1063376 by -14
retitle -14 RM: r-bioc-genomicfeatures [armel armhf i386 hppa m68k powerpc sh4] 
-- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -14 + src:r-bioc-genomicfeatures

clone 1063379 -15
block 1063376 by -15
retitle -15 RM: r-bioc-edaseq [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -15 + src:r-bioc-edaseq

clone 1063379 -16
block 1063376 by -16
retitle -16 RM: r-bioc-genomicalignments [armel armhf i386 hppa m68k powerpc 
sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -16 + src:r-bioc-genomicalignments

clone 1063379 -17
block 1063376 by -17
retitle -17 RM: r-bioc-ioniser [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -17 + src:r-bioc-ioniser

clone 1063379 -18
block 1063376 by -18
retitle -18 RM: r-bioc-grohmm [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -18 + src:r-bioc-grohmm

clone 1063379 -19
block 1063376 by -19
retitle -19 RM: r-bioc-isoformswitchanalyzer [armel armhf i386 hppa m68k 
powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures 
any more
affects -19 + src:r-bioc-isoformswitchanalyzer

clone 1063379 -20
block 1063376 by -20
retitle -20 RM: r-bioc-gviz [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -20 + src:r-bioc-gviz

clone 1063379 -21
block 1063376 by -21
retitle -21 RM: r-bioc-organismdbi [armel armhf i386 hppa m68k powerpc sh4] -- 
ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -21 + src:r-bioc-organismdbi

clone 1063379 -22
block 1063376 by -22
retitle -22 RM: r-bioc-mutationalpatterns [armel armhf i386 hppa m68k powerpc 
sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -22 + src:r-bioc-mutationalpatterns

clone 1063379 -23
block 1063376 by -23
retitle -23 RM: r-bioc-rgsepd [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-b

Bug#1065611: Additional support for SolidRun HoneyComb

[Diederik de Haas]

Hi Josua,

On Tuesday, 12 March 2024 16:28:06 CET Josua Mayer wrote:
> I believe I found the answer:
> EDAC_MPC85XX is for power-pc only,
> EDAC_LAYERSCAPE is for arm (see drivers/edac/layerscape_edac.c).

You're right. In the commit I referenced earlier (ea2eb9a8b6207ee4),
I misinterpreted the commit message.
That commit also created ``drivers/edac/fsl_ddr_edac.c`` which got the arch 
independent (or at least dual arch) parts. Its header has this:
```
 * Support Power-based SoCs including MPC85xx, MPC86xx, MPC83xx and
 * ARM-based Layerscape SoCs including LS2xxx. Originally split
 * out from mpc85xx_edac EDAC driver.
```

> Am 12.03.24 um 16:13 schrieb Josua Mayer:
> >
> > Thank you for taking care of this!
> > First the additional changes you found seem reasonable.

Excellent, then I'll make a MR for them (except EDAC_MPC85XX):
- drivers/hwmon/pmbus: Enable PMBUS, SENSORS_PMBUS and
   SENSORS_LTC2978 as modules
- drivers/nvmem: Enable NVMEM_LAYERSCAPE_SFP as module
- drivers/rtc: Enable RTC_DRV_FSL_FTM_ALARM as module
- drivers/soc/fsl: Enable FSL_RCPM

> > Regarding edac - I checked NXPs reference BSP for LX2160,
> > and their linux fork has the same status, driver can not be enabled on
> > arm64.
> > However I also agree it should be enabled if it were possible.
> > The driver appears to setup ecc bit error interrupts so that hey can be
> > reported by Linux.
> > ...
> > I may have access to an lx2160a system with ecc memory within the coming
> > week, so I could test (on vendor kernel based on 5.10 only) whether any
> > problems show up. If not, perhaps a patch to the kernel is advisable.

As EDAC_LAYERSCAPE got enabled in 5.5.17-1 via bug 948576 (with a patch from 
you), ECC support should already work with the Stable 6.1 kernel (or newer).

> > Am 07.03.24 um 13:34 schrieb Diederik de Haas:
> >> On Thursday, 18 January 2024 17:40:38 CET Josua Mayer wrote:
> >> 
> >>> LX2160 SoC early silicon revisions have a pci-e generation 4
> >>> controller.
> >>> It requires a different driver from newer gen-3 silicon.
> >>>
> >>> This affects the SolidRun Honeycomb Workstation which
> >>> is otherwise fully supported in Debian.
> >> 
> >> I cloned bug report #1061116 into #1065611 to discuss some additional
> >> support for the SolidRun HoneyComb.
> >>
> >> I analyzed the HoneyComb dts file and the following included .dtsi
> >> files:
> >> - arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
> >> - arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
> >> - arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi

If my MR gets merged, then there's truly full support in Debian :)

Cheers,
  Diederik

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

Bug#1065806: pam: recent upgrade changes previous default umask

[Antoine Le Gonidec]

The change of behaviour can have an unexpected and quite nasty
side-effect, by applying a misconfiguration that was ignored until this
update.

A setting of "UMASK 077" in /etc/login.defs was ignored before this
update, and is now applied (as it should) leading to unreadable files
if the user is not expecting it.

In my case this was a misconfiguration, as I thought it was a setting
applied only to the $HOME directory itself (I should have used
"HOME_MODE 0700" instead). But since it had no effect until the recent
update, I got taken by surprise with files generated with rw-rw
permissions when I was expecting the regular rw-r--r--.

I am not bumping the severity of this bug report because the new
behaviour is the correct one, but it should be kept in mind that other
people might get unexpected effects from this update.

Bug#1066102: icingaweb2-module-nagvis: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-nagvis
Version: 1.1.1-4
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for
icingaweb2-module-nagvis
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers

Bug#1066108: intel-microcode: CVE-2023-43490 CVE-2023-39368 CVE-2023-38575 CVE-2023-22655 CVE-2023-28746

[Salvatore Bonaccorso]

Source: intel-microcode
Version: 3.20231114.1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.20231114.1~deb12u1
Control: found -1 3.20231114.1~deb11u1

Hi,

The following vulnerabilities were published for intel-microcode.

CVE-2023-43490[0], CVE-2023-39368[1], CVE-2023-38575[2],
CVE-2023-22655[3] and CVE-2023-28746[4].


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-43490
https://www.cve.org/CVERecord?id=CVE-2023-43490

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01045.html
[1] https://security-tracker.debian.org/tracker/CVE-2023-39368
https://www.cve.org/CVERecord?id=CVE-2023-39368

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00972.html
[2] https://security-tracker.debian.org/tracker/CVE-2023-38575
https://www.cve.org/CVERecord?id=CVE-2023-38575

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00982.html
[3] https://security-tracker.debian.org/tracker/CVE-2023-22655
https://www.cve.org/CVERecord?id=CVE-2023-22655

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00960.html
[4] https://security-tracker.debian.org/tracker/CVE-2023-28746
https://www.cve.org/CVERecord?id=CVE-2023-28746

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00898.html

https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/register-file-data-sampling.html

I think we should do a classical top-down approach here, let it first
go through unstable. We can decide if we want to postpone it trough
the point release afterwards or go via a point release.

Regards,
Salvatore

Bug#1065759: Retitle libbio-samtools-perl: FTBFS on arm{el,hf}: lib/Bio/DB/Sam.xs:324:4: error: implicit declaration of function ‘bam_sort_core’; did you mean ‘bam_format1_core’? [-Werror=implicit-fun

[Andreas Tille]

Control: retitle -1 libbio-samtools-perl: FTBFS: lib/Bio/DB/Sam.xs:324:4: 
error: implicit declaration of function ‘bam_sort_core’; did you mean 
‘bam_format1_core’? [-Werror=implicit-function-declaration]
Control: tags -1 help
thanks

I can confirm that this bug also occures on amd64 thus removing the
arm-restriction from the title.  Unfortunately I have no idea how to fix
this (except by possibly suppressing the -Werror=implicit-function-declaration
option).  Thus tagging 'help'

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1065767: libopendbx: FTBFS on arm{el,hf}: mssql_basic.c:324:21: error: implicit declaration of function ‘dbpoll’ [-Werror=implicit-function-declaration]

[Andrey Rakhmatullin]

On Sat, Mar 09, 2024 at 09:26:38PM +0100, Sebastian Ramacher wrote:
> mssql_basic.c: In function ‘mssql_odbx_result’:
> mssql_basic.c:324:21: error: implicit declaration of function ‘dbpoll’ 
> [-Werror=implicit-function-declaration]
>   324 | if( dbpoll( dbproc, ms, &cdbproc, &reason ) == FAIL ) 
> { return -ODBX_ERR_BACKEND; }
>   | ^~
dbpoll() is unimplemented: 
https://github.com/FreeTDS/freetds/blob/4a6356010ef1e841bcdf3d26f8bbacbf2262d525/src/dblib/dblib.c#L7211
Thus its prototype is only available under #ifdef DBLIB_UNIMPLEMENTED,
whatever semantics does that have (I couldn't find docs for that).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1066055: rust-symphonia-core: FTBFS on i386 units::tests::verify_timebase panic

[Peter Green]

rust-symphonia-core appears to FTBFS from an i386 sbuild chroot with a
test 'units::tests::verify_timebase' panicking

 units::tests::verify_timebase stdout 
thread 'units::tests::verify_timebase' panicked at 'assertion failed:  
`(left == right)`

   left: `4503599627370496`,
  right: `4503599627370497`', src/units.rs:257:9


The code in question is.

>assert_eq!(
>tb1.calc_timestamp(Time::new(14_073_748_835_532, 0.803125)),
>0x10___0001
>);

Given the appearance of a floating point number in the test, this is
almost certainly caused by a difference in floating point rounding
behaviour on x87 (which is used by the Debian i386 port) compared
to modern FPUs.

On modern FPUs, values are rounded to their "storage format" after
every operation. On x87 this is not the case, floating point
values have more precision when stored in registers than when
stored in memory. Usually this just results in calculations
being slightly more accurate than they would be on a modern
FPU, but it can become a problem if repeatability is more
important than accuracy, or if algorithms are carefully designed
to take account of rounding and then the rounding they expect
does not happen.

The questions this leaves are as follows.

1. Does this (and any other similar test failures) represent a
   significant behavioural difference that would render symphonia
   unwise to use on Debian i386? or does it just represent an
   overzealous test? This is something that should ideally be
   discussed with upstream, though I don't know if their response
   will be positive.
2. Is it worth expending effort on getting symphonia available on
   i386? to me that depends on what software is using or planning
   to use it. For a port in it's twilight years, keeping existing
   software working seems more important than making new software
   available.

Bug#1036884: transition: time64_t

[Fabian Grünbichler]

On Tue, Mar 12, 2024 at 05:55:59PM +0100, Emanuele Rocca wrote:
> [ debian-rust added to CC ]
> 
> Hi,
> 
> On 2024-03-12 11:03, Simon McVittie wrote:
> > In the medium term, cargo needs re-bootstrapping on the affected
> > architectures (armel and armhf, plus a bunch of -ports architectures
> > where as far as I can see cargo was never available in the past) -
> > that's #1065787, and Steve already replied to that bug describing how
> > Ubuntu did this.
> 
> I don't think Ubuntu actually fixed cargo yet, at least if the data in
> UDD is reliable -- and if I'm looking in the right place. :-)
>
> udd=> select source,version,date from ubuntu_upload_history where 
> source='cargo' order by date desc limit 2;
>  source |  version   |  date  
> ++
>  cargo  | 0.67.1+ds0ubuntu0.libgit2-0ubuntu0.20.04.2 | 2023-07-05 09:36:28+00
>  cargo  | 0.67.1+ds0ubuntu0.libgit2-0ubuntu0.22.04.2 | 2023-07-05 09:36:27+00
> (2 rows)
> 
> Maybe when Steve mentioned the work done in Ubuntu on
> https://bugs.debian.org/1065787#22 he meant other packages?

possibly the "Ubuntu did this" was referring to post-cargo/rustc-merge?

we've planned that as well, and it's about 75% prepared, but I didn't
manage to finish in Debian in time for t64 to kick off so I held off
finalizing it until the dust settles. in hindsight, that might have been
a mistake - src:rustc (the target of the source package merge) comes
with builtin (re)bootstrap support from upstream statically linked
stage0 ;)

> > Is there a porter who can take responsibility for that?
> 
> I did manage to get cargo to build in a armhf chroot by manually
> installing the various deps, see the build artifacts at
> https://people.debian.org/~ema/cargo/. I can work on armel next. The
> tests are green but maybe there's some more meaningful validation we can
> do before uploading? Anyone from debian-rust has ideas or comments?

if the tests are green, you could try a rebuild of rustc and/or cargo
with the built cargo next? I don't think anything else that is packaged
exercises anywhere near that amount of the functionality of cargo ;)

thanks for taking care of this! don't hesitate to holler here or in
#debian-rust/dev/release (ping me for the latter two, I don't read the
full backlog there).

Fabian

Bug#1066109: sudo: pam-script env variables not populated because of sudo change

[Andy Roulin]

Package: sudo
Version: 1.9.13p3-1+deb12u1
Severity: important
Tags: patch
X-Debbugs-Cc: arou...@nvidia.com

Dear Maintainer,

>From sudo version 1.9.4 to version 1.9.14, there is a bug breaking pam-script
environment variables: https://github.com/sudo-project/sudo/issues/318

Because of this bug, pam-script called through a sudo command are not getting
called with the necessary filled PAM_* environment variables for the pam scripts
to perform their checks.

For example, if the command executed is "sudo ls", then a pam-script should get
the PAM_SERVICE populated to be "sudo". That is not the case with debian 12
sudo package where PAM_SERVICE, in this sudo scenario, is simply empty.

Would it be possible to backport the upstream fix or update sudo to 1.9.15 in
the Debian 12 repositories? We are experiencing the same issue described in
the Github link.

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

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

Versions of packages sudo depends on:
ii  init-system-helpers  1.65.2
ii  libaudit11:3.0.9-1
ii  libc62.36-9+deb12u4
ii  libpam-modules   1.5.2-6+deb12u1
ii  libpam0g 1.5.2-6+deb12u1
ii  libselinux1  3.4-1+b6
ii  zlib1g   1:1.2.13.dfsg-1

sudo recommends no packages.

sudo suggests no packages.

-- Configuration Files:
/etc/sudoers [Errno 13] Permission denied: '/etc/sudoers'
/etc/sudoers.d/README [Errno 13] Permission denied: '/etc/sudoers.d/README'

-- no debconf information

Bug#1066055: re: rust-symphonia-core: FTBFS on i386 units::tests::verify_timebase panic

[Mike Gerow]

On Tue, 12 Mar 2024 17:55:42 + Peter Green  wrote:
> 2. Is it worth expending effort on getting symphonia available on
> i386? to me that depends on what software is using or planning
> to use it. For a port in it's twilight years, keeping existing
> software working seems more important than making new software
> available.
Speaking as a user, if this package simply doesn't support i386 I'd be
ok with that outcome.

The main reason I noticed this is because I work on a project that
does clean internal rebuilds of Debian packages, and if this packages
simply shouldn't support i386 any more that resolves it from my
perspective.

Bug#1066100: Acknowledgement (freeciv: new cities unmanageable in a long game)

[Marko Lindqvist]

On Tue, 12 Mar 2024 at 18:42, Giacomo Mulas  wrote:

> Please find attached a saved game on which the bug can be seen.
> Just load the saved game with freeciv and look for the cities of
> Oberhausen or Bischweiler, and try e.g. to change the production in any of
> them, it will not be possible (or at least it is impossible here!).
>
> Bye, thanks in advance
> Giacomo
>

 Reproduced in upstream 3.1 branch, and opened a ticket about other, but
likely related, error messages I saw in the process:
https://redmine.freeciv.org/issues/304


 - ML

Bug#1066110: tracker-extract: regular crash

[Patrice Duroux]

Package: tracker-extract
Version: 3.7~rc-3
Severity: minor

Dear Maintainer,

Don't know if:

1. it is a duplicate to #1064196 but seems not,
2. due to the ongoing t_time transition,
3. somehow involve also a trouble in libfontconfig,

but here is a coredumpctl output:

   PID: 33307 (tracker-extract)
   UID: 1001 (patrice)
   GID: 1001 (patrice)
Signal: 31 (SYS)
 Timestamp: Tue 2024-03-12 19:29:44 CET (8min ago)
  Command Line: /usr/libexec/tracker-extract-3 --socket-fd 3
Executable: /usr/libexec/tracker-extract-3
 Control Group:
/user.slice/user-1001.slice/user@1001.service/background.slice/tracker-miner-
fs-3.service
  Unit: user@1001.service
 User Unit: tracker-miner-fs-3.service
 Slice: user-1001.slice
 Owner UID: 1001 (patrice)
   Boot ID: d3355804fb3a455cb193c8c5c0ddd63b
Machine ID: be351e757dc049ffa300ddbaf0f4856a
  Hostname: kos-moceratops
   Storage: /var/lib/systemd/coredump/core.tracker-
extract.1001.d3355804fb3a455cb193c8c5c0ddd63b.33307.171026818400.zst
(present)
  Size on Disk: 15.4M
   Message: Process 33307 (tracker-extract) of user 1001 dumped core.

Module libsystemd.so.0 from deb systemd-255.4-1+b1.amd64
Module libudev.so.1 from deb systemd-255.4-1+b1.amd64
Module libarchive.so.13 from deb libarchive-3.7.2-1.1.amd64
Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64
Stack trace of thread 33311:
#0  0x7ff0c8c0c207 __tgkill (libc.so.6 + 0x10a207)
#1  0x7ff0c8b3e510 __restore_rt (libc.so.6 + 0x3c510)
#2  0x7ff0c8bf95a7 __GI___chmod (libc.so.6 + 0xf75a7)
#3  0x7ff0c54f1d68 n/a (libfontconfig.so.1 + 0xbd68)
#4  0x7ff0c54fc00b n/a (libfontconfig.so.1 + 0x1600b)
#5  0x7ff0c54fc283 FcDirCacheRead (libfontconfig.so.1 +
0x16283)
#6  0x7ff0c54f67f1 n/a (libfontconfig.so.1 + 0x107f1)
#7  0x7ff0c54f68c4 FcConfigBuildFonts (libfontconfig.so.1 +
0x108c4)
#8  0x7ff0c5502d8c FcInitLoadConfigAndFonts
(libfontconfig.so.1 + 0x1cd8c)
#9  0x7ff0c54f2f26 n/a (libfontconfig.so.1 + 0xcf26)
#10 0x7ff0c54f2f8d n/a (libfontconfig.so.1 + 0xcf8d)
#11 0x7ff0bc39e415 n/a (libpangoft2-1.0.so.0 + 0xc415)
#12 0x7ff0c9161ab1 n/a (libglib-2.0.so.0 + 0x87ab1)
#13 0x7ff0c8b8a45c start_thread (libc.so.6 + 0x8845c)
#14 0x7ff0c8c0abbc __clone3 (libc.so.6 + 0x108bbc)

Stack trace of thread 33307:
#0  0x7ff0c8b54810 __GI___isoc99_sscanf (libc.so.6 +
0x52810)
#1  0x7ff0be501002 n/a (libgstreamer-1.0.so.0 + 0xe7002)
#2  0x7ff0be4ffd3c n/a (libgstreamer-1.0.so.0 + 0xe5d3c)
#3  0x7ff0be50015b n/a (libgstreamer-1.0.so.0 + 0xe615b)
#4  0x7ff0be4d5d2e n/a (libgstreamer-1.0.so.0 + 0xbbd2e)
#5  0x7ff0be474623 gst_caps_from_string
(libgstreamer-1.0.so.0 + 0x5a623)
#6  0x7ff0a32604a6 n/a (libgstvideosignal.so + 0x14a6)
#7  0x7ff0c8ec33be g_type_class_ref (libgobject-2.0.so.0 +
0x373be)
#8  0x7ff0be48af12 gst_element_register
(libgstreamer-1.0.so.0 + 0x70f12)
#9  0x7ff0a3260352 n/a (libgstvideosignal.so + 0x1352)
#10 0x7ff0be4b7212 n/a (libgstreamer-1.0.so.0 + 0x9d212)
#11 0x7ff0be4b95ed n/a (libgstreamer-1.0.so.0 + 0x9f5ed)
#12 0x7ff0be4c592d n/a (libgstreamer-1.0.so.0 + 0xab92d)
#13 0x7ff0be4c69ef n/a (libgstreamer-1.0.so.0 + 0xac9ef)
#14 0x7ff0be4c6d6e n/a (libgstreamer-1.0.so.0 + 0xacd6e)
#15 0x7ff0be4c8f26 gst_update_registry
(libgstreamer-1.0.so.0 + 0xaef26)
#16 0x7ff0be456e4a n/a (libgstreamer-1.0.so.0 + 0x3ce4a)
#17 0x7ff0be456f95 n/a (libgstreamer-1.0.so.0 + 0x3cf95)
#18 0x7ff0c9143e99 g_option_context_parse (libglib-2.0.so.0
+ 0x69e99)
#19 0x7ff0be457937 gst_init_check (libgstreamer-1.0.so.0 +
0x3d937)
#20 0x7ff0be4579c8 gst_init (libgstreamer-1.0.so.0 +
0x3d9c8)
#21 0x7ff0beb0f8d2 tracker_extract_module_init (libextract-
gstreamer.so + 0x98d2)
#22 0x7ff0c9228abc n/a (libtracker-extract.so + 0x8abc)
#23 0x7ff0c92296c0 tracker_module_manager_load_modules
(libtracker-extract.so + 0x96c0)
#24 0x55e8434d2be8 main (tracker-extract-3 + 0xbbe8)
#25 0x7ff0c8b296ca __libc_start_call_main (libc.so.6 +
0x276ca)
#26 0x7ff0c8b29785 __libc_start_main_impl (libc.so.6 +
0x27785)
#27 0x55e8434d2fd1 _start (tracker-extr