Bug#1066078: vigor FTBFS due to -Werror=implicit-function-declaration

[Helmut Grohne]

Source: vigor
Version: 0.016-31
Severity: serious
Tags: ftbfs

Due to time64 and thus enabling -Werror=implicit-function-declaration,
vigor now fails to build from source:

| ../../build/../cl/cl_screen.c: In function ‘cl_screen’:
| ../../build/../cl/cl_screen.c:112:25: error: implicit declaration of function 
‘tputs’; did you mean ‘puts’? [-Werror=implicit-function-declaration]
|   112 | tputs(tgoto(clp->cup,
|   | ^
|   | puts
| ../../build/../cl/cl_screen.c:112:31: error: implicit declaration of function 
‘tgoto’ [-Werror=implicit-function-declaration]
|   112 | tputs(tgoto(clp->cup,
|   |   ^
| ../../build/../cl/cl_funcs.c: In function ‘cl_attr’:
| ../../build/../cl/cl_funcs.c:125:39: error: implicit declaration of function 
‘tputs’; did you mean ‘puts’? [-Werror=implicit-function-declaration]
|   125 | (void)tputs(clp->smcup, 1, 
cl_putchar);
|   |   ^
|   |   puts
| ../../build/../cl/cl_read.c: In function ‘block_for_read’:
| ../../build/../cl/cl_read.c:137:9: error: implicit declaration of function 
‘mega_select’ [-Werror=implicit-function-declaration]
|   137 | mega_select(fd+1, , NULL, NULL, NULL);
|   | ^~~
| ../../build/../cl/cl_funcs.c: In function ‘cl_ex_adjust’:
| ../../build/../cl/cl_funcs.c:350:37: error: implicit declaration of function 
‘tgoto’; did you mean ‘v_lgoto’? [-Werror=implicit-function-declaration]
|   350 | (void)tputs(tgoto(clp->cup,
|   | ^
|   | v_lgoto
| ../../build/../cl/cl_funcs.c: In function ‘cl_bell’:
| ../../build/../cl/cl_funcs.c:214:23: warning: ignoring return value of 
‘write’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
|   214 | (void)write(STDOUT_FILENO, "\07", 1);   /* \a 
*/
|   |   ^~
| ../../build/../cl/cl_bsd.c: In function ‘setupterm’:
| ../../build/../cl/cl_bsd.c:176:22: error: implicit declaration of function 
‘tgetent’; did you mean ‘getenv’? [-Werror=implicit-function-declaration]
|   176 | if ((*errp = tgetent(buf, ttype)) > 0) {
|   |  ^~~
|   |  getenv

Helmut

Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small

[Matthew Garrett]

On Sun, Mar 10, 2024 at 10:06:42AM +0800, Sean Whitton wrote:
> Package: tech-ctte
> X-debbugs-cc: csm...@debian.org, lea...@debian.org
> 
> I call for votes on the following ballot to fill a vacant seat on the
> Debian Technical Committee.  The voting period starts immediately and
> lasts for up to one week, or until the outcome is no longer in doubt.
> 
> ===BEGIN
> The Technical Committee recommends that Craig Small  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> C: Recommend to Appoint Craig Small 
> F: Further Discussion
> ===END

I vote C > F


signature.asc
Description: PGP signature

Bug#1065787: 64-bit time_t transition: cargo needs manual intervention

[Steve Langasek]

On Mon, Mar 11, 2024 at 09:07:17PM -0500, Steven Robbins wrote:
> Peter convincingly argues (details in bug) that manual intervention is needed 
> for package "cargo":

> On Sun, 10 Mar 2024 00:48:32 + Peter Michael Green  
> wrote:

> > This will require manual intervention to resolve, either through
> > cross-building or through building manually in a hacked-up build
> > environment.

> > I've certainly seen mention of rustc on #debian-devel recently,
> > so I think the people handling the time_t transition are already
> > aware of this.

> I'm wondering if the time_t people or the rust people could comment on this?  
> This build failure has a surprisingly (to me) long chain of casualties.  Is 
> this an easy thing to fix or is going to take weeks?

The quickest fix for this based on what we've done in Ubuntu is:

- unpack cargo and libstd-rust debs to the root via dpkg-deb -x
- use equivs to mock up packages by these names with no dependencies and
  install those
- bootstrap
- enjoy

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


signature.asc
Description: PGP signature

Bug#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" 

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#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#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#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 

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#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#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#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#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#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=3.9.2-1=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 upgrade : it removes packages when it shouldn't.

[Miguel Angel Rojas]

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

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#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#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#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#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#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#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#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#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#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#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#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#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#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=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]

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#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#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#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#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#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

[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#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#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#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#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#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#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#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#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#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#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#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#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#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#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 ...

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=3.9.2-1=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#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#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#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
> > 

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#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#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#1066130: keystone: please remove extraneous python3-unittest2 build dependency

[Alexandre Detiste]

Source: keystone
Version: 2:24.0.0-3
Severity: normal

This package uses the new "unittest" from the standard library.

Greetings

tchet@brix /tmp/unittest2/keystone.git $ grep unittest2 -r .
./debian/control: python3-unittest2,
tchet@brix /tmp/unittest2/keystone.git $

Bug#1066131: RFS: streamlink/6.7.0-1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 6.7.0.

  * Package name: streamlink
Version : 6.7.0-1
Upstream Author : Streamlink Team
  * URL : https://streamlink.github.io/
  * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
  * Vcs : https://salsa.debian.org/amurzeau/streamlink/
Section : python

It builds those binary packages:
  python3-streamlink - Python module for extracting video streams from
various websites
  python3-streamlink-doc - CLI for extracting video streams from
various websites (documentation)
  streamlink - CLI for extracting video streams from various websites
to a video player


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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.7.0-1.dsc



Changes since the last upload to unstable:
streamlink (6.7.0-1) unstable; urgency=medium

  * New upstream version 6.7.0
  * d/patches: fix tests by resetting the logger level on teardown

 -- Alexis Murzeau   Tue, 12 Mar 2024 23:03:17 +0100

Regards,

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|


OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066137: gnupg2: -Werror=implicit-function-declaration failure testing for ldap_open

[Thorsten Glaser]

clone 1066137 -1
reassign -1 gnupg1 1.4.23-1.1
retitle -1 gnupg1: fails to build gpgkeys_ldap, probably due to 
-Werror=implicit-function-declaration
thanks

Dixi quod…

>This matches the following failure mode at the end of the build:

Same for gnupg1 according to the buildd page:
https://buildd.debian.org/status/package.php?p=gnupg1

>Trying to binNMU gnupg2 to make it installable during t64 transition,

Please do also reduce the B-D as Helmut noted in #980768; specifically,
dropping ghostscript, imagemagick, libcurl4-gnutls-dev and transfig
from src:gnupg2 produces identical binary packages according to his
analysis. Perhaps some of that applies to gnupg1 as well. This will
help tremendously.

Thanks,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

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

[David W]

On Tue, Mar 12, 2024, 06:04 Luca Boccassi  wrote:

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

It's something I set up manually 15 years ago or something, to deal with a
situation where /usr plus some other static directories needed to live on a
different hard drive. Different times...

Obviously not something any installer will ever do, but I don't think it's
against policy? Given that packages depend on usr-is-merged to signal
proper merged state, it shouldn't force you to undo that (especially given
that it's a very risky/tricky operation).

>

Bug#1031802: Move fuse_new_31 to FUSE_3.13?

[Bernd Schubert]

Hi Andrea,

thanks for raising my attention and thanks for the detailed analysis.
Would it help to move that symbol to FUSE_3.13 in the version script
(for example in libfuse-3.17?)?


Thanks,
Bernd

Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture

[Simon McVittie]

On Tue, 12 Mar 2024 at 22:30:01 +0100, Michael Biebl wrote:
> On Wed, 9 Aug 2023 04:05:43 +0200 Bertram Felgenhauer  wrote:
> > My speculation is that this happened while satisfying dependencies for
> > a third party i386 application. That meant installing required 32 bit
> > libraries, and one of them must have come with a polkitd dependency,
> > and the i386 version was selected because I was installing an i386
> > package.
...
> Is there a valid use case where we need/want a foreign systemd/policykit-1?

The valid use-case for polkitd being Multi-Arch: foreign is the scenario
Bertram described: you install third-party, potentially binary-only
i386 software onto an amd64 system, and it depends on polkitd. We want
polkitd:amd64 to be able to satisfy that dependency.

That's also why we want systemd(-sysv) to be Multi-Arch: foreign:
for example the i386-only quake4-server needs systemd (in that case
it's actually a only Recommends, because you don't *need* to use the
systemd units, but it could in principle have been a Depends) and we
want systemd(-sysv):amd64 to satisfy that dependency.

I don't know of any valid use-case for polkitd and systemd(-sysv)
being of an architecture that is not the same as the system's primary
architecture, except for perhaps briefly during crossgrading, but that
isn't what Multi-Arch: foreign means anyway.

"The primary architecture" really just means "the same architecture
as dpkg", and I don't think there is any metadata that could be set on
polkitd or systemd to say that they must be of that same architecture.

smcv

Bug#1066145: debootstrap: fails with multiversion repositories, including Debian’s

[Thorsten Glaser]

Package: debootstrap
Version: 1.0.134
Severity: important

There exist multiversion Packages files, e.g. they can be created
by dpkg-scanpackages -m but dak also occasionally seems to create
them.

I just had multiple attempts at creating a buildd chroot fail.

One was with debootstrap --variant=buildd where perl-modules-5.38
failed the bootstrap because the Packages file contains two versions
of it (5.38.2-3.2 (the one we want) followed by 5.38.2-3). According
to cbmuser, the arch:all part of debian-ports Packages files is an
identical embedded copy of binaries-all/Packages from dak for sid,
so this is not just a debian-ports or mini-dak problem.

Then I tried --variant=minbase which failed the cowbuilder --create
as well but only after the debootstrap stage: debootstrap installed
libaudit-common 1:3.1.2-2 instead of 1:3.1.2-2.1 so the chroot had
libaudit1’s dependency on libaudit-common unfulfilled, which made a
later apt-get dist-upgrade fail without manually running an apt-get
-f install first (which I thankfully could do in a pbuilder hook
script).

This is a real problem affecting real-world scenarios (such as
buildd maintainers frantically trying to stay on top of t64), and
apparently at least arch:all packages can have multiple versions
show up in the Packages file in Debian sid.

The two failure modes are that debootstrap either results in a
chroot in which packages are installed that don’t meet each other’s
dependencies (which a real-world dpkg call would need --force-depends)
or that debootstrap itself even aborts.

The fix is of course to consider all versions of all packages,
though this will be very hard; apt seems to normally only consider
the latest version (unless another is installed or pinned), so
doing that would be another option, which while not being helpful
in situations of nōn-arch:all packages lagging would fix this bug
just as well.


-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: m68k

Kernel: Linux 6.6.15-m68k
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages debootstrap depends on:
ii  wget  1.16.3-3

Versions of packages debootstrap recommends:
pn  arch-test   
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.19-5
ii  mount   2.26.2-9

Versions of packages debootstrap suggests:
ii  binutils2.25.1-1
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  
ii  xz-utils5.1.1alpha+20120614-2.1
pn  zstd

-- no debconf information

Bug#1066123: RFA: rust-colorsys -- Module for color conversion and mutation - Rust source code

[Stephan Lachnit]

Package: wnpp
Severity: normal
X-Debbugs-Cc: rust-color...@packages.debian.org, debian-r...@lists.debian.org, 
stephanlach...@debian.org
Control: affects -1 + src:rust-colorsys

I request an adopter for the rust-colorsys package. If you adopt this package,
please remove me from the uploaders list.

The package description is:
 Works with RGB(a)( as hexadecimal too), HSL(a), CMYK color models and with
ANSI
 color codes
 .
 This package contains the source for the Rust colorsys crate, packaged by
 debcargo for use with cargo and dh-cargo.

Bug#1066124: RFA: rust-enum-iterator -- Tools to iterate over the variants of a field-less enum - Rust source code

[Stephan Lachnit]

Package: wnpp
Severity: normal
X-Debbugs-Cc: rust-enum-itera...@packages.debian.org, 
debian-r...@lists.debian.org, stephanlach...@debian.org
Control: affects -1 + src:rust-enum-iterator

I request an adopter for the rust-enum-iterator package. If you adopt this
package, please remove me from the uploaders list.

The package description is:
 This package contains the source for the Rust enum-iterator crate, packaged by
 debcargo for use with cargo and dh-cargo.

Bug#1066144: python-pyproj: please remove obsolete python3-mock build-dependency

[Alexandre Detiste]

Source: python-pyproj
Version: 3.6.1-3
Severity: normal

Dear Maintainer,

"mock" has been absorbed by the Python standard library as "unittest.mock".

The standalone python3-mock package is deprecated
and slowly being removed from the distribution.

Please remove the stale line from debian/control.

Greetings,

Alexandre

tchet@brix /tmp/python-pyproj $ grep mock -r debian/
debian/changelog:  * Add python{,3}-{mock,pytest} to build dependencies.
debian/control:   python3-mock,

tchet@brix /tmp/python-pyproj $ grep mock -r | grep import
test/crs/test_crs.py:from unittest.mock import patch
test/test_cli.py:from unittest.mock import patch
test/test_datadir.py:from unittest.mock import patch
test/test_network.py:from unittest.mock import patch
test/test_proj.py:from unittest.mock import patch
test/test_sync.py:from unittest.mock import MagicMock, patch
test/test_transformer.py:from unittest.mock import call, patch
tchet@brix /tmp/python-pyproj $

Bug#1066127: RFA: rust-kmon -- Interactive kernel monitor that combines dmesg and kmod

[Stephan Lachnit]

Package: wnpp
Severity: normal
X-Debbugs-Cc: rust-k...@packages.debian.org, debian-r...@lists.debian.org, 
stephanlach...@debian.org
Control: affects -1 + src:rust-kmon

I request an adopter for the rust-kmon package. If you adopt this package,
please remove me from the uploaders list.

The package description is:
 kmon is an interactive kernel monitor for the terminal. It can insepct and
load
 kernel modules, and it can monitor kernel activity. It basically combines
dmesg
 and kmod into one application. Note that is probably needs to run as root.

Bug#1066126: RFA: rust-enum-unitary -- Trait and macro for unitary enums - Rust source code

[Stephan Lachnit]

Package: wnpp
Severity: normal
X-Debbugs-Cc: rust-enum-unit...@packages.debian.org, 
debian-r...@lists.debian.org, stephanlach...@debian.org
Control: affects -1 + src:rust-enum-unitary

I request an adopter for the rust-enum-unitary package. If you adopt this
package, please remove me from the uploaders list.

The package description is:
 This package contains the source for the Rust enum-unitary crate, packaged by
 debcargo for use with cargo and dh-cargo.

Bug#1066125: RFA: rust-enum-iterator-derive -- Procedural macro to iterate over the variants of a field-less enum - Rust source code

[Stephan Lachnit]

Package: wnpp
Severity: normal
X-Debbugs-Cc: rust-enum-iterator-der...@packages.debian.org, 
debian-r...@lists.debian.org, stephanlach...@debian.org
Control: affects -1 + src:rust-enum-iterator-derive

I request an adopter for the rust-enum-iterator-derive package. If you adopt
this package, please remove me from the uploaders list.

The package description is:
 This package contains the source for the Rust enum-iterator-derive crate,
 packaged by debcargo for use with cargo and dh-cargo.

Bug#1066128: connman: fails to take multiple search domains into account

[Francesco Poli (wintermute)]

Package: connman
Version: 1.42-5
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello and thanks for maintaining this package in Debian!
I have used it for quite some time, and I can say that it works pretty
well for most cases.

However, I have recently encountered a case where connman could work
better...
The case is a network where the DHCP server sends two domains as
"search domains" (let's call them MYDOMAIN and OTHERDOMAIN). These
two search domains are sent by the DHCP server in the
domain search list (DHCP Option 119).

If I don't use connman and configure the Ethernet network with
ifupdown (through a stanza in /etc/network/interfaces ), the DHCP
client (dhcpcd-base) writes the two search domains to /etc/resolv.conf
and everything works as intended.

If instead I use connman to connect to the Ethernet (or Wireless) network,
/etc/resolv.conf is not overwritten, since connman implements an internal
name server. Hence, the dynamically generated resolv.conf is:

  $ cat /run/connman/resolv.conf
  # Generated by Connection Manager
  nameserver ::1
  nameserver 127.0.0.1

That would be OK as /etc/resolv.conf (which could be a symlink to
/run/connman/resolv.conf ), as long as connman is aware of the two
search domains. But connman does not seem to take the two search
domains into account. In the network-specific settings of the GUI,
I see MYDOMAIN as the only domain in the "Domains" tab. However,
if I try to use non-fully-qualified host names, they are not resolved
into IP addresses:

  $ ping -c 3 HOST
  ping: HOST: Name or service not known
  $ ping -c 3 HOST.MYDOMAIN
  PING HOST.MYDOMAIN (192.168.0.143) 56(84) bytes of data.
  64 bytes from HOST.MYDOMAIN (192.168.0.143): icmp_seq=1 ttl=64 time=3.81 ms
  64 bytes from HOST.MYDOMAIN (192.168.0.143): icmp_seq=2 ttl=64 time=4.99 ms
  64 bytes from HOST.MYDOMAIN (192.168.0.143): icmp_seq=3 ttl=64 time=4.79 ms
  
  --- HOST.MYDOMAIN ping statistics ---
  3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 3.807/4.527/4.987/0.515 ms

Moreover, this network needs

  options single-request-reopen

in /etc/resolv.conf , in order to avoid slow name server replies
(see resolv.conf(5) for more details on this option).
How can I add this option with connman?
It would be great, if connman could be configured to use this option
(globally, or, even better, on a per-network basis).
Can this be done?

Currently, I have the following /etc/resolv.conf (not a symlink):

  $ cat /etc/resolv.conf
  # Generated by dhcpcd
  options single-request-reopen
  # /etc/resolv.conf.tail can replace this line

which was left by dhcpcd-base and has the needed option.
Using this together with connman seems to work (in the sense that
it avoids the slow name server reply), but, as I said, connman does
not take the two search domains into account.


I think connman should be improved, so that it can take the two search
domains into account and it can be configured to add options to the
dynamically generated /run/connman/resolv.conf .

Another strategy could be to delegate all the DHCP client stuff to
an external DHCP client (such as dhcpcd-base, which would manage
/etc/resolv.conf directly).
Is that already possible?


Am I misunderstanding anything?

Please clarify and/or enhance the connman Debian package and/or forward
my bug report upstream, as appropriate.

Thanks for your time and dedication!




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

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

Versions of packages connman depends on:
ii  dbus 1.14.10-4
ii  init-system-helpers  1.66
ii  iptables 1.8.10-3
ii  libc62.37-15
ii  libdbus-1-3  1.14.10-4
ii  libglib2.0-0 2.78.4-1
ii  libgnutls30  3.8.3-1
ii  libreadline8 8.2-3+b1
ii  libxtables12 1.8.10-3

Versions of packages connman recommends:
ii  bluez  5.71-1
pn  ofono  
ii  wpasupplicant  2:2.10-21

Versions of packages connman suggests:
pn  connman-vpn  

-- no debconf information

Bug#1062911: solvespace: NMU diff for 64-bit time_t transition

[Rylie Pavlik]

On Thu, 29 Feb 2024 17:03:41 + Benjamin Drung  wrote:

Source: solvespace
Dear maintainer,

Please find attached a final version of this patch for the time_t
transition.  This patch is being uploaded to unstable.

Note that this adds a versioned build-dependency on dpkg-dev, to guard
against accidental backports with a wrong ABI.

Thanks!


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

Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect



Thank you for the patch and NMU! I have imported the debdiff into the 
git repo on Salsa, so the NMU will be "acknowledged" in the next 
maintainer upload of SolveSpace.


Rylie Pavlik


OpenPGP_0x9045010AE5C2B9ED.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066137: gnupg2: -Werror=implicit-function-declaration failure testing for ldap_open

[Thorsten Glaser]

Source: gnupg2
Version: 2.2.40-1.1
Severity: serious
Justification: ftbfs
X-Debbugs-Cc: t...@mirbsd.de

Trying to binNMU gnupg2 to make it installable during t64 transition,
I notice the following configury output:

[…]
checking for library containing dn_skipname... none required
checking whether the resolver is usable... yes
checking whether LDAP via "-lldap" is present and sane... no
checking whether I can make LDAP be sane with lber.h... no
checking whether LDAP via "-lldap -llber" is present and sane... no
checking whether I can make LDAP be sane with lber.h... no
checking whether LDAP via "-lldap -llber -lresolv" is present and sane... no
checking whether I can make LDAP be sane with lber.h... no
checking whether LDAP via "-lwldap32" is present and sane... no
checking whether I can make LDAP be sane with lber.h... no
checking for ber_free in -llber... yes
configure: WARNING:
***
*** Building without LDAP support.
*** No CRL access or X.509 certificate search available.
***
checking for sendmail... no
[…]

This matches the following failure mode at the end of the build:

19:50⎜ I can't build gnugpg2:
19:50⎜dh_install -a -O--builddirectory=build
19:50⎜ dh_install: warning: Cannot find (any matches for)
 ⎜"debian/tmp/usr/lib/gnupg/dirmngr_ldap" (tried in ., debian/tmp)
19:50⎜ dh_install: warning: dirmngr missing files:
 ⎜debian/tmp/usr/lib/gnupg/dirmngr_ldap
19:50⎜ dh_install: error: missing files, aborting

The cause in config.log:

configure:11580: checking whether LDAP via "-lldap" is present and sane
configure:11600: gcc -o conftest -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/tmp/buildd/gnupg2-2.2.40=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2  
-specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -Wl,-z,now conftest.c -lldap 
  >&5
conftest.c: In function 'main':
conftest.c:96:1: error: implicit declaration of function 'ldap_open'; did you 
mean 'ldap_turn'? [-Werror=implicit-function-declaration]
   96 | ldap_open("foobar",1234);
  | ^
  | ldap_turn
cc1: some warnings being treated as errors
configure:11600: $? = 1
configure: failed program was:
[…]
| /* end confdefs.h.  */
| 
| #ifdef _WIN32
| #include 
| #include 
| #else
| #include 
| #endif
| 
| int
| main (void)
| {
| ldap_open("foobar",1234);
|   ;
|   return 0;
| }
configure:11608: result: no


Prototypes are now mandatory, both for C23 and because the t64 transition
can only work if prototypes are properly used.

bye,
//mirabilos

Bug#1066136: python3-xapian-haystack: unusable on stable due to use of deprecated module django.utils.six

[Ole Peder Brandtzæg]

Package: python3-xapian-haystack
Version: 2.1.1-1
Severity: grave
Tags: upstream patch
Justification: renders package unusable

Dear Maintainer,

I installed python3-xapian-haystack in order to employ Xapian as a
Haystack backend in mailman3-web on stable (bookworm).

However, upon actually trying to use it, I got the following traceback:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 
47, in inner
response = get_response(request)
  File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 181, 
in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/lib/python3/dist-packages/hyperkitty/views/search.py", line 54, in 
search
results = EmptySearchQuerySet()
  File "/usr/lib/python3/dist-packages/haystack/query.py", line 25, in __init__
self._determine_backend()
  File "/usr/lib/python3/dist-packages/haystack/query.py", line 58, in 
_determine_backend
self.query = connections[backend_alias].get_query()
  File "/usr/lib/python3/dist-packages/haystack/utils/loading.py", line 114, in 
__getitem__
self.thread_local.connections[key] = load_backend(
  File "/usr/lib/python3/dist-packages/haystack/utils/loading.py", line 60, in 
load_backend
return import_class(full_backend_path)
  File "/usr/lib/python3/dist-packages/haystack/utils/loading.py", line 22, in 
import_class
module_itself = importlib.import_module(module_path)
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1206, in _gcd_import

  File "", line 1178, in _find_and_load

  File "", line 1149, in _find_and_load_unlocked

  File "", line 690, in _load_unlocked

  File "", line 940, in exec_module

  File "", line 241, in _call_with_frames_removed

  File "/usr/lib/python3/dist-packages/xapian_backend.py", line 10, in 
from django.utils import six

Exception Type: ImportError at /hyperkitty/search
Exception Value: cannot import name 'six' from 'django.utils' 
(/usr/lib/python3/dist-packages/django/utils/__init__.py)

django.utils.six was removed in Django 3.0; the version of Django in
stable is 3.2. Hence python3-xapian-haystack is currently unusable in
stable, as it simply throws an ImportError upon loading.

Upstream fixed this issue when they dropped Python 2 support in [0].
However, I have a simpler patch that just removes the six import and
changes all occurences of `six.moves.range()` to the built-in `range()`,
which I've applied locally (hence the debsums complaint) and seems to do
the trick.

I would very much like a stable-update for this given that the package
simply does not work without the patch.

Many thanks,
Ole

[0]: 
https://github.com/notanumber/xapian-haystack/commit/0f9d94fb23ebf8cf194a3a88948a86f6dc69e786#diff-b4466d919fc4105c6306804abd396d6e0ba5e4630346928df34a5308c4700d97

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

Kernel: Linux 6.7.8 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_DK:en_US:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-xapian-haystack depends on:
ii  python3  3.11.2-1+b1
ii  python3-django-haystack  3.2.1-1
ii  python3-xapian   1.4.22-1

python3-xapian-haystack recommends no packages.

python3-xapian-haystack suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/python3/dist-packages/xapian_backend.py (from 
python3-xapian-haystack package)
--- xapian_backend.py   2017-05-18 08:50:23.0 +0200
+++ /usr/lib/python3/dist-packages/xapian_backend.py2024-03-12 
01:06:33.011301452 +0100
@@ -7,7 +7,6 @@
 import shutil
 import sys
 
-from django.utils import six
 from django.conf import settings
 from django.core.exceptions import ImproperlyConfigured
 from django.utils.encoding import force_text
@@ -346,7 +345,7 @@
 def _get_ngram_lengths(value):
 values = value.split()
 for item in values:
-for ngram_length in six.moves.range(NGRAM_MIN_LENGTH, 
NGRAM_MAX_LENGTH + 1):
+for ngram_length in range(NGRAM_MIN_LENGTH, 
NGRAM_MAX_LENGTH + 1):
 yield item, ngram_length
 
 for obj in iterable:
@@ -356,8 +355,8 @@
 def ngram_terms(value):
 for item, length in _get_ngram_lengths(value):
 item_length = len(item)
-for start in six.moves.range(0, item_length - length + 
1):
-for size in six.moves.range(length, length + 1):
+  

Bug#1066140: afflib: strlcpy,strlcat in .symbols but not part of API; ftbfs with glibc >= 2.38

[Steve Langasek]

Package: afflib
Version: 3.7.20-1.1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Hi João,

afflib fails to build from source in Ubuntu because Ubuntu ships glibc 2.39
which now provides implementations of strlcat and strlcpy, which means other
packages no longer include their own implementations, resulting in a
mismatch with the libafflib0t64 symbols file.

The attached patch treats these symbols as optional, since they are not part
of the afflib API.

This change has been uploaded to Ubuntu.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru afflib-3.7.20/debian/libafflib0t64.symbols 
afflib-3.7.20/debian/libafflib0t64.symbols
--- afflib-3.7.20/debian/libafflib0t64.symbols  2024-02-27 16:12:21.0 
-0800
+++ afflib-3.7.20/debian/libafflib0t64.symbols  2024-03-12 17:10:21.0 
-0700
@@ -787,8 +787,8 @@
  s3_request_retry_count@Base 3.7.6
  s3_retry_max@Base 3.7.6
  split_raw_increment_fname@Base 3.7.6
- strlcat@Base 3.7.6
- strlcpy@Base 3.7.6
+ (optional)strlcat@Base 3.7.6
+ (optional)strlcpy@Base 3.7.6
  strstart@Base 3.7.6
  term_print_filename@Base 3.7.6
  term_printf@Base 3.7.6

Bug#1066142: python-croniter: please drop obsolete python3-mock build dependency

[Alexandre Detiste]

Source: python-croniter
Version: 1.3.15-2
Severity: normal

This projects no longer uses the old "mock".

Greetings


tchet@brix /tmp/python-croniter $ grep mock -r
debian/control: python3-mock,
requirements/test.txt:mock>=2.0.0  # For Python 2
tchet@brix /tmp/python-croniter $

Bug#1066131: Acknowledgement (RFS: streamlink/6.7.0-1 -- CLI for extracting video streams from various websites to a video player)

[Alexis Murzeau]

Hi,

I've re-uploaded the package to change how the tests are fixed.
Instead of patching upstream code, I've changed how pytest is called.

Upstream uses pytest tests' name ("nodeid") to order tests and they are
named relative to the "rootdir" [1].

By default, the rootdir used by pytest is where the pyproject.toml is,
so I need to change it to where the used `tests` directory is (that is
in /<>/.pybuild/cpython3_3.11/build/).
This way, the upstream configuration to properly order tests works and
there is no more test failures.


[1]: 
https://github.com/streamlink/streamlink/blob/251fe08f8da8214dafdf094afd80c543b8e2e0fe/tests/conftest.py#L16


See also https://github.com/streamlink/streamlink/pull/5888.

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Santiago Ruano Rincón]

Control: fixed -1 4.1.9+dfsg-1+deb12u4

From 
https://sources.debian.org/src/spip/4.1.9%2Bdfsg-1%2Bdeb12u4/debian/changelog/

spip (4.1.9+dfsg-1+deb12u4) bookworm; urgency=medium

  * Backport security fix from 4.1.15
- fix XSS in uploaded files using bigup

 -- David Prévot   Fri, 12 Jan 2024 13:42:36 +0100

spip (4.1.9+dfsg-1+deb12u3) bookworm; urgency=medium

  * Backport security fix from 4.1.13
- fix XSS when calling some templates

 -- David Prévot   Thu, 21 Dec 2023 19:24:13 +0100

The 4.1.13 backport was part of 4.1.9+dfsg-1+deb12u3, but it seems it
was not uploaded.

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#1066143: general/glibc(?): simple IPv6 test program fails on m68k

[Thorsten Glaser]

>The same program works on amd64.

I noticed another difference between the amd64 system
and the four m68k ones.

$ ip a show dev lo
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever

vs.

# ip a show dev lo
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever

/etc/network/interfaces just has…

auto lo
iface lo inet loopback

… on all systems, so something weird is going on.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#1062777: RFP: cracktunes -- hassle-free, highly performant Discord music bot

[cycle.five]

Hello,

I am the author of this code, it is in active development. If there's interest 
in it, I'm more than happy to work with anyone to mold it to their specific 
needs.

Regards,
Lothrop

On Sat, 03 Feb 2024 16:31:19 +0800 Maytham Alsudany wrote: > Package: wnpp > 
Severity: wishlist > X-Debbugs-Cc: debian-r...@lists.debian.org > > -BEGIN 
PGP SIGNED MESSAGE- > Hash: SHA512 > > * Package name : cracktunes > 
Version : 0.2.16 > Upstream Contact: Cycle Five > * URL : 
https://git.sr.ht/~cycle-five/cracktunes > * License : Expat > Programming 
Lang: Rust > Description : hassle-free, highly performant Discord music bot > > 
Cracktunes is a hassle-free, highly performant, host-it-yourself, > cracking 
smoking Discord music bot. > > -BEGIN PGP SIGNATURE- > > 
iQJMBAEBCgA2FiEESl/RzRFQh8wD3DXB1ZeJcgbF8H8FAmW9+dQYHG1heXRoYTh0 > 
aGVkZXZAZ21haWwuY29tAAoJENWXiXIGxfB/M3cQAJDiqLwBPXX/GYmgkUP/4k1r > 
uunrAvl5kPamMAPmmUKFJixjCuCx8B5PuqdWTawIu5qtYAhQmO2xG+6z1cYrcVMt > 
YqDxNwrDrcTalOMyOu2yDQpm7jZtyWU2K8RTZRppRf3hnzKEX4a/f/BMK20G/O2e > 
1fSDEuim/Ku6BoKakGDNsZmy+J2oMvlqdvyS/jJOQBwuWobQao0m6CqBYYdgOnPn > 
pscRNR7n8m0OW8139n5qPq1TeOF7jtt/eSmqD4dV7cjdUuP3JRyOHZyC7r8sQGXm > 
+YHLbJd6zBnM5qaenzXn1oYTTkmWcmDmdmkNb2FSDqlpdH4ywbUpDZwpcYjTLSNr > 
CBuCcbppM6j8JI6cYLiUzo6MAE8faX/ia7ceMY7sLbahP125rTxUZ9AUXbai/eX5 > 
zobM284MhZNmtwDYlBDycwKYc7KcbcBzKbjeYLp+70njOzW5J/0KlKVF8eG5G2ui > 
l97LlmsDcNuS4NzbHGxKEq0bvHa93ccwxkQkI3p1Za++pa/d8/n+Zm4V0YCWpjUs > 
zQ87yYxv9WcG7ogRwPaacvnkBhBvZjcoeWrRaBSwTZO08TvjYRg8nrTw/h7BioeD > 
Wk8xX+ZGmIaN/2JrGxKyRxPxFe6rs8i2nx0Bs8HooQpFyVSzlfzaqlDLhmuCYVae > 
ItZ9IVBDFgR502SCMHUC > =DFmB > -END PGP SIGNATURE- > >


publickey - cycle.five@proton.me - 0x4A83D4B3.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#1066144: python-pyproj: please remove obsolete python3-mock build-dependency

[Sebastiaan Couwenberg]

Control: tags -1 pending

Fixed in git.

Kind Regards,

Bas

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

Bug#1066118: telegram-desktop: does not start under Debian sid

[Paul Martin]

Package: telegram-desktop
Version: 4.14.9+ds-1+b1
Severity: grave
Justification: renders package unusable

It depends on a symbol not present in the current libqt5quick5 
(automatically rebuilt as part of the time_t migration).

$ telegram-desktop
telegram-desktop: symbol lookup error: /lib/x86_64-linux-gnu/libQt5Quick.so.5: 
undefined symbol: 
_ZN18QTextureGlyphCache8populateEP11QFontEngineiPKjPK11QFixedPoint, version 
Qt_5_PRIVATE_API

-- Package-specific info:

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

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

Versions of packages telegram-desktop depends on:
ii  libabsl20220623t64   20220623.1-3.1
ii  libavcodec60 7:6.1.1-2
ii  libavfilter9 7:6.1.1-2
ii  libavformat607:6.1.1-2
ii  libavutil58  7:6.1.1-2
ii  libc62.37-15.1
ii  libgcc-s114-20240303-1
ii  libglib2.0-0t64  2.78.4-4
ii  libglibmm-2.68-1t64  2.78.1-2.2
ii  libhunspell-1.7-01.7.2+really1.7.2-10+b1
ii  libjpeg62-turbo  1:2.1.5-2+b2
ii  libkf5coreaddons55.107.0-1+b1
ii  liblz4-1 1.9.4-1+b2
ii  libminizip1t64   1:1.3.dfsg-3.1
ii  libopenal1   1:1.23.1-4+b1
ii  libopus0 1.4-1+b1
ii  libqrcodegencpp1 1.8.0-1.2+b1
ii  libqt5core5t64 [qtbase-abi-5-15-10]  5.15.10+dfsg-7.2+b1
ii  libqt5gui5t645.15.10+dfsg-7.2+b1
ii  libqt5network5t645.15.10+dfsg-7.2+b1
ii  libqt5qml5   5.15.10+dfsg-2+b1
ii  libqt5quick5 5.15.10+dfsg-2+b1
ii  libqt5quickwidgets5  5.15.10+dfsg-2+b1
ii  libqt5svg5   5.15.10-2+b1
ii  libqt5waylandcompositor5 5.15.10-2+b2
ii  libqt5widgets5t645.15.10+dfsg-7.2+b1
ii  librlottie0-10.1+dfsg-4+b2
ii  libsigc++-3.0-0  3.6.0-1
ii  libsrtp2-1   2.5.0-3
ii  libssl3t64   3.1.5-1.1
ii  libstdc++6   14-20240303-1
ii  libswresample4   7:6.1.1-2
ii  libswscale7  7:6.1.1-2
ii  libvpx8  1.13.1-2
ii  libx11-6 2:1.8.7-1
ii  libxcb-keysyms1  0.4.0-1+b2
ii  libxcb-record0   1.15-1
ii  libxcb-screensaver0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  libxxhash0   0.8.2-2+b1
ii  libyuv0  0.0~git202401110.af6ac82-1
ii  qt5-image-formats-plugins5.15.10-2+b1
ii  zlib1g   1:1.3.dfsg-3.1

Versions of packages telegram-desktop recommends:
ii  fonts-open-sans   1.11-2
ii  libwebkit2gtk-4.0-37  2.42.5-1+b2
ii  libwebkit2gtk-4.1-0   2.42.5-1+b2

telegram-desktop suggests no packages.

Versions of packages telegram-desktop is related to:
ii  xdg-desktop-portal   1.18.2-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.15.1-1

-- no debconf information
[2024.03.08 13:09:47] Launched version: 4015001, install beta: [FALSE], alpha: 
0, debug mode: [FALSE]
[2024.03.08 13:09:47] Executable dir: /tmp/Telegram/, name: Telegram
[2024.03.08 13:09:47] Initial working dir: /tmp/Telegram/
[2024.03.08 13:09:47] Working dir: /home/pm/.local/share/TelegramDesktop/
[2024.03.08 13:09:47] Command line: ./Telegram
[2024.03.08 13:09:47] Executable path before check: /tmp/Telegram/Telegram
[2024.03.08 13:09:47] Logs started
[2024.03.08 13:09:47] App ID: 
org.telegram.desktop._c898ff95bd08685f9e37429ed2c529f6
[2024.03.08 13:09:47] Connecting local socket to 
0f980833885dc97616380fc10e7837b3-TelegramDesktop...
[2024.03.08 13:09:47] Socket connect error 0, starting server and app...
[2024.03.08 13:09:47] Moved logging from 
'/home/pm/.local/share/TelegramDesktop/log_start0.txt' to 
'/home/pm/.local/share/TelegramDesktop/log.txt'!
[2024.03.08 13:09:47]