Bug#1082939: /usr/bin/deb-systemd-helper: error: unable to read virtlockd.socket

[Andrea Bolognani]

On Sun, Oct 06, 2024 at 01:12:57PM +0200, Michael Biebl wrote:
> Am 05.10.24 um 19:51 schrieb Andrea Bolognani:
> > On Fri, Oct 04, 2024 at 08:57:36PM +0200, Michael Biebl wrote:
> > > My recommendation would be to drop the "Also=virtlockd.socket" line from
> > > libvirt.service (and "Also=virtlogd.socket" as well), or upgrade the weak
> > > recommends to a depends for both packages.
> > 
> > The current setup seem to match intentions, with one caveat that I'll
> > address below.
> > 
> > virtlogd and virtlockd are secondary daemons that the primary
> > libvirtd daemon might need to delegate some operations to, so it
> > makes sense that they'll be enabled/started together with it; at the
> > same time, there are scenarios in which it's valid to have just the
> > primary daemon, hence why weak dependencies are used both between
> > unit files and packages.
> > 
> > The caveat is that libvirtd.service contains Requires=virtlogd.socket
> > without a matching Depends from libvirt-daemon to libvirt-daemon-log.
> > This is an obvious bug that needs to be addressed.
> > 
> > Turning the Recommends from libvirt-daemon to libvirt-daemon-lock
> > into a Depends is undesirable, as it would force people to have
> > virtlockd installed on their systems even though the vast majority of
> > setups don't actually need it. The whole point of moving the various
> > drivers and daemons to separate packages was to allow for
> > minimalistic, carefully curated installations, so this would
> > represent an unwanted step backwards.
> > 
> > Dropping the Also= lines is undesirable too, as it would require
> > users to explicitly care about enabling/disabling virtlogd and
> > virtlockd when enabling/disabling libvirtd. With the way things
> > currently work, it's enough for users to operate on the primary
> > daemon and the secondary ones will come along for the ride. Plus it
> > would mean having to diverge from upstream.
> > 
> > It should be noted that systemd itself is perfectly happy with this
> > arrangement: since Wants= and Also= are weak dependencies, the
> > corresponding units being missing is not considered a problem. As far
> > as I can tell, that doesn't even cause a warning to be logged
> > anywhere, much less print out an error message.
> > 
> > I don't know the internals of deb-systemd-helper very well, but is
> > there a chance that we could simply make it as tolerant to this
> > scenario as systemd itself is?
> 
> /usr/lib/systemd/system/virtlockd-admin.socket:Also=virtlockd.socket
> 
> Yet debian/rules uses:
> 
> dh_installsystemd -p libvirt-daemon --no-also libvirtd.service
> dh_installsystemd -p libvirt-daemon --no-stop-on-upgrade libvirtd.socket
> libvirtd-ro.socket libvirtd-admin.socket
> 
> I.e. virtlockd.socket is also referenced from virtlockd-admin.socket but the
> dh_installsystemd line for libvirtd-admin.socket does not contain
> "--no-also"

Sorry, I'm very confused.

These are the Also= lines for libvirtd sockets:

  $ grep -h Also= libvirtd*.socket | sort -u
  Also=libvirtd-admin.socket
  Also=libvirtd-ro.socket
  Also=libvirtd.socket

and these are the ones for virtlockd sockets:

  $ grep -h Also= virtlockd*.socket | sort -u
  Also=virtlockd-admin.socket
  Also=virtlockd.socket

So the libvirtd sockets only reference other libvirtd sockets, and
the virtlockd sockets only reference other virtlockd sockets.

The only cross-package references that exist are the ones we've
already identified:

  $ grep Also= libvirtd.service | sort -u | grep -v libvirtd
  Also=virtlockd.socket
  Also=virtlogd.socket

But as you've noted above the relevant dh_installsystemd invocation
uses --no-also:

  dh_installsystemd -p libvirt-daemon --no-also libvirtd.service

So it doesn't look like this is the problem? Unless I'm missing
something.

> so dh_installsystem will generate maintscript code to enable
> virtlockd.socket in libvirt-daemon.postinst (you can check the generated
> code after a successful build to verify that).

I'm not seeing any reference to virtlockd (or virtlogd) in
libvirt-daemon.postinst, is it supposed to be called out explicitly?
Can you please show me the snippet you're referring to?

> You probably need to more closely inspect which unit file references which
> other unit via Also= and if they are shipped in the same package or if not,
> what packaging relationship they have.

This is a good idea in general :) I'm not surprised to see some
fallout from the recent package split.

> Keep in mind that "--no-also" is currentl

Bug#1082939: /usr/bin/deb-systemd-helper: error: unable to read virtlockd.socket

[Andrea Bolognani]

On Fri, Oct 04, 2024 at 09:10:45PM +0200, Christoph Anton Mitterer wrote:
> It would additionally be nice know *what exactly* virtlogd/virtlockd
> are needed for (and thus, whether one really needs it or not)... so
> far, I seem to run fine without virtlockd (which I haven't installed,
> after it was split out).

virtlogd is used to handle the output generated by the QEMU process.
Having this as a separate process means that libvirtd can be
restarted without affecting running VMs.

Technically speaking it's only a hard dependency of the QEMU driver,
but until we have split daemons (coming to Debian at some point) it
has to be dragged in unconditionally.

virtlockd is used for storage locking; it's one of two such solutions
implemented in libvirt, the other being sanlock. Most deployments
don't need this, and it's turned off by default. It's safe to leave
it out unless you know that you need it.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1082939: /usr/bin/deb-systemd-helper: error: unable to read virtlockd.socket

[Andrea Bolognani]

On Fri, Oct 04, 2024 at 08:57:36PM +0200, Michael Biebl wrote:
> On Sat, 28 Sep 2024 18:57:05 +0200 Christoph Anton Mitterer 
>  wrote:
> > Upgrading the package gives:
> > Setting up libvirt-daemon (10.7.0-3) ...
> > /usr/bin/deb-systemd-helper: error: unable to read virtlockd.socket
> > Setting up libvirt-daemon-driver-nwfilter (10.7.0-3) ...
> 
> I guess the issue here is the following:
> 
> libvirtd.service:Wants=virtlockd.socket
> libvirtd.service:After=virtlockd.socket
> libvirtd.service:Also=virtlockd.socket
> 
> Especially the Also=virtlockd.socket means, that when enabling
> libvirtd.service, it is attempted to enable virtlockd.socket as well.

Correct.

> You don't have that installed though (as libvirt-daemon does not declare a
> hard dependency)

This is intentional.

> > pn  libvirt-daemon-lock
> 
> My recommendation would be to drop the "Also=virtlockd.socket" line from
> libvirt.service (and "Also=virtlogd.socket" as well), or upgrade the weak
> recommends to a depends for both packages.

The current setup seem to match intentions, with one caveat that I'll
address below.

virtlogd and virtlockd are secondary daemons that the primary
libvirtd daemon might need to delegate some operations to, so it
makes sense that they'll be enabled/started together with it; at the
same time, there are scenarios in which it's valid to have just the
primary daemon, hence why weak dependencies are used both between
unit files and packages.

The caveat is that libvirtd.service contains Requires=virtlogd.socket
without a matching Depends from libvirt-daemon to libvirt-daemon-log.
This is an obvious bug that needs to be addressed.

Turning the Recommends from libvirt-daemon to libvirt-daemon-lock
into a Depends is undesirable, as it would force people to have
virtlockd installed on their systems even though the vast majority of
setups don't actually need it. The whole point of moving the various
drivers and daemons to separate packages was to allow for
minimalistic, carefully curated installations, so this would
represent an unwanted step backwards.

Dropping the Also= lines is undesirable too, as it would require
users to explicitly care about enabling/disabling virtlogd and
virtlockd when enabling/disabling libvirtd. With the way things
currently work, it's enough for users to operate on the primary
daemon and the secondary ones will come along for the ride. Plus it
would mean having to diverge from upstream.

It should be noted that systemd itself is perfectly happy with this
arrangement: since Wants= and Also= are weak dependencies, the
corresponding units being missing is not considered a problem. As far
as I can tell, that doesn't even cause a warning to be logged
anywhere, much less print out an error message.

I don't know the internals of deb-systemd-helper very well, but is
there a chance that we could simply make it as tolerant to this
scenario as systemd itself is?

Thanks for looking into this!

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1084023: systemd: please stop conflicting with opensysusers 0.7.3-4 and newer

[Andrea Pappacoda]

Source: systemd
Version: 256.6-1
Severity: normal
Control: affects -1 opensysusers

Hi! I've fixed the issues which prevented co-installability of systemd 
and opensysusers. Could you please update the Conflicts so that new 
opensysusers versions can be installed again?


This is currently preventing opensysusers from migrating to testing, 
since DebCI tries to install opensysusers in an LXC container with 
systemd already installed.


I've opened a Salsa merge request a few weeks ago, for your convenience.  
You can find it here: 
.


Thanks! Bye :)


signature.asc
Description: PGP signature

Bug#1083053: muon-meson: please make the build reproducible

[Andrea Pappacoda]

Hi Chris,

On Mon Sep 30, 2024 at 6:25 PM CEST, Chris Lamb wrote:

Whilst working on the Reproducible Builds effort [0], we noticed that
muon-meson could not be built reproducibly. This is because the docs
embed a timezone-dependent date:

[...]

It's based on SOURCE_DATE_EPOCH, but it does not take into account the
build system's timezone.


Thanks for the report (and the patch!).

Could you please help me understand why setting the timezone is 
necessary, since I'm just using a date and not a time? Is it because 
a given timestamp might refer to 2024-09-27 23:30 in one time zone, but 
2024-09-28 00:30 in another one?


I'll add the fix in the following days. If you want, you can also NMU 
the fix, but please be sure to update dgit and Salsa too (I'm in the 
LowThresholdNMU list).


Thanks again! Bye :)


signature.asc
Description: PGP signature

Bug#1082640: [Pkg-libvirt-maintainers] Bug#1082640: libvirt-daemon: Sysvinit scripts are not executable

[Andrea Bolognani]

On Mon, Sep 23, 2024 at 11:14:02PM +0300, Mikko Rasa wrote:
> After upgrading from 10.6.0-1 to 10.7.0-3 the scripts in /etc/init.d are not
> executable and libvirtd fails to start.  Easily rectified by doing chmod +x
> on the scripts, after which everything works.
> 
> Also affects libvirt-daemon-log (virtlogd), libvirt-daemon-common
> (libvirt-guests) and possibly others which I do not use.

This seems weird, since the executable bit is present in the package
itself:

  $ dpkg-deb -x libvirt-daemon_10.7.0-3_amd64.deb .
  $ ls -l etc/init.d/libvirtd 
  -rwxr-xr-x 1 abologna abologna 6136 Sep 16 21:41 etc/init.d/libvirtd

I have personally tested upgrades from 10.6.0-1 to 10.7.0-3 on hosts
using sysvinit and openrc instead of systemd to ensure that things
would work as expected in those scenarios, and I never encountered a
scenario like the one you're describing.

Did you customize the init scripts? We have some logic to carry
existing customizations over, and it might have gotten confused
somehow, though it should just move files around so I can't imagine
the executable bits getting lost in the process.

Any other local customizations that might be relevant?

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1082765: mdocml: please ship libmandoc.a

[Andrea Pappacoda]

Source: mdocml
Version: 1.14.6-1
Severity: wishlist
Tags: patch

Hi!

Could you please ship the libmandoc.a library? It's needed for the 
packaging of mangl, <https://mentors.debian.net/package/mangl/>.


I've already worked on this locally, and I'm attaching a patch here. 
Since installing the library in the correct path requires configuring 
mandoc's build system to set LIBDIR to a dynamic path depending on 
DEB_HOST_MULTIARCH, I've refactored the creation of configure.local to 
happen at build-time via debian/rules instead of using a static patch.


As I've mentioned to the current maintainer of mdocml (Michael) in 
a private email, I'd be glad to take over maintenance of the package to 
fix this and other open bugs.


Bye :)
From c2744142281053e8bbddae0066cfc4ab3eefc1db Mon Sep 17 00:00:00 2001
From: Andrea Pappacoda 
Date: Wed, 25 Sep 2024 15:44:01 +0200
Subject: [PATCH 1/2] d/rules: write configure.local during build instead of
 using patch

Apart from being easier to handle, this allows populating fields
dynamically depending on the build environment.
---
 debian/patches/configure.local.patch | 27 -
 debian/patches/series|  1 -
 debian/rules | 35 +---
 3 files changed, 32 insertions(+), 31 deletions(-)
 delete mode 100644 debian/patches/configure.local.patch
 delete mode 100644 debian/patches/series

diff --git a/debian/patches/configure.local.patch b/debian/patches/configure.local.patch
deleted file mode 100644
index 25321d8..000
--- a/debian/patches/configure.local.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-Description: create configure.local to set Debian defaults
-Author: Bdale Garbee 
-
-Index: mdocml/configure.local
-===
 /dev/null
-+++ mdocml/configure.local
-@@ -0,0 +1,19 @@
-+HAVE_WCHAR=1
-+OSNAME="Debian"
-+PREFIX="/usr"
-+MANDIR="${PREFIX}/share/man"
-+EXAMPLEDIR="${PREFIX}/share/doc/mandoc"
-+INSTALL_MAN="debian/install_mandoc"
-+MANM_MAN="mandoc_man"   # default is "man"
-+MANM_MDOC="mandoc_mdoc" # default is "mdoc"
-+MANM_ROFF="mandoc_roff" # default is "roff"
-+MANM_EQN="mandoc_eqn"   # default is "eqn"
-+MANM_TBL="mandoc_tbl"   # default is "tbl"
-+BINM_MAN=mman   # default is "man"
-+BINM_APROPOS=mapropos   # default is "apropos"
-+BINM_SOELIM=msoelim # default is "soelim"
-+BINM_WHATIS=mwhatis # default is "whatis"
-+BINM_CATMAN=mcatman # default is "catman"
-+BUILD_DB=0
-+BUILD_CATMAN=1
-+LN="ln -sf"
diff --git a/debian/patches/series b/debian/patches/series
deleted file mode 100644
index cdacd77..000
--- a/debian/patches/series
+++ /dev/null
@@ -1 +0,0 @@
-configure.local.patch
diff --git a/debian/rules b/debian/rules
index af1a63f..b70611a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,6 +4,7 @@
 #export DH_VERBOSE = 1
 
 include /usr/share/dpkg/architecture.mk
+include /usr/share/dpkg/vendor.mk
 
 # see FEATURE AREAS in dpkg-buildflags(1)
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
@@ -24,12 +25,40 @@ endif
 %:
 	dh $@
 
+execute_before_dh_auto_configure:
+	printf '%s\n' \
+		'OSNAME="$(DEB_VENDOR)"' \
+		'CC="$(CC)"' \
+		'CFLAGS="$(CFLAGS)"' \
+		'CPPFLAGS="$(CPPFLAGS)"' \
+		'LDFLAGS="$(LDFLAGS)"' \
+		'BUILD_CATMAN=1' \
+		'BUILD_DB=0' \
+		'HAVE_WCHAR=1' \
+		'PREFIX=/usr' \
+		'MANDIR="$${PREFIX}/share/man"' \
+		'EXAMPLEDIR="$${PREFIX}/share/doc/mandoc"' \
+		'BINM_APROPOS=mapropos' \
+		'BINM_CATMAN=mcatman' \
+		'BINM_MAN=mman' \
+		'BINM_SOELIM=msoelim' \
+		'BINM_WHATIS=mwhatis' \
+		'MANM_MAN="mandoc_man"' \
+		'MANM_MDOC="mandoc_mdoc"' \
+		'MANM_ROFF="mandoc_roff"' \
+		'MANM_EQN="mandoc_eqn"' \
+		'MANM_TBL="mandoc_tbl"' \
+		'INSTALL_PROGRAM="$${INSTALL} -m 0755"' \
+		'INSTALL_LIB="$${INSTALL} -m 0644"' \
+		'INSTALL_MAN="debian/install_mandoc"' \
+		'INSTALL_DATA="$${INSTALL} -m 0644"' \
+		'LN="ln -sf"' \
+		> configure.local
+
 override_dh_auto_clean:
+	$(RM) configure.local
 	[ ! -f Makefile.local ] || $(MAKE) clean
 
-override_dh_auto_build:
-	dh_auto_build -- CC=$(CC) CFLAGS="$$CFLAGS" CPPFLAGS="$$CPPFLAGS" LDFLAGS="$$LDFLAGS"
-
 override_dh_installchangelogs:
 	dh_installchangel

Bug#1082146: cloudflare-ddns: cloudflare-ddns[1222841]: terminate called after throwing an instance of 'simdjson::simdjson_error'

[Andrea Pappacoda]

Hi Justin,

On Fri Sep 20, 2024 at 4:52 PM CEST, Justin Piszcz wrote:
If you prefer, I could backport cloudflare-ddns 2.1.0 to 
bookworm-backports, since it has better error handling, and you could 
upgrade to that version.



This would be helpful to see if the issue recurs with 2.1.0, thank you!


I've just prepared the backport and asked the debian-backports list to 
upload it to bookworm-backports. You can see my request here: 
. 
It should get there shortly!


Bye :)


signature.asc
Description: PGP signature

Bug#1082724: debhelper: compat 14's new dh_fixperm ordering breaks builds

[Andrea Pappacoda]

Package: debhelper
Version: 13.20
Severity: normal

Hi! Please consider this a follow up to bug #1082719. Consider its 
example code, but with the following modifications:


   diff --git a/Makefile b/Makefile
   index 959dd73..7898fb8 100644
   --- a/Makefile
   +++ b/Makefile
   @@ -17,7 +17,7 @@ main.o: main.c
   
install: main

$(MKDIR) $(DESTDIR)$(PREFIX)/$(BINDIR)
   -$(INSTALL) main $(DESTDIR)$(PREFIX)/$(BINDIR)
   +$(INSTALL) -m 0555 main $(DESTDIR)$(PREFIX)/$(BINDIR)
   
uninstall:

$(RM) $(DESTDIR)$(PREFIX)/$(BINDIR)/main
   diff --git a/debian/rules b/debian/rules
   index 2f671b9..fea8621 100755
   --- a/debian/rules
   +++ b/debian/rules
   @@ -4,4 +4,4 @@
dh $@
   
override_dh_auto_install:

   -dh_auto_install -- PREFIX=/usr
   +dh_auto_install --destdir=debian/compat-14-test/ -- PREFIX=/usr

As dh_fixperm is now run later in debhelper's sequence, tools trying to 
modify the "main" binary will fail, since upstream's build system 
installs it with mode 0555 instead of 0755:


  dh_strip -a
   strip: unable to copy file 'debian/compat-14-test/usr/bin/main'; reason: 
Permission denied
   dh_strip: error: strip --remove-section=.comment --remove-section=.note 
debian/compat-14-test/usr/bin/main returned exit code 1
   dh_strip: error: Aborting due to earlier error
   make: *** [debian/rules:4: binary] Error 25

This is somewhat mentioned in the debhelper-compat-upgrade-checklist(7) 
manual page, and says to file bugs to the relevant tools. Since 
dh_fixpem is owned by debhelper, here I am :)


How do you think should we handle this? I see how dh_fixperm should be 
run before dh_compress, but why is it now run so late compared to 
before? Why not split dh_fixperm in to parts, one that allows debhelper 
tools to act on the files, and the other one which makes sure that 
permissions are normalzied? Maybe adding a dh_make_writable command?


Let me know! I'd love to see compat 14 ready to be released!


signature.asc
Description: PGP signature

Bug#1082719: debhelper: dh-sequence-single-binary not working with compat 14

[Andrea Pappacoda]

Package: debhelper
Version: 13.20
Severity: normal

Hi! I've just tried out compat 14 to start preparing one of my packages 
to it, but noticed that the dh-sequence-single-binary dependency doesn't 
work as expected. According to the manpage, if that addon is used, 
dh_auto_build should install files to debian/singlepackage/, not 
debian/tmp/, but this is not what I'm observing. Here's a reproducer:


   $ cat Makefile
   .POSIX:
   
   # Paths

   PREFIX = /usr/local
   BINDIR = bin
   
   # Utilities

   INSTALL = install
   MKDIR = mkdir -p
   RM = rm -f
   
   all: main
   
   main: main.o
   
   main.o: main.c
   
   install: main

$(MKDIR) $(DESTDIR)$(PREFIX)/$(BINDIR)
$(INSTALL) main $(DESTDIR)$(PREFIX)/$(BINDIR)
   
   uninstall:

$(RM) $(DESTDIR)$(PREFIX)/$(BINDIR)/main
   
   clean:

$(RM) main main.o
   
   .PHONY: all clean install uninstall
   
   $ cat main.c

   #include 
   
   int main(void) {

puts("Hello, world!");
return 0;
   }
   
   $ cat debian/changelog

   compat-14-test (1.0) UNRELEASED; urgency=low
   
 * Initial release. (Closes: #XX)
   
-- Andrea Pappacoda   Tue, 24 Sep 2024 23:33:13 +0200
   
   $ cat debian/control

   Source: compat-14-test
   Section: misc
   Priority: optional
   Maintainer: Andrea Pappacoda 
   Build-Depends:
debhelper (>= 13~),
dh-sequence-single-binary,
dpkg-build-api (= 1),
   Standards-Version: 4.7.0
   X-DH-Compat: 14
   X-Style: black
   
   Package: compat-14-test

   Architecture: any
   Description: test for debhelper compat 14
   
   $ cat debian/rules

   #!/usr/bin/make -f
   
   %:

dh $@
   
   override_dh_auto_install:

dh_auto_install -- PREFIX=/usr

   $ cat debian/source/format
   3.0 (native)

If I build the package as-is, the build fails as follows:

   dh_auto_install -- PREFIX=/usr
make -j12 install DESTDIR=/tmp/tmp.hKSeWe1Ril/compat-14-test/debian/tmp 
AM_UPDATE_INFO_DIR=no "INSTALL=install --strip-program=true" PREFIX=/usr
   make[2]: Entering directory '/tmp/tmp.hKSeWe1Ril/compat-14-test'
   mkdir -p /tmp/tmp.hKSeWe1Ril/compat-14-test/debian/tmp/usr/bin
   install --strip-program=true main 
/tmp/tmp.hKSeWe1Ril/compat-14-test/debian/tmp/usr/bin
   install: WARNING: ignoring --strip-program option as -s option was not 
specified
   make[2]: Leaving directory '/tmp/tmp.hKSeWe1Ril/compat-14-test'
   make[1]: Leaving directory '/tmp/tmp.hKSeWe1Ril/compat-14-test'
  dh_installdocs
  dh_installchangelogs
  dh_perl
  dh_link
  dh_missing
   dh_missing: warning: usr/bin/main exists in debian/tmp but is not installed 
to anywhere
The following debhelper tools have reported what they installed (with 
files per package)
* dh_installdocs: compat-14-test (0)
If the missing files are installed by another tool, please file a bug 
against it.
When filing the report, if the tool is not part of debhelper itself, 
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
 (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.md.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built
If the omission is intentional or no other helper can take care of this 
consider adding the
paths to debian/not-installed.
   dh_missing: error: missing files, aborting
   make: *** [debian/rules:4: binary] Error 255

As you can see, the files get installed in debian/tmp even if the addon 
is present, which then leads to a failure. The same exact package, under 
compat 13, builds fine.


Am I misunderstanding what dh-sequence-single-binary should do? If I add 
a bare debian/install file then the build completes successfully under 
compat 14, but fails in compat 13.


Bye!


signature.asc
Description: PGP signature

Bug#1082240: ITP: meow -- Print ASCII cats to your terminal

[Andrea Pappacoda]

Hi Sergey,

On Mon Sep 23, 2024 at 2:58 PM CEST, Sergey wrote:
This is a new terminal command, which is in the spirit of "cowsay" or 
"figlet". The name is deliberately short in order to be funny; 
renaming it to something longer like "ascii-meow" would go against the 
spirit of the command.
There is no other software named meow, and there are no other such 
ITPs in the debian repositories. There is another Cargo/rust package 
named "meow"; however, this is an unmaintained piece of software and 
will likely not be packaged as a Debian package in the future.


This makes sense, and I do agree that having a longer name wouldn't be 
desireable. Still, since we have a single global namespace, I personally 
think it'd be better for your little app to be a bit more widespread 
before taking the "meow" name. Try posting it on Reddit or Hacker News, 
and see what others think!


In addition, this software has been released under the package name 
"meow" in the Nixpkgs repository: 
https://search.nixos.org/packages?channel=unstable&show=meow
For consistency, the package should be named the same across different 
package repositories.


While I do agree that consistency is a nice thing, please be aware that 
Nixpkgs doesn't have the same high standards as Debian's (or any other 
typical distro) archive, so you shouldn't generally take them as the 
example to follow.


signature.asc
Description: PGP signature

Bug#989239: dash: support $'…' style quotes

[Andrea Pappacoda]

I'd really appreciate this to be supported in dash. It is a nice and 
portable way of printing terminal control sequences, since neither 
printf nor echo are required to support the '\e' escape, but 
Dollar-Single-Quotes strings are.


signature.asc
Description: PGP signature

Bug#1082146: cloudflare-ddns: cloudflare-ddns[1222841]: terminate called after throwing an instance of 'simdjson::simdjson_error'

[Andrea Pappacoda]

Hi Justin, thanks for the report.

The cloudflare-ddns version in Stable, 2.0.0, doesn't have great error
handling, so it's hard to understand what has gone wrong from its error
messages.

In any case, the most likely issue here is that either your network
temporarily failed, or Cloudflare returned an invalid response, so the
parsing failed and the program exited with an error.

Everything is fine though, you can simply restart the service and
it'll continue working as always (or you could even ignore the failure
completely, the timer will take care of restarting it automatically).

If you prefer, I could backport cloudflare-ddns 2.1.0 to
bookworm-backports, since it has better error handling, and you could
upgrade to that version.

Thanks for using cloudflare-ddns! Glad it is being useful to you :)

Bye!

Bug#1082240: ITP: meow -- Print ASCII cats to your terminal

[Andrea Pappacoda]

Hi Sergey, I find the package name "meow" a bit to general, especially for a 
package with apparently no users.

1. Does other software called "meow" exist?
2. Have you considered other names, like "ascii-meow"?

Bye!

Il 19 settembre 2024 15:30:29 CEST, PixelSergey  
ha scritto:
>Package: wnpp
>Severity: wishlist
>Owner: PixelSergey 
>X-Debbugs-Cc: debian-de...@lists.debian.org, sergey.ichtche...@gmail.com
>
>* Package name: meow
>  Version : 2.1.3 
>  Upstream Contact: PixelSergey 
>* URL : https://github.com/PixelSergey/meow
>* License : MIT
>  Programming Lang: Rust
>  Description : Print ASCII cats to your terminal
>
>This is a simple app to print ASCII cats directly to your terminal.
>Run `meow` for a single cat, `meow -c ` for more cats,
>or `meow -l` if you think that you are literally the cat that will be printed.
>
>This package addresses the critical lack of cats in the Linux ecosystem.
>This package needs a sponsor.
>

Bug#1055514: adopted first patch

[Andrea Pappacoda]

Hi all!

I know that a lot of time has passed, but I've finally made a decision.  
While opensysusers indeed has some issues when used as a drop-in 
replacement for systemd-sysusers, and even upstream is unsure whether it 
should be used as such[1], I chose to fix this bug by adopting Helmut's 
first patch, which fixes the diversions and moves the binary to /usr.


The decision of whether opensysusers should stop being co-installable 
with systemd, or should be used as a systemd-sysusers replacement, can 
be done in another moment.


Thanks again, Helmut, for your patch! Bye :)

[1]: https://github.com/cromerc/opensysusers/issues/6#issuecomment-2352832207


signature.asc
Description: PGP signature

Bug#1082022: RFS: cpp-httplib/0.18.0+ds-1 -- C++ HTTP/HTTPS server and client library

[Andrea Pappacoda]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "cpp-httplib":

* Package name : cpp-httplib
  Version  : 0.18.0+ds-1
  Upstream contact : Yuji Hirose 
* URL  : https://github.com/yhirose/cpp-httplib
* License  : Expat
* Vcs  : https://salsa.debian.org/debian/cpp-httplib
  Section  : libs

The source builds the following binary packages:

 libcpp-httplib0.18 - C++ HTTP/HTTPS server and client library
 libcpp-httplib-dev - C++ HTTP/HTTPS server and client library - development 
files

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


 https://mentors.debian.net/package/cpp-httplib/

cpp-httplib is maintained using Git and dgit, so could you please use 
dgit to perform the upload? In case you've never used it, here are the 
steps you should follow:


  apt install dgit git-debrebase
  git clone g...@salsa.debian.org:debian/cpp-httplib.git
  cd cpp-httplib
  origtargz
  dgit sbuild
  dgit --new push-built && git push --all --follow-tags

Be sure to perform the last pipeline as described! Otherwise the Git 
repository hosted on Salsa will get out of date. Thanks!


Changes since the last upload:

cpp-httplib (0.18.0+ds-1) experimental; urgency=medium
.
  * Update to new upstream version 0.18.0+ds.
  * d/control: libcpp-httplib0.16 -> libcpp-httplib0.18
  * d/control: apply X-Style: black
  * d/control: add build dependency on libcurl-dev

Bye!


signature.asc
Description: PGP signature

Bug#1081396: libvirt-daemon: AppArmor support for QEMU domains is (mostly silently) disabled unless libvirt-daemon-driver-lxc is installed

[Andrea Bolognani]

Control: tags -1 fixed-upstream

On Wed, Sep 11, 2024 at 08:06:18PM +0200, Andrea Bolognani wrote:
> On Wed, Sep 11, 2024 at 02:21:07PM +0200, intrigeri wrote:
> > If libvirt-daemon-driver-lxc is not installed, libvirtd logs this on 
> > startup:
> > 
> >   libvirtd[2085]: internal error: template 
> > '/etc/apparmor.d/libvirt/TEMPLATE.lxc' does not exist
> > 
> > … and then apparently the logic to generate AppArmor profiles for QEMU VMs 
> > and
> > enforce them is disabled. That was not obvious to me: I thought "OK, I don't
> > have the LXC driver installed, so sure that file is missing, it's fine" and 
> > did
> > not guess this would break a previously working security feature.
> 
> Thanks for the report.
> 
> This is definitely *not* expected and *not* acceptable. AppArmor
> confinement for QEMU domains should work regardless of whether or not
> an unrelated hypervisor driver is installed.
> 
> I'll look into it. I'm fairly sure it will require an upstream fix.

Fixed upstream with

  commit d622ca04f6525b90cfe6d8274efaf4bee043d8ba
  Author: Andrea Bolognani 
  Date:   Mon Sep 16 16:39:11 2024 +0200

apparmor: Don't check for existence of templates upfront

Currently, if either template is missing AppArmor support is
completely disabled. This means that uninstalling the LXC
driver from a system results in QEMU domains being started
without AppArmor confinement, which obviously doesn't make any
sense.

The problematic scenario was impossible to hit in Debian until
very recently, because all AppArmor files were shipped as part
of the same package; now that the Debian package is much closer
to the Fedora one, and specifically ships the AppArmor files
together with the corresponding driver, it becomes trivial to
trigger it.

Drop the checks entirely. virt-aa-helper, which is responsible
for creating the per-domain profiles starting from the
driver-specific template, already fails if the latter is not
present, so they were always redundant.

https://bugs.debian.org/1081396

Signed-off-by: Andrea Bolognani 
Reviewed-by: Daniel P. Berrangé 

I'll prepare an upload shortly.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1055777: opensysusers/0.7.3-3: Wrong closed bug

[Andrea Pappacoda]

Version: opensysusers/0.7.3-3
Control: reopen 1055777

Ops, version 0.7.3-3 closed bug #1055517, not #1055777. Guess you 
shouldn't try fixing critical bugs at 1 am...


signature.asc
Description: PGP signature

Bug#1081939: logcheck ignores -t flag for systemd journal

[Andrea Janna]

Package: logcheck
Version: 1.4.3
Severity: minor
Tags: patch upstream
X-Debbugs-Cc: andrea...@dpss.psy.unipd.it

Dear Maintainer,

When logcheck is invoked with -t flag it should not update the offset of the 
log files. This works for regular log files but the flag is ineffective (the 
offset is updated anyway) when logcheck reads the log from systemd journal.
The attached patch fixes this problem.


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

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

Versions of packages logcheck depends on:
ii  adduser3.137
ii  cron [cron-daemon] 3.0pl1-189
ii  exim4-daemon-light [mail-transport-agent]  4.98-1
ii  lockfile-progs 0.1.19+nmu1
ii  logtail1.4.3
ii  mime-construct 1.12+really1.11-1

Versions of packages logcheck recommends:
ii  logcheck-database  1.4.3

Versions of packages logcheck suggests:
pn  rsyslog | system-log-daemon  

-- Configuration Files:
/etc/logcheck/logcheck.logfiles.d/syslog.logfiles changed:


-- no debconf information
--- logcheck.orig   2023-07-18 12:54:10.0 +0200
+++ logcheck2024-09-16 09:59:25.208019356 +0200
@@ -511,7 +511,9 @@
"$JOURNALCTL" 
"${JOURNALCTL_OPTS[@]}" --quiet "$offsettime" \

>> "$TMPDIR/logoutput/$file" 2>&1 \
|| error "Could 
not run journalctl or save output"
-   touch "$offsetfile"
+   if [ "$LOGTAIL_OPTS" != '-t' ]; 
then
+   touch "$offsetfile"
+   fi
else
echo "E: File could not be 
read: $file" >> "$TMPDIR/errors" \
|| error "Could 
not output to $TMPDIR/errors"

Bug#1081357: oz: Needs explicit Depends on libvirt-daemon-driver-qemu

[Andrea Bolognani]

On Thu, Sep 12, 2024 at 04:42:15PM +0200, Simon Josefsson wrote:
> 12 sep. 2024 kl. 16:27 skrev Michael Biebl :
> > failing tests are considered RC by the release team, especially
> > since they gate testing migration.  I'm thus raising the severity
> > accordingly.
> > 
> > Given the package is marked as LowNMU and the last maintainer
> > upload more than 3 years ago, you might consider doing a NMU for
> > this change.
> 
> Thanks for caring about this package

To be completely honest, I only really care insomuch as it prevents
libvirt from migrating to testing O:-)

> feel free to NMU and push changes to salsa!

I'm not a DD, so NMUs are out of the question for me. Someone else
would have to take care of that.

> I think it would be better if this package was
> team maintained. I no longer use it, and upstream broke the self
> tests with some changes in the last release and wasn’t responsive
> in fixing them, so the state of this package seems less than ideal.
> Is anyone using it? While I liked the philosophy of oz, and used it
> for a couple of years, the bugs and limitations of it drove me away
> into cloud images or pure preseed installs via virt-install
> instead. It should still do a reasonable job of what it was
> designed for though.

Team maintenance would probably make sense.

Perhaps it could live under the libvirt-team umbrella. There is ample
precendent for packages that use libvirt or are somewhat related to
it being maintained there: libosinfo, hivex and rhsrvany are
examples.

That said, I cannot in good conscience commit to spending any of my
own time on it. I'm not familiar at all with the tool, and taking
care of libvirt itself already consumes pretty much all the time I
can dedicate to Debian.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1081357: oz: Needs explicit Depends on libvirt-daemon-driver-qemu

[Andrea Bolognani]

On Thu, Sep 12, 2024 at 04:35:33PM +0200, Michael Biebl wrote:
> > Helmut mentioned on IRC that it's probably also a good idea to add a
> > versioned Breaks against oz to libvirt-daemon.
> 
> We further discussed this on IRC. Since it only seems to affect the
> autopkgtest, a versioned Breaks is probably not necessary or particularly
> helpful.

It's actually fairly surprising to me that oz itself doesn't seem to
have a runtime dependency on the libvirt daemon, just the client
library. I would have assumed that it would at the very least
recommend it.

> That said, have you reviewed other rdeps of libvirt-daemon, like gnome-boxes
> and mom. Maybe they are affected in a similar way.

I was planning to, but I haven't gotten around to it yet. I was also
considering announcing the changes more widely with a message to
debian-devel. Taking care of oz has priority though, since it blocks
migration to testing.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1069872: [PATCH] d/patches: fix input type=checkbox output

[Andrea Pappacoda]

Closes: #1077671
---
Hi! Here is a patch fixing this bug. You can apply this with `git am`.

Bye :)

 debian/patches/series |  1 +
 debian/patches/string-before-concat.patch | 25 +++
 debian/tests/pkgreport.html.supposed  |  8 
 3 files changed, 30 insertions(+), 4 deletions(-)
 create mode 100644 debian/patches/series
 create mode 100644 debian/patches/string-before-concat.patch

diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..d5395da
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+string-before-concat.patch
diff --git a/debian/patches/string-before-concat.patch 
b/debian/patches/string-before-concat.patch
new file mode 100644
index 000..b4b6e74
--- /dev/null
+++ b/debian/patches/string-before-concat.patch
@@ -0,0 +1,25 @@
+Description: format(input): convert to string before concat
+ The checked character for `` was concatenated to
+ the '[' and ']' characters before converting it to string, which
+ resulted in an expression like '[' + 'X' + ']', which results in an
+ arithmetic sum between the integer values of the three characters,
+ leading to an unexpected result.
+ .
+ To fix this, simply wrap the checked ternary expression with a braced
+ string constructor.
+Author: Andrea Pappacoda 
+Bug-Debian: https://bugs.debian.org/1077671
+Forwarded: https://gitlab.com/grobian/html2text/-/merge_requests/54
+Last-Update: 2024-09-12
+
+--- html2text-2.2.3.orig/format.cpp
 html2text-2.2.3/format.cpp
+@@ -908,7 +908,7 @@ Input::line_format() const
+   size = 20;
+   res = '[' + string(size, '*') + ']';
+   } else if (cmp_nocase(type, "CHECKBOX") == 0) {
+-  res = '[' + (checked ? 'X' : ' ') + ']';
++  res = '[' + string{checked ? 'X' : ' '} + ']';
+   } else if (cmp_nocase(type, "RADIO") == 0) {
+   res = checked ? '#' : 'o';
+   } else if (cmp_nocase(type, "SUBMIT") == 0) {
diff --git a/debian/tests/pkgreport.html.supposed 
b/debian/tests/pkgreport.html.supposed
index accd52e..f276dde 100644
--- a/debian/tests/pkgreport.html.supposed
+++ b/debian/tests/pkgreport.html.supposed
@@ -514,10 +514,10 @@ From other Branch bugs -- Critical bugs (30 bugs)
 * Categorize using
 *
 * Order by *
- ??Repeat Merged
- ??Reverse Bugs
- ??Reverse Pending
- ??Reverse Severity
+ [ ]Repeat Merged
+ [ ]Reverse Bugs
+ [ ]Reverse Pending
+ [ ]Reverse Severity
  [One of: None/testing/
 * Misc options * oldstable/experimental/
  unstable/stable]
-- 
2.45.2

Bug#1081396: libvirt-daemon: AppArmor support for QEMU domains is (mostly silently) disabled unless libvirt-daemon-driver-lxc is installed

[Andrea Bolognani]

Control: severity -1 important

On Wed, Sep 11, 2024 at 02:21:07PM +0200, intrigeri wrote:
> If libvirt-daemon-driver-lxc is not installed, libvirtd logs this on startup:
> 
>   libvirtd[2085]: internal error: template 
> '/etc/apparmor.d/libvirt/TEMPLATE.lxc' does not exist
> 
> … and then apparently the logic to generate AppArmor profiles for QEMU VMs and
> enforce them is disabled. That was not obvious to me: I thought "OK, I don't
> have the LXC driver installed, so sure that file is missing, it's fine" and 
> did
> not guess this would break a previously working security feature.

Thanks for the report.

This is definitely *not* expected and *not* acceptable. AppArmor
confinement for QEMU domains should work regardless of whether or not
an unrelated hypervisor driver is installed.

I'll look into it. I'm fairly sure it will require an upstream fix.

> I'm under the impression that this breakage happened recently, because just
> a few weeks ago I had AppArmor denials break stuff for 1 of my VMs, so it must
> have been working back then.

There was a pretty massive package restructuring landing recently in
unstable with 10.7.0-1, after having marinated for some time in
experimental. So that would be the cause.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1081357: oz: Needs explicit Depends on libvirt-daemon-driver-qemu

[Andrea Bolognani]

Control: tags -1 patch

On Wed, Sep 11, 2024 at 01:13:01AM +0200, Andrea Bolognani wrote:
> I'll attach a tentative patch here and also open a merge request on
> salsa. Feel free to pick up whichever one is more convenient.

Patch is attached. The merge request is

  https://salsa.debian.org/debian/oz/-/merge_requests/2

As partial proof that the fix works as intended, compare

  https://salsa.debian.org/abologna/oz/-/jobs/6252654

which doesn't include the change and

  https://salsa.debian.org/abologna/oz/-/jobs/6253326

which does. In the former, we can see the following error:

  > raise libvirtError('virConnectOpen() failed')
  E libvirt.libvirtError: no connection driver available for qemu:///session

which is caused by the QEMU connection driver being absent; the
latter contains other failures, but not that one.

I haven't really tried running the autopkgtest locally because I'm
not sure that the isolation/virtualization used for the testbed will
play nicely with oz's own tests, which supposedly will also want to
use virtualization. If someone who's more familiar with the package
than I am is willing to contribute some tips on how to effectively
test these changes locally, I'll be happy to do so.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.
From b5672536f84413d8ceb45f5ce11277b4fea088b8 Mon Sep 17 00:00:00 2001
From: Andrea Bolognani 
Date: Mon, 9 Sep 2024 21:26:51 +0200
Subject: [PATCH] autopkgtest: Add libvirt-daemon-driver-qemu dependency

Historically, the libvirt-daemon package has had a hard
dependency on the libvirt-daemon-driver-qemu package, which
contains the QEMU connection driver.

That has changed in libvirt 10.6.0-2, where the Depends was
downgraded to a Recommends in order to increase flexibility
when it comes to deployment options, opening the door to
things such as an LXC-only hypervisor host.

Since Recommends are ignored when setting up the
environment in which autopkgtest are run, we need to add an
explicit dependency on the QEMU connection driver, which is
used as part of the functional tests.

Closes: #1081357
Signed-off-by: Andrea Bolognani 
---
 debian/tests/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/tests/control b/debian/tests/control
index 5a5e809..8b91f16 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,3 +1,3 @@
 Tests: oz
 Architecture: amd64
-Depends: libvirt-daemon, oz, python3-pytest, python3-py
+Depends: libvirt-daemon, libvirt-daemon-driver-qemu, oz, python3-pytest, python3-py
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1081357: oz: Needs explicit Depends on libvirt-daemon-driver-qemu

[Andrea Bolognani]

Source: oz
Version: 0.17.0-5.1
Severity: normal

oz uses the libvirt QEMU connection driver for autopkgtest.

It currently declares a Depends on libvirt-daemon, which provides the
daemon itself, but not on the QEMU connection driver, which is in the
libvirt-daemon-driver-qemu package.

This has worked fine until now because the daemon had a Depends on
the QEMU connection driver, but starting with 10.6.0-2 we've moved to
a more modular packaging and that Depends has been demoted to a
Recommends.

Please add an explicit Depends on libvirt-daemon-driver-qemu to
ensure that the autopkgtest can work even with the updated libvirt
package.

I'll attach a tentative patch here and also open a merge request on
salsa. Feel free to pick up whichever one is more convenient.

Note that the failing autopkgtest is preventing libvirt from
migrating to testing, so ideally this would be addressed sooner
rather than later.

Thanks!


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

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

Bug#1081066: ITP: libjs-htmx -- framework for performing various javascript actions from html

[Andrea Pappacoda]

On Mon Sep 9, 2024 at 10:03 AM CEST, Jonathan Carter wrote:

Hmm, I was sure I saw this working on Saturday.


As far as I know, this is not possible, unfortunately. But I'm happy to 
be proven wrong!


Anyway, I was strongly considering shipping the unzipped version 
anyway, so I'll upload a new version that does just that later today.


Good to hear, thanks :D


signature.asc
Description: PGP signature

Bug#754809: informational IETF draft

[Andrea Pappacoda]

Hi all,

some more time has passed, and in the meanwhile an informational IETF 
draft has been published which discusses the various mitigations to this 
issue. You can find it here: 



It does not contain any magical solution, but might be a good starting 
point for someone wanting to figure out what is happening and eventually 
working on a fix.


Bye!

P.S. my email domain has a DMARC p=reject policy


signature.asc
Description: PGP signature

Bug#1081066: ITP: libjs-htmx -- framework for performing various javascript actions from html

[Andrea Pappacoda]

On Mon Sep 9, 2024 at 9:35 AM CEST, Jonathan Carter wrote:

I went with libjs-htmx, it's now in unstable.


Wow, that was quick!


This installs the htmx binary to:
/usr/share/javascript/htmx/htmx.min.js.gz


I'm not an expert when it comes to JavaScript (and that's in part why
I like htmx), and know even less about JavaScript policies in Debian.
But, wouldn't installing a gzipped file create issues? Can I directly
include it into a browser?


Yes, browsers support gz decompression, and the decompression doesn't 
cause any noticeable overhead.


I'm of course aware of that :)

What I meant is that browsers support gzip decompression only as part as 
the HTTP spec, and I feared that it wouldn't be possible to directly 
include the js file without using a webserver, with something like:


   

And, after checking, that's indeed not possible.

Could you please ship both a compressed and an uncompressed version of 
the file? libjs-jquery does this, while libjs-highlight-js only ships 
uncompressed files:


   $ dpkg --listfiles libjs-jquery | grep javascript/
   /usr/share/javascript/jquery
   /usr/share/javascript/jquery/jquery.js
   /usr/share/javascript/jquery/jquery.min.js
   /usr/share/javascript/jquery/jquery.min.js.brotli
   /usr/share/javascript/jquery/jquery.min.js.gz
   /usr/share/javascript/jquery/jquery.min.map
   /usr/share/javascript/jquery/jquery.min.map.brotli
   /usr/share/javascript/jquery/jquery.min.map.gz

   $ dpkg --listfiles libjs-highlight.js | grep javascript/ | grep -v styles
   /usr/share/javascript/highlight.js
   /usr/share/javascript/highlight.js/highlight.js
   /usr/share/javascript/highlight.js/highlight.min.js

Thanks! Bye :)


signature.asc
Description: PGP signature

Bug#1081066: ITP: libjs-htmx -- framework for performing various javascript actions from html

[Andrea Pappacoda]

Hi Jonathan, thanks for packaging htmx!

On Sat Sep 7, 2024 at 9:51 PM CEST, Jonathan Carter wrote:

* Package name: libjs-htmx


Should the source package be called htmx.js or libjs-htmx? According to 
, browser only libraries 
should be called libjs-htmx, but since version 2.0.0 an ECMAScript 
Module is provided too.



This installs the htmx binary to:
/usr/share/javascript/htmx/htmx.min.js.gz


I'm not an expert when it comes to JavaScript (and that's in part why 
I like htmx), and know even less about JavaScript policies in Debian. 
But, wouldn't installing a gzipped file create issues? Can I directly 
include it into a browser?


Thanks again! Bye :)


signature.asc
Description: PGP signature

Bug#1064126: [Pkg-libvirt-maintainers] Bug#1064126: libvirt: install NSS modules into /usr

[Andrea Bolognani]

On Thu, Sep 05, 2024 at 05:59:15AM +0200, Helmut Grohne wrote:
> On Wed, Sep 04, 2024 at 10:23:53PM +0200, Andrea Bolognani wrote:
> > This has now been accepted, and the package uploaded to experimental.
> > 
> > Please let me know how dumat feels about it :)
> 
> Thanks. It reached dumat and the libvirt report entirely disappeared.
> Green light for unstable from my side.

10.7.0-1, which includes these changes, is now in unstable.

> Thanks for collaborating on this.

Thanks to you and Michael! It's been a very long journey, and it
feels great to finally put it behind us.

Now bracing for the inevitable fallout, hoping that it will not
be *too* bad to deal with... O:-)

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1080416: RFS: u-config/0.33.1-1 [ITP] -- smaller, simpler, portable pkg-config clone

[Andrea Pappacoda]

On Sat Sep 7, 2024 at 4:27 PM CEST, Boyuan Yang wrote:

Okay. I have uploaded this version of the package.


Thanks!

One caveat that I will need to point out (but not necessarily 
a blocker): by hardcoding PKG_CONFIG_SYSTEM_LIBRARY_PATH at build 
time, your package may not build correctly when being cross built when 
the host arch is different from the target arch. I am not an export in 
this field, but you may need to dig into it if necessary.


The variable is obtained via GCC, which I believe should print the 
corrent paths when cross compiling. I haven't checked though. I'll fix 
this if needed, thanks for the pointer :)


Bye!

Bug#1064126: [Pkg-libvirt-maintainers] Bug#1064126: libvirt: install NSS modules into /usr

[Andrea Bolognani]

On Sun, Sep 01, 2024 at 05:17:28PM +0200, Andrea Bolognani wrote:
> On Fri, Aug 30, 2024 at 09:38:46PM +0200, Helmut Grohne wrote:
> > Looking forward to your update.
> 
> MR here:
> 
>   https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/232
> 
> Please take a look.

This has now been accepted, and the package uploaded to experimental.

Please let me know how dumat feels about it :)

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1080416: RFS: u-config/0.33.1-1 [ITP] -- smaller, simpler, portable pkg-config clone

[Andrea Pappacoda]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "u-config":

* Package name : u-config
  Version  : 0.33.1-1
  Upstream contact : Chris Wellons 
* URL  : https://github.com/skeeto/u-config
* License  : Unlicense
* Vcs  : https://salsa.debian.org/tachi/u-config
  Section  : devel

The source builds the following binary package:

 u-config - smaller, simpler, portable pkg-config clone

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

 https://mentors.debian.net/package/u-config/

The package is maintained with Git, on Salsa, and I'd recommend checking
it out this way. I'd be happy if you could perform the upload using
dgit, but it is not required.

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

 dget -x 
https://mentors.debian.net/debian/pool/main/u/u-config/u-config_0.33.1-1.dsc

Changes for the initial release:

u-config (0.33.1-1) unstable; urgency=medium
.
  * Initial release. (Closes: #1080307)

Bye :D


signature.asc
Description: PGP signature

Bug#1080383: RFS: vixl/7.0.0-1 -- ARMv8 Runtime Code Generation Library

[Andrea Pappacoda]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : vixl
  Version  : 7.0.0-1
  Upstream contact : Linaro 
* URL  : https://github.com/Linaro/vixl
* License  : BSD-3-Clause
* Vcs  : https://salsa.debian.org/debian/vixl
  Section  : libs

The source builds the following binary packages:

 libvixl7 - ARMv8 Runtime Code Generation Library
 libvixl-dev - ARMv8 Runtime Code Generation Library - develop

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

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

Vixl is maintained using Git and dgit, so could you please use dgit to
perform the upload? In case you've never used it, here are the steps you
should follow:

   apt install dgit git-debrebase
   git clone g...@salsa.debian.org:debian/vixl.git
   cd vixl
   origtargz
   dgit sbuild
   dgit --new push-built && git push --all --follow-tags

Be sure to perform the last pipeline as described! Otherwise the Git
repository hosted on Salsa will get out of date. Thanks!

Changes since the last upload:

vixl (7.0.0-1) experimental; urgency=medium
.
  * Update to new upstream version 7.0.0.
  * d/control: libvixl5 -> libvixl7
  * d/control: declare dpkg-build-api = 1
  * d/control: prefer markdown to discount.
Discount has some minor differences in output which might affect
negatively the produced HTML. Since upstream suggests installing the
"markdown" program, do that if possible, falling back to discount.
  * d/patches: update Meson patch

Bye :D


signature.asc
Description: PGP signature

Bug#1074248: transition: mbedtls

[Andrea Pappacoda]

Hi, mbedtls upstream has now released version 3.6.1. I'd like to go 
ahead with the transition, if possible.


Bye :)


signature.asc
Description: PGP signature

Bug#1080307: ITP: u-config -- smaller, simpler, portable pkg-config clone

[Andrea Pappacoda]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: u-config
  Version : 0.33.1
  Upstream Contact: Chris Wellons 
* URL : https://github.com/skeeto/u-config
* License : UNLICENSE
  Programming Lang: C
  Description : smaller, simpler, portable pkg-config clone

 u-config ("micro-config") is a small, highly portable pkg-config and
 pkgconf clone.
 .
 It is a fraction of the size while retaining the core, user-level
 features of pkg-config and pkgconf. It is also highly portable,
 supporting a variety of compilers and operating systems; it can even be
 built without libc.
 .
 u-config focuses on supporting existing pkg-config based builds, while
 omitting developer-level features like debugging options. It also adds
 some unique features, like the possibility of separating arguments by
 line feeds instead of spaces, and better handling of spaces in file
 paths.

I find u-config useful when checking pkg-config files, and it is a nice little
tool which does it job well. It also performs well against malicious inputs.

I'll need a sponsor for the first upload.


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZtTY+BQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p2YOAP9hZ8z7fjmVz2PWv8OzrxChijqWNYU2
nYeqCbWpiwJwwAD/SeqYBE0+2xyGsTbk1O0yDPsVyCI5nzY/Y5I0H6zKQwQ=
=XBVT
-END PGP SIGNATURE-

Bug#1080144: xbyak: FTBFS: failing tests

[Andrea Pappacoda]

On Fri Aug 30, 2024 at 8:29 PM CEST, Santiago Vila wrote:

It happens in testing already:


Yeah, I hadn't upgraded my packages since a few weeks.

I've ran a bisection with debbisect and it reported the following:

   bisection finished successfully
 last good timestamp: 20240809T084720Z
 first bad timestamp: 20240809T144756Z

Additionally, diffing the build dependencies used by the two builds 
I get the following:


   $ diff good-pkgs bad-pkgs 
   75,76c75,76

   < libaudit-common=1:3.1.2-4
   < libaudit1:amd64=1:3.1.2-4+b1
   ---
   > libaudit-common=1:4.0.1-1
   > libaudit1:amd64=1:4.0.1-1
   206c206
   < nasm=2.16.01-1
   ---
   > nasm=2.16.03-1

I doubt libaudit caused the issue, since it is not a build dependency of 
xbyak (it is pulled in by apt), so it seems that nasm 2.16.03 changed 
something in its output which broke xbyak tests.


Thanks for the report! I'll now try to figure out if this is xbyak 
hardcoding something it shouldn't or if this is a legitimate issue 
introduced by the new nasm release.


signature.asc
Description: PGP signature

Bug#1078134: lz4: new lz4Config.cmake file causes FTBFS due to bogus xxhash dependency

[Andrea Pappacoda]

Hi, yuzu has been now removed from testing because of this bug.

Could you please let me know what solution would you like to adopt? If 
you want, I can provide a patch.


Bye!

Bug#1064126: [Pkg-libvirt-maintainers] Bug#1064126: libvirt: install NSS modules into /usr

[Andrea Bolognani]

On Fri, Aug 30, 2024 at 09:38:46PM +0200, Helmut Grohne wrote:
> On Fri, Aug 30, 2024 at 09:19:08PM +0200, Andrea Bolognani wrote:
> > I disagree on the check being useless in general though. The
> > diversion should only be created when upgrading from a version of
> > libvirt that was not usr-merged to one that is; when upgrading from a
> > version that is already usr-merged, we should do nothing.
> > 
> > So the correct check should be
> > 
> >   if [ -n "$2" ] && dpkg --compare-versions -- "$2" gt "$lastver"; then
> >   return 0
> >   fi
> 
> Indeed. If you already are on a moved version, that should work. Please
> keep in mind that when doing this, you must not backport libvirt as
> bookworm (including bookworm-backports) need to have systemd units in
> aliased locations as otherwise debhelper will fail to generate
> maintainer scripts.

We've already effectively ruled out backports to bookworm when we
decided to move unit files using the straightforward method instead
of investigating dh_movetousr, so this is understood.

> So the $lastver should be the last version that ever
> becomes part of any bookworm release. To accommodate security updates, I
> recommend changing it to `ge "$firstver"`.

Well I just got it wrong the second time around too O:-)

The {create,delete}_protective_diversion() functions don't take
"lastver" as argument, so I should have used "firstver" there.

I believe that using "gt" is correct though. It's what we're using in
the other snippets already, and that in turn is based on the advice
present in dpkg-maintscript-helper(1), specifically the part about
the prior-version common parameter.

Checking the actual code for dpkg-maintscript-helper, this is how
that argument is used:

  if [ "$1" = "install" -o "$1" = "upgrade" ] && [ -n "$2" ] &&
 dpkg --compare-versions -- "$2" le-nl "$LASTVERSION"; then
# perform action
  fi

So if, for built-in operations, the action is performed when

  "$2" le "$LASTVERSION"

it seems right that in our case it would be *skipped* when

  "$2" gt "$firstver"

which is the opposite condition.

In both cases the version number we provide to the script would be
e.g. 10.6.0-3~ for a change happening in 10.6.0-3, which is again
consistent with the advice found in dpkg-maintscript-helper(1).

Do you have any reason to believe "ge" is correct here and "gt" is
not? Otherwise, I'd rather stick with the approach that we've adopted
until now and which has not, at least as far as I'm aware of, caused
any issues so far.

> > I'm not familiar with running piuparts locally. If you can share some
> > brief instructions on how to do that, I'll happily try things out
> > before creating the MR.
> 
> You may just pass a .changes file to piuparts and it'll debootstrap into
> a directory and clean up behind itself. This will not test upgrades, but
> it'll catch the worst of mistakes. piuparts expects to be run as root
> though. You may run unstable piuparts without root by wrapping it in
> 
> unshare --user --map-auto --setuid 0 --setgid 0 --mount --pid --fork 
> --mount-proc true
> 
> For details refer to
> https://salsa.debian.org/debian/piuparts/-/merge_requests/60. Failing
> that, just upload to experimental and let piuparts.d.o do it.

If this doesn't test upgrades, it doesn't sound like it would be very
useful... Might as well let the service deployed on debian.org do its
thing after the upload to experimental, same as with dumat.

> > I'll work on implementing and testing this over the weekend. I'll
> > update the bug as appropriate.
> 
> Looking forward to your update.

MR here:

  https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/232

Please take a look.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1006169: closed by j...@debian.org (Close 1006169)

[Andrea Pappacoda]

Control: tag -1 wontfix

On Sat Aug 31, 2024 at 2:15 PM CEST, Debian Bug Tracking System wrote:
We regret that your request could not be reviewed in time for the 
final point release of bullseye (11.11).


That's sad. I've put a lot of efforts in this over a long period of 
time, but I'm happy I've learned someting. Hope it'll go better next 
time!

Bug#1064126: [Pkg-libvirt-maintainers] Bug#1064126: libvirt: install NSS modules into /usr

[Andrea Bolognani]

On Wed, Aug 28, 2024 at 09:53:29AM +0200, Helmut Grohne wrote:
> Let me do the review part here given that you already did most of the
> work and given that a number of remarks have multiple options and I
> don't happen to know your preference.

Thanks!

> If you happen to enjoy merge requests originating from the Debian
> Janitor, you may wrap all the added code like this:
> 
> # begin-remove-after: released:trixie
> #DELETE_PROTECTIVE_DIVERSION#
> # end-remove-after
> 
> This serves both as a human-readable reminder for removing the code
> eventually, but it also is machine-readable and will make the Debian
> Janitor propose a MR for removing this code at the desired time. I'll
> leave it up to you whether you want to add support for this or not. If
> you do, please wrap all relevant code to avoid a partial removal.

We've generally strived to maintain wider compatibility than just one
Debian release, for example with the most recent Ubuntu LTS at the
very least and possibly some more. So this suggestion, albeit really
useful, doesn't really apply to libvirt.

> > +for unit in $VIRTLOGD_UNITS; do
> > +delete_protective_diversion \
> > +"/lib/systemd/system/$unit" \
> > +"10.6.0-3~" \
> > +-- \
> > +"$@"
> > +done
> 
> I suggest running this snippet also in the abort-upgrade case.

For preinst, abort-upgrade is called against old-preinst, so this
doesn't seem very useful. Older versions of the package, by
definition, will not know about the diversion so there won't be
anything to clean up in those cases.

> Also add these calls to postrm matching the arguments failed-upgrade,
> abort-install, and abort-upgrade.

This, on the other hand, makes perfect sense.

> You have handled the libvirt-daemon-log units. The dumat report
> mentioned three other packages libvirt-daemon, libvirt-daemon-common,
> and libvirt-daemon-lock. Will you repeat the maintainer scripts for them
> and their mentioned units in the dumat report? I hope it is fairly
> obvious how to apply this.

Yes, I've just used virtlogd as an example. The other services will
be handled as well.

> > +create_protective_diversion() {
> > +local usrfile="$1"
> > +local firstver="$2"
> > +
> > +if [ "$2" != "--" ]; then
> 
> Do you mean $3 here? I think $2 is firstver.

Yes, I've mentioned the fact that tis was an oversight in a follow-up
message. I guess you must have missed it :)

> > +if [ -z "$2" ] || dpkg --compare-versions -- "$2" gt "$lastver"; then
> > +return 0
> > +fi
> 
> Please remove this check. For instance, libvirt-daemon-common does not
> exist in bookworm. Hence $2 will be empty and you'd skip the addition of
> these diversions when installing libvirt-daemon-common, but they're
> really needed on such a first installation. What you could check here is
> the version of libvirt-daemon-system (the package we are moving the
> units from), but the added value in doing so does not warrant the added
> complexity in my opinion.

Right, this is incorrect. Another consequence of very quickly
sketching out a draft implementation :)

I disagree on the check being useless in general though. The
diversion should only be created when upgrading from a version of
libvirt that was not usr-merged to one that is; when upgrading from a
version that is already usr-merged, we should do nothing.

So the correct check should be

  if [ -n "$2" ] && dpkg --compare-versions -- "$2" gt "$lastver"; then
  return 0
  fi

That is, perform an early exit if we are upgrading from a version of
the package that is newer than the one where usr-merge was
implemented, and create the diversion otherwise.

> > +if [ ! -e "$usrfile.usr-is-merged" ]; then
> > +return 0
> > +fi
> 
> Please remove this check. The diverted file is expected to never exist.
> The sole point of the diversion is to redirect the removal of the file
> to a harmless location. This check would result in the diversions never
> getting removed. If you feel like you need to add a condition, consider
> using this:
> 
> if [ -z "$(dpkg-divert --list "$usrfile")" ]; then
> return 0
> fi

Got it. I'll use something along the lines of what you suggested
instead.

> Does your salsa-ci pipeline run piuparts? If not, consider running it
> locally before uploading to experimental. It should catch the worst of
> issues.

The pipeline is set up to run piuparts, but the information reported
by the job is unfortuna

Bug#1080144: xbyak: FTBFS: failing tests

[Andrea Pappacoda]

Hi Santiago, thanks for the report.

I found out about the failure yesterday, but it'd be nice to know which package 
update in unstable broke xbyak's tests, so that I can debug the issue quicker.

The issue does not appear yet on Testing.

Thanks!

(sorry for the crappy email - I'm on my phone)

Il 30 agosto 2024 19:39:56 CEST, Santiago Vila  ha scritto:
>Package: src:xbyak
>Version: 7.05-1
>Severity: serious
>Tags: ftbfs
>
>Dear maintainer:
>
>During a rebuild of all packages in unstable, your package failed to build:
>
>
>[...]
> debian/rules binary
>dh binary --buildsystem=meson
>   dh_update_autotools_config -O--buildsystem=meson
>   dh_autoreconf -O--buildsystem=meson
>   dh_auto_configure -O--buildsystem=meson
>   cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 
> meson setup .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr 
> --sysconfdir=/etc --localstatedir=/var --libdir=lib/x86_64-linux-gnu 
> -Dpython.bytecompile=-1
>The Meson build system
>Version: 1.5.1
>Source dir: /<>
>Build dir: /<>/obj-x86_64-linux-gnu
>Build type: native build
>Project name: xbyak
>Project version: 7.05
>C++ compiler for the host machine: c++ (gcc 14.2.0 "c++ (Debian 14.2.0-3) 
>14.2.0")
>C++ linker for the host machine: c++ ld.bfd 2.43.1
>Host machine cpu family: x86_64
>Host machine cpu: x86_64
>Did not find pkg-config by name 'pkg-config'
>Found pkg-config: NO
>Program cmake found: YES (/usr/bin/cmake)
>Build targets in project: 0
>
>xbyak 7.05
>
>  User defined options
>buildtype : plain
>libdir: lib/x86_64-linux-gnu
>localstatedir : /var
>prefix: /usr
>sysconfdir: /etc
>wrap_mode : nodownload
>python.bytecompile: -1
>
>Found ninja-1.12.1 at /usr/bin/ninja
>   dh_auto_build -O--buildsystem=meson
>   cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j2 -v
>ninja: no work to do.
>   debian/rules execute_after_dh_auto_build-arch
>make[1]: Entering directory '/<>'
>make -C sample BIT=64
>make[2]: Entering directory '/<>/sample'
>g++ -g -O2 -fomit-frame-pointer -Wall -I../ -Wall -Wextra -Wformat=2 
>-Wcast-qual -Wcast-align -Wwrite-strings -Wfloat-equal -Wpointer-arith  -g -O2 
>-Werror=clobbered -Werror=volatile-register-var 
>-D__DEB_CANARY_CXXFLAGS_c09f9caf5e08836d4673ccdd69bb041e__ 
>-ffile-prefix-map=/<>=. -fstack-protector-strong 
>-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
>-D__DEB_CANARY_CPPFLAGS_c09f9caf5e08836d4673ccdd69bb041e__ -Wdate-time 
>-D_FORTIFY_SOURCE=2 -Wl,-z,deb-canary-c09f9caf5e08836d4673ccdd69bb041e 
>-Wl,-z,relro -Wl,-z,now test0.cpp -o test64 -m64
>/usr/bin/ld: warning: -z deb-canary-c09f9caf5e08836d4673ccdd69bb041e ignored
>g++ -g -O2 -fomit-frame-pointer -Wall -I../ -Wall -Wextra -Wformat=2 
>-Wcast-qual -Wcast-align -Wwrite-strings -Wfloat-equal -Wpointer-arith  -g -O2 
>-Werror=clobbered -Werror=volatile-register-var 
>-D__DEB_CANARY_CXXFLAGS_c09f9caf5e08836d4673ccdd69bb041e__ 
>-ffile-prefix-map=/<>=. -fstack-protector-strong 
>-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
>-D__DEB_CANARY_CPPFLAGS_c09f9caf5e08836d4673ccdd69bb041e__ -Wdate-time 
>-D_FORTIFY_SOURCE=2 -Wl,-z,deb-canary-c09f9caf5e08836d4673ccdd69bb041e 
>-Wl,-z,relro -Wl,-z,now bf.cpp -o bf64 -m64
>/usr/bin/ld: warning: -z deb-canary-c09f9caf5e08836d4673ccdd69bb041e ignored
>g++ -g -O2 -fomit-frame-pointer -Wall -I../ -Wall -Wextra -Wformat=2 
>-Wcast-qual -Wcast-align -Wwrite-strings -Wfloat-equal -Wpointer-arith  -g -O2 
>-Werror=clobbered -Werror=volatile-register-var 
>-D__DEB_CANARY_CXXFLAGS_c09f9caf5e08836d4673ccdd69bb041e__ 
>-ffile-prefix-map=/<>=. -fstack-protector-strong 
>-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
>-D__DEB_CANARY_CPPFLAGS_c09f9caf5e08836d4673ccdd69bb041e__ -Wdate-time 
>-D_FORTIFY_SOURCE=2 -Wl,-z,deb-canary-c09f9caf5e08836d4673ccdd69bb041e 
>-Wl,-z,relro -Wl,-z,now memfunc.cpp -o memfunc64 -m64
>/usr/bin/ld: warning: -z deb-canary-c09f9caf5e08836d4673ccdd69bb041e ignored
>g++ -g -O2 -fomit-frame-pointer -Wall -I../ -Wall -Wextra -Wformat=2 
>-Wcast-qual -Wcast-align -Wwrite-strings -Wfloat-equal -Wpointer-arith  -g -O2 
>-Werror=clobbered -Werror=volatile-register-var 
>-D__DEB_CANARY_CXXFLAGS_c09f9caf5e08836d4673ccdd69bb041e__ 
>-ffile-prefix-map=/<>=. -fstack-protector-strong 
>-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
>-D__DEB_CANARY_CPPFLAGS_c09f9caf5e08836d4673ccdd69bb041e__ -Wdate-time 
>-D_FORTIFY_SOURCE=2 -Wl,-z,deb-canary-c09f9caf5e08836d4673ccdd69bb041e 
>-Wl,-z,relro -Wl,-z,now test_util.cpp -o test_util64 -m64
>/usr/bin/ld: warning: -z deb-canary-c09f9caf5e08836d4673ccdd69bb041e ignored
>g++ -g -O2 -fomit-frame-pointer -Wall -I../ -Wall -Wextra -Wformat=2 
>-Wcast-qual -Wcast-align -Wwrite-strings -Wfloat-equal -Wpointer-arith  -g -O2 
>-Werror=clobbered -Werror=volatile

Bug#1064126: [Pkg-libvirt-maintainers] Bug#1064126: libvirt: install NSS modules into /usr

[Andrea Bolognani]

On Wed, Aug 28, 2024 at 12:17:05AM +0200, Andrea Bolognani wrote:
> +#BEGIN CREATE_PROTECTIVE_DIVERSION
> +create_protective_diversion() {
> +local usrfile="$1"
> +local firstver="$2"
> +
> +if [ "$2" != "--" ]; then

This should be "$3" for things to work. Same in the other snippet.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1061477: [PATCH] Add text/ecmascript, move es file ext to it

[Andrea Pappacoda]

RFC 9239 section 6.1.1 and 6.2.1 define two media types, text/javascript
and text/ecmascript, respectively. It also assigns the file extensions
"js" and "mjs" to the former, and "es" and "mjs" to the latter.
text/ecmascript is considered obsolete, but still distinct from
text/javascript.

This patch hence updates the mime.types file to reflect this fact.

Closes: #1061477
---
 mime.types | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mime.types b/mime.types
index b6a8be0..a845d81 100644
--- a/mime.types
+++ b/mime.types
@@ -2109,6 +2109,7 @@ text/css  css
 text/csv   csv
 text/csv-schemacsvs
 text/dns   soa zone
+text/ecmascriptes mjs
 text/encaprtp
 text/enriched
 text/example
@@ -2119,7 +2120,7 @@ text/gff3 gff3
 text/grammar-ref-list
 text/hl7v2
 text/html  html htm shtml
-text/javascriptes js mjs
+text/javascriptjs mjs
 text/jcr-cnd   cnd
 text/markdown  md markdown
 text/mizar miz
-- 
2.45.2

Bug#1064126: [Pkg-libvirt-maintainers] Bug#1064126: libvirt: install NSS modules into /usr

[Andrea Bolognani]

cha.



diff --git a/debian/libvirt-daemon-log.postinst.in 
b/debian/libvirt-daemon-log.postinst.in
index 21723d4307..d75b30d930 100644
--- a/debian/libvirt-daemon-log.postinst.in
+++ b/debian/libvirt-daemon-log.postinst.in
@@ -15,6 +15,7 @@ set -e
 # the debian-policy package
 
 #FINISH_CONFFILE_TRANSFER#
+#DELETE_PROTECTIVE_DIVERSION#
 
 DAEMON_SYSTEM_TO_DAEMON_LOG="
 /etc/default/virtlogd
@@ -24,6 +25,12 @@ DAEMON_SYSTEM_SYSV_TO_DAEMON_LOG="
 /etc/init.d/virtlogd
 "
 
+VIRTLOGD_UNITS="
+virtlogd-admin.socket
+virtlogd.service
+virtlogd.socket
+"
+
 case "$1" in
 configure)
 for conf in $DAEMON_SYSTEM_TO_DAEMON_LOG; do
@@ -46,6 +53,13 @@ case "$1" in
 -- \
 "$@"
 done
+for unit in $VIRTLOGD_UNITS; do
+delete_protective_diversion \
+"/lib/systemd/system/$unit" \
+"10.6.0-3~" \
+-- \
+"$@"
+done
 ;;
 
 abort-upgrade|abort-remove|abort-deconfigure)
diff --git a/debian/libvirt-daemon-log.preinst.in 
b/debian/libvirt-daemon-log.preinst.in
new file mode 100644
index 00..f5dbf73de9
--- /dev/null
+++ b/debian/libvirt-daemon-log.preinst.in
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+set -e
+
+# summary of how this script can be called:
+#
+#   *  `install'
+#   *  `install'  
+#   *  `upgrade'  
+#   *  `abort-upgrade' 
+#
+# for details, see https://www.debian.org/doc/debian-policy/ or
+# the debian-policy package
+
+#CREATE_PROTECTIVE_DIVERSION#
+
+VIRTLOGD_UNITS="
+virtlogd-admin.socket
+virtlogd.service
+virtlogd.socket
+"
+
+case "$1" in
+install|upgrade)
+for unit in $VIRTLOGD_UNITS; do
+create_protective_diversion \
+"/lib/systemd/system/$unit" \
+"10.6.0-3~" \
+-- \
+"$@"
+done
+;;
+
+abort-upgrade)
+;;
+
+*)
+echo "preinst called with unknown argument \`$1'" >&2
+exit 1
+;;
+esac
+
+#DEBHELPER#
+
+exit 0
diff --git a/debian/snippets.sh b/debian/snippets.sh
index 6b03f242d6..ad86432332 100644
--- a/debian/snippets.sh
+++ b/debian/snippets.sh
@@ -194,6 +194,54 @@ remove_config_from_template() {
 }
 #END REMOVE_CONFIG_FROM_TEMPLATE
 
+#BEGIN CREATE_PROTECTIVE_DIVERSION
+create_protective_diversion() {
+local usrfile="$1"
+local firstver="$2"
+
+if [ "$2" != "--" ]; then
+echo "create_protective_diversion called with the wrong number of 
arguments" >&2
+return 1
+fi
+for _ in $(seq 1 2); do
+shift
+done
+
+if [ -z "$2" ] || dpkg --compare-versions -- "$2" gt "$lastver"; then
+return 0
+fi
+
+dpkg-divert \
+--no-rename \
+--divert "$usrfile.usr-is-merged" \
+--add "$usrfile"
+}
+#END CREATE_PROTECTIVE_DIVERSION
+
+#BEGIN DELETE_PROTECTIVE_DIVERSION
+delete_protective_diversion() {
+local usrfile="$1"
+local firstver="$2"
+
+if [ "$2" != "--" ]; then
+echo "delete_protective_diversion called with the wrong number of 
arguments" >&2
+return 1
+fi
+for _ in $(seq 1 2); do
+shift
+done
+
+if [ ! -e "$usrfile.usr-is-merged" ]; then
+return 0
+fi
+
+dpkg-divert \
+--no-rename \
+--divert "$usrfile.usr-is-merged" \
+--remove "$usrfile"
+}
+#END DELETE_PROTECTIVE_DIVERSION
+
 #BEGIN SYSTEMD_DAEMON_RELOAD
 systemd_daemon_reload() {
 if [ -z "${DPKG_ROOT:-}" ] && [ -d /run/systemd/system ]; then
-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1078426: [PATCH] bts: fix crash when using submissions/smtps

[Andrea Pappacoda]

This patch fixes a regression introduced in
dd2ac025db69bc78ca62391153ce4e74215e4903, which broke the bts script
when using implicit TLS via the submissions port (465), i.e. when
setting `--smtp-host` to a string starting with "smtps://" or
"ssmtp://".

The issue was that the mentioned commit added a line unconditionally
upgrading the connection with STARTTLS, even when the connection was
already using TLS via implicit TLS, which is an illegal operation and
causes Net::SMTP::starttls to die with message "SMTP connection is
already in SSL mode".

Closes: #1078426
---
 scripts/bts.pl | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/scripts/bts.pl b/scripts/bts.pl
index 9a878430..7ca37f6a 100755
--- a/scripts/bts.pl
+++ b/scripts/bts.pl
@@ -2684,7 +2684,8 @@ sub send_mail {
 } elsif (length $smtphost) {
 my $smtp;
 
-if ($smtphost =~ m%^(?:(?:ssmtp|smtps)://)(.*)$%) {
+my $smtps = $smtphost =~ m%^(?:(?:ssmtp|smtps)://)(.*)$%;
+if ($smtps) {
 my ($host, $port) = split(/:/, $1);
 $port ||= '465';
 
@@ -2711,10 +2712,12 @@ sub send_mail {
 if ($smtpuser) {
 if (have_authen_sasl) {
 $smtppass = getpass() if not $smtppass;
-# Enforce STARTTLS; Net::SMTP will otherwise refuse auth() in
-# the next step, and terminate the connection with FIN.
+# Enforce STARTTLS, unless we're using SMTPS; Net::SMTP will
+# otherwise refuse auth() in the next step, and terminate the
+# connection with FIN.
 $smtp->starttls()
-  or die "$progname: Could not upgrade with STARTTLS";
+  or die "$progname: Could not upgrade with STARTTLS"
+  unless $smtps;
 $smtp->auth($smtpuser, $smtppass)
   or die
   "$progname: failed to authenticate to $smtphost\n($@)\n";
-- 
2.45.2

Bug#1064126: [Pkg-libvirt-maintainers] Bug#1064126: libvirt: install NSS modules into /usr

[Andrea Bolognani]

On Sat, Aug 24, 2024 at 02:29:52PM +0200, Andrea Bolognani wrote:
> The changes I've been working on are now available here:
> 
>   https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/229
> 
> Thank you all for your patience.

10.6.0-2, which includes the changes, is now in experimental. Thanks
again for taking care of the upload, in addition to reviewing and
testing everything, Guido!

Do we need to do anything to cause dumat do do its thing, or will
that happen automatically? And will you (Helmut, Michael) let us know
what the outcome of its analysis is, or is that something that we
will need to look up ourselves?

Assuming no issues are detected, I would like to upload 10.7.0-1 with
these changes and the new upstream release to unstable in a week or
so, but I can delay that for a bit if more time is needed.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1076335: bookworm-pu: package libvirt/9.0.0-4

[Andrea Bolognani]

On Sun, Aug 25, 2024 at 12:22:30AM +0100, Adam D. Barratt wrote:
> On Sat, 2024-08-24 at 23:12 +0200, Andrea Bolognani wrote:
> > After performing the upload ~4 hours ago, I have received a message
> > with subject
> > 
> >   libvirt_9.0.0-4+deb12u1_source.changes
> >   ACCEPTED into proposed-updates->stable-new
> > 
> > and (partial) contents
> > 
> >   Mapping bookworm to stable.
> >   Mapping stable to proposed-updates.
> > 
> > so I think I'm good? The tracker.d.o page hasn't been updated yet
> > though, and none of the bugs that the upload is supposed to close
> > have changed their state. This usually happens pretty quickly when
> > uploading to unstable.
> 
> Your package is in the stable-new policy queue, as per the emails you
> received. It will stay there until SRM accept it. You don't need to do
> anything other than wait for that to happen, or an e-mail that says
> there's a problem. There's nothing for you to do in the meantime.

Excellent. I figured something like that might be going on, but it's
good to have explicit confirmation.

Thank you for all your help!

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1076335: bookworm-pu: package libvirt/9.0.0-4

[Andrea Bolognani]

On Sat, Aug 24, 2024 at 05:03:50PM +0200, Andrea Bolognani wrote:
> The debdiff is attached, and the corresponding MR is
> 
>   https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/230
> 
> I'll grab some coffee while I wait for the pipeline to run, and
> proceed with the upload in ~30 minutes unless you tell me otherwise.

After performing the upload ~4 hours ago, I have received a message
with subject

  libvirt_9.0.0-4+deb12u1_source.changes
  ACCEPTED into proposed-updates->stable-new

and (partial) contents

  Mapping bookworm to stable.
  Mapping stable to proposed-updates.

so I think I'm good? The tracker.d.o page hasn't been updated yet
though, and none of the bugs that the upload is supposed to close
have changed their state. This usually happens pretty quickly when
uploading to unstable.

As I mentioned this is my first time preparing a stable update, so
I'd love to be reassured that things are progressing as expected,
especially considering the fairly tight deadline.

Thanks!

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1076335: bookworm-pu: package libvirt/9.0.0-4

[Andrea Bolognani]

On Sat, Aug 24, 2024 at 03:53:52PM +0100, Adam D. Barratt wrote:
> On Sat, 2024-08-24 at 15:41 +0200, Andrea Bolognani wrote:
> > Just so that we're on the same page, do you want me to share the
> > debdiff here and get an explicit ACK from you before proceeding with
> > the upload, or should I go for the the upload first in the interest
> > of time?
> 
> If the change from the previously-acked diff is just the addition of
> the new patch as per the MR, and a changelog entry for it, then feel
> free to upload without waiting for a new ack. Please do still send the
> new debdiff to this bug.

I've made a couple of tiny tweaks to the commit messages and patch
metadata, but nothing functionally relevant.

The debdiff is attached, and the corresponding MR is

  https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/230

I'll grab some coffee while I wait for the pipeline to run, and
proceed with the upload in ~30 minutes unless you tell me otherwise.

Thanks!

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.
diff -Nru libvirt-9.0.0/debian/changelog libvirt-9.0.0/debian/changelog
--- libvirt-9.0.0/debian/changelog  2023-05-21 11:31:31.0 +0200
+++ libvirt-9.0.0/debian/changelog  2024-08-24 16:05:45.0 +0200
@@ -1,3 +1,28 @@
+libvirt (9.0.0-4+deb12u1) bookworm; urgency=medium
+
+  [ Cyril Brulebois ]
+  * [6a7f95a] patches: Add backports
+- backport/virsh-Make-domif-setlink-work-more-than-once.patch
+  - Closes: #1075718
+
+  [ Andrea Bolognani ]
+  * [56f1ae3] patches: Add backports
+- backport/Fix-off-by-one-error-in-udevListInterfacesByStatus.patch
+  - Fixes CVE-2024-1441
+- backport/interface-fix-udev_device_get_sysattr_value-return-value-.patch
+  - Fixes CVE-2024-2496
+- backport/remote-check-for-negative-array-lengths-before-allocation.patch
+  - Fixes CVE-2024-2494
+- backport/storage-Fix-returning-of-locked-objects-from-virStoragePo.patch
+  - Fixes CVE-2023-3750
+
+  [ Lee Garrett ]
+  * [7dc22f9] patches: Add backports
+- backport/qemu-domain-Fix-logic-when-tainting-domain.patch
+  - Closes: #1052405
+
+ -- Andrea Bolognani   Sat, 24 Aug 2024 16:05:45 +0200
+
 libvirt (9.0.0-4) unstable; urgency=medium
 
   * [79f6669] patches: Add backports
diff -Nru libvirt-9.0.0/debian/patches/backport/apparmor-Allow-umount-dev.patch 
libvirt-9.0.0/debian/patches/backport/apparmor-Allow-umount-dev.patch
--- libvirt-9.0.0/debian/patches/backport/apparmor-Allow-umount-dev.patch   
2023-05-21 11:31:31.0 +0200
+++ libvirt-9.0.0/debian/patches/backport/apparmor-Allow-umount-dev.patch   
2024-08-24 16:05:45.0 +0200
@@ -24,7 +24,7 @@
 Reviewed-by: Jim Fehlig 
 (cherry picked from commit ef4829510549ec68cf80774e98b200a3e7bbe51f)
 
-Forwarded: non-needed
+Forwarded: not-needed
 Origin: 
https://gitlab.com/libvirt/libvirt/-/commit/ef4829510549ec68cf80774e98b200a3e7bbe51f
 ---
  src/security/apparmor/usr.sbin.libvirtd.in  | 1 +
diff -Nru 
libvirt-9.0.0/debian/patches/backport/Fix-off-by-one-error-in-udevListInterfacesByStatus.patch
 
libvirt-9.0.0/debian/patches/backport/Fix-off-by-one-error-in-udevListInterfacesByStatus.patch
--- 
libvirt-9.0.0/debian/patches/backport/Fix-off-by-one-error-in-udevListInterfacesByStatus.patch
  1970-01-01 01:00:00.0 +0100
+++ 
libvirt-9.0.0/debian/patches/backport/Fix-off-by-one-error-in-udevListInterfacesByStatus.patch
  2024-08-24 16:05:45.0 +0200
@@ -0,0 +1,46 @@
+From: Martin Kletzander 
+Date: Tue, 27 Feb 2024 16:20:12 +0100
+Subject: Fix off-by-one error in udevListInterfacesByStatus
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Ever since this function was introduced in 2012 it could've tried
+filling in an extra interface name.  That was made worse in 2019 when
+the caller functions started accepting NULL arrays of size 0.
+
+This is assigned CVE-2024-1441.
+
+Signed-off-by: Martin Kletzander 
+Reported-by: Alexander Kuznetsov 
+Fixes: 5a33366f5c0b18c93d161bd144f9f079de4ac8ca
+Fixes: d6064e2759a24e0802f363e3a810dc5a7d7ebb15
+Reviewed-by: Ján Tomko 
+(cherry picked from commit c664015fe3a7bf59db26686e9ed69af011c6ebb8)
+
+Conflicts:
+
+  * NEWS.rst
+- missing context; the hunk is not relevant to the Debian
+  package anyway and has been dropped
+
+Forwarded: not-needed
+Origin: 
https://gitlab.com/libvirt/libvirt/-/commit/c664015fe3a7bf59db26686e9ed69af011c6ebb8
+Bug-Debian: https://bugs.debian.org/1066058
+---
+ src/interface/interface_backend_udev.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/interface/interface_backend_udev.c 
b/src/interface/interface_backend_udev.c
+index 54b43fb..01d6f55 100644
+--- a/src/interface/interface_backend_udev.c
 b/src/interface/interface_backend_udev.c
+@@ -219,7 +219,7 @@ udevListInterfacesByStatus(virConnectPtr conn,
+ g_autoptr

Bug#1076335: bookworm-pu: package libvirt/9.0.0-4

[Andrea Bolognani]

On Sat, Aug 24, 2024 at 02:13:25PM +0100, Adam D. Barratt wrote:
> On Sat, 2024-08-24 at 14:58 +0200, Andrea Bolognani wrote:
> > thank you for looking into this and sorry for the late reply. I had
> > to focus all my Debian time on something else for a couple of weeks.
> > 
> > In the meantime, this MR was opened asking for an additional bugfix
> > to be included in the next upload targeting bookworm:
> > 
> >   https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/227
> > 
> > What is the Release Team's preference here? Should I go ahead with
> > the upload that was originally agreed upon, or should I prepare a
> > debdiff that includes the additional changes so that you can have
> > another look and we can have a single upload covering everything?
> 
> Well... I'd be OK with including that fix as well, but it depends how
> quickly you can handle things, and how urgent the other fixes are.
> 
> The window for getting updates into the 12.7 point release closes this
> weekend, and it's already Saturday afternoon. If you can update your
> package to include the new fix and get it uploaded in time (with a new
> debdiff added to this bug log for the record) then fine.

I had no idea we were cutting it this close! I can get on it right
away and probably have things ready within an hour or two.

Just so that we're on the same page, do you want me to share the
debdiff here and get an explicit ACK from you before proceeding with
the upload, or should I go for the the upload first in the interest
of time?

Thanks again!

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1076335: bookworm-pu: package libvirt/9.0.0-4

[Andrea Bolognani]

On Wed, Aug 14, 2024 at 08:46:43PM +0100, Adam D. Barratt wrote:
> On Sun, 2024-07-14 at 17:15 +0200, Andrea Bolognani wrote:
> > The update would cover a number of issues that have been found to
> > affect the version of libvirt in bookworm.
> > 
> > The first one is a user-visible issue where the "virsh domif-setlink"
> > command can only be successfully used in certain conditions: this has
> > been reported as
> > 
> >   * https://bugs.debian.org/1075718
> > 
> > and has already been fixed upstream, so fixing it in stable involves
> > cherry-picking the relevant upstream change.
> > 
> > The remaining ones are all security issues, which have CVEs assigned
> > to them and are tracked in the Debian security tracker:
> 
> Please go ahead.

Hi Adam,

thank you for looking into this and sorry for the late reply. I had
to focus all my Debian time on something else for a couple of weeks.

In the meantime, this MR was opened asking for an additional bugfix
to be included in the next upload targeting bookworm:

  https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/227

What is the Release Team's preference here? Should I go ahead with
the upload that was originally agreed upon, or should I prepare a
debdiff that includes the additional changes so that you can have
another look and we can have a single upload covering everything?

My personal preference would probably be the latter, but I'll leave
the actual decision up to you.

Thanks in advance.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1064126: [Pkg-libvirt-maintainers] Bug#1064126: libvirt: install NSS modules into /usr

[Andrea Bolognani]

On Tue, Aug 20, 2024 at 09:30:52PM +0200, Andrea Bolognani wrote:
> On Tue, Aug 20, 2024 at 08:14:59AM +0200, Guido Günther wrote:
> > On Mon, Aug 19, 2024 at 12:03:47AM +0200, Andrea Bolognani wrote:
> > > I have however realized that there is an obstacle to enacting the
> > > plan as outlined above: the restructuring involves introducing
> > > several new binary packages, which in turns requires a trip through
> > > the NEW queue, and I'm not (yet) a Debian Developer so I can't
> > > prepare the upload myself.
> > > 
> > > Guido, would you be willing to take care of that part?
> > 
> > I can sure handle the upload. Would be nice to be able to look at the
> > diff (commits don't need to be cleaned up yet) as early as possible.
> 
> Yes, that absolutely makes sense. I'll try my best to make the branch
> available sooner rather than later, but at the same time I'm
> convinced that the current messy status would make reviewing the
> changes *harder* instead of easier so I'm not keen on publishing
> things quite yet. Please hold tight just a little bit longer!

The changes I've been working on are now available here:

  https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/229

Thank you all for your patience.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1079489: dpkg-dev: buildflags.mk messes with string double quoting

[Andrea Pappacoda]

Package: dpkg-dev
Version: 1.22.11
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi! I've just noted a strange behaviour of buildflags.mk. In short, including
the file seems to remove some level of string quoting from preprocessor flags
defined with DEB_CPPFLAGS_MAINT_APPEND, almost as if the value was passed to a
shell one too many times. It is simpler to explain this with an example.

Let's suppose the upstream software requires you to define a preprocessor
variable with a string value, like this one:

$ cat main.c
#include 
int main(void) {
puts(FOO);
return 0;
}

Let's also add a control and changelog file so that we can build the package:

$ cat debian/control
Source: testpackage
Section: devel
Priority: optional
    Maintainer: Andrea Pappacoda 
Build-Depends:
 debhelper-compat (= 13),
 dpkg-build-api (= 1),
Standards-Version: 4.7.0
X-Style: black

Package: testpackage
Architecture: any
Multi-Arch: foreign
Depends:
 ${misc:Depends},
 ${shlibs:Depends},
Description: test package
 This is a test package

$ cat debian/changelog
testpackage (1.0-1) UNRELEASED; urgency=medium

  * Initial release. (Closes: #XX)

 -- Andrea Pappacoda   Fri, 23 Aug 2024 22:27:04 +0200

Finally, let's add a working rules file:

$ cat debian/rules
#!/usr/bin/make -f

export DEB_CPPFLAGS_MAINT_APPEND = -DFOO='"string_value"'

%:
dh $@ --buildsystem=none

override_dh_auto_build:
$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o main main.c

override_dh_auto_test:
./main

Let's now build the package with dpkg-buildpackage:

$ dpkg-buildpackage
dpkg-buildpackage: info: source package testpackage
dpkg-buildpackage: info: source version 1.0-1
dpkg-buildpackage: info: source distribution UNRELEASED
    dpkg-buildpackage: info: source changed by Andrea Pappacoda

 dpkg-source --diff-ignore=true --tar-ignore=true --before-build .
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
dh clean --buildsystem=none
   dh_auto_clean -O--buildsystem=none
   dh_autoreconf_clean -O--buildsystem=none
   dh_clean -O--buildsystem=none
 dpkg-source --diff-ignore=true --tar-ignore=true -b .
dpkg-source: warning: no source format specified in debian/source/format,
see dpkg-source(1)
dpkg-source: warning: native package version may not have a revision
dpkg-source: warning: source directory 'testpackage' is not
- 'testpackage-1.0'
dpkg-source: info: using source format '1.0'
dpkg-source: info: building testpackage in testpackage_1.0-1.tar.gz
dpkg-source: info: building testpackage in testpackage_1.0-1.dsc
 debian/rules binary
dh binary --buildsystem=none
   dh_update_autotools_config -O--buildsystem=none
   dh_autoreconf -O--buildsystem=none
   dh_auto_configure -O--buildsystem=none
   debian/rules override_dh_auto_build
make[1]: Entering directory '/tmp/tmp.RvxkGPOuQf/testpackage'
cc -Wdate-time -D_FORTIFY_SOURCE=2 -DFOO='"string_value"' -g -O2
- -Werror=implicit-function-declaration -ffile-prefix-
map=/tmp/tmp.RvxkGPOuQf/testpackage=. -fstack-protector-strong -fstack-clash-
protection -Wformat -Werror=format-security -fcf-protection -Wl,-z,relro -o
main main.c
make[1]: Leaving directory '/tmp/tmp.RvxkGPOuQf/testpackage'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/tmp/tmp.RvxkGPOuQf/testpackage'
./main
string_value
make[1]: Leaving directory '/tmp/tmp.RvxkGPOuQf/testpackage'
   create-stamp debian/debhelper-build-stamp
   dh_testroot -O--buildsystem=none
   dh_prep -O--buildsystem=none
   dh_auto_install --destdir=debian/testpackage/ -O--buildsystem=none
   dh_installdocs -O--buildsystem=none
   dh_installchangelogs -O--buildsystem=none
   dh_installsystemduser -O--buildsystem=none
   dh_perl -O--buildsystem=none
   dh_link -O--buildsystem=none
   dh_strip_nondeterminism -O--buildsystem=none
   dh_compress -O--buildsystem=none
   dh_fixperms -O--buildsystem=none
   dh_missing -O--buildsystem=none
   dh_dwz -a -O--buildsystem=none
   dh_strip -a -O--buildsystem=none
   dh_makeshlibs -a -O--buildsystem=none
   dh_shlibdeps -a -O--buildsystem=none
   dh_installdeb -O--buildsystem=none
   dh_gencontrol -O--buildsystem=none
dpkg-gencontrol: warning: Depends field of package testpackage:
substitution variable ${shlibs:Depends} used, but is not defined
   dh_md5sums -O--buildsystem=none
   dh_builddeb -O--buildsystem=none
dpkg-deb: building package 'testpackage' in
'../testpackage_1.0-1_amd64.deb'.
 dpkg-genbuildinfo -O../testpackage_1.0-1_amd64.buildinfo
 dpk

Bug#1064126: [Pkg-libvirt-maintainers] Bug#1064126: libvirt: install NSS modules into /usr

[Andrea Bolognani]

On Tue, Aug 20, 2024 at 08:14:59AM +0200, Guido Günther wrote:
> On Mon, Aug 19, 2024 at 12:03:47AM +0200, Andrea Bolognani wrote:
> > I have however realized that there is an obstacle to enacting the
> > plan as outlined above: the restructuring involves introducing
> > several new binary packages, which in turns requires a trip through
> > the NEW queue, and I'm not (yet) a Debian Developer so I can't
> > prepare the upload myself.
> > 
> > Guido, would you be willing to take care of that part?
> 
> I can sure handle the upload. Would be nice to be able to look at the
> diff (commits don't need to be cleaned up yet) as early as possible.

Yes, that absolutely makes sense. I'll try my best to make the branch
available sooner rather than later, but at the same time I'm
convinced that the current messy status would make reviewing the
changes *harder* instead of easier so I'm not keen on publishing
things quite yet. Please hold tight just a little bit longer!

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1064126: [Pkg-libvirt-maintainers] Bug#1064126: libvirt: install NSS modules into /usr

[Andrea Bolognani]

On Sat, Aug 10, 2024 at 06:19:31PM +0200, Andrea Bolognani wrote:
> I spent some more time testing the restructuring today, and it seems
> to behave well. There is still one known issue with transferring
> conffiles between packages under certain conditions, but I believe
> that I have a solid plan to deal with that and I just need to
> implement it. There are probably other smaller issues with
> dependencies and such, but I think that the overall "shape" of the
> end result is near-final.
> 
> The git history is still a complete mess though, and I really need to
> polish that up before I feel comfortable asking the poor reviewers to
> wade through it O:-)
> 
> So, here's my proposal: in two weeks' time, i.e. by August 25, I
> will upload a version of libvirt that includes both the restructuring
> and the usr-merge bits to experimental.
> 
> This upload will not be prepared from the official git repository,
> but from my own fork. This removes the need to have all changes
> squeaky-clean and reviewed before we can proceed, and allows us to
> move forward with whatever I have ready at the time.
> 
> The idea is that this will give dumat a chance to validate the whole
> ordeal and ensure that users will not run into file loss scenarios.
> If any issue is detected, we'll have the opportunity to rectify it;
> if not, we can feel safer about taking a bit longer to polish and
> land the restructuring.
> 
> I will of course endeavor to get the branch in a reviewable shape, or
> as close to that as possible, before then.
> 
> Does this plan sound reasonable?

Since no disagreement was raised, I'm working under the assumption
that everybody is okay with this plan.

I've made some more progress over the past week, including fixing the
known bug mentioned earlier and integrating the usr-merge patches.
Things generally seem to work fine.

I have however realized that there is an obstacle to enacting the
plan as outlined above: the restructuring involves introducing
several new binary packages, which in turns requires a trip through
the NEW queue, and I'm not (yet) a Debian Developer so I can't
prepare the upload myself.

Guido, would you be willing to take care of that part?

I still need to clean up the git history, but given the current
status I'm feeling relatively optimistic and I'm convinced I should
be able to cobble together something good enough for a proper (draft)
merge request by either Friday or Saturday evening.

That'd give Guido approximately a day to sanity-check the changes and
prepare the upload if we want to stick to the original schedule.
Hopefully that's workable.

Also note that the implementation of usr-merge I've imported is the
same proposed by Michael, which can't be sensibly backported to older
releases. As mentioned in [59] this might be a problem for Ubuntu, so
I'm CC'ing Christian again in order to give him another chance to
speak up.


[59] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064126#59
-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1078929: glib2.0 breaks architecture bootstrap

[Andrea Pappacoda]

On Sat Aug 17, 2024 at 11:26 PM CEST, Helmut Grohne wrote:

glib2.0 certainly is not the simplest of packages when it comes to meson
use. The trivial approach of replacing meson yields:

err unknown option '--wrap-mode=nodownload'

That's the third option passed to meson of many. I don't think this is
feasible with reasonable effort, but I'm happy to let you prove me wrong
about this.


Sorry, I forgot to mention that muon and meson have different (but 
similar) command line interfaces, so, for example, debhelper should be 
patched to recognize muon and pass options differently.


One of the differences is that muon does not have long options like 
"--wrap-mode", and the way you set the wrap mode is by directly 
modifying the built-in option via -Dwrap_mode=nodownload (which will 
also work with regular Meson, since long options most of the time are 
just a fancy way of setting built-in options).


After changing the command line syntax, muon is almost capable of 
compiling glib, it just seems to hang at the end, probably due to glib's 
relyance of Meson's "gnome" module, which is incomplete in muon.


Please let me know if muon could be helful to your use case. If so, 
I can try to work with upstream to fix glib's compilation. muon's 
development of features is driven by real-world use cases.


Bye!

Bug#1078929: glib2.0 breaks architecture bootstrap

[Andrea Pappacoda]

Hi Helmut,

On Sat Aug 17, 2024 at 10:28 PM CEST, Helmut Grohne wrote:
I fear we need to have another conversation about glib2.0 and 
bootstrapping.

[...]
Let's look into Build-Depends and Build-Depends-Arch.

[...]
meson (>= 1.2.0),
 -> non-trivial, Arch:all, but it pulls ninja-build and a few Python 
dependencies. I suspect a loop here.

[...]

I think there are two sticking issues here. One is Python. Cross 
building Python used to work in the cross phase, but that was before 
removing glib2.0. I expect that we also have to remove Python. The 
other is meson. It pulls e.g. cmake via ninja-build. This definitely 
does not just work.


I don't know much about glib2.0, especially when it comes to cross 
compiling, but I have a suggestion regarding meson and ninja-build in 
particular.


I maintain the muon package, which is a C re-implementation of Meson. 
The thing that might be useful to you is that it does not require 
python3 to run, and while it currently depends on ninja-build as well, 
it can be built with built-in samu support, which is a ninja 
re-implementation. I haven't enabled that option since in Debian we 
already have ninja-build, and I haven't saw a use case for it before 
now.


Please let me know if this could help. I'm willing to make changes to 
muon packaging in order to help you with your bootstrapping efforts. 
After all, muon's raison d'être is portability.


Bye :D

Bug#829444: Accepting DEP14?

[Andrea Pappacoda]

Hi all,

On Fri Aug 16, 2024 at 10:31 AM CEST, Guido Günther wrote:
> It's never been a lack of motivation (I use DEP-14 in about all
> projects). More a lack of time to figure out a proper migration path.

In #829444 it has been proposed the addition of a new "layout" option to
gbp.conf, which would tell git-buildpackage which layout to follow,
allowing for a graceful migration.

I've been thinking about a different approach though. What about adding
a warning to git-buildpackage when `debian-branch` and `upstream-branch`
are not set in gbp.conf? Compared to the `layout` option, it would have
the following benefits:

- People already following DEP-14 don't have to do anything (big benefit
  in my opinion)
- It would (probably) be easier to implement in gbp

I also see the follwing cons:

- We'd have to hardcode "debian/latest" and "upstream/latest"
  everywhere, which isn't pretty
- Maintainers may be less prone to change branch names since having
  `debian-branch = master` doesn't look as bad as having `layout
  = legacy`

After giving enough time to people to fix the warning (either by
switching to DEP-14 or by keep using their own custom branch names for
whatever reason), git-buildpackage can be switched to use DEP-14 branch
names by default.

How does it sound to you? Am I missing something?

Bye!


signature.asc
Description: PGP signature

Bug#1073088: markdown is no longer scheduled for removal

[Andrea Pappacoda]

Control: retitle 1073088 abinit: build-depends on markdown
Control: retitle 1073092 erlang-cowlib: build-depends on markdown
Control: retitle 1073093 glogg: build-depends on markdown
Control: retitle 1073094 gtk3-nocsd: build-depends on markdown
Control: retitle 1073096 keras: build-depends on markdown
Control: retitle 1073098 libvcflib: build-depends on markdown
Control: retitle 1073098 math-numeric-tower-clojure: build-depends on markdown
Control: retitle 1073109 vowpal-wabbit: build-depends on markdown
Control: severity 1073088 normal
Control: severity 1073092 normal
Control: severity 1073093 normal
Control: severity 1073094 normal
Control: severity 1073096 normal
Control: severity 1073098 normal
Control: severity 1073098 normal
Control: severity 1073109 normal

Hi! markdown is no longer scheduled for removal, but please be aware
that it is not maintained upstream. While the Markdown language itself
does not change over time, the markdown package (which is the original,
"canonical" implementation) has some minor bugs which may generate
surprising output in some corner case. What I'd suggest is switching to
a CommonMark implementation, like cmark or md4c's md2html, assuming your
Markdown files are compliant with the CommonMark specification.

Alternatively, if you don't want to convert your files to CommonMark but
would still like to avoid using the original markdown implementation,
you can try to switch to the discount package. It tries to follow the
original markdown implementation, but in a way it has its own Markdown
dialect and I would not recommended it. It may also mess with your
output in unexpected (but documented) ways.

Of course, if using the markdown package is fine for your needs, there's
nothing wrong with it! Feel free to mark this bug as wontfix.

Bye :D

Bug#1057176: [PATCH v2] Do not raise silent-on-rules-requiring-root if dpkg-build-api is v1 or newer

[Andrea Pappacoda]

Closes: #1057176

Also see  for additional context.
---
This revision adds tests and reformats with perltidy.

 .../Debian/Control/Field/RulesRequiresRoot.pm   |  4 +++-
 .../build-spec/debian/control.in| 17 +
 .../build-spec/fill-values  |  4 
 .../eval/desc   |  4 
 .../eval/hints  |  0
 5 files changed, 28 insertions(+), 1 deletion(-)
 create mode 100644 
t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/debian/control.in
 create mode 100644 
t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/fill-values
 create mode 100644 
t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/eval/desc
 create mode 100644 
t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/eval/hints

diff --git a/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm 
b/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm
index b97a673b3..9d5d043a7 100644
--- a/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm
+++ b/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm
@@ -38,6 +38,7 @@ sub source {
 
 my $control = $self->processable->debian_control;
 my $source_fields = $control->source_fields;
+my $build_prerequisites= $self->processable->relation('Build-Depends-All');
 
 my @r3_misspelled = grep { $_ ne 'Rules-Requires-Root' }
   grep { m{^ Rules? - Requires? - Roots? $}xi } $source_fields->names;
@@ -64,7 +65,8 @@ sub source {
   && $source_fields->value('Rules-Requires-Root') ne 'no';
 
 $self->pointed_hint('silent-on-rules-requiring-root', $pointer)
-  unless $source_fields->declares('Rules-Requires-Root');
+  unless $source_fields->declares('Rules-Requires-Root')
+  || $build_prerequisites->satisfies('dpkg-build-api (>= 1)');
 
 if (  !$source_fields->declares('Rules-Requires-Root')
 || $source_fields->value('Rules-Requires-Root') eq 'no') {
diff --git 
a/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/debian/control.in
 
b/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/debian/control.in
new file mode 100644
index 0..fb3b62f68
--- /dev/null
+++ 
b/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/debian/control.in
@@ -0,0 +1,17 @@
+Source: [% $source %]
+Priority: [% $priority %]
+Section: [% $section %]
+Maintainer: [% $author %]
+Standards-Version: [% $standards_version %]
+Build-Depends: [% $build_depends %]
+Homepage: [% $homepage %]
+
+Package: [% $source %]
+Architecture: [% $package_architecture %]
+Pre-Depends: ${misc:Pre-Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: [% $description %]
+ This is a test package designed to exercise some feature or tag of
+ Lintian.  It is part of the Lintian test suite and may do very odd
+ things.  It should not be installed like a regular package.  It may
+ be an empty package.
diff --git 
a/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/fill-values
 
b/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/fill-values
new file mode 100644
index 0..65be27a45
--- /dev/null
+++ 
b/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/build-spec/fill-values
@@ -0,0 +1,4 @@
+Testname: rules-requires-root-missing-with-dpkg-build-api
+Skeleton: upload-native
+Description: d/control without explicit rules-requires-root but with 
dpkg-build-api
+Extra-Build-Depends: dpkg-build-api (= 1)
diff --git 
a/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/eval/desc
 
b/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/eval/desc
new file mode 100644
index 0..12305298c
--- /dev/null
+++ 
b/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/eval/desc
@@ -0,0 +1,4 @@
+Testname: rules-requires-root-missing-with-dpkg-build-api
+Check: debian/control/field/rules-requires-root
+Test-Against: silent-on-rules-requiring-root
+See-Also: Bug #1057176
diff --git 
a/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/eval/hints
 
b/t/recipes/checks/debian/control/field/rules-requires-root/rules-requires-root-missing-with-dpkg-build-api/eval/hints
new file mode 100644
index 0..e69de29bb
-- 
2.

Bug#1078267: RFS: markdown/1.0.1-13 [ITA] [RC] -- Text-to-HTML conversion tool

[Andrea Pappacoda]

On Tue Aug 13, 2024 at 11:36 PM CEST, Soren Stoutner wrote:

This all looks good to me.  I have sponsored the package.


Thanks! Both for the review and for the upload :)

I see that you are a DM.  Based on the quality of your packaging, would you 
like me to grant you upload rights for markdown?


Of course!


Also, I see you are involved with a lot of packages.

https://qa.debian.org/developer.php?login=andrea%40pappacoda.it

Have you considered applying to become a Debian Developer?


Yeah, I've been considering it for some time now. I just need to take 
some time to read all the relevant documentation to figure out what 
I should do to start the process. But yeah, that day will come :)


Thanks again Soren, bye!

Bug#1057176: [PATCH] Do not raise silent-on-rules-requiring-root if dpkg-build-api is v1 or newer

[Andrea Pappacoda]

Closes: #1057176

Also see  for additional context.
---
I know you prefer Salsa merge requests, but I currently cannot login 
into my Salsa account, so I'm posting this here for the time being :)

 lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm 
b/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm
index b97a673b3..32f9a67ac 100644
--- a/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm
+++ b/lib/Lintian/Check/Debian/Control/Field/RulesRequiresRoot.pm
@@ -38,6 +38,8 @@ sub source {
 
 my $control = $self->processable->debian_control;
 my $source_fields = $control->source_fields;
+my $build_prerequisites
+  = $self->processable->relation('Build-Depends-All');
 
 my @r3_misspelled = grep { $_ ne 'Rules-Requires-Root' }
   grep { m{^ Rules? - Requires? - Roots? $}xi } $source_fields->names;
@@ -64,7 +66,8 @@ sub source {
   && $source_fields->value('Rules-Requires-Root') ne 'no';
 
 $self->pointed_hint('silent-on-rules-requiring-root', $pointer)
-  unless $source_fields->declares('Rules-Requires-Root');
+  unless $source_fields->declares('Rules-Requires-Root')
+  || $build_prerequisites->satisfies('dpkg-build-api (>= 1)');
 
 if (  !$source_fields->declares('Rules-Requires-Root')
 || $source_fields->value('Rules-Requires-Root') eq 'no') {
-- 
2.43.0

Bug#1078267: RFS: markdown/1.0.1-13 [ITA] [RC] -- Text-to-HTML conversion tool

[Andrea Pappacoda]

Soren, Niels, thank you both for your feedback!

I've pushed an update to the markdown package on Mentors, where I've 
split the single big debian.patch into six different well documented 
patches, and also added back Rules-Requires-Root while keeping the 
build-dependency on dpkg-build-api (= 1). I'll watch closely for Policy 
updates, waiting for the day I'll be able to remove this odd thing 
I have to copy-paste in all my control files :)


Let me know if there's anything else you think I should fix! As always, 
you can find the package on both Mentors[1] and Salsa[2].


Bye!

[1]: https://mentors.debian.net/package/markdown/
[2]: https://salsa.debian.org/tachi/markdown

Bug#1078267: RFS: markdown/1.0.1-13 [ITA] [RC] -- Text-to-HTML conversion tool

[Andrea Pappacoda]

Hi Soren, thanks for taking the time to look at this! Sorry if formatting is 
off, I'm writing from my phone.

I'll reply in-line below.


Il 12 agosto 2024 21:55:03 CEST, Soren Stoutner  ha scritto:
>1.  markdown source: quilt-patch-missing-description [debian/patches/
>debian.patch]
>
>Could you please add a description to this patch?

I thought at this, but as I haven't written the patch myself I'm not sure what 
to write. It's a patch that Bastian created while converting the package to the 
3.0 (quilt) source format. Since it does different things, I might try to split 
it up in different smaller patches and document them individually. Does it make 
sense to you?

>2.  I: markdown source: upstream-metadata-missing-repository [debian/upstream/
>metadata]
>
>I’m assuming this is because the upstream doesn’t have a repository, just a 
>tarball download (the little investigation I did indicated that might be 
>true).  If that is the case, please override this lintian tag with a 
>description in the comment as to why.

Yeah, upstream never head a Git repository. I'll add an override as you suggest.

>3.  P: markdown source: silent-on-rules-requiring-root [debian/control]
>
>I am assuming your program doesn’t require root to build (few do).  If so, 
>please add the line “Rules-Requires-Root: no” to debian/control.

That's a false positive. Rules-Requires-Root: no is already implied by the 
build dependency on dpkg-build-api (= 1). Please see dpkg-build-api(7) and bug 
#1057176. I also think that adding a lintian override is wrong since this 
should really be fixed lintian-side.

>4.  It might be nice to include an explanation in the binary package 
>description that this is the original markdown program and some indication of 
>how this relates to other implementations and under which circumstances 
>someone would like to install this compared to other versions.  This is 
>optional and I leave it up to your discretion if you would like to do so and 
>how it would be best worded.

Makes sense, I'll do it later today.

Thanks again! Bye :)

Bug#1064126: [Pkg-libvirt-maintainers] Bug#1064126: libvirt: install NSS modules into /usr

[Andrea Bolognani]

On Sat, Aug 10, 2024 at 06:19:31PM +0200, Andrea Bolognani wrote:
> So, here's my proposal: in two weeks' time, i.e. by September 25, I
> will upload a version of libvirt that includes both the restructuring
> and the usr-merge bits to experimental.

I obviously meant *August* 25 here O:-)

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1064126: [Pkg-libvirt-maintainers] Bug#1064126: libvirt: install NSS modules into /usr

[Andrea Bolognani]

On Sat, Aug 10, 2024 at 05:41:25PM +0200, Guido Günther wrote:
> On Sat, Aug 10, 2024 at 03:30:23PM +0200, Andrea Bolognani wrote:
> > Note that I have also uploaded 10.6.0-1 in the meantime, which is set
> > to migrate to testing tomorrow. I wonder how the two uploads will
> > interact with each other.
> 
> It is my understanding that since 10.6.0-1 is a higher version number
> than 10.5.0-1.1 the upload from
> 
>   https://ftp-master.debian.org/deferred.html
> 
> will be discarded which, given what you write above, sounds like the
> right thing to happen.

Thanks for weighing in, Guido.

I spent some more time testing the restructuring today, and it seems
to behave well. There is still one known issue with transferring
conffiles between packages under certain conditions, but I believe
that I have a solid plan to deal with that and I just need to
implement it. There are probably other smaller issues with
dependencies and such, but I think that the overall "shape" of the
end result is near-final.

The git history is still a complete mess though, and I really need to
polish that up before I feel comfortable asking the poor reviewers to
wade through it O:-)

So, here's my proposal: in two weeks' time, i.e. by September 25, I
will upload a version of libvirt that includes both the restructuring
and the usr-merge bits to experimental.

This upload will not be prepared from the official git repository,
but from my own fork. This removes the need to have all changes
squeaky-clean and reviewed before we can proceed, and allows us to
move forward with whatever I have ready at the time.

The idea is that this will give dumat a chance to validate the whole
ordeal and ensure that users will not run into file loss scenarios.
If any issue is detected, we'll have the opportunity to rectify it;
if not, we can feel safer about taking a bit longer to polish and
land the restructuring.

I will of course endeavor to get the branch in a reviewable shape, or
as close to that as possible, before then.

Does this plan sound reasonable?

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1064126: libvirt: install NSS modules into /usr

[Andrea Bolognani]

On Tue, Aug 06, 2024 at 10:46:36PM +0200, Michael Biebl wrote:
> Hi Andrea
> 
> I just uploaded the attached debdiff to DELAYED/7.
> 
> As discussed in this bug report, the changes for usrmerge *must* happen for
> trixie and are not optional. So it is better to get those out of the way.
> Your planned package restructuring can still happen for trixie, but in this
> case, please upload to experimental first as dumat will then flag the
> potential issues. Please get in contact with the usrmerge team then and we
> are happy to assist you.
> I acknowledge that you wanted to do the usrmove changes and the package
> restructuring at the same time. But experience has shown that it's actually
> better to do those separately.

You didn't CC me on this message, so I only noticed it today by pure
chance.

Obviously I'm extremely unhappy to see changes being made
unilaterally to a package that I've spent the past several years
dutifully caring for, especially after I had explicitly, on multiple
occasions, expressed my disagreement with your plan of action.


I have already acknowledged the importance of completing the
usr-merge work for trixie. That was never up for debate. But there
are still several months worth of opportunities to get those changes
in, which is something that you yourself implicitly admit by saying
how I can still get my restructuring done in time. Plus there's the
quote from Helmut a little earlier in the thread:

> The hard deadline from my point of view is the start of the transition
> freeze. Until then, we'll increasingly poke and if you get too close,
> you risk using an inferior solution due to time pressure. I imagine that
> if you get late, you may have to revert part of the restructuring.
>
> Traditionally freeze happens on January 12th. So we'll be poking quite
> hard in December already. Let us avoid such poking for libvirt.

No need to poke hard in December when the change has already been
forcefully performed in August, I guess!


From my side, I haven't been sitting idly since our last interaction
and I have made significant progress on the restructuring front. To
further prove my commitment to making that happen, I have even taken
a few days off work specifically so that I could focus on getting it
done as soon as possible. Unfortunately there are outside factors
that conspire to limit the time I can dedicate to Debian in any given
week, but really I'm doing the best that I can here.


Anyway, you've uploaded the changes now, so it's a done deal I guess.
I'll just figure out how to deal with any potential fallout. Maybe
it will turn out that I've been worrying over nothing and there are
no bad interactions resulting from the two restructurings happening
in separate uploads... I certainly hope that's the case.


Note that I have also uploaded 10.6.0-1 in the meantime, which is set
to migrate to testing tomorrow. I wonder how the two uploads will
interact with each other.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1077732: dpkg-dev: please document a best-practice way to use DEB_CFLAGS_MAINT_APPEND etc. in d/rules

[Andrea Pappacoda]

Hi Simon,

On Thu, 1 Aug 2024 10:14:07 +0100 Simon McVittie  
wrote:

> dpkg-buildflags(1) documents how maintainers can set
> DEB_CFLAGS_MAINT_APPEND and friends, but there's no best-practice 
example

> of how to use them in d/rules.

An example d/rules assuming debhelper usage (in case it matters) would 
be useful indeed, alongside an explanation of when and why we should 
use DPKG_EXPORT_BUILDFLAGS.


> Questions whose answers are unclear to me:
>
> * Do DEB_*_MAINT_* need to be exported as environment variables, or 
is it

>   sufficient for them to be set as make(1) variables?

According to the dpkg-buildflags(1) manpage, "The default flags [...] 
can be extended/overridden in several ways: [...] dynamically by the 
package maintainer with environment variables set via debian/rules (see 
section "ENVIRONMENT")". So it seems that make(1) variables are not 
enough.


> * Do DEB_*_MAINT_* need to be set before including buildflags.mk, or
>   do they use enough lazy-evaluation that it is sufficient to set 
them

>   anywhere in debian/rules?

Also, _when_ should be include buildflags.mk? Is it needed when using 
debhelper? Is it there a case where you would *not* want to include it?


> * Are there other requirements or interactions that maintainers will
>   typically need to take into account?

As I said above, it'd be also nice to specify what is already implied 
by debhelper usage, possibly pointing to its appropriate documentation.

Bug#1078352: md4c: Please package md2html tool

[Andrea Pappacoda]

Source: md4c
Version: 0.4.8-1
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all!

Could you please consider shipping the md2html utility alongside the md4c
libraries? It started out as a test tool, but it is not considered "production
ready" from upstream.

I'd love to start using it instead of some other alternatives!

I've attached a patch with the proposed changes. If you need any more help with
packaging of md4c, let me know. I'd love to work a bit on it, like updating to
the latest upstream release.

Thanks! Bye :)


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

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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZrakhBQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p4EZAP0bd28BcSWGa3uFhbqechAZqa7dhyF8
yvFjf6F9Y4lscAEAmsEBX3zdapmWOdA4jlMbDn9nRD4Tg2sp+91TapYRVQQ=
=YEmM
-END PGP SIGNATURE-
From 3aa66a2244effaf3fb708f318ff76411771e4997 Mon Sep 17 00:00:00 2001
From: Andrea Pappacoda 
Date: Sat, 10 Aug 2024 01:18:16 +0200
Subject: [PATCH] Build and ship md2html utility

---
 debian/control| 17 
 debian/md2html.install|  1 +
 debian/md2html.manpages   |  1 +
 .../disable_building_the_example.patch| 20 ---
 debian/patches/series |  1 -
 5 files changed, 19 insertions(+), 21 deletions(-)
 create mode 100644 debian/md2html.install
 create mode 100644 debian/md2html.manpages
 delete mode 100644 debian/patches/disable_building_the_example.patch
 delete mode 100644 debian/patches/series

diff --git a/debian/control b/debian/control
index 436426e..22162d5 100644
--- a/debian/control
+++ b/debian/control
@@ -139,3 +139,20 @@ Description: Markdown for C HTML-renderer
  Permissive license: MD4C is available under the MIT license.
  .
  This package ships the standalone Markdown-to-HTML converter.
+
+Package: md2html
+Section: text
+Architecture: any
+Multi-Arch: foreign
+Depends: ${misc:Depends}, ${shlibs:Depends}
+Description: Markdown to HTML converter
+ md2html is a command line utility based on the MD4C library which converts
+ Markdown files to HTML.
+ .
+ It supports the CommonMark and GitHub Flavored dialects of Markdown, and has
+ multiple options enabling different extensions like URL autolinking,
+ strikethrough, tables, and more.
+ .
+ Being based on the MD4C library, it benefits from its performance and
+ portability. For more information about the MD4C library, see the libmd4c-dev
+ package.
diff --git a/debian/md2html.install b/debian/md2html.install
new file mode 100644
index 000..5b7fd5b
--- /dev/null
+++ b/debian/md2html.install
@@ -0,0 +1 @@
+usr/bin/md2html
diff --git a/debian/md2html.manpages b/debian/md2html.manpages
new file mode 100644
index 000..73efe53
--- /dev/null
+++ b/debian/md2html.manpages
@@ -0,0 +1 @@
+usr/share/man/man1/md2html.1
diff --git a/debian/patches/disable_building_the_example.patch 
b/debian/patches/disable_building_the_example.patch
deleted file mode 100644
index f8cf510..000
--- a/debian/patches/disable_building_the_example.patch
+++ /dev/null
@@ -1,20 +0,0 @@
-Description: do not build the md2html example.
- The author expressed it's only an example code.
- It is currently not being installed as an example, so
- simply avoid building it.
-Author: Lisandro Damián Nicanor Pérez Meyer 
-Forwarded: not-needed
-

- CMakeLists.txt |3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
 a/CMakeLists.txt
-+++ b/CMakeLists.txt
-@@ -56,4 +56,5 @@
- include(GNUInstallDirs)
- 
- add_subdirectory(src)
--add_subdirectory(md2html)
-+# Do not build the example.
-+#add_subdirectory(md2html)
diff --git a/debian/patches/series b/debian/patches/series
deleted file mode 100644
index cbdeb27..000
--- a/debian/patches/series
+++ /dev/null
@@ -1 +0,0 @@
-disable_building_the_example.patch
-- 
2.43.0

Bug#1078267: RFS: markdown/1.0.1-13 [ITA] [RC] -- Text-to-HTML conversion tool

[Andrea Pappacoda]

On Fri, 9 Aug 2024 17:47:50 +0200 Bastian Germann 
 wrote:

> Please see #1072958 for the RM request on markdown.
> It should be replaced with a maintained alternative such as discount.
> You can check the blocking bugs for that RM bug to find the packages 
that need some change.


I'm aware of that, and the submitter of the RM bug, while still being 
unhappy of the fact that markdown is unmaintained upstream, is OK with 
me adopting the package and closing the RM bug.


> I would strongly advise against adopting the package because that 
will

> alleviate the reverse dependencies' urge to update.

There's no urge of updating if you're targeting the original Markdown 
as opposed to some dialect like CommonMark. Despite not being perfect, 
Markdown.pl is a fine implementation. Please see 
 for some 
more reasons why I think that the original markdown implementation 
should stay.


On Fri, 9 Aug 2024 19:42:21 +0200 Daniel Gröber  
wrote:

> Problem is discount breaks some of my hacky markdown :)

Another reason why keeping the original implementation is desirable!

> I considered suggesting letting the RM go through and just 
re-uploading but
> doing it that way seems a waste of ftp-master time. Do you have any 
other

> suggestions?

As I mentioned above, the submitter of the removal request told me to 
just close the RM bug after uploading the package.


On Fri, 9 Aug 2024 19:55:22 +0200 Bastian Germann  
wrote:
> There are so many markdown impementations in Debian, just some 
suggestions with executables:

> python3-markdown
> python3-markdown2
> python3-markdown-it
> rust-markdown
> libtext-markdown-perl
> pmarkdown

Not all of these are perfect too. libtext-markdown-perl, for example, 
is slow, and has seen its last upstream update more roughly ten years 
ago. I don't know about the others. Which dialect do they implement? 
How compatible are with the original markdown syntax? Are they a 
bug-for-bug replacement for Markdown.pl? Markdown looks like a simple 
matter on the surface, but the lack of a canonical specification (which 
CommonMark tries to be) makes everything a bit more intricate.


Hope my request looks more reasonable now :)

Bug#1078267: RFS: markdown/1.0.1-13 [ITA] [RC] -- Text-to-HTML conversion tool

[Andrea Pappacoda]

On Fri, 09 Aug 2024 12:33:24 +0100 Phil Wyett 
 wrote:

> Hi Andrea,
>
> For a future upload would also be to fix the pedantic lintian below.
>
> P silent-on-rules-requiring-root
>   [debian/control]

Hi Phil, that's a false positive. Declaring a build dependency on 
dpkg-build-api (= 1) already implies that. Please see dpkg-build-api(7) 
and bug #1057176.


Bye :)

Bug#1078267: RFS: markdown/1.0.1-13 [ITA] [RC] -- Text-to-HTML conversion tool

[Andrea Pappacoda]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for the package "markdown":

* Package name : markdown
  Version  : 1.0.1-13
  Upstream contact : John Gruber 
* URL  : https://daringfireball.net/projects/markdown/
* License  : BSD-3-Clause
* Vcs  : https://salsa.debian.org/tachi/markdown
  Section  : web

The source builds the following binary packages:

 markdown - Text-to-HTML conversion tool

I'm adopting this package since I still see significant value in having 
the original markdown implementation in Debian. See the ITA bug #466330 
for my reasoning.


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


You can locally check out and review the package by cloning the Git 
repository hosted on Salsa:


   gbp clone g...@salsa.debian.org:tachi/markdown.git

To quickly see what's changed, just run:

   git diff debian/1.0.1-12

Changes since the last upload:

markdown (1.0.1-13) unstable; urgency=medium
.
  * d/control: adopt package (Closes: #466330)
  * d/control: add Vcs fields
  * d: convert packaging to debhelper (Closes: #1063645)
  * d/copyright: convert to DEP-5 format
  * d/watch: add basic watch file
  * d/u/metadata: add upstream metadata

Thanks! Bye :)

Bug#466330: ITA: adopting markdown

[Andrea Pappacoda]

Il giorno ven 9 ago 2024 alle 00:05:02 +02:00:00, Chris Hofstaedtler 
 ha scritto:

I think effectively its pointless to downstream maintain
upstream-dead code, especially when there are drop-in, maintained
alternatives, but you do you.


In general I agree with you, but the _original_ markdown language is 
pretty much defined by the markdown.pl program itself. In a way, there 
are no real "alternatives" if you look it that way. Yeah, there's 
CommonMark, but that's a different thing (and for that you've got 
cmark, md4c, markdown-it, etc.).


For my own files I just use CommonMark, but when I have to write 
something that has to pass through different markdown interpreters 
which might use their own different markdown dialects, I just restrict 
myself to the highest common denominator - and that is the markdown 
package.


Hope it makes more sense now :)


Just cancel the RM bug when you're done.


Got it. Would you want to sponsor my upload, or should I look for a 
sponsor elsewhere?


Thanks!

Bug#466330: ITA: adopting markdown

[Andrea Pappacoda]

Control: retitle -1 ITA: markdown -- Text-to-HTML conversion tool
Control: owner -1 !

Hi all!

I think having the original markdown implementation in Debian is a good 
thing, for historical reference and for compatibility - there's people 
still using this package (I myself use this quite often when wanting to 
check for correctness of my markdown files).


I worked a bit on modernizing packaging, and attached you can find 
three patches which contain all my changes. Since I'm a DM, somebody 
would need to either add me to the DM acl of this package or to sponsor 
my upload. In any case, I've pushed my update to Mentors too: 



Chris, I noticed you've asked for removal of the markdown package. As 
you might guess, I disagree with its removal, and with my adoption I'm 
already fixing the Serious bug preventing the package to migrate to 
testing. Is it possible to stop the RM procedure?


Thanks!

Bug#1074774: Upgrading bctoolbox to 5.3.x

[Andrea Pappacoda]

Hi Bernhard, writing to you directly since sometimes the BTS discards 
emails.


Could you please let me know if you have plans for upgrading bctoolbox 
to a new upstream version from the 5.3 branch? It's needed to continue 
with the mbedtls 3.6 transition.


If not, would it be ok if I work on the update myself and then push an 
NMU?


Let me know! Bye :)

Bug#1078134: lz4: new lz4Config.cmake file causes FTBFS due to bogus xxhash dependency

[Andrea Pappacoda]

Source: lz4
Version: 1.9.4-3
Severity: important
Tags: ftbfs
Control: affects -1 yuzu
Control: block 1077401 by -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, the newly introduced lz4Config.cmake file is currently causing yuzu (and
probably other packages as well) to failing to build from source, since the
file contains an INTERFACE (aka transitive) dependency on the "xxhash" library,
contained in libxxhash-dev. This is wrong, since xxhash is a hidden (i.e.
internal) dependency of liblz4, and users need not pass compiler or linker
directives mentioning xxhash when consuming liblz4. As you can see from the
files themselves:

$ dpkg --listfiles liblz4-dev | xargs grep -s xxhash
/usr/lib/x86_64-linux-gnu/cmake/lz4/lz4Targets.cmake:
INTERFACE_LINK_LIBRARIES "xxhash"
/usr/lib/x86_64-linux-gnu/cmake/lz4/lz4Targets.cmake:
INTERFACE_LINK_LIBRARIES "xxhash"
grep: /usr/lib/x86_64-linux-gnu/liblz4.so: binary file matches

xxhash isn't included in public headers, and the pkg-config file rightfully
doesn't mention xxhash at all. CMake is the only one wrong.

Given upstream's only supported build system are Makefiles, and the only
supported way of consuming the library as a dependency is via its pkg-config
file, you have two choices:

1. Go back to using the official Makefiles, and stop using the community
maintained CMake build scripts
2. Fix this issue upstream, and keep fixing CMake issues, adding maintenance
burden

Given using CMake instead of the officially supported build system has caused
issues to Arch Linux in the past[1] for the zstd package (which has the same
upstream developer and build system situation), I generally find it unwise to
use CMake at all for Debian. I know, people will keep asking for CMake config
files, but sometimes it's fine to just say no. In my opinion, this is a
decision that has to be taken upstream, not here; Debian should follow
upstream's recommendations.

If you have any question related to CMake or build systems in general, feel
free to ask!

Bye :)

[1]: https://www.phoronix.com/news/Arch-Linux-Bizarre-Zstd


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

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZrNMwxQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p9KMAQC6tGUvQD30GejfqLARrGRuGBL4E0S8
KCy0FaiuG6TIEwD+PacPP0ElqhY9EdQ88VmkAvdX7al6Nb1jSljNldNC3Qg=
=ladj
-END PGP SIGNATURE-

Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"

[Andrea Zagli]

Colin Watson  writes:

> On Fri, Aug 02, 2024 at 05:16:57PM +0200, Andrea Zagli wrote:
>> i have "sshd: ALL" in hosts.allow and "ALL: ALL" in hosts.deny...
>
> Perfect, thanks, I see the problem now.  Will upload a fix shortly.


ok, i added sshd-session to hosts.allow and it works

Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"

[Andrea Zagli]

Andrea Zagli  writes:

> Colin Watson  writes:
>
>> (CCing the bug report again so that this is archived)
>>
>> On Fri, Aug 02, 2024 at 04:30:35PM +0200, Andrea Zagli wrote:
>>> i think it's disabled
>>> 
>>> ○ ssh.socket - OpenBSD Secure Shell server socket
>>>  Loaded: loaded (/usr/lib/systemd/system/ssh.socket; disabled; preset: 
>>> enabled)
>>>  Active: inactive (dead)
>>>Triggers: ● ssh.service
>>>  Listen: [::]:22 (Stream)
>>> 
>>> 
>>> the sshd service starts without problems
>>> 
>>> i tried with a clean sshd_config file, but same problem
>>> 
>>> i downgraded openssh to 9.7 and it works
>>
>> In that case I need all the ssh-related log entries you can give me -
>> "journalctl -u ssh.service --lines=1000", /var/log/auth.log, and so on.
>
>
> the only log produced 
>
> ago 02 16:30:11 deimos sshd[27821]: Received signal 15; terminating.
> ago 02 16:30:11 deimos systemd[1]: Stopping ssh.service - OpenBSD Secure 
> Shell server...
> ago 02 16:30:11 deimos systemd[1]: ssh.service: Deactivated successfully.
> ago 02 16:30:11 deimos systemd[1]: Stopped ssh.service - OpenBSD Secure Shell 
> server.
> ago 02 16:30:25 deimos systemd[1]: Starting ssh.service - OpenBSD Secure 
> Shell server...
> ago 02 16:30:25 deimos sshd[32054]: Server listening on 0.0.0.0 port 22.
> ago 02 16:30:25 deimos sshd[32054]: Server listening on :: port 22.
> ago 02 16:30:25 deimos systemd[1]: Started ssh.service - OpenBSD Secure Shell 
> server.
> ago 02 16:30:29 deimos sshd-session[32063]: refused connect from 10.0.0.99 
> (10.0.0.99)
>
>
> last line also on auth.log


i set sshd loglevel to debug3 and i found


ago 02 17:06:21 deimos sshd-session[35156]: debug1: Connection refused by tcp 
wrapper


i have "sshd: ALL" in hosts.allow and "ALL: ALL" in hosts.deny... never
changed these files from years

Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"

[Andrea Zagli]

Colin Watson  writes:

> (CCing the bug report again so that this is archived)
>
> On Fri, Aug 02, 2024 at 04:30:35PM +0200, Andrea Zagli wrote:
>> i think it's disabled
>> 
>> ○ ssh.socket - OpenBSD Secure Shell server socket
>>  Loaded: loaded (/usr/lib/systemd/system/ssh.socket; disabled; preset: 
>> enabled)
>>  Active: inactive (dead)
>>Triggers: ● ssh.service
>>  Listen: [::]:22 (Stream)
>> 
>> 
>> the sshd service starts without problems
>> 
>> i tried with a clean sshd_config file, but same problem
>> 
>> i downgraded openssh to 9.7 and it works
>
> In that case I need all the ssh-related log entries you can give me -
> "journalctl -u ssh.service --lines=1000", /var/log/auth.log, and so on.


the only log produced 

ago 02 16:30:11 deimos sshd[27821]: Received signal 15; terminating.
ago 02 16:30:11 deimos systemd[1]: Stopping ssh.service - OpenBSD Secure Shell 
server...
ago 02 16:30:11 deimos systemd[1]: ssh.service: Deactivated successfully.
ago 02 16:30:11 deimos systemd[1]: Stopped ssh.service - OpenBSD Secure Shell 
server.
ago 02 16:30:25 deimos systemd[1]: Starting ssh.service - OpenBSD Secure Shell 
server...
ago 02 16:30:25 deimos sshd[32054]: Server listening on 0.0.0.0 port 22.
ago 02 16:30:25 deimos sshd[32054]: Server listening on :: port 22.
ago 02 16:30:25 deimos systemd[1]: Started ssh.service - OpenBSD Secure Shell 
server.
ago 02 16:30:29 deimos sshd-session[32063]: refused connect from 10.0.0.99 
(10.0.0.99)


last line also on auth.log

Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"

[Andrea Zagli]

Package: openssh-server
Version: 1:9.8p1-1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 6.9.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 openssh-server depends on:
ii  adduser   3.137
ii  debconf [debconf-2.0] 1.5.87
ii  init-system-helpers   1.66
ii  libaudit1 1:3.1.2-4+b1
ii  libc6 2.39-6
ii  libcom-err2t64 [libcom-err2]  1.47.0-2.3+b1
ii  libcrypt1 1:4.4.36-4
ii  libgssapi-krb5-2  1.21.3-3
ii  libkrb5-3 1.21.3-3
ii  libpam-modules1.5.3-7
ii  libpam-runtime1.5.3-7
ii  libpam0g  1.5.3-7
ii  libselinux1   3.5-2+b3
ii  libssl3t643.2.2-1
ii  libwrap0  7.6.q-33
ii  lsb-base  11.6
ii  openssh-client1:9.8p1-1
ii  openssh-sftp-server   1:9.8p1-1
ii  procps2:4.0.4-5
ii  runit-helper  2.16.3
ii  sysvinit-utils [lsb-base] 3.09-2
ii  ucf   3.0043+nmu1
ii  zlib1g1:1.3.dfsg+really1.3.1-1

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  256.4-2
ii  ncurses-term 6.5-2
ii  xauth1:1.1.2-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  ssh-askpass   
pn  ufw   

-- debconf information excluded

Bug#1076335: bookworm-pu: package libvirt/9.0.0-4

[Andrea Bolognani]

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

[ Reason ]

The update would cover a number of issues that have been found to
affect the version of libvirt in bookworm.

The first one is a user-visible issue where the "virsh domif-setlink"
command can only be successfully used in certain conditions: this has
been reported as

  * https://bugs.debian.org/1075718

and has already been fixed upstream, so fixing it in stable involves
cherry-picking the relevant upstream change.

The remaining ones are all security issues, which have CVEs assigned
to them and are tracked in the Debian security tracker:

  * https://security-tracker.debian.org/tracker/CVE-2023-3750
  * https://security-tracker.debian.org/tracker/CVE-2024-1441
  * https://security-tracker.debian.org/tracker/CVE-2024-2494
  * https://security-tracker.debian.org/tracker/CVE-2024-2496

For all of them too, the fix has already been committed upstream and
so we just need to cherry-pick those changes. In a couple of cases
the cherry-pick is not a completely clean one, but the conflict
resolution is trivial and documented.


[ Impact ]

If the update isn't approved, stable users will keep being unable to
use the "virsh domif-setlink" command in some scenarios and will
remain exposed to a number of security issues.


[ Tests ]

The update was smoke-tested by starting and connecting to a few VMs.

I have manually inspected all the added patches to confirm that they
appear to do what they claim to; since they are all cherry-picked
from upstream, I have high confidence that they are correct.


[ Risks ]

The fixes are all extremely small and targeted, and have already been
validated upstream. libvirt has an extremely high bar for breaking
backwards compatibility, so the risk of that being an issue is very
low.


[ 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 stable
  [x] the issue is verified as fixed in unstable


[ Changes ]

Already detailed above.


[ Other info ]

This is my first time preparing a stable update, so it's not
unreasonable to expect that I might have gotten something wrong.
Please bear with me :)

The only thing that strikes me as a bit odd and we might need to
rectify is that CVE-2024-2496, while properly tracked in the Debian
security tracker, doesn't have a corresponding Debian bug. Should one
be filed?

I have been preparing unstable/experimental uploads for 4+ years, and
I'm also one of the upstream developers, so I am familiar both with
the Debian packaging and the underlying software.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.
diff -Nru libvirt-9.0.0/debian/changelog libvirt-9.0.0/debian/changelog
--- libvirt-9.0.0/debian/changelog	2023-05-21 11:31:31.0 +0200
+++ libvirt-9.0.0/debian/changelog	2024-07-13 21:00:26.0 +0200
@@ -1,3 +1,23 @@
+libvirt (9.0.0-4+deb12u1) bookworm; urgency=medium
+
+  [ Cyril Brulebois ]
+  * [923b6a8] patches: Add backports
+- backport/virsh-Make-domif-setlink-work-more-than-once.patch
+  - Closes: #1075718
+
+  [ Andrea Bolognani ]
+  * [94893a2] patches: Add backports
+- backport/Fix-off-by-one-error-in-udevListInterfacesByStatus.patch
+  - Fixes CVE-2024-1441
+- backport/interface-fix-udev_device_get_sysattr_value-return-value-.patch
+  - Fixes CVE-2024-2496
+- backport/remote-check-for-negative-array-lengths-before-allocation.patch
+  - Fixes CVE-2024-2494
+- backport/storage-Fix-returning-of-locked-objects-from-virStoragePo.patch
+  - Fixes CVE-2023-3750
+
+ -- Andrea Bolognani   Sat, 13 Jul 2024 21:00:26 +0200
+
 libvirt (9.0.0-4) unstable; urgency=medium
 
   * [79f6669] patches: Add backports
diff -Nru libvirt-9.0.0/debian/patches/backport/Fix-off-by-one-error-in-udevListInterfacesByStatus.patch libvirt-9.0.0/debian/patches/backport/Fix-off-by-one-error-in-udevListInterfacesByStatus.patch
--- libvirt-9.0.0/debian/patches/backport/Fix-off-by-one-error-in-udevListInterfacesByStatus.patch	1970-01-01 01:00:00.0 +0100
+++ libvirt-9.0.0/debian/patches/backport/Fix-off-by-one-error-in-udevListInterfacesByStatus.patch	2024-07-13 21:00:26.0 +0200
@@ -0,0 +1,46 @@
+From: Martin Kletzander 
+Date: Tue, 27 Feb 2024 16:20:12 +0100
+Subject: Fix off-by-one error in udevListInterfacesByStatus
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Ever since this function was introduced in 2012 it could've tried
+filling in an extra interface name.  That was made worse in 2019 when
+the caller functions started accepting NULL arrays of size 0.
+
+This is assigned CVE-2024-1441.
+
+Signed-off-by: Martin Kletzander 
+Reported-by: Alexander Kuznetsov 

Bug#1076287: git-debrebase: Add "Gbp-Dch: Ignore" to autogenerated commits

[Andrea Pappacoda]

On Sat Jul 13, 2024 at 7:47 PM CEST, Ian Jackson wrote:
You're talking about "commit the patch queue" etc., I think? 
I think what you suggest might make sense.


Yep, I was thinking about those.

I wonder if the same should be true of autogenerated commits made by 
the more general dgit quilt-fixup (modes like linear and smash).


I've never used it, so I don't know what you're talking about, but feel 
free to reassign this bug to dgit or src:dgit :)


Bye!

Bug#1076287: git-debrebase: Add "Gbp-Dch: Ignore" to autogenerated commits

[Andrea Pappacoda]

Package: git-debrebase
Version: 11.10
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all!

I've just started using git-debrebase, and I find it really cool; great work!

I'd really like to keep using gbp-dch(1) to generate my changelog from commit
messages though, as I find it a bit nicer than manually editing d/changelog. It
also allows me to write meaningful commit messages and have that same
information in d/changelog without having to write stuff twice.

git-debrebase makes using gbp-dch a bit problematic though, as it tends to
generate some commits which will then be picked up by gbp-dch.

Would it be possible to add a "Gbp-Dch: Ignore" pseudo header in commit
messages generated by git-debrebase, so that I don't have to remove them
manually when finalizing the changelog?

If you think I shouldn't be using gbp-dch with git-debrebase, I'm happy to hear
what you'd suggest instead :)

Thanks!


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

Kernel: Linux 6.9.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 git-debrebase depends on:
ii  devscripts  2.23.7
ii  git [git-core]  1:2.43.0-1+b1
ii  libdpkg-perl1.22.6
ii  libfile-fnmatch-perl0.02-3+b3
ii  liblocale-gettext-perl  1.07-7
ii  perl5.38.2-5

Versions of packages git-debrebase recommends:
ii  dgit  11.10
ii  git-buildpackage  0.9.34

git-debrebase suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZpK7uBQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p5GlAP4hLLAWhaCcNEwvn6ZbQ3q7QK1jffBk
Ibzim5BKtwmJbgEArzXqpqAqJpCIaf2+LrJ2a34KpLm55Z3qF36fsWz0egI=
=heEL
-END PGP SIGNATURE-

Bug#1074248: transition: mbedtls

[Andrea Pappacoda]

Hi Emilio,

On Tue Jul 9, 2024 at 1:42 PM CEST, Emilio Pozuelo Monfort wrote:

On 02/07/2024 18:43, Andrea Pappacoda wrote:
I'm nonetheless at least looking at all the failures and filing bug 
reports when necessary. Once I've checked all the packages and the 
key packages you've mentioned are ready, I'll go ahead with the 
transition.


Please mail us before proceeding, so that we can check that things are 
looking good and that there are no conflicting transitions, and we'll 
give you the go-ahead.


Of course! As you can see on the bug web page, I've submitted bug 
reports to pretty much all packages affected negatively by this 
transition. As for the affected key packages:


- bctoolbox needs an update to the latest upstream version
- libgit2 has already been fixed in experimental
- rustc was a false positive

What do you suggest me to do? Do you think I should work on upgrading 
bctoolbox and fixing the other packages, or should I just go ahead with 
the transition after you'll tell me that things are ok?


Thanks!

Bug#1006169: bullseye-pu: package mbedtls/2.16.12-0+deb11u1

[Andrea Pappacoda]

Hi Jonathan!

On Sun Jul 7, 2024 at 8:51 PM CEST, Jonathan Wiltshire wrote:

Sorry about the long delay to this.


No worries :)


On Sun, Feb 20, 2022 at 12:25:47PM +0100, Andrea Pappacoda wrote:

This upstream release only contains fixes anyway,


I'm not sure that's strictly true:


+Default behavior changes
+   * In mbedtls_rsa_context objects, the ver field was formerly documented
+ as always 0. It is now reserved for internal purposes and may take
+ different values.


Yeah, back when I was working on this I was a bit scared by this 
changelog entry, but if I recall correctly there was nothing that was 
actually depending on this "ver" field. And I honestly cannot think of 
useful piece of user code that would depend on having a certain struct 
member being zero.



and arguably:

> +Changes

+   * Improve the performance of base64 constant-flow code. The result is still
+ slower than the original non-constant-flow implementation, but much faster
+ than the previous constant-flow implementation. Fixes #4814.


(not a functional change, but one with some risk).


This is a performance improvement relative to an MbedTLS 2.16.10 
regression. In MbedTLS 2.16.10, some base64 code was made constant-flow, 
leading to a noticeable performance hit. In MbedTLS 2.16.12, this 
constant-flow code was improved. This isn't relevant for us though, 
since Debian Bullseye ships 2.16.9, i.e. the non-constant-flow 
implementation. Since a secure implementation needs to be constant-flow, 
we might as well choose the faster constant-flow one :)



In any case, I'm not sure that CVE-2021-44732 is as serious as you make
out. It's impactful yes, but doesn't the out-of-memory condition mean
another exploit or outrageous good fortune is also required to trigger
this?


I honestly do not remember what this CVE is about, but I see it has 
a 9.8 CRITICAL score, so it might make sense to fix it anyway. I know 
CVE scores are often a joke, but still.


Would you be able to accept this proposed update into bullseye? If yes, 
I could resume my work on this.


Thanks! Bye :)


signature.asc
Description: PGP signature

Bug#1075880: rust-psa-crypto-sys: FTBFS with MbedTLS 3.6

[Andrea Pappacoda]

On Sun Jul 7, 2024 at 4:51 AM CEST, Peter Michael Green wrote:

I've looked at that pull request, it doesn't seem relavent,
seems to relate to building the embedded copy of mbedtls,
while the debian package is patched to use system mbedtls.


Sorry for that! Yesterday night I submitted way to many bug reports, 
I should've been more careful :)



I looked at what was actually failing and noticed that the Debian
package currently ships a patch to build against system psa-crypto
instead of the embedded copy.

I was able to tweak that patch to build with the new version of
mbedtls, but in doing so broke the build with the old mbedtls,
as such I have uploaded it to experimental for now.


Thanks!

Bug#1075880: rust-psa-crypto-sys: FTBFS with MbedTLS 3.6

[Andrea Pappacoda]

Source: rust-psa-crypto-sys
Version: 0.9.3-2
Severity: important
Tags: ftbfs
Control: block 1074248 by -1
Control: forward -1 https://github.com/parallaxsecond/rust-psa-crypto/pull/137

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi! I'm working on transitioning Debian to MbedTLS 3.6 LTS from the old 
2.28 LTS branch. Unfortunately, rust-psa-crypto is failing to build with 
this new version.

Luckily for you, upstream has already fixed this issue in the master Git 
branch; I've linked the pull request above.

Could you please prepare an upload which builds with MbedTLS 3.6? 
Thanks!

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZomwOBQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3pxHWAP9jwJW2rLRAb33Fja+Sp7kkd3Ee+A2r
Wm0OftPGTyuqlwD+OXOdPQ5jGNxNkXfchYrn5BaFF9C19k+cm2H1vPd1MwY=
=j8hf
-END PGP SIGNATURE-

Bug#1075872: python-mbedtls: FTBFS with MbedTLS 3.6

[Andrea Pappacoda]

Source: python-mbedtls
Version: 2.10.1-1
Severity: important
Tags: ftbfs
Control: block 1074248 by -1
Control: forwarded -1 https://github.com/Synss/python-mbedtls/issues/118

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi! I'm working on transitioning Debian to MbedTLS 3.6 LTS from the old 2.28
LTS branch. Unfortunately, python-mbedtls is failing to build with this new
version.

I've submitted this bug report upstream. Since this package binds to MbedTLS
pretty closely, let's see what they think.

Bye :)


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

Kernel: Linux 6.9.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZomsjhQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p5XrAQDEjfxExbUXVbmLKTK9OOkx6dsR0yf5
hAxoXP4vQcGtegD9HddeKOh3KUV8Cvy03CqMmyYJiX8JumwjFwqgcCqAEgA=
=09mL
-END PGP SIGNATURE-

Bug#1075870: privoxy: FTBFS with MbedTLS 3.6

[Andrea Pappacoda]

Source: privoxy
Version: 3.0.34-5
Severity: important
Tags: ftbfs
Control: block 1074248 by -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

Hi! I'm working on transitioning Debian to MbedTLS 3.6 LTS from the old 2.28
LTS branch. Unfortunately, privoxy is failing to build with this new version.

I haven't been able to report the issue upstream, and it seems that nobody has
done so either. Nonetheless, you could try to start working on this by
replacing "#include mbedtls/config.h" with "#include mbedtls/build_info.h", and
see what breaks from there.

If you could manage to fix this and upload a new version to unstable, it'd be
great!

Bye :)


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

Kernel: Linux 6.9.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZomo4xQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p2KHAQChT0hHyetwAPCuH4nAsrvwmU+Lx98X
RmvDdiIYY3AqzwEA3Iat0bgfWtyIil4Ea1MkbyLGtyGNGMF8W79wx5XGggE=
=bi5v
-END PGP SIGNATURE-

Bug#1075869: neko: FTBFS with MbedTLS 3.6

[Andrea Pappacoda]

Source: neko
Version: 2.3.0-2
Severity: important
Tags: ftbfs
Control: block 1074248 by -1
Control: forwarded -1 https://github.com/HaxeFoundation/neko/pull/290

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi! I'm working on transitioning Debian to MbedTLS 3.6 LTS from the old 2.28
LTS branch. Unfortunately, neko is failing to build with this new version.

Luckily for you, the fix has been committed just a couple of days ago upstream
- - you just need to backport the pull request I've linked above :)

Could you please backport the fix and prepare an upload? Thanks!


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

Kernel: Linux 6.9.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZomm/hQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p8FqAQDEUkb0ug/DHYMfPw2qdxGyeKPNluhn
f+Iu+IsgeHtbNgEA3e9u3NEMtWCrTdoj6B9lk5+DK1Y3uh2PFIs1L0nYgw8=
=Nd2/
-END PGP SIGNATURE-

Bug#1075868: ncbi-vdb: FTBFS with MbedTLS 3.6

[Andrea Pappacoda]

Source: ncbi-vdb
Version: 3.0.2+dfsg-2
Severity: important
Tags: ftbfs
Control: fixed -1 3.0.9+dfsg-1
Control: block 1074248 by -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi! As you already know, I'm working on transitioning to MbedTLS 3.6. You've
already uploaded a version of ncbi-vdb on experimental which already builds
with MbedTLS 3.x, so there's not much I have to say apart from thank you :)

I'm opening this bug just for the purposes of the transition. If you think I
shouldn't have done this, let me know! It's my first time doing something like
this.

Thanks again :D


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

Kernel: Linux 6.9.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZomk8hQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p4UcAP9BvGtVfZJnp7cq7pkL0FY7akhJg+O9
2vsFndWHYAVI4wD+LcXaMr2I6aYlamm2l7E1FEKvDZL0KRhWpjHRETaCmg0=
=M5Cq
-END PGP SIGNATURE-

Bug#1075867: ncbi-blast+: FTBFS with MbedTLS 3.6

[Andrea Pappacoda]

Source: ncbi-blast+
Version: 2.12.0+ds-4
Severity: important
Tags: ftbfs
Control: block 1074248 by -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi! I'm working on transitioning Debian to MbedTLS 3.6 LTS from the old 2.28
LTS branch. Unfortunately, ncbi-blast+ is failing to build with this new
version. Upstream is currently using a few APIs no longer available in MbedTLS
3.x, and I haven't been able to report the issue upstream myself, nor check if
somebody already did. If you could add the Bug-Database and Bug-Submit fields
to d/upstream/metadata, it'd be great.

If you manage to prepare an upload which fixes builds with the new LTS, it'd be
awesome :)

Bye!


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

Kernel: Linux 6.9.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZomi0xQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3pxPGAP9tERllsdriDoiMfUxwakWwrDipoZpD
gRkhPxve5I/fbAD+PA78Z19sP30AUXuhZLVl0X1ZXaJcz9GRGS2F9i9A6gg=
=pY/Z
-END PGP SIGNATURE-

Bug#1075866: mongrel2: FTBFS with MbedTLS 3.6

[Andrea Pappacoda]

Source: mongrel2
Version: 1.12.2-3
Severity: important
Tags: ftbfs
Control: block 1074248 by -1
Control: forwarded -1 https://github.com/mongrel2/mongrel2/issues/359

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi! I'm working on transitioning Debian to MbedTLS 3.6 LTS from the old 2.28
LTS branch. Unfortunately, mongrel2 is failing to build with this new version.
There are multiple issues which prevent building with the new LTS, the main one
being that mongrel2 accesses struct members which have now been removed by
MbedTLS' public API.

Given upstream's scarce activity I don't expect them to fix this issue in a
reasonable time. If you're able to, it'd be great if you could patch this
yourself :)

Thanks!


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

Kernel: Linux 6.9.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZomfpBQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p93cAQDGExX25LhDBaP1yIHAPlpqsLatOsFv
aRK2wWbtqA8exQEApmaWa7Zjn9knFAHgREo5AAlQGUrxGcH/Z5yhlNLEaww=
=6iHf
-END PGP SIGNATURE-

Bug#1075865: micropython: FTBFS with MbedTLS 3.6

[Andrea Pappacoda]

Source: micropython
Version: 1.22.1+ds-1
Severity: important
Tags: ftbfs
Control: block 1074248 by -1
Control: forwarded -1 https://github.com/micropython/micropython/pull/8988

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm working towards transitioning mbedtls from version 2.28 LTS to 3.6 LTS.
Unfortunately, micropython 1.22 fails to build with mbedtls 3.x, so is one of
the packages holding back the transition.

Luckily for you, upstream has already switched to mbedtls 3.x in micropython
1.23 and newer, so all you need to do is "just" upgrade to a new upstream
release.

Could you please start preparing the upgrade, ideally pushing the new release
to experimental first?

Thanks!


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

Kernel: Linux 6.9.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZomeGxQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p0vDAQD/yiuOKdCC/zq5749jNGR7wHupfKPt
C8LdygIAWQb5+gEA8BXoh9RJ+cBzojS1O62q93cXTfsNyBHLU3DoSgla6gw=
=6igZ
-END PGP SIGNATURE-

Bug#1075864: lib60870: FTBFS with MbedTLS 3.6

[Andrea Pappacoda]

Source: lib60870
Version: 2.3.2-1
Severity: important
Tags: ftbfs
Control: block 1074248 by -1
Control: forwarded -1 https://github.com/mz-automation/lib60870/issues/156

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi! I'm working on transitioning Debian to MbedTLS 3.6 LTS from the old 2.28
LTS branch. Unfortunately, lib60870 is failing to build with this new version.

Upstream is using some APIs which have been removed from MbedTLS 3.6, so I
honestly don't know how much difficult it would be to switch to the new LTS. In
any case, I've also submitted the bug report upstream.

If you're nonetheless able to prepare an upload which fixes the build with
mbedtls 3.x it'd be great!

Bye :)


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

Kernel: Linux 6.9.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZomadRQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p+HrAQDP9RLt5eodSUeKXvWER0Rv0WeUqHkA
I+TLEhK31H7fTQD6Au10sNmbnXupEyn8cycIn57Fc6TGnQDLYdhtzl7Znww=
=AsVI
-END PGP SIGNATURE-

Bug#1075827: haxe: FTBFS with MbedTLS 3.6

[Andrea Pappacoda]

Source: haxe
Version: 1:4.3.4-1
Severity: important
Tags: ftbfs
Control: block 1074248 by -1
Control: forwarded -1 https://github.com/HaxeFoundation/haxe/pull/11646

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

I'm working towards transitioning mbedtls from version 2.28 LTS to 3.6 LTS.
Unfortunately, haxe 4.3.4 fails to build with mbedtls 3.x, so is one of the
packages holding back the transition.

Upstream has already fixed build with MbedTLS 3.x, but hasn't yet tagged a new
release. To fix this issue you could backport the relevant commits (which you
can find in the "forwarded" URL I linked above). If you could do so, it'd be
great!

Thanks :)


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

Kernel: Linux 6.9.7-amd64 (SMP w/4 CPU threads; PREEMPT)
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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZohgkBQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p3JOAP9gitjBmSykjnTNtl3Kwmn1HwWWqMp1
UH7r6pO4Jt9jKAD+KPMmkf8td0JDK6VIk1LdP282odkIRA0zDSSzfzt9gQ4=
=YWNV
-END PGP SIGNATURE-

Bug#1075825: gauche: FTBFS with MbedTLS 3.6

[Andrea Pappacoda]

Source: gauche
Version: 0.9.14-5
Severity: important
Tags: ftbfs
Control: block 1074248 by -1
Control: forwared -1 https://github.com/shirok/Gauche/issues/1047

Hi!

I'm working on transitioning mbedtls from version 2.28 LTS to version 3.6 LTS.
Unfortunately, gauche 0.9.14 fails to build with it - more precisely, some
tests fail.

This has been fixed upstream: a part of the fixes landed in version 0.9.14,
while some other were merged a couple of weeks ago into the master Git branch
(more precisely, in commit 4a0e88993424b5e2fd5fd2b6a17cd8969f08d038).

Could you please upgrade to the latest upstream release, and backport upstream
commit 4a0e88993424b5e2fd5fd2b6a17cd8969f08d038, so that I can go ahead with
the transition? If you prefer, you could upload the fixed package in
experimental, and upload to unstable once I upload mbedtls 3.6 to unstable.

Thanks!


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

Kernel: Linux 6.9.7-amd64 (SMP w/4 CPU threads; PREEMPT)
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

Bug#1074774: bctoolbox: FTBFS with MbedTLS 3.6

[Andrea Pappacoda]

Source: bctoolbox
Version: 5.2.0-2.1
Severity: important
Tags: ftbfs
Control: block 1074248 by -1
Control: forwarded -1 
https://gitlab.linphone.org/BC/public/bctoolbox/-/merge_requests/216

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

I'm working towards transitioning mbedtls from version 2.28 LTS to 3.6 LTS.
Unfortunately, bctoolbox 5.2 fails to build with mbedtls 3.x, so is one of the
(key) packages holding back the transition.

Luckily for you, upstream has already switched to mbedtls 3.x in bctoolbox 5.3
and newer, so all you need to do is "just" upgrade to a new upstream release.

Could you please start preparing the upgrade, ideally pushing the new release
to experimental first?

Thanks!


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

Kernel: Linux 6.8.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZoQ6chQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p+xBAQCwXFWeC+SHgTkSXRtMKUveKiBlg1TW
74z2dImIXXlPCgEA7gVKeorv87PkFIBZY0kU/FsGWCaG8I14k6NHcspc9gk=
=kdrA
-END PGP SIGNATURE-

Bug#1074248: transition: mbedtls

[Andrea Pappacoda]

Hi Emilio!


Il 2 luglio 2024 13:13:43 CEST, Emilio Pozuelo Monfort  ha 
scritto:
>Cool. btw I checked those packages and only these 3 are key packages:
>
>bctoolbox
>libgit2
>rustc
>
>It'd be nice to know if rustc will build if it wasn't for the disk space. Also 
>it'd be good to have the other two packages sorted (e.g. with a patch prepared 
>or identified) before starting this transition.

bctoolbox switched to using mbedtls 3.x since version 5.3.0, so the package 
maintainers would only need to upgrade the package. libgit2 too switched to the 
latest mbedtls in version 1.8.0, which is already in experimental. As for 
rustc, yeah, I'd need to build on a system with more disk space.

I'm nonetheless at least looking at all the failures and filing bug reports 
when necessary. Once I've checked all the packages and the key packages you've 
mentioned are ready, I'll go ahead with the transition. I can't NMU fixes since 
I'm only a DM, so there's not much I can do if the respective maintainers don't 
fix the build failures with mbedtls 3.

If you have any other suggestions, please let me know!

Thanks :)

P.S. formatting is probably off, since I'm replying from my phone. Sorry for 
that!