Bug#1082494: [Debian-med-packaging] Bug#1082494: build ignores requested number of parallel processes

[Johannes Schauer Marin Rodrigues]

Hi Étienne,

Quoting Étienne Mollier (2024-09-21 10:52:55)
> Thanks for the patch, I applied it, modulo the typo at the end of the
> "patsubst" line.  Sorry I didn't think of situations where it is desirable to
> run builds and tests in a single thread when hardwiring pytest options some
> time ago.

uh awesome, thank you for the quick fix!

Yeah, my machine only has 3.6 GB of RAM but six cores, so parallel builds are
not a good idea here. XD

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1082494: build ignores requested number of parallel processes

[Johannes Schauer Marin Rodrigues]

Source: pyranges
Severity: normal

Hi,

when building your package with dpkg-buildpackage -j X, which sets
DEB_BUILD_OPTIONS=parallel=X, the dh_auto_test step ignores that setting
and will run with whatever `nproc` returns regardless. Untested patch:

--- a/debian/rules
+++ b/debian/rules
@@ -10,7 +10,13 @@ export PYBUILD_BEFORE_TEST=\
&& cp -av {dir}/tests/test_data {build_dir}/tests \
&& cp -av {dir}/tests/data {build_dir}/tests \
&& cp -av {dir}/pyranges/example_data {build_dir}/pyranges
-export PYBUILD_TEST_ARGS=-v -n $(shell nproc)
+
+ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
+   NUMJOBS = $(patsubst parallel=%,%,$(filter 
parallel=%,$(DEB_BUILD_OPTIONS)))"
+else
+   NUMJOBS = $(shell nproc)
+endif
+export PYBUILD_TEST_ARGS=-v -n $(NUMJOBS)
 
 %:
dh $@ --buildsystem=pybuild


Thanks!

cheers, josch

Bug#1082429: tests ignore selected parallelism

[Johannes Schauer Marin Rodrigues]

Source: debugpy
Version: 1.8.5+ds-1
Severity: normal

Hi,

I'm building src:debugpy on a system with 3.6 GB of RAM. For this to
work, I need to be able to reduce the number of concurrent processes. I
do this by passing -j2 to dpkg-buildpackage which in turn will add
parallel=2 to DEB_BUILD_OPTIONS.

But during dh_auto_test, this setting is ignored and pytest is run with
--numprocesses=auto. I think this happens in debian/run_tests.

Please respect the desired parallelism setting instead of telling pytest
to choose it automatically.

Thanks!

cheers, josch

Bug#1082358: unreproducible timestamp in man pages

[Johannes Schauer Marin Rodrigues]

Package: sbuild
Version: 0.85.11
Severity: normal
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

sbuild fails the reprotest job in salsa CI with differences like this:

│ │ ├── data.tar.xz
│ │ │ ├── data.tar
│ │ │ │ ├── ./usr/share/perl5/Sbuild/Sysconfig.pm
│ │ │ │ │ @@ -29,15 +29,15 @@
│ │ │ │ │  
│ │ │ │ │  @ISA = qw(Exporter);
│ │ │ │ │  
│ │ │ │ │  @EXPORT_OK = qw($version $release_date $compat_mode %paths 
%programs);
│ │ │ │ │  }
│ │ │ │ │  
│ │ │ │ │  our $version = "0.85.11+salsaci+20240920+283";
│ │ │ │ │ +our $release_date = "28 august 2024";
│ │ │ │ │ -our $release_date = "28 August 2024";
│ │ │ │ │  our $compat_mode = 0;
│ │ │ │ │  
│ │ │ │ │  # Paths
│ │ │ │ │  my $prefix = "/usr";
│ │ │ │ │  my $exec_prefix = "${prefix}";
│ │ │ │ │  # Depend on prefix
│ │ │ │ │  my $includedir = "${prefix}/include";

or this:

│ │ ├── data.tar.xz
│ │ │ ├── data.tar
│ │ │ │ ├── ./usr/share/man/man1/buildd-abort.1.gz
│ │ │ │ │ ├── buildd-abort.1
│ │ │ │ │ │ @@ -21,15 +21,15 @@
│ │ │ │ │ │  .ds SCHROOT_SYSCONF_DIR /etc/schroot
│ │ │ │ │ │  .ds BUILDD_CONF /etc/buildd/buildd.conf
│ │ │ │ │ │  .ds BUILDD_SYSCONF_DIR /etc/buildd
│ │ │ │ │ │  .ds SBUILD_CONF /etc/sbuild/sbuild.conf
│ │ │ │ │ │  .ds SBUILD_SYSCONF_DIR /etc/sbuild
│ │ │ │ │ │  .ds WANNA_BUILD_LIBEXEC_DIR @WANNA_BUILD_LIBEXEC_DIR@
│ │ │ │ │ │  .ds SBUILD_LIBEXEC_DIR /usr/libexec/sbuild
│ │ │ │ │ │ +.ds RELEASE_DATE 28 august 2024
│ │ │ │ │ │ -.ds RELEASE_DATE 28 August 2024
│ │ │ │ │ │  .ds VERSION 0.85.11+salsaci+20240920+283
│ │ │ │ │ │  .ds PACKAGE sbuild
│ │ │ │ │ │  .ds PACKAGE_URL 
│ │ │ │ │ │  .ds PACKAGE_BUGREPORT buildd-tools-de...@lists.alioth.debian.org
│ │ │ │ │ │  .ds PACKAGE_STRING sbuild 0.85.11+salsaci+20240920+283
│ │ │ │ │ │  .ds PACKAGE_VERSION 0.85.11+salsaci+20240920+283
│ │ │ │ │ │  .ds PACKAGE_TARNAME sbuild

The differing timestamp ("august" versus "August") gets generated in
./configure by essentially running:

$ date --utc --date=$(dpkg-parsechangelog --show-field Timestamp) '+%d %B 
%Y')

The issue is fixed by this patch to d/rules:

--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,8 @@
 #!/usr/bin/make -f
 
+# prevent different timestamps in man pages (see #X)
+export LC_ALL=C.UTF-8
+
 %:
dh $@
 

Filed here to close it later for the internet points. Thanks!

cheers, josch

Bug#897927: equivs builds packages in surprising location

[Johannes Schauer Marin Rodrigues]

Control: severity -1 important
Control: block 1081839 by -1
Control: tags -1 + patch

Hi,

On Fri, 04 May 2018 17:06:04 -0400 Marten van Kerkwijk  
wrote:
> When I previously used equivs-build, the .deb file was generated in the
> current working directory, but with version 2.1.0 it preferentially uses
> $TMPDIR.  In principle, this is a good change, but it would be helpful if the
> man page states where the package ends up.  (I spent about an hours trying to
> debug, until I finally thought to look at the source code...)

I'm raising the severity of this bug because this affects consumers of equivs
like mk-build-deps or, like in bug #1081839, debootsnap and thus also
debrebuild. The effect we see is, that on systems with TMPDIR set, debrebuild
will fail with:

E: Unable to locate package debootsnap-dummy

If debrebuild is run without TMPDIR set, it will succeed. The current behaviour
makes equivs-build hard (or at least very surprising) to use in scripts where
the program running equivs-build expects a reliable location of the artifacts
as they are produced by equivs-build. Figuring out that the bug you are trying
to reproduce is due to TMPDIR being set or not is very frustrating and cost me
and Holger many hours of our lives.

At the very least, please accept the patch at the bottom of this mail which
documents this behaviour.

Even better, maybe add an option to equivs-build which allows scripts that
use it to set the output directory in a deterministic way.

While I'm here: is equivs still developed/maintained? The version in unstable
is the same as the version in oldstable and this bug is from 2018 and has no
replies. Maybe scripts written today should be using something else?

Thanks!

cheers, josch

--- equivs-2.3.1/equivs-build.pod   2018-11-13 21:44:07.0 +0100
+++ equivs-2.3.1+nmu1/equivs-build.pod  2024-09-16 09:46:29.0 +0200
@@ -14,6 +14,11 @@
 can be created with equivs. These can be used as "profile" packages 
 which just mark other ones for installation.
 
+The resulting packages are placed in the current working directory (not in the
+parent directory as indicated by B output) or, if the
+I environment variable is set, in the filesystem location indicated by
+the I environment variable.
+
 Please note that this is a crude hack and if thoughtlessly used,
 it might possibly do damage to your packaging system. And please
 note as well that using it is not the recommended way of dealing

signature.asc
Description: signature

Bug#1077452: picolibc: FTBFS: make[1]: *** [debian/rules:134: override_dh_auto_test] Error 104

[Johannes Schauer Marin Rodrigues]

Quoting Keith Packard (2024-09-11 19:59:25)
> > In an upstream github issue that Keith responded to a week or more ago he
> > did say he couldn't do anything immediately as he was "off flying rockets"
> > - I took that to mean he is likely enjoying a vacation but may be back to
> > tackle this soon.
> 
> I've been managing some final PRs into picolibc 1.8.7 and am busy releasing
> that today. This will close #1077452 and #1080065.

Thank you for your work and congrats on the new upstream release! :)

signature.asc
Description: signature

Bug#1081336: Intermittent FTBFS due to hang in tests/test_api_base.py

[Johannes Schauer Marin Rodrigues]

Hi,

On Tue, 10 Sep 2024 21:37:20 +0200 Stefano Rivera  wrote:
> During a test rebuild, bmap-tools failed to rebuild.
> 
> I see it has hung in the same place in the past, on a buildd.
> Filing at the important level as it apparently built after being
> retried, on the buildd.
> 
> ---
> [...]
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/<>'
> faketime '2022-06-26 17:10:50' dh_auto_test
> I: pybuild base:311: cd /<>/.pybuild/cpython3_3.12/build; 
> python3.12 -m pytest tests
> = test session starts 
> ==
> platform linux -- Python 3.12.5, pytest-8.3.2, pluggy-1.5.0
> rootdir: /<>/.pybuild/cpython3_3.12/build
> configfile: pyproject.toml
> plugins: typeguard-4.3.0
> collected 19 items
> 
> tests/test_CLI.py .  [ 
> 26%]
> tests/test_api_base.py 
> E: Build killed with signal TERM after 150 minutes of inactivity

my guess is, that this is due to the system starved of random numbers. The
function generate_test_files() makes heavy use of the python random module to
generate lots of data. Maybe the build system is just starved of entropy and
maybe this is also why it's not failing reliably?

I wasn't able to reproduce this issue locally with sbuild but saw in htop that
the test in question was not using much CPU but was generating a lot of I/O by
writing out all the temporary test files.

The effect also happened on the buildds where the build ran into a timeout on
x86-csail-02 but then built successfully within 2 minutes on x86-grnet-02 a
week later: 
https://buildd.debian.org/status/logs.php?pkg=bmap-tools&ver=3.8.0-1&arch=all

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1081392: tuigreet: Character corruption in window title

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Andy Piper (2024-09-11 14:01:06)
> I updated to the latest tuigreet package, and then rebooted.
> 
> The tuigreet window on my MNT Pocket Reform now shows Authenticate into
> {c}hostname" where {c} is an ASCII diamond character; and the last
> character of the hostname appears again underneath the hostname on the
> line before the Username prompt.
> 
> I have not changed any configuration related to tuigreet. I have tried
> changing the console font but this same display issue happens across
> several tried via dpkg-reconfigure console-setup.
> 
> NB the LC_* information in the system information is due to ssh'ing from
> a Mac to make this report; they are (I believe) unrelated to the
> tuigreet issue.

thank you for your report. Tuigreet 0.9 changed the rendering engine to ratatui
and this might be some fallout from that switch. Does your issue look like this?

https://github.com/apognu/tuigreet/issues/152

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1077452: picolibc: FTBFS: make[1]: *** [debian/rules:134: override_dh_auto_test] Error 104

[Johannes Schauer Marin Rodrigues]

On Tue, 10 Sep 2024 16:56:49 + Tj  wrote:
> > Since Keith seems to still be busy, I'm wondering how to best fix this 
> > FTBFS via an NMU without doing a huge change like importing a new upstream 
> > release.
> > 
> > What do you think of doing a minimal NMU which just temporarily (until a 
> > new upstream version is packaged) disables the tests?
> 
> In an upstream github issue that Keith responded to a week or more ago he did
> say he couldn't do anything immediately as he was "off flying rockets" - I
> took that to mean he is likely enjoying a vacation but may be back to tackle
> this soon.

In case of Keith, "off flying rockets" means literally that. :)

Keith wrote a firmware called [AltOS] which coincidentally is one of the users
of picolibc. :D

Thanks!

cheers, josch

[AltOS] https://altusmetrum.org/AltOS/

signature.asc
Description: signature

Bug#1077452: picolibc: FTBFS: make[1]: *** [debian/rules:134: override_dh_auto_test] Error 104

[Johannes Schauer Marin Rodrigues]

Hi,

On Thu, 05 Sep 2024 14:13:14 +0100 Tj  wrote:
> The package needs updating to the current (2024-09-05) upstream HEAD /and/
> build-testing via sbuild to ensure it builds and tests correctly.
> 
> There are an entire series of TIMEOUT issues in the arm and aarch64
> tests that are fixed by various patches since 1.8.6.
> 
> It is not worth trying to pick out the commits to fix the failures -
> I've done that extensively and it is not practical.
> 
> The arm tests failed due to two issues; MMU not being enabled
> (commit 5252f4dd236e4) and exception vector table being generated with
> Thumb instructions not ARM32 (commit dd711267309fbc3d and
> b2d921a71ea011d4c1c) but other commits are needed preceding those.
> 
> With all the arm tests fixed there are 32 failed aarch64 tests and no
> idea if other architectures will also have failures.
> 
> Building with latest origin/main all tests pass and package builds
> successfully.

thank you and mjt for all the time you've put into figuring out what's going
on!

Since Keith seems to still be busy, I'm wondering how to best fix this FTBFS
via an NMU without doing a huge change like importing a new upstream release.

What do you think of doing a minimal NMU which just temporarily (until a new
upstream version is packaged) disables the tests?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1081201: libc6-dev:amd64 : Breaks: libc6-dev-amd64-cross (< 2.40~) but 2.39-4cross1 is to be installed

[Johannes Schauer Marin Rodrigues]

Package: libc6-dev-amd64-cross
Version: 2.39-4cross1
Severity: serious
X-Debbugs-Cc: debian-cr...@lists.debian.org

Hi,

while trying to cross-build the next upload of my source package pico-sdk for
amd64 on my arm64 box in a clean unstable chroot with sbuild, I ran into the
following problem:

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
Execute external solver...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libc6-dev:amd64 : Breaks: libc6-dev-amd64-cross (< 2.40~) but 2.39-4cross1 is 
to be installed
E: Broken packages
apt-get failed.
E: Package installation failed


On salsa-ci, the problem is even more weird. The test-crossbuild-arm64 job ends
up installing the native architecture compilers:

The following NEW packages will be installed:
  binutils-aarch64-linux-gnu:arm64 binutils-common:arm64
  cpp-14-aarch64-linux-gnu:arm64 cpp-aarch64-linux-gnu cross-config
  crossbuild-essential-arm64 dpkg-cross file g++-14-aarch64-linux-gnu:arm64
  g++-aarch64-linux-gnu gcc-14-aarch64-linux-gnu:arm64 gcc-14-base:arm64
  gcc-aarch64-linux-gnu libasan8:arm64 libatomic1:arm64 libbinutils:arm64
  libc6:arm64 libc6-dev:arm64 libcc1-0:arm64 libconfig-auto-perl
  libconfig-inifiles-perl libcrypt-dev:arm64 libcrypt1:arm64
  libctf-nobfd0:arm64 libctf0:arm64 libdebian-dpkgcross-perl
  libfile-homedir-perl libfile-which-perl libgcc-14-dev:arm64 libgcc-s1:arm64
  libgmp10:arm64 libgomp1:arm64 libgprofng0:arm64 libhwasan0:arm64 libicu72
  libio-string-perl libisl23:arm64 libitm1:arm64 libjansson4:arm64
  liblocale-gettext-perl liblsan0:arm64 libmagic-mgc libmagic1t64
  libmpc3:arm64 libmpfr6:arm64 libsframe1:arm64 libstdc++-14-dev:arm64
  libstdc++6:arm64 libtsan2:arm64 libubsan1:arm64 libxml-libxml-perl
  libxml-namespacesupport-perl libxml-sax-base-perl libxml-sax-perl
  libxml-simple-perl libxml2 libyaml-perl libzstd1:arm64 sensible-utils ucf
  zlib1g:arm64

This means that the build later fails with:

/usr/lib/ccache/aarch64-linux-gnu-g++   -g -O2 
-ffile-prefix-map=/builds/debian/pico-sdk/debian/output/source_dir=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -o CMakeFiles/cmTC_e5da0.dir/testCXXCompiler.cxx.o -c 
/builds/debian/pico-sdk/debian/output/source_dir/pioasm-obj-aarch64-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-fi0q8w/testCXXCompiler.cxx
ccache: error: execute_noreturn of /usr/bin/aarch64-linux-gnu-g++ failed: 
Exec format error

Because obviously, the compiler binary from g++-14-aarch64-linux-gnu:arm64
cannot be executed on amd64.

Full log here: https://salsa.debian.org/debian/pico-sdk/-/jobs/6250227/raw

The problem does not seem to be limited to my package pico-sdk, hence the 
severity.

Thanks!

cheers, josch

Bug#1078693: e2fsprogs: introduced a bootstrap dependency cycle with libarchive

[Johannes Schauer Marin Rodrigues]

Hi again,

Quoting Johannes Schauer Marin Rodrigues (2024-08-21 12:25:48)
> Quoting Helmut Grohne (2024-08-15 07:19:52)
> > On Thu, Aug 15, 2024 at 12:14:52AM -0400, Theodore Ts'o wrote:
> > > This only passes the "it builds, ship it!" test, but it appears that
> > > it might be enough to replace
> > 
> > My message was primarily targeted at getting an agreement on the
> > direction of a solution. As you imply that you are ok with this kind of
> > solution, I guess Johannes will volunteer to supply a patch for detailed
> > discussion.
> 
> please find a tested patch attached which is only little more than what was
> provided by Ted already. I built this with and without nocheck. When built 
> with
> nocheck, libarchive-dev does not get installed and attempting to use the
> resulting package will yield:
> 
> Copying files into the device: __populate_fs_from_tar: you need libarchive to
> be able to process tarballs mke2fs: Operation not permitted while populating
> file system
> 
> After installing libarchive13t64, I was able to create filesystems from
> tarballs as usual. Building without nocheck, tests pass fine.
> 
> Does this look okay?

it does not. Helmut discovered that my last patch breaks --without-libarchive.
If e2fsprogs builds fine even without archive.h present, then its existence can
no longer be used to also carry the meaning of whether to disable libarchive
support or not. Hence, my updated patch introduces a new config definition
called CONFIG_DISABLE_LIBARCHIVE which is set if --without-libarchive is
passed. In the other cases, the presence of archive.h will be used to determine
whether to include the real header or use the hard-coded forward declarations.

This was discovered because as a workaround for #1070042, e2fsprogs disables
libarchive support on mips64el in debian/rules. Since that bug is fixed, commit
018cd6e9a659917ac1374775f5a60b1cf0be182c can probably be reverted?

Thanks!

cheers, josch>From 83ed3084ddc21cb085fbd5ffeaca30ae0741821a Mon Sep 17 00:00:00 2001
From: Johannes Schauer Marin Rodrigues 
Date: Tue, 3 Sep 2024 13:15:33 +0200
Subject: [PATCH] misc/create_inode_libarchive.c: decouple --without-libarchive
 and HAVE_ARCHIVE_H

To aid bootstrapping, it would be useful to be able to build e2fsprogs
without archive.h as otherwise there is a build dependency loop with
libarchive. If archive.h is not present, add the missing forward
declarations and preprocessor definitions and typedefs. Since this
allows building e2fsprogs with libarchive support even without the
archive.h header present on the system, we cannot check HAVE_ARCHIVE_H
anymore to decide whether to build with libarchive support or not. So if
--without-libarchive is passed to ./configure, CONFIG_DISABLE_LIBARCHIVE
gets set and later checked to decide about libarchive support.

Closes: #1078693
---
 configure  |  3 +++
 configure.ac   |  2 ++
 lib/config.h.in|  3 +++
 misc/create_inode_libarchive.c | 12 +++-
 4 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index cba3191c..3310cecc 100755
--- a/configure
+++ b/configure
@@ -13745,6 +13745,9 @@ then
 	try_libarchive=""
 	{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: Disabling libarchive support" >&5
 printf "%s\n" "Disabling libarchive support" >&6; }
+
+printf "%s\n" "#define CONFIG_DISABLE_LIBARCHIVE 1" >>confdefs.h
+
 elif test "$withval" = "direct"
 then
 	try_libarchive="direct"
diff --git a/configure.ac b/configure.ac
index 131caef3..ed5ba0aa 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1307,6 +1307,8 @@ AS_HELP_STRING([--without-libarchive],[disable use of libarchive]),
 then
 	try_libarchive=""
 	AC_MSG_RESULT([Disabling libarchive support])
+	AC_DEFINE(CONFIG_DISABLE_LIBARCHIVE, 1,
+		[Define to 1 to completely disable libarchive])
 elif test "$withval" = "direct"
 then
 	try_libarchive="direct"
diff --git a/lib/config.h.in b/lib/config.h.in
index 04cec72b..819c4331 100644
--- a/lib/config.h.in
+++ b/lib/config.h.in
@@ -12,6 +12,9 @@
 /* Define to 1 for features for use by ext4 developers */
 #undef CONFIG_DEVELOPER_FEATURES
 
+/* Define to 1 to completely disable libarchive */
+#undef CONFIG_DISABLE_LIBARCHIVE
+
 /* Define to 1 if using dlopen to access libarchive */
 #undef CONFIG_DLOPEN_LIBARCHIVE
 
diff --git a/misc/create_inode_libarchive.c b/misc/create_inode_libarchive.c
index 8705eb16..15749689 100644
--- a/misc/create_inode_libarchive.c
+++ b/misc/create_inode_libarchive.c
@@ -18,15 +18,25 @@
 #include "create_inode_libarchive.h"
 #include "support/nls-enable.h"
 
-#ifdef HAVE_ARCHIVE_H
+#ifndef CONFIG_DISABLE_LIBARCHIVE
 
 /* 64KiB is the minim

Bug#1079938: sbuild-createchroot creates unmerged /usr for bookworm by default

[Johannes Schauer Marin Rodrigues]

Hi Santiago,

Quoting Santiago Vila (2024-08-30 14:25:39)
> My use case is that sometimes I need to know in which date
> some package stopped failing to build in testing because
> an unknown build-dependency finally propagated to testing.
> 
> For that to happen I need either:
> 
> (A) Create a usr-merged buildd chroot of bookworm, then upgrade to the
> desired trixie at some unspecified date using snapshot.debian.org.
> 
> (B) Create a non-usr-merged buildd chroot of bookworm, usr-merge it,
> then upgrade to snapshot.debian.org.
> 
> What is the route that I'm supposed to follow?
> 
> Do you disagree that at least one of those two options should be fully
> supported?

Why the upgrade step? Why do you not create a trixie buildd chroot from a given
snapshot.d.o timestamp directly? Do you do that because you also want to test
the upgrade scenario?

If you do not need the upgrade part, there is the tool debootsnap which creates
a chroot with precisely the package versions you require without upgrading, for
example from a buildinfo file.

There is also the tool "debbisect" which I usually use to track down when a
package started to FTBFS in unstable (but you can use it for testing all the
same).  Just recently I ran this to track down #1077452:

$ DEBIAN_BISECT_SRCPKG=picolibc debbisect --cache=./cache 2024-02-26 2024-08-27 
/usr/share/doc/devscripts/examples/debbisect_buildsrc.sh

That this is possible does of course not invalidate your question whether
either of your options above should be fully supported. I just wanted to let
you know that maybe there is a practical solution for your use-case that works
better than what you are currently doing.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1080065: Vcs-Git field does not refer to the Debian packaging git

[Johannes Schauer Marin Rodrigues]

Source: picolibc
Version: 1.8.6-2
Severity: normal

Hi,

the Vcs-Git field of picolibc refers to
git://keithp.com/git/picolibc.git but after cloning that repo, there is
no debian directory. Maybe the packaging lives in the branch called
"debian"? If so, then the Vcs-Git field should look like this instead:

Vcs-Git: git://keithp.com/git/picolibc.git -b debian

The "-b debian" at the end specifies the git branch where the packaging
can be found.

Also, when having a look into debian/changelog, it appears that only
version 1.8.6-1 is there while the Debian archive has version 1.8.6-2.
Maybe you forgot to git push your last upload into the repo?

Thanks!

cheers, josch

Bug#1079938: sbuild-createchroot creates unmerged /usr for bookworm by default

[Johannes Schauer Marin Rodrigues]

Hi Lee,

there seems to be some confusion (also from my end) -- read further below.

Quoting Lee Garrett (2024-08-28 20:35:06)
> when creating a bookworm schroot e.g. with sbuild-createchroot --merged-usr
> bookworm /var/lib/schroot/schroots/bookworm-amd64-sbuild
> http://localhost:3142/deb.debian.org/debian/
> 
> the resulting schroot has an unmerged /usr. This creates some interesting
> problems, like upgrade tests failing. Or in theory it's possible to 
> successfully
> build and test packages that would be broken when installed on a "real"
> bookworm.
> 
> Is there a reason for this? At least for me this break user expectation, as a
> merged /usr is required per release notes [0]. I've tentatively set this to
> severity serious, as I believe this could have been an oversight. If this is 
> by
> design, I think it's best if sbuild-createchroot would very prominently say so
> on the end of the build run.
> 
> Thanks in advance!
> 
> Regards,
> Lee
> 
> [0] 
> https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#a-merged-usr-is-now-required
> 
> -- System Information:
> Debian Release: 12.7
>   APT prefers stable-updates
>   APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
> 'proposed-updates'), (990, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.9.7+bpo-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 sbuild depends on:
> ii  adduser 3.134
> ii  libsbuild-perl  0.85.0
> ii  perl5.36.0-7+deb12u1
> 
> Versions of packages sbuild recommends:
> ii  autopkgtest  5.39
> ii  debootstrap  1.0.128+nmu2+deb12u1
> ii  schroot  1.6.13-3+b2
> ii  uidmap   1:4.13+dfsg1-1+b1
> 
> Versions of packages sbuild suggests:
> pn  deborphan  
> ii  e2fsprogs  1.47.0-2
> ii  kmod   30+20221128-1
> ii  wget   1.21.3-1+b2
> 
> -- no debconf information

Your package selection suggests that you are on bookworm. I am as well. As far
as I can see, I have the same package versions installed for sbuild and
debootstrap as you do.

$ apt-cache policy sbuild debootstrap
sbuild:
  Installed: 0.85.0
[...]
debootstrap:
  Installed: 1.0.128+nmu2+deb12u1



But I am unable to reproduce this. It seems that
debootstrap should indeed respect the --merged-usr flag even when building
bookworm buildd chroots. I'm running this and I fail to reproduce your issue:

$ sudo sbuild-createchroot --merged-usr bookworm tmp/debian-bookworm
[...]
$ ls -lha ~/tmp/debian-bookworm
total 144K
drwxr-xr-x  18 root   root   4.0K Aug 29 14:40 .
drwxrwxrwt 156 josch  josch   72K Aug 29 14:37 ..
lrwxrwxrwx   1 root   root  7 Aug 29 14:39 bin -> usr/bin
drwxr-xr-x   2 root   root   4.0K Mar 29 18:20 boot
drwxrws---   2 sbuild sbuild 4.0K Aug 29 14:40 build
drwxr-xr-x   4 root   root   4.0K Aug 29 14:39 dev
drwxr-xr-x  31 root   root   4.0K Aug 29 14:40 etc
drwxr-xr-x   2 root   root   4.0K Mar 29 18:20 home
lrwxrwxrwx   1 root   root  7 Aug 29 14:39 lib -> usr/lib
drwxr-xr-x   2 root   root   4.0K Aug 29 14:39 media
drwxr-xr-x   2 root   root   4.0K Aug 29 14:39 mnt
drwxr-xr-x   2 root   root   4.0K Aug 29 14:39 opt
drwxr-xr-x   2 root   root   4.0K Mar 29 18:20 proc
drwx--   2 root   root   4.0K Aug 29 14:39 root
drwxr-xr-x   4 root   root   4.0K Aug 29 14:39 run
lrwxrwxrwx   1 root   root  8 Aug 29 14:39 sbin -> usr/sbin
drwxr-xr-x   2 root   root   4.0K Aug 29 14:39 srv
drwxr-xr-x   2 root   root   4.0K Mar 29 18:20 sys
drwxrwxrwt   2 root   root   4.0K Aug 29 14:40 tmp
drwxr-xr-x  11 root   root   4.0K Aug 29 14:39 usr
drwxr-xr-x  11 root   root   4.0K Aug 29 14:39 var

This seems to be the intended behaviour. Can you try again?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1079938: sbuild-createchroot creates unmerged /usr for bookworm by default

[Johannes Schauer Marin Rodrigues]

Hi Santiago,

Quoting Santiago Vila (2024-08-29 14:02:43)
> Lee Garret wrote:
> > when creating a bookworm schroot e.g. with
> > sbuild-createchroot --merged-usr bookworm 
> > /var/lib/schroot/schroots/bookworm-amd64-sbuild 
> > http://localhost:3142/deb.debian.org/debian/
> > the resulting schroot has an unmerged /usr.
> 
> I'm doing this:
> 
> sbuild-createchroot --merged-usr bookworm /tmp/mychroot 
> http://deb.debian.org/debian
> 
> and it works for me. I get a usrmerged system that way.
> 
> I'm using sbuild and debootstrap in bookworm
> (i.e. 0.85.0 and 1.0.128+nmu2+deb12u1).

I can confirm this on bookworm.

> Johannes Schauer Marin Rodrigues wrote:
> > Do you think that this change addresses your concerns?
> 
> I don't. If it works in bookworm, I don't see a good reason
> why it should suddenly stop working.
> 
> In fact, without --merged-usr, a non usrmerged is created
> but having the usr-is-merged package installed. That's very bad and I hope
> somebody can address it.

So now there are multiple bugs. One is, that on bookworm, --merged-usr
--variant=buildd is creating a merged-/usr chroot. The other bug is that in
unstable, there is nothing in the debootstrap output which tells the user that
their bookworm buildd chroot will not be merged despite that flag.

We have to talk to more people to figure out how this is supposed to work...

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1079938: sbuild-createchroot creates unmerged /usr for bookworm by default

[Johannes Schauer Marin Rodrigues]

Hi Lee,

Quoting Chris Hofstaedtler (2024-08-29 02:33:26)
> Control: severity -1 normal
> 
> On Wed, Aug 28, 2024 at 08:35:06PM +0200, Lee Garrett wrote:
> > when creating a bookworm schroot e.g. with
> > sbuild-createchroot --merged-usr bookworm 
> > /var/lib/schroot/schroots/bookworm-amd64-sbuild 
> > http://localhost:3142/deb.debian.org/debian/
> > 
> > the resulting schroot has an unmerged /usr.
> 
> For bookworm, the expectation was (and is!) that builds are
> performed on unmerged chroots.
> 
> This was the only "supported" usecase for having an unmerged install on
> bookworm. And yes, upgrading these is not supported.

we talked in IRC #debian-devel and decided that this bug is actually a
documentation bug. I filed this MR against debootstrap:

https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/125

Do you think that this change addresses your concerns?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1079702: Both autopkgtest are flaky

[Johannes Schauer Marin Rodrigues]

Hi Jeremy,

Quoting Jeremy Bícha (2024-08-28 14:56:56)
> On Wed, Aug 28, 2024 at 8:51 AM Johannes Schauer Marin Rodrigues
>  wrote:
> > That would be odd because the autopkgtest runs just fine and reliable on 
> > salsa
> > ci. But I have to find a better way to automate testing of gtk4 applications
> > before I tackle this problem again. Taking screenshots via VNC and trying to
> > find buttons in them is not smart.
> 
> There is dogtail but I haven't really used it.

I have and it works great -- under Xorg. :)

In wayland, things are a bit more complicated because, as I understood it, the
fact that one application cannot find out the position of widgets in another is
a deliberate security feature. This makes automation hard but also hampers
accessibility. As far as I've read (I'm not a Gnome user) Gnome works around
this by having a daemon process always running in the background which is able
to negotiate widget position and content of all applications that are running
in a gnome session. But as far as I know, automating wayland applications is
just not a thing...

I assume the gtk software in Debian is stuck at Xorg for automation purposes?

> There is openqa.debian.net but I believe it's not currently connected to
> britney for blocking migration to Testing. It appears to only current support
> amd64 and arm64 which may be enough since that's where most of our users are.
> Since OpenQA also works with screenshots, it is susceptible to changes in
> fonts, themes, and text rendering although the threshold for how sensitive it
> is can be modified.

Yes, I've been in contact with Phil Hands on that topic and was already given a
quick introduction. According to Phil, running this on openqa.d.n is definitely
in scope of the service. I just have to learn how to interact with it now. :)

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1079702: autopkgtest 'test_without_chroot' is flaky

[Johannes Schauer Marin Rodrigues]

Quoting Jeremy Bícha (2024-08-27 22:26:39)
> gtk4 has more failing build tests than other architectures.
> Unfortunately, we are forced to ignore them because our understanding
> is that it's currently required for desktop tasks to be installable on
> all release architectures. (Or I guess someone could fix the bugs but
> that can be difficult.)

My next upload (today) will disable the autopkgtest of reform-setup-wizard and
should thus not be an issue anymore for you. Sorry for the inconvenience this
has caused you.

> If you have screenshots to demonstrate s390x breakage that may be gtk4's
> fault, please forward them to the Debian bugtracker for gtk4.

No, the bug is probably in the VNC server wayvnc which is serving me a
screenshot with the RGBA values in reverse making it look like this:
https://mister-muffin.de/p/O9dl.png Likely just a big-endian issue.

Thanks!

cheres, josch

signature.asc
Description: signature

Bug#1079702: Both autopkgtest are flaky

[Johannes Schauer Marin Rodrigues]

Quoting Reinhard Tartler (2024-08-28 13:43:30)
> Seems I made a mistake in my previous report. It is actually the test
> 'test_without_chroot' that is flaky. Also, I noticed this comment in
> https://sources.debian.org/src/reform-setup-wizard/1.0-11/debian/tests/control/#L7-L25:
> 
> # Since this test is skipped if it runs inside LXC because podman errors 
> out
> # when run under LXC, this test will never be used for migration checks, 
> so
> # we do not need to be rigorous here.
> #
> 
> 
> As it turns out, this test *is* currently holding up testing migration 
> of podman to testing.

I'm currently preparing a new upload which will disable the autopkgtests
altogether.

> Looking at the test logs, it seems it tries to start up Xwayland but the test
> runs without xwayland installed in the testbed? Maybe a matter of missing
> test dependencies?

That would be odd because the autopkgtest runs just fine and reliable on salsa
ci. But I have to find a better way to automate testing of gtk4 applications
before I tackle this problem again. Taking screenshots via VNC and trying to
find buttons in them is not smart.

> May I suggest to add at very least the restriction 'isolation-machine', and
> possibly 'flaky'?

No sense in spending CPU time on a flaky one.

Sorry for the inconvenience my package caused you.

cheers, josch

signature.asc
Description: signature

Bug#1077452: picolibc: FTBFS: make[1]: *** [debian/rules:134: override_dh_auto_test] Error 104

[Johannes Schauer Marin Rodrigues]

Control: clone -1 -2
Control: reassign -2 src:qemu 1:9.0.1+ds-1
Control: tags -2 =
Control: severity -2 important
Control: retitle -2 Regression: QEMU 9 makes picolibc FTBFS (failing tests)
Control: block -1 by -2

Hi,

On Mon, 29 Jul 2024 07:54:19 +0200 Lucas Nussbaum  wrote:
> Source: picolibc
> Version: 1.8.6-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240728 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.

it's qemu. I used debbisect to make sure of this:

$ DEBIAN_BISECT_SRCPKG=picolibc debbisect --cache=./cache 2024-02-26 2024-08-27 
/usr/share/doc/devscripts/examples/debbisect_buildsrc.sh
[...]
bisection finished successfully
  last good timestamp: 20240705T143429Z
  first bad timestamp: 20240705T203346Z
the following packages differ between the last good and first bad timestamp:
  qemu-system-arm 1:8.2.5+ds-2 -> 1:9.0.1+ds-1
  qemu-system-common 1:8.2.5+ds-2 -> 1:9.0.1+ds-1
  qemu-system-data 1:8.2.5+ds-2 -> 1:9.0.1+ds-1
  qemu-system-misc 1:8.2.5+ds-2 -> 1:9.0.1+ds-1

I unfortunately had to look into this because this FTBFS triggers the testing
autoremover for some of my packages (pico-sdk & picotool).

mjt, how would you track this down? Maybe pick one of the failing tests and use
it to bisect QEMU upstream between 8.2.5 and 9.0.1? Do you have a recipe to
"quickly" bisect QEMU for these situations?

Keith, how can I run just a single test of the picolibc testsuite? Can I
increase its verbosity? I'd also be very happy if you could take this from here
because my laptop is very weak and I ssh into a different machine to diagnose
this. Despite its name, picolibc compiles for many hours on my laptop without
an end in sight (so many tens of thousands of files o0). I don't even think
about compiling another large package like QEMU multiple times. :D

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1079292: libgtk-3-0t64: segfault in gdk_window_get_toplevel() crashes waybar when clicking any tray icon

[Johannes Schauer Marin Rodrigues]

Contorl: forwarded -1 https://gitlab.gnome.org/GNOME/gtk/-/issues/6958

Quoting Jeremy Bícha (2024-08-23 14:07:35)
> On Fri, Aug 23, 2024 at 3:30 AM Johannes Schauer Marin Rodrigues
>  wrote:
> > I now built four libgtk-3-0t64 packages. Each of them identical to what is
> > currently in unstable except, each of them has one of above four packages 
> > *not*
> > applied. I tried this in a vanilla Debian unstable system booted from 
> > SD-card
> > on my arm64 laptop and the only package where the bug did *not* surface was 
> > the
> > package that I built without
> > wayland-Add-support-for-v2-of-xdg_foreign-protocol.patch
> 
> Thank you! Are you able to do one more thing and report this issue upstream?
> 
> https://gitlab.gnome.org/GNOME/gtk/-/issues

Done.

signature.asc
Description: signature

Bug#1079292: libgtk-3-0t64: segfault in gdk_window_get_toplevel() crashes waybar when clicking any tray icon

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Johannes Schauer Marin Rodrigues (2024-08-22 18:43:31)
> Quoting Jeremy Bícha (2024-08-22 18:15:16)
> > On Thu, Aug 22, 2024 at 11:59 AM Johannes Schauer Marin Rodrigues
> >  wrote:
> > > Quoting Jeremy Bícha (2024-08-22 17:49:40)
> > > > On Thu, Aug 22, 2024 at 11:45 AM Johannes Schauer Marin Rodrigues
> > > >  wrote:
> > > > > Rebuilding src:gtk+3.0 with this patch fixes the issue:
> > > >
> > > > Thank you. I agree with bumping the severity. Do you have time to
> > > > bisect and figure out which specific patch is broken? This would be
> > > > very helpful upstream so that the problematic commit does not make it
> > > > into the next stable gtk3 release.
> > >
> > > I do not have a lot of time. Maybe we can share the work? If you have a 
> > > hunch
> > > which of the commits could be the likely culprit, I'll test out just 
> > > dropping
> > > that one. Bisecting six commits needs 3 tries anyways. :)
> > 
> > These 4 all do things with windows:
> > 
> > wayland-Add-support-for-v2-of-xdg_foreign-protocol.patch
> > Ensure-the-staging_cairo_surface-is-destroyed-before-re-a.patch
> > a11y-Use-non-empty-message-dialog-title-as-a11y-name.patch
> > immulticontext-Don-t-have-a-global_context_id.patch
> 
> thank you, that helps!

I now built four libgtk-3-0t64 packages. Each of them identical to what is
currently in unstable except, each of them has one of above four packages *not*
applied. I tried this in a vanilla Debian unstable system booted from SD-card
on my arm64 laptop and the only package where the bug did *not* surface was the
package that I built without
wayland-Add-support-for-v2-of-xdg_foreign-protocol.patch

I hope that helps!

cheers, josch

signature.asc
Description: signature

Bug#1079292: libgtk-3-0t64: segfault in gdk_window_get_toplevel() crashes waybar when clicking any tray icon

[Johannes Schauer Marin Rodrigues]

hi,

Quoting Jeremy Bícha (2024-08-22 18:15:16)
> On Thu, Aug 22, 2024 at 11:59 AM Johannes Schauer Marin Rodrigues
>  wrote:
> > Quoting Jeremy Bícha (2024-08-22 17:49:40)
> > > On Thu, Aug 22, 2024 at 11:45 AM Johannes Schauer Marin Rodrigues
> > >  wrote:
> > > > Rebuilding src:gtk+3.0 with this patch fixes the issue:
> > >
> > > Thank you. I agree with bumping the severity. Do you have time to
> > > bisect and figure out which specific patch is broken? This would be
> > > very helpful upstream so that the problematic commit does not make it
> > > into the next stable gtk3 release.
> >
> > I do not have a lot of time. Maybe we can share the work? If you have a 
> > hunch
> > which of the commits could be the likely culprit, I'll test out just 
> > dropping
> > that one. Bisecting six commits needs 3 tries anyways. :)
> 
> These 4 all do things with windows:
> 
> wayland-Add-support-for-v2-of-xdg_foreign-protocol.patch
> Ensure-the-staging_cairo_surface-is-destroyed-before-re-a.patch
> a11y-Use-non-empty-message-dialog-title-as-a11y-name.patch
> immulticontext-Don-t-have-a-global_context_id.patch

thank you, that helps!

> If you use sbuild, you can add --profiles=noudeb,nocheck to speed up the
> build for this case.

Thankhs, I'll add those. The build is not the problem but testing it is. I do
run Debian bookworm, so to test this, I'm using an SD-Card with Debian unstable
on it that I flash every time... XD

signature.asc
Description: signature

Bug#1079292: libgtk-3-0t64: segfault in gdk_window_get_toplevel() crashes waybar when clicking any tray icon

[Johannes Schauer Marin Rodrigues]

Quoting Jeremy Bícha (2024-08-22 17:49:40)
> On Thu, Aug 22, 2024 at 11:45 AM Johannes Schauer Marin Rodrigues
>  wrote:
> > Rebuilding src:gtk+3.0 with this patch fixes the issue:
> 
> Thank you. I agree with bumping the severity. Do you have time to
> bisect and figure out which specific patch is broken? This would be
> very helpful upstream so that the problematic commit does not make it
> into the next stable gtk3 release.

I do not have a lot of time. Maybe we can share the work? If you have a hunch
which of the commits could be the likely culprit, I'll test out just dropping
that one. Bisecting six commits needs 3 tries anyways. :)

signature.asc
Description: signature

Bug#1079332: reform-setup-wizard: upcoming rust-gtk4 update

[Johannes Schauer Marin Rodrigues]

Hi werdahias,

Quoting Matthias Geiger (2024-08-22 15:42:13)
> I intend to ship the latest upstream gtk-rs release (0.9) into unstable at
> some point in the next two weeks. Attached is a patch facilitating that.
> gtk-rs 0.9 is already available in experimental in case you want to try it.

thank you! Do you have any preference when I upload r-s-w with your patch? Feel
free to ping me whenever you'd like me to make that upload.

> I also noticed r-s-w does not Build-Depend on gdk-pixbuf; see second attached
> patch fixing this.

Thank you, I will apply it.

cheers, josch

signature.asc
Description: signature

Bug#1079292: libgtk-3-0t64: segfault in gdk_window_get_toplevel() crashes waybar when clicking any tray icon

[Johannes Schauer Marin Rodrigues]

Control: severity -1 serious

Hi,

I'm bumping severity because this bug breaks unrelated software on the system
and (if you are a waybar user) makes the system unusable unless you are a bit
more technically versed.

On Thu, 22 Aug 2024 12:44:36 +0200 "Lukas F. Hartmann"  wrote:
> Some of our MNT Reform aarch64 users (which runs unstable by default), and I,
> also on my amd64 PC, upgraded the libgtk-3-0t64 today. This renders tray icon
> functionality in waybar, a popular wayland task bar, unusable. Clicking any
> tray icon makes waybar crash and exit. Running waybar under gdb reveals a
> segfault in libgtk-3's gdk_window_get_toplevel():

Rebuilding src:gtk+3.0 with this patch fixes the issue:

--- gtk+3.0-3.24.43/debian/patches/series  2024-08-20 22:42:46.0 
+0200
+++ gtk+3.0-3.24.43/debian/patches/series  2024-08-22 12:35:57.0 
+0200
@@ -3,9 +3,3 @@
 060_ignore-random-icons.patch
 reftest_compare_surfaces-Report-how-much-the-images-diffe.patch
 reftests-Allow-minor-differences-to-be-tolerated.patch
-wayland-Add-support-for-v2-of-xdg_foreign-protocol.patch
-immulticontext-Don-t-have-a-global_context_id.patch
-Ensure-the-staging_cairo_surface-is-destroyed-before-re-a.patch
-gesture-set-widget-x-and-y-if-coordinate-translation-betw.patch
-a11y-Extract-helper-function-to-set-GtkMessageDialog-a11y.patch
-a11y-Use-non-empty-message-dialog-title-as-a11y-name.patch

It is thus likely that some of the patches that were cherry picked with the
last upload are responsible for this.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1078693: e2fsprogs: introduced a bootstrap dependency cycle with libarchive

[Johannes Schauer Marin Rodrigues]

Hi Helmut&Ted,

Quoting Helmut Grohne (2024-08-15 07:19:52)
> On Thu, Aug 15, 2024 at 12:14:52AM -0400, Theodore Ts'o wrote:
> > This only passes the "it builds, ship it!" test, but it appears that
> > it might be enough to replace
> 
> My message was primarily targeted at getting an agreement on the
> direction of a solution. As you imply that you are ok with this kind of
> solution, I guess Johannes will volunteer to supply a patch for detailed
> discussion.

please find a tested patch attached which is only little more than what was
provided by Ted already. I built this with and without nocheck. When built with
nocheck, libarchive-dev does not get installed and attempting to use the
resulting package will yield:

Copying files into the device: __populate_fs_from_tar: you need libarchive to
be able to process tarballs mke2fs: Operation not permitted while populating
file system

After installing libarchive13t64, I was able to create filesystems from
tarballs as usual. Building without nocheck, tests pass fine.

Does this look okay?

Thanks!

cheers, joschdiff -Nru e2fsprogs-1.47.1/debian/changelog e2fsprogs-1.47.1/debian/changelog
--- e2fsprogs-1.47.1/debian/changelog	2024-05-20 21:28:06.0 +0200
+++ e2fsprogs-1.47.1/debian/changelog	2024-08-21 11:40:08.0 +0200
@@ -1,3 +1,10 @@
+e2fsprogs (1.47.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Allow building without archive.h (Closes: #1078693)
+
+ -- Johannes Schauer Marin Rodrigues   Wed, 21 Aug 2024 11:40:08 +0200
+
 e2fsprogs (1.47.1-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru e2fsprogs-1.47.1/debian/control e2fsprogs-1.47.1/debian/control
--- e2fsprogs-1.47.1/debian/control	2024-05-20 21:28:06.0 +0200
+++ e2fsprogs-1.47.1/debian/control	2024-08-21 11:29:04.0 +0200
@@ -2,7 +2,7 @@
 Section: admin
 Priority: required
 Maintainer: Theodore Y. Ts'o 
-Build-Depends: dpkg-dev (>= 1.22.5), gettext, texinfo, pkgconf, libarchive-dev, libfuse3-dev [linux-any kfreebsd-any] , debhelper-compat (= 12), dh-exec, libblkid-dev, uuid-dev, m4, udev [linux-any], systemd [linux-any], systemd-dev [linux-any], cron [linux-any], dh-sequence-movetousr
+Build-Depends: dpkg-dev (>= 1.22.5), gettext, texinfo, pkgconf, libarchive-dev , libfuse3-dev [linux-any kfreebsd-any] , debhelper-compat (= 12), dh-exec, libblkid-dev, uuid-dev, m4, udev [linux-any], systemd [linux-any], systemd-dev [linux-any], cron [linux-any], dh-sequence-movetousr
 Rules-Requires-Root: no
 Standards-Version: 4.7.0
 Homepage: http://e2fsprogs.sourceforge.net
diff -Nru e2fsprogs-1.47.1/debian/.gitignore e2fsprogs-1.47.1/debian/.gitignore
--- e2fsprogs-1.47.1/debian/.gitignore	2024-05-20 21:28:06.0 +0200
+++ e2fsprogs-1.47.1/debian/.gitignore	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-!patches
diff -Nru e2fsprogs-1.47.1/debian/patches/bootstrap.patch e2fsprogs-1.47.1/debian/patches/bootstrap.patch
--- e2fsprogs-1.47.1/debian/patches/bootstrap.patch	1970-01-01 01:00:00.0 +0100
+++ e2fsprogs-1.47.1/debian/patches/bootstrap.patch	2024-08-21 11:40:08.0 +0200
@@ -0,0 +1,65 @@
+Description: Allow building without archive.h
+ Since src:libarchive build-depends on libext2fs-dev, a build dependency cycle
+ is created which breaks architecture bootstrap.
+ .
+ This patch allows building e2fsprogs even if archive.h is not present by
+ adding the necessary forward declarations, typedefs and preprocessor
+ definitions if archive.h was not found.
+Author: Theodore Y. Ts'o 
+Bug-Debian: https://bugs.debian.org/1078693
+
+--- a/misc/create_inode_libarchive.c
 b/misc/create_inode_libarchive.c
+@@ -18,15 +18,23 @@
+ #include "create_inode_libarchive.h"
+ #include "support/nls-enable.h"
+ 
+-#ifdef HAVE_ARCHIVE_H
+-
+ /* 64KiB is the minimum blksize to best minimize system call overhead. */
+ //#define COPY_FILE_BUFLEN 65536
+ //#define COPY_FILE_BUFLEN 1048576
+ #define COPY_FILE_BUFLEN 16777216
+ 
++#ifdef HAVE_ARCHIVE_H
+ #include 
+ #include 
++#else
++struct archive;
++struct archive_entry;
++#define	ARCHIVE_EOF	  1	/* Found end of archive. */
++#define	ARCHIVE_OK	  0	/* Operation was successful. */
++#include   /* ssize_t */
++typedef ssize_t la_ssize_t;
++#endif
++
+ #include 
+ #include 
+ 
+@@ -541,7 +549,6 @@ static errcode_t handle_entry(ext2_filsy
+ 	}
+ 	return 0;
+ }
+-#endif
+ 
+ errcode_t __populate_fs_from_tar(ext2_filsys fs, ext2_ino_t root_ino,
+  const char *source_tar, ext2_ino_t root,
+@@ -549,12 +556,6 @@ errcode_t __populate_fs_from_tar(ext2_fi
+  struct file_info *target,
+  struct fs_ops_callbacks *fs_callbacks)
+ {
+-#ifndef HAVE_ARCHIVE_H
+-	com_err(__func__, 0,
+-		_("you need to compile e2fsprogs with libarchive to "
+-		  "be able to process tarballs"));
+-	return 1;
+-#else
+ 	char *path2, *path3, *dir, *name;
+ 	unsigned int dir_exists;
+ 	struct archive *a;
+@@ -700,5 +7

Bug#1079193: RM: reform-setup-wizard [armel armhf mips64el ppc64el riscv64 s390x] -- ROM; only useful on desktop architectures

[Johannes Schauer Marin Rodrigues]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

please remove the binaries of my package reform-setup-wizard from armel,
armhf, mips64el, ppc64el, riscv64 and s390x. I have already spent too
many days and 10 uploads to unstable to make the package work reliably
on architectures that are either very slow, have no graphics support or
desktop. I rather give up on the architectures that this package will
never be used on anyways and spent my time elsewhere.

Thanks!

cheers, josch

Bug#1079192: ModuleNotFoundError: No module named 'jaraco'

[Johannes Schauer Marin Rodrigues]

Package: reprotest
Version: 0.7.27
Severity: normal

Hi,

reprotest failed on salsaci:

https://salsa.debian.org/reform-team/reform-handbook/-/jobs/6157681

last lines from the log:

Traceback (most recent call last):
  File "/usr/bin/reprotest", line 33, in 
sys.exit(load_entry_point('reprotest==0.7.27', 'console_scripts', 
'reprotest')())
 
^
  File "/usr/bin/reprotest", line 25, in importlib_load_entry_point
return next(matches).load()
   
  File "/usr/lib/python3.12/importlib/metadata/__init__.py", line 205, in load
module = import_module(match.group('module'))
 
  File "/usr/lib/python3.12/importlib/__init__.py", line 90, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1387, in _gcd_import
  File "", line 1360, in _find_and_load
  File "", line 1331, in _find_and_load_unlocked
  File "", line 935, in _load_unlocked
  File "", line 995, in exec_module
  File "", line 488, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 20, in 

import pkg_resources
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 96, in 

from jaraco.text import (
ModuleNotFoundError: No module named 'jaraco'


Thanks!

cheers, josch

Bug#1079022: kmod: symbol lookup error: /usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, version LIBKMOD_5

[Johannes Schauer Marin Rodrigues]

Hi Marco,

Quoting Marco d'Itri (2024-08-19 23:48:24)
> The quick and easy solution would be to rebuild dracut-install, but the 
> release team refused to binNMU it (#1079038).
> 
> The stupid solution would be to revert the change, and I will not do it
> because I do not want to diverge from upstream.
> 
> The elegant solution would be to keep for a while both symbols in the 
> library, but I am not good enough with ld(1) and could not actually 
> manage to do it myself.
> 
> The nuclear solution would be to make a new upload with "Breaks: 
> dracut-install (<= 103-1)", which at least would make libkmod2 not 
> installable until somebody will be forced to do a new sourceful upload 
> of dracut-install.
> 
> So I will wait for a while to see if anybody can help with #3, and if not
> then I will proceed with #4.

given that this issue can render our user's systems unbootable, could we have a
quick-and-dirty solution now rather than the proper solution in a few days?

You could upload kmod with an ugly version like
33+20240816-2~really32+20240611-1 and the contents of the last-working version
of kmod and then take all the time you need to implement the correct solution.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1079022: kmod: symbol lookup error: /usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, version LIBKMOD_5

[Johannes Schauer Marin Rodrigues]

Hi,

On Mon, 19 Aug 2024 14:13:39 -0400 =?utf-8?Q?Antoine_Beaupr=C3=A9?= 
 wrote:
> So bizarrely, I installed an image from snapshot:
> 
> https://snapshot.debian.org/archive/debian/20240813
> 
> and *that* worked. So maybe `testing` doesn't work as an install target
> for that build script. Anyway.
> 
> So I confirm that kmod 32+20240611-1 doesn't have that issue, perhaps we
> should just upload that back to unstable until we figure out a fix? :)

we are building bootable system images for the MNT Reform open hardware laptop.
Since this is breaking our images and since this bug is still open, let me also
confirm here as well that using these two packages from snapshot.d.o prevents
the issue from happening:

wget 
http://snapshot.debian.org/archive/debian/20240612T203258Z/pool/main/k/kmod/libkmod2_32%2B20240611-1_arm64.deb
wget 
http://snapshot.debian.org/archive/debian/20240612T203258Z/pool/main/k/kmod/kmod_32%2B20240611-1_arm64.deb

Maybe this information (downgrading to the packages above) helps somebody who
is affected by this to make their system bootable again.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1079047: ITP: reform-handbook -- MNT Reform Operator Handbook

[Johannes Schauer Marin Rodrigues]

Package: wnpp
Severity: wishlist
Owner: Johannes Schauer Marin Rodrigues 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: reform-handbook
  Version : 2024-08-19
  Upstream Contact: Lukas F. Hartmann 
* URL : https://source.mnt.re/reform/reform-handbook/
* License : GPL-3+ and CC-BY-SA-4.0 and CERN-OHL-S-2.0
  Programming Lang: LaTeX
  Description : MNT Reform Operator Handbook

The HTML and PDF version of the operator handbook for the MNT Reform open
hardware laptop. It contains topics like:

 - Linux basics (terminal, shell, filesystem, managing software with apt)
 - the graphical desktops sway and wayfire with waybar
 - MNT Reform specific software and scripts
 - the hardware (case, motherboard, processor modules, keyboard, trackball,
   trackpad, battery packs)
 - advanced topics (serial via uart, u-boot)
 - hardware schematics and bill of materials

Bug#1078871: some backlog from #1076952 (installer: reserve first 16 MiB space in default recipes for ARM devices?)

[Johannes Schauer Marin Rodrigues]

On Sat, 17 Aug 2024 13:00:36 +0200 Holger Wansing  wrote:
> Pascal Hambourg  wrote:
> > 16 MB (~15.3 MiB) or 16 MiB (~16.8 MB) ?
> > In partman, 1 MB really means 10^6 bytes, not 1 MiB (2^20 bytes).
> 
> I think I've actually tried both and IIRC that didn't make a difference.

for the MNT Reform we recently bumped the start of the first partition to be at
16777216 (16 MiB), i.e. in our scripts we run:

/sbin/parted -s "$SYSIMAGE.img" "mkpart primary ext4 16MiB ..."

For the longest time, our offset for the first partition was at 4194304 bytes
but since there is now the rk3588 module that we want to support, this had to
be bumped quite a bit. Initially we had it at 12 MiB (which worked fine) but
after having read https://opensource.rock-chips.com/wiki_Partitions this now
became 16 MiB just to be on the safe-side (no idea how the user will be
repurposing their system) and because 4 MiB extra do not add much in the grand
scheme of things...

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1078506: reform-setup-wizard: autopkgtest that requires podman should install netavark

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Reinhard Tartler (2024-08-11 17:25:00)
> while looking at
> https://ci.debian.net/packages/r/reform-setup-wizard/unstable/arm64/50343230/ 
> I
> noticed that your package is using podman to run an autopkgtest:
> 
> https://sources.debian.org/src/reform-setup-wizard/1.0-7/debian/tests/control/#L1-L20
> 
> that's awesome!
> 
> However, the test above fails with:
> 
> 
> 120s + rm wayvnc.conf swayvnc.sh
> 120s + podman rmi -f swayvnc
> 120s Error: could not find "netavark" in one of [/usr/local/libexec/podman 
> /usr/local/lib/podman /usr/libexec/podman /usr/lib/podman].  To resolve this 
> error, set the helper_binaries_dir key in the `[engine]` section of 
> containers.conf to the directory containing your helper binaries.
> 
> 
> Please don't fail on this podman invocation or depend on the 'netavark' 
> package
> which is required for rootful podman. For rootless podman, you'll need to
> depend on the 'passt' package for getting networking setup.

thank you for having look at my silly little package! How did you come across
this failure? I hope this did not block anything for you? Thanks for filing
this bug!

I'm a complete podman-noop, so I'm happy that you are chiming in. Pulling in
the netavark package is easy but I wonder if this is a new behaviour? If you
look at other CI results on arm64, then it did succeed in the past and I why
that is if the test is missing a dependency:

https://ci.debian.net/packages/r/reform-setup-wizard/unstable/arm64/

I'm actually not so sure whether I want to keep having this autopkgtest in the
first place. The functionality of this package should maybe rather get checked
by openqa.debian.net because trying to find buttons on screenshots is very
fragile and there is a nasty big-endian bug hidden in my code which shows on
s390x.

Of course even better than scanning screenshots would be to use something like
dogtail but alas, automating interaction with gtk applications seems to be
non-functional under wayland because of intentional wayland design choices...

Anyways, I'll be helpful for any input you can give.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1077827: even with [[featureset]] name = 'rt' enable = false in config.local/defines.toml, linux-headers-*-common-rt is still getting built

[Johannes Schauer Marin Rodrigues]

Quoting Bastian Blank (2024-08-07 21:31:57)
> On Sat, Aug 03, 2024 at 01:52:47AM +0200, Johannes Schauer Marin Rodrigues 
> wrote:
> > according to Ben [1] this should disable the rt build and it mostly does but
> > the package linux-headers-*-common-rt will still be built.
> 
> No bug in Debian, as we don't push this modification to Debian.  But
> fixed in https://salsa.debian.org/kernel-team/linux/-/merge_requests/1154

Thank you! <3

signature.asc
Description: signature

Bug#1073926: clapper 0.5.2 built against 1.24 doesn't play videos on PinePhone and Librem 5

[Johannes Schauer Marin Rodrigues]

Quoting Andrey Skvortsov (2024-08-05 12:26:15)
> Thanks, clapper 0.6 plays video on OG PP and Librem 5 now, when
> GST_CLAPPER_USE_PLAYBIN3=1 is set.
> 
> Previous clapper versions had tweak settings for this, but it was
> removed in 0.6. See https://github.com/Rafostar/clapper/issues/464
> I've set 'export GST_CLAPPER_USE_PLAYBIN3=1' in ~/.profile.

Thank you for your feedback! Glad to hear it works again for you. :)

signature.asc
Description: signature

Bug#1077922: regression: `debian/rules debian/control-real` results in: TypeError: 'BinaryPackage' object is not subscriptable

[Johannes Schauer Marin Rodrigues]

Source: linux
Version: 6.10-1~exp1
Severity: normal

Hi,

in our Debian packaging for the MNT Reform hardware family we add a
`debian/templates/extra.control.in` which you can see at the end of this
email. Since version 6.10-1~exp1 in experimental, running `debian/rules
debian/control-real` results in the following backtrace:

PYTHONHASHSEED=0 debian/bin/gencontrol.py
Traceback (most recent call last):
  File "/home/josch/deb/linux/debian/bin/gencontrol.py", line 645, in 
Gencontrol()()
  File "/home/josch/deb/linux/debian/bin/debian_linux/gencontrol.py", line 386, 
in __call__
self.do_extra()
  File "/home/josch/deb/linux/debian/bin/debian_linux/gencontrol.py", line 457, 
in do_extra
arches = package['Architecture']
 ~~~
TypeError: 'BinaryPackage' object is not subscriptable
make: *** [debian/rules:149: debian/control-real] Error 1

Bisecting the Debian linux git reveals that this is due to commit
1f3a3d27318a99feef7ffcdb4e302d164250af64 and "git tag --contains" confirms that
this commit first appeared in `debian/6.10-1_exp1`.

Maybe this is intentional and I have to change something in my
`extra.control.in` or maybe this is a regression?

Thanks!

cheers, josch




Package: linux-image-arm64
Architecture: arm64
Meta-Rules-Target: meta
Build-Profiles: 
Depends: linux-image-mnt-reform-arm64 (= ${binary:Version}), ${misc:Depends}
Section: oldlibs
Description: Linux for 64-bit ARMv8 machines (MNT Reform) (meta-meta-package)
 This meta-meta-package depends on the linux-image-mnt-reform-arm64
 meta-package for use on MNT Reform 2, MNT Pocket Reform and Reform Next to
 ensure a smooth transition after changing the kernel flavour name in 6.8.9.
 .
 This is an empty transitional package and can be safely removed as its
 functionality is provided by the linux-image-mnt-reform-arm64 package instead.

Package: linux-headers-arm64
Architecture: arm64
Meta-Rules-Target: meta
Build-Profiles: 
Depends: linux-headers-mnt-reform-arm64 (= ${binary:Version}), ${misc:Depends}
Section: oldlibs
Description: Linux for 64-bit ARMv8 machines (MNT Reform) (meta-meta-package)
 This meta-meta-package depends on the linux-headers-mnt-reform-arm64
 meta-package for use on MNT Reform 2, MNT Pocket Reform and Reform Next to
 ensure a smooth transition after changing the kernel flavour name in 6.8.9.
 .
 This is an empty transitional package and can be safely removed as its
 functionality is provided by the linux-headers-mnt-reform-arm64 package
 instead.

Bug#1077827: even with [[featureset]] name = 'rt' enable = false in config.local/defines.toml, linux-headers-*-common-rt is still getting built

[Johannes Schauer Marin Rodrigues]

Source: linux
Severity: normal

Hi,

steps to reproduce:

cat << END >> debian/config.local/defines.toml
[[featureset]]
name = 'rt'
enable = false
END

according to Ben [1] this should disable the rt build and it mostly does but
the package linux-headers-*-common-rt will still be built.

[1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/957#note_507817


Thanks!

cheers, josch

Bug#1077812: clapper: Please split library and development files to separate packages

[Johannes Schauer Marin Rodrigues]

Control: severity -1 important

Hi,

Quoting Arnaud Ferraris (2024-08-02 22:24:09)
> It's not strictly "breaking" anything, but I'm packaging tuba[1] which 
> is now built against libclapper, and I'd appreciate if this package could:
> * build-depend only on libclapper-dev (or whatever) rather than the 
> whole clapper package
> * depend only on libclapper rather than all of clapper
> * not have to explicitly build-depend on libclapper-dev's dependencies; 
> this is somehow orthogonal to the split, but without the split those 
> should be made dependencies of clapper itself, which is clearly 
> suboptimal (no need for a mere video player to pull a whole bunch of 
> gstreamer development files)
> 
> This would bring a (admittedly minor) improvement to bandwidth usage for 
> buildds and disk usage for users, not mentioning the fact that it aligns 
> with current practice in Debian.

you do not need to convince me with more than "tuba needs it". ;)

For the most of its existance, libclapper was only an internal implementation
which was not supposed to be used by others. This changed with the recent (2
weeks ago) upload of clapper 0.6. Since then, libclapper is supposed to be used
by others with the caveat that its API is still not deemed to be stable. Thus,
I did not yet split up the packaging into clapper and libclapper-dev with my
upload 2 weeks ago and was waiting if somebody even would need it because if
that's not the case, why bother FTP master and increase the package count in
the archive?

Now that tuba needs it, the split has to be done. If you want it be done
faster, feel free to submit a patch either via the BTS or as a MR against the
clapper packaging repository.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1077812: clapper: Please split library and development files to separate packages

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Arnaud Ferraris (2024-08-02 18:36:23)
> The current "clapper" package includes not only the software and its data
> files, but also several shared libraries, gobject-introspection data and
> development files (C headers, pkg-config files...).
> 
> This implies any software linked against libclapper, for example, will have to
> depend on the full "clapper" package instead of just the library. Likewise, 
> any
> user of this software will also have all the development files installed, 
> which
> are only necessary for actually developing with libclapper.
> 
> Additionally, the development files also need the development files for
> gstreamer-plugins-base and several other libs, which should therefore be
> dependencies for this package.
> 
> Could you please split this package so the shared libraries, development files
> and gobject-introspection data are all shipped in separate packages?

is this a request out of necessity? Is the current packaging breaking something
for you?

Thanks!

cheers, josch

signature.asc
Description: signature

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

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Simon McVittie (2024-08-01 11:22:39)
> > I recently encountered the following packages that would fail to install
> > their Build-Depends due to choosing a host architecture Python interpreter
> > and failing its postinst: [29 packages]
> 
> That's not actually all that many. I wonder whether it would be pragmatic
> to add python3:native to their B-D and move on?
> 
> Or teach crossqa or sbuild to always --add-depends=python3:native when
> cross-building? In the worst case scenario that's adding python3 when
> it isn't actually needed, but increasingly many packages use Meson which
> pulls in python3 anyway, so maybe that's not so bad?

no, this would be very wrong. I think it is really important to keep the set of
build dependencies that gets installed minimal. I was putting quite a bit of
work to getting the set of packages in the buildd variant reduced to just
essenital plus build-essential plus apt. I'd very much dislike adding python or
other culprits to the list. Even when we say "but it's just for cross
compiling" that makes it even worse in my eyes. We should *reduce* the
special-casing for cross compilation and not add to it.

But I might be persuaded to extend /usr/lib/apt/solvers/sbuild-cross-resolver
to carry an allow-list of packages which need to be installed in their native
variant. That script already takes care to install M-A:foreign packages in
their native architecture. Maybe more packages just need to be added to this
special handling?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1077600: mmdebstrap: Breaks with gpg-from-sq which does not implement --update-trustdb

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Blair Noctis (2024-07-30 12:55:39)
> With gpg-from-sq installed, which diverts gnupg and links
> sequoia-chameleon-gnupg as /usr/bin/gpg, which did not implement
> --update-trustdb yet, mmdebstrap breaks:
> 
> > I: automatically chosen mode: unshare
> > I: chroot architecture amd64 is equal to the host's architecture
> > gpg: The command --update-trustdb is not yet implemented in the Sequoia
> > gpg: Chameleon.  To help us prioritize our work, please file a bug at
> > gpg:   https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues
> > E: gpg failed to initialize trustdb:: 512
> 
> Reading its source, mmdebstrap seems to call gpg with --update-trustdb
> unconditionally. It seems unnecessary and fragile to add a check, is it 
> possible
> to maybe add a customization that disables it? Thanks.

this part of the mmdebstrap codebase is very ugly and caters for a lot of the
idiosyncrasies of gpg. Ideally, mmdebstrap shouldn't even be doing any of that.
Ideally, I'd remove all of that code and replace it with something that more
reliably and without using gpg at all is able to map a Debian suite to a
keyring filename. Are you interested in working on that and submit a patch?

Until then, a simple workaround is to run mmdebstrap with
--skip=check/signed-by

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1077486: ITP: fonts-iosevka-term -- Versatile typeface for code, from code

[Johannes Schauer Marin Rodrigues]

Package: wnpp
Severity: wishlist
Owner: Johannes Schauer Marin Rodrigues 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-fo...@lists.debian.org

* Package name: fonts-iosevka-term
  Version : 31.0.0
  Upstream Contact: Renzhi Li aka. Belleve Invis 
* URL : https://github.com/be5invis/Iosevka
* License : OFL-1.1
  Programming Lang: TTF
  Description : Versatile typeface for code, from code

Iosevka [ˌjɔˈseβ.kʰa] is an open-source, sans-serif + slab-serif, monospace +
quasi‑proportional typeface family, designed for writing code, using in
terminals, and preparing technical documents.

This package provides the "Term" subfamily of Iosevka as ttf.

This is a dependency of the reform-tools package used by MNT for the Reform
family of open hardware computers.

Bug#1076932: webdis: FTBFS: src/client.h:6:10: fatal error: http_parser.h: No such file or directory

[Johannes Schauer Marin Rodrigues]

Hi James,

Quoting James McCoy (2024-07-26 19:48:52)
> Nothing has changed in the packaging since it last successfully built, so I
> used debbisect to narrow down the problem to the dpkg 1.22.7 upload.

you are now (to my knowledge) the second user of debbisect. Could you share
your debbisect invocation? I'm interested in hearing how others are using it to
potentially improve on its interface.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#973995: ITP: fonts-iosevka -- Slender typeface for code, from code

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Johannes Schauer Marin Rodrigues (2024-07-26 07:50:59)
> I'm interested in seeing this packaged and archive.org shows that on
> phd-sid.ethz.ch there used to be a dsc. So you already made considerable
> progress with packaging this? Unfortunately the URL is 404 now. Can you share
> your current state of packaging iosevka?

thank you for restoring the link. It seems that right now the packaging
requires verda to be packaged. Did you already look into that?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#973995: ITP: fonts-iosevka -- Slender typeface for code, from code

[Johannes Schauer Marin Rodrigues]

Hi,

On Sun, 08 Nov 2020 19:36:06 +0100 =?UTF-8?Q?G=C3=BCrkan_Myczko?= 
 wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: fonts-iosevka
>Version : 3.71
>Upstream Authors: Belleve Invis 
> * URL : https://github.com/be5invis/Iosevka
> * License : OFL-1.1
>Description : Slender typeface for code, from code
>   This typeface contains 9 weights (Thin to Heavy) alongside with both 
> italic
>   and oblique versions, with the same metrics as the regular one.
> 
> Package will be available at 
> http://phd-sid.ethz.ch/debian/fonts-iosevka/
> and also at mentors.debian.net (ITP to follow) and fonts team maintained

I'm interested in seeing this packaged and archive.org shows that on
phd-sid.ethz.ch there used to be a dsc. So you already made considerable
progress with packaging this? Unfortunately the URL is 404 now. Can you share
your current state of packaging iosevka?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1076620: RM: vcmi [armel] -- ROM; armel needs constant patching

[Johannes Schauer Marin Rodrigues]

Quoting Alexandre Detiste (2024-07-19 23:29:36)
> Le ven. 19 juil. 2024 à 23:21, Johannes Schauer Marin Rodrigues
>  a écrit :
> > I'm a bit surprised by this. I have maintained vcmi in Debian since 2014. 
> > You
> > just did your first upload of the package and when you encountered a build
> > failure instead of fixing it you immediately give up and request for 
> > removal of
> > the package on that architecture?
> I have a lot of stale half done packages here ... I feel a bit
> overwhelmed, I try to catch up.
> I need more reflection.
> I now have set the "more info" tag on this bug.
> 
> > Or was there some other discussion about this build failure that I wasn't 
> > aware of?
> Could this fix be upstreamed ?

Would it be okay for you if I patch the package again so that it builds on
armel and once that works I make another attempt to get this accepted upstream?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1076620: RM: vcmi [armel] -- ROM; armel needs constant patching

[Johannes Schauer Marin Rodrigues]

Hi Alexandre,

Quoting Alexandre Detiste (2024-07-19 22:51:42)
> Package: ftp.debian.org
> Severity: normal
> X-Debbugs-Cc: v...@packages.debian.org, Johannes 'josch' Schauer 
> 
> Control: affects -1 + src:vcmi
> User: ftp.debian@packages.debian.org
> Usertags: remove
> 
> Dear FTP Masters,
> 
> Please remove the armel binary for vcmi.

I'm a bit surprised by this. I have maintained vcmi in Debian since 2014. You
just did your first upload of the package and when you encountered a build
failure instead of fixing it you immediately give up and request for removal of
the package on that architecture?

Or was there some other discussion about this build failure that I wasn't aware
of?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1076501: rename binary package to bmaptool

[Johannes Schauer Marin Rodrigues]

Source: bmap-tools
Severity: normal
Tags: patch

Hi,

this is a follow-up of #1032062. The same arguments apply:

 - bmap-tools with a hyphen contains a tool without a hyphen
 - bmap-tools is plural but only contains a single tool
 - upstream changed to yoctoproject and even calls the project bmaptool

I'm not suggesting to rename the source package. But when working with
bmaptool and even while writing this email I always keep asking myself
and end up checking to make sure whether the binary name or the package
name was the one with the hyphen or the one with plural "s" at the end.

All this confusion could end by naming the binary package after the tool
it contains and following the naming of the new upstream at the same
time.

Here is a patch. I would create a MR on salsa but you still didn't push
the recent 3.8 upload. :)

--- a/debian/control
+++ b/debian/control
@@ -20,7 +20,18 @@ Rules-Requires-Root: no
 Homepage: https://github.com/intel/bmap-tools
 
 Package: bmap-tools
+Depends: bmaptool, ${misc:Depends}
 Architecture: all
+Priority: optional
+Section: oldlibs
+Description: transitional package
+ This is a transitional package. It can safely be removed.
+
+Package: bmaptool
+Architecture: all
+Replaces: bmap-tools (<< 1.8)
+Breaks: bmap-tools (<< 1.8)
+Provides: bmap-tools
 Depends:
  python3,
  python3-six,
@@ -36,8 +47,6 @@ Suggests:
  pigz,
  python3-gpg,
  unzip,
-Provides:
- bmaptool (= ${binary:Version}),
 Description: tool to flash image files to block devices using the block map
  bmaptool is a generic tool for creating the block map (bmap) for a
  file, and copying files using the block map. The idea is that large



There is one package that Depends and one package that Recommends bmap-tools. I
can take care of fixing these two if you agree with the rename.

Thanks!

cheers, josch

Bug#1076476: mmdebstrap-autopkgtest-build-qemu asks to install libarchive13, but should ask for libarchive13t64

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Francesco Poli (wintermute) (2024-07-16 23:58:53)
> I tried to run mmdebstrap-autopkgtest-build-qemu, but now it fails:
> 
>   $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
>--size=25G --boot=efi sid unstable-autopkgtest-amd64.img
>   please install libarchive13
> 
> I already had that package on my system, except that, due to the
> t64 transition, it is now called 'libarchive13t64':
> 
>   $ aptitude search libarchive13
>   v   libarchive13-
>   i A libarchive13t64 - Multi-format archive [...]
> 
> and it only provides 'libarchive13' as a virtual package...
> 
> [t64]: 
> 
> I think the check at line 283 of mmdebstrap-autopkgtest-build-qemu
> should be changed from:
> 
>   for pkg in autopkgtest dosfstools e2fsprogs fdisk mount mtools passwd 
> uidmap libarchive13; do
>   test_installed "$pkg"
>   done
> 
> to the following:
> 
>   for pkg in autopkgtest dosfstools e2fsprogs fdisk mount mtools passwd 
> uidmap libarchive13t64; do
>   test_installed "$pkg"
>   done

no. With that change, mmdebstrap-autopkgtest-build-qemu will no longer work on
systems without libarchive13t64.

> Is there a better strategy (that doesn't force you to modify that line in
> mmdebstrap-autopkgtest-build-qemu each time an ABI transition happens
> in src:libarchive ) ?

This was not an ABI transition from libarchive but an artificial one from
Debian. The last time libarchive bumped the SONAME was a decade ago.

The proper fix is this:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/98b3c7f2cdeb42c0fdf71bef28423cded83b7516

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code

[Johannes Schauer Marin Rodrigues]

Hi Jonas,

Quoting Jonas Smedegaard (2024-07-11 18:06:21)
> Package: wnpp
> Severity: wishlist
> Owner: Jonas Smedegaard 
> X-Debbugs-Cc: debian-de...@lists.debian.org, build-common team 
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> * Package name: dh-rust
>   Version : 0.0.1
>   Upstream Contact: build-common team 
> * URL : https://salsa.debian.org/build-common-team/dh-rust
> * License : GPL-3+
>   Programming Lang: Perl
>   Description : debhelper buildsystem for Rust code
> 
>  dh-rust provides a debhelper buildsystem to build Rust code.
>  .
>  This builds and tests binaries and libraries from rust crates,
>  the latter installed as source code below /usr/share/cargo/registry.
>  .
>  Feature highlights, compared to dh-cargo:
>   * supports workspace (i.e. multi-crate project)
>   * allows overriding CARGO_HOME
>   * installs crate contents using "cargo package"
>   * can use debian/Cargo.lock or Cargo.lock during build
>   * uses crates below debian/vendorlibs when available
>   * builds in make target dh_auto_build (not dh_auto_test)

I'm still left a bit puzzled concerning who the target audience for dh-rust is
supposed to be. From the description I infer that I should probably switch the
following two packages to dh-rust?

https://tracker.debian.org/media/packages/t/tuigreet/rules-0.8.0-4
https://tracker.debian.org/media/packages/r/reform-setup-wizard/rules-1.0-7

Or am I misunderstanding the purpose of it?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1073926: clapper 0.5.2 built against 1.24 doesn't play videos on PinePhone and Librem 5

[Johannes Schauer Marin Rodrigues]

Hi Anrey,

Quoting Andrey Skvortsov (2024-06-27 20:59:40)
> On 24-06-20 13:08, Johannes Schauer Marin Rodrigues wrote: the problem
> appeared in 1.24.1 and wasn't on 1.24.0. 1.24.1 introduced DMA_DRM caps
> support for v4l2codecs and clapper gstreamer sink doesn't support it.
> 
> I think in 0.6 it's handled by following commit:
> https://github.com/Rafostar/clapper/commit/681da9e2f39fd5180317113e7349272586ae645d

I uploaded clapper 0.6 to unstable. Can you confirm that it fixes the problems
you saw?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1075986: ITP: rotatepdf -- A simple utility to rotate PDF documents.

[Johannes Schauer Marin Rodrigues]

Quoting Joseph Warner (2024-07-09 03:03:07)
> Rotate PDF files in place. Rotatepdf is a wrapper around PDFtk.
> Terminal usage and several GUI-based file managers are supported.
> 
> Why?
> Provide a simpler method to rotate entire PDF files than PDFtk itslef, which
> is very powerful but extremely complicated for such a simple use case.

Great idea! How about you also file ITPs for catpdf, shufflepdf, burstpdf,
stamppdf and so on? You see the problem?

A tool with 10 functionalities does not become simpler by splitting it into 10
tools. Now instead of learning how to use one tool, the user has to learn how
to use 10 tools. If pdftk is too complicated, maybe work on providing
documentation to make it easier for users to figure out how to use it. In case
of pdftk, the man page has these entries:

   Rotate the first PDF page to 90 degrees clockwise
 pdftk in.pdf cat 1east 2-end output out.pdf

   Rotate an entire PDF document to 180 degrees
 pdftk in.pdf cat 1-endsouth output out.pdf

What is the problem with that?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1075871: /usr/bin/sbuild-createchroot: sbuild-createchroot takes toooooooo long with --include=gpg

[Johannes Schauer Marin Rodrigues]

Hi Charles,

Quoting Carlos Henrique Lima Melara (2024-07-07 00:07:03)
> I'm CC'ing 1075871, but if you you're the only maintainer I can add -quiet.
> Just let me know.

I think it's better to have all bug communication in public even though it's
unlikely that any of the other sbuild contributors replies here. I don't know
if people like Jochen or Christian are subscribed to the bug mails.

> Yes, it's a thin wrapper (I think, don't speak perl, sorry). But the
> problem is the last step where it chroot (plain chroot, nothing fancy)
> to do an apt update. There it just invoke chroot but don't mount /proc
> inside the chroor and then this triggers the fallback behaviour of
> gpg-agent (exhaustively closing fds on a fork). It's the following
> section of sbuild-createchroot that do the update [1]:
> 
> if (!$conf->get('SETUP_ONLY') || !$conf->get('MAKE_SBUILD_TARBALL')) {
> # FIXME: also update packages with the unshare backend
> if ($conf->get('ARCH') eq $conf->get('HOST_ARCH') && 
> $conf->get('CHROOT_MODE') ne 'unshare') {
> my $session = Sbuild::ChrootPlain->new($conf, $target);
> my $host = Sbuild::ChrootRoot->new($conf);
> if (defined($session)) {
> $session->set('Log Stream', \*STDOUT);
> 
> if (!$session->begin_session() || !$host->begin_session()) {
> print STDERR "E: Error creating chroot session: skipping apt 
> update\n";
> } else {
> my $resolver = Sbuild::AptResolver->new($conf, $session, 
> $host);
> $resolver->setup();
> 
> In sbuild-update, it begins a new schroot source session with sbuild -
> and here sbuild/schroot mounts /proc so gpg-agent use it to only close
> the open fds. That's the main difference between sbuild-update and
> sbuild-createchroot's update step.

Ah, you are right. Even though I find it very odd that gpg chose to de-facto
require mounted /proc to operate, I think this code path would benefit from
having a bit more of a setup so that processes run inside the chroot can feel a
bit more like home.

> > Also, why are you using sbuild-createchroot? Are you trying to set up the
> > initial schroot configuration?
> 
> Yes, to create a schroot to use with sbuild. Mainly as a convenience
> script instead of using debootstrap.

Good. That's its intended use.

I am not using the schroot backend and when I did in the past, I used it
exclusively with tarballs. You seem to be creating directory-based chroots for
schroot. This is nothing that I am using in my daily sbuild usage, which
probably explains why I'm not running into bugs like these.

If you can supply a patch that does the right thing, that'd make me very happy.
As I'm not using schroot anymore, my motivation to fix this is low but it'll be
put on the TODO list.

For anybody having a go at fixing the issue, maybe it would be best to use the
ChrootUnshare backend for $session instead of ChrootPlain. The code is run as
the superuser anyways.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1075871: /usr/bin/sbuild-createchroot: sbuild-createchroot takes toooooooo long with --include=gpg

[Johannes Schauer Marin Rodrigues]

Hi Charles (Carlos?),

Quoting Carlos Henrique Lima Melara (2024-07-06 22:34:45)
> I was creating some chroots this past month and noticed it was taking
> too long in the last step which is the update step. After a pretty
> intense debugging session with sergiodj, we were able to pin down the
> problem to a interaction between 3 things. Including gpg in the chroot,
> the bump in the max number of file descriptors and this update step only
> doing a chroot without mounting /proc - and not using sbuild-update,
> which does not show this bahaviour.
> 
> It basically boils down to gpg-agent trying to close all the possible
> file descriptors when it's running. This happens because this is the
> fallback behaviour when /proc is not mounted. When it is mounted, it
> just closes what is showed in /proc//fd/. This always happened, but
> with the increase of the max number of fds [1], it's really taking a
> lng time to finish sbuild-createchroot.

this sounds like a bug but how is it a bug in sbuild-createchroot? The tool is
just a very thin wrapper around debootstrap and the issue will also appear in
debootstrap, no?

Also, why are you using sbuild-createchroot? Are you trying to set up the
initial schroot configuration?

Why is this not a bug in gpg-agent?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1071861: plakativ: prepare for next python3-fitz version

[Johannes Schauer Marin Rodrigues]

Quoting Bastian Germann (2024-06-26 19:36:05)
> Control: retitle -1 plakativ: autopkgtest fails with python3-fitz 1.24.x
> Control: severity -1 serious
> 
> Now the pymupdf version has been updated.

Thank you!

Unfortunately, with the changes and the new version I now get a segmentation
fault in the tests:

https://ci.debian.net/packages/p/plakativ/testing/amd64/48338176/

I didn't look into this yet.

signature.asc
Description: signature

Bug#1074111: [arm64] boot stops at 'Starting kernel ...' without any further output when kernel built with recent binutils

[Johannes Schauer Marin Rodrigues]

Source: linux
Version: 6.9.2-1~exp1
Severity: serious

Hi,

to reproduce this locally, on arm64, run the following:

$ debvm-create -- --include=linux-image-generic/experimental "deb 
http://deb.debian.org/debian unstable main" "deb http://deb.debian.org/debian 
experimental main"
$ debvm-run

The debvm-run output will stop at the point where it starts qemu and then print
nothing.  It works fine with kernel 6.8 in unstable.

Now comes my naive attempt to figure out what triggered this regression. Please
bear in mind that I'm far from an expert on this topic.

We observed this problem when we built the linux kernel for the MNT Reform
which is the Debian linux kernel plus some additional patches. Compiling the
same kernel version 6.8.12 in *unstable* within a more recent build environment
results in a vmlinuz that just prints on boot:

Starting kernel ...

And then nothing else. Since neither the linux sources in debian unstable
changed, nor our patch stack changed between these rebuilds, the culprit is
likely in the build environment. Kernel 6.9 from experimental exhibits the same
problems. We also observed that copying the vmlinuz from an earlier build in
the good chroot environment made the system boot fine again. We also observed
how the good vmlinuz has a size of 31M and the bad vmlinuz a size of only 26M.
This is with the same sources, just different build chroot environment. An
old-enough build environment can be constructed using snapshot.d.o.

One of the differences in the build environment between good and bad builds is
binutils-arm-linux-gnueabihf with version 2.42-4 in the good environment and
version 2.42.50.20240618-1 in the bad environment. To test whether this indeed
triggers the problem, we tested building our kernel with current unstable but
with binutils (= 2.42-4) and gcc-13 (= 13.2.0-25). We also have to choose an
older gcc from snapshot.d.o because recent gcc-13 requires recent binutils.
This makes the kernel work again.

So, given that the problem affects linux in unstable *if* built with a more
recent build environment, the problem might not be in src:linux but elsewhere
(maybe binutils or gcc-13). I'm still filing it here as I lack the skills to
investigate this problem further. Since the issue shows up with qemu, I'm sure
that you can get to the bottom of it and can re-assign this bug to the package
to which it belongs.

Gratitude is due to Chris Hofstaedtler who convinced me that maybe this is a
problem even with vanilla Debian kernel and not only with the Debian kernel
with our patches on top.

Thanks!

cheers, josch

Bug#1073991: ezurio-qcacld-2.0-dkms: module fails to build for Linux 6.9: wlan_hdd_hostapd.c:1574:9: error: too many arguments to function 'cfg80211_ch_switch_notify'

[Johannes Schauer Marin Rodrigues]

Control: severity -1 serious

Hi Andreas,

Quoting Andreas Beckmann (2024-06-21 09:25:43)
> your package fails to build a module for Linux 6.9 in experimental:
> 
> /var/lib/dkms/ezurio-qcacld-2.0/0.0~git20230623.2cd31b6/build/CORE/HDD/src/wlan_hdd_hostapd.c:
>  In function 'hdd_chan_change_notify':
> /var/lib/dkms/ezurio-qcacld-2.0/0.0~git20230623.2cd31b6/build/CORE/HDD/src/wlan_hdd_hostapd.c:1574:9:
>  error: too many arguments to function 'cfg80211_ch_switch_notify'
>  1574 | cfg80211_ch_switch_notify(dev, &chandef, 0, 0);
>   | ^
> 
> Please see the attached make.log for lots of warnings that could be related.

thanks a lot for testing this!

I'm bumping severity, so that this does not get forgotten.

cheers, josch

signature.asc
Description: signature

Bug#1073926: clapper 0.5.2 built against 1.24 doesn't play videos on PinePhone and Librem 5

[Johannes Schauer Marin Rodrigues]

Hi Andrey–

Quoting Andrey Skvortsov (2024-06-20 12:14:39)
> after gstreamer update from 1.22 to 1.23/1.24 clapper stopped playing videos
> (h264 at least) on PinePhone (ARM aarch64, allwinner a64). The SoC uses v4l2
> stateless decoder. Librem5 (iMX8) was checked as well on trixie from
> 19.06.2024 and clapper is not working there either.

what is the error on the Librem5? I tested this on the MNT Reform 2 which also
uses the imx8mq just as the librem 5 does and hardware decoding does work there
with gstreamer 1.24. We used to ship some gstreamer patches for before the 1.24
release but those were all integrated now.

> If I take old clapper build before gstreamer update to 1.24, then
> videoplayback in clapper works.
> 
> I've tried to backport upstream clapper fix for gstreamer 1.24.
> https://github.com/Rafostar/clapper/commit/a9769f95378d1cf20d6f6105eb90df7a3fe3f8f0
> But it wasn't enough to get clapper 0.5.2 working on PinePhone.
> 
> clapper 0.6 contains several fixes for gstreamer 1.24 compatibility. 
> I've tried to build clapper 0.6 against gstreamer 1.24 localy and video
> playback started to work on PinePhone.

I take it then that this is mainly about the PinePhone and not the Librem 5?

> Please consider updating clapper to the next released version 0.6.

Certainly! It is on my TODO list now. Should I fail to come back to this, feel
free to ping me until I get the work done.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1073509: sbuild-qemu-update works, but increases image allocated size each time

[Johannes Schauer Marin Rodrigues]

Hi again,

Quoting Johannes Schauer Marin Rodrigues (2024-06-17 08:34:27)
> Quoting Francesco Poli (wintermute) (2024-06-16 19:09:08)
> > But, the allocated size has significantly grown:
> > 
> >   $ cd ~/.cache/sbuild/
> >   $ ls -altrFs --si
> >   total 4.4G
> >   4.1k drwx-- 37 $USER $USER 4.1k May  4 16:03 ../
> >   4.1k drwxrwx---  2 $USER $USER 4.1k May 13 23:19 build/
> >   3.6G -rw-rw  1 $USER $USER  27G Jun  9 22:00 
> > OLD_unstable-autopkgtest-amd64.img
> >   4.1k drwxrwx---  3 $USER $USER 4.1k Jun 16 18:26 ./
> >   832M -rw-rw  1 $USER $USER  27G Jun 16 18:26 
> > unstable-autopkgtest-amd64.img
> > 
> > Now the allocated size is 832 MB, instead of 705 MB !!!
> > That could explain how I had reached 3.6 GB, one run of sbuild-qemu-update
> > after the other...
> > 
> > But why does the allocated size increase?
> > Maybe there's something about sparse file support that I do not
> > fully understand.
> > 
> > Is there anything that can be done inside sbuild-qemu-update to prevent
> > the allocated size from growing indefinitely?
> > Apart from periodically regenerating the image from scratch, I mean...
> 
> as you suspected this is because of how sparse files work. Whenever you 
> upgrade
> something in your image, data gets deleted and new data gets added. The
> filesystem driver in the kernel does not zero-out those parts that it deletes
> and even if it would, qemu has no idea which blocks of the underlying image
> file it should now mark "sparse".
> 
> One tool that should reduce size again is e2image from e2fsprogs:
> 
> $ e2image -rap old.img new.img
> 
> But this requires copying the actual file data. I didn't try it out, but there
> is also the "discard" extended option of e2fsck:
> 
> $ e2fsck -E discard your.img
> 
> Lastly, I do not know if the zerofree tool has support for sparse files?
> Maybe try running it on your FS and see what happens. :)

follow-up question: are you on bookworm or on trixie? If the latter, would you
mind testing an improved version of mmdebstrap-autopkgtest-build-qemu which is
able to create bit-by-bit identical disk images?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1073543: mmdebstrap-autopkgtest-build-qemu: selects wrong kernel package for armhf

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Colin Watson (2024-06-17 13:39:08)
> On Mon, Jun 17, 2024 at 01:25:14PM +0200, Johannes Schauer Marin Rodrigues 
> wrote:
> > Quoting Colin Watson (2024-06-17 12:20:44)
> > > i386)
> > > EFIIMG=bootia32.efi
> > > QEMUARCH=i386
> > > VMFPKG=ovmf-ia32
> > > +   LINUXIMAGE=linux-image-rt-686-pae
> > 
> > Why with PREEMPT_RT and not just linux-image-686-pae?
> 
> I somehow missed that linux-image-686-pae is in unstable.  Yes, that
> would be better.
> 
> > It seems to me that the kernel selection should follow what debvm does:
> > 
> > https://sources.debian.org/src/debvm/0.3/share/customize-kernel.sh/#L20
> 
> Makes sense.  Would you mind adjusting my patch to fit whatever you
> think is best here?  I was just doing this by way of yak-shaving another
> problem ...

Sure thing!

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/bda207af6333748639b892e78902cfac04804df8

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1073543: mmdebstrap-autopkgtest-build-qemu: selects wrong kernel package for armhf

[Johannes Schauer Marin Rodrigues]

Hi,

thank you for your patch!

Quoting Colin Watson (2024-06-17 12:20:44)
> --- /usr/bin/mmdebstrap-autopkgtest-build-qemu  2024-05-14 06:39:00.0 
> +0100
> +++ mmdebstrap-autopkgtest-build-qemu   2024-06-17 11:17:34.619003852 +0100
> @@ -235,26 +235,31 @@
> EFIIMG=bootx64.efi
> QEMUARCH=x86_64
> VMFPKG=ovmf
> +   LINUXIMAGE=linux-image-amd64
> ;;
> arm64)
> EFIIMG=bootaa64.efi
> QEMUARCH=aarch64
> VMFPKG=qemu-efi-aarch64
> +   LINUXIMAGE=linux-image-arm64
> ;;
> armhf)
> EFIIMG=bootarm.efi
> QEMUARCH=arm
> VMFPKG=qemu-efi-arm
> +   LINUXIMAGE=linux-image-armmp
> ;;
> i386)
> EFIIMG=bootia32.efi
> QEMUARCH=i386
> VMFPKG=ovmf-ia32
> +   LINUXIMAGE=linux-image-rt-686-pae

Why with PREEMPT_RT and not just linux-image-686-pae?

> ;;
> riscv64)
> EFIIMG=bootriscv64.efi
> QEMUARCH=riscv64
> VMFPKG=
> +   LINUXIMAGE=linux-image-riscv64
> ;;
> *)
> die "unsupported architecture: $ARCHITECTURE"
> @@ -344,7 +349,7 @@
> set -- "$@" --hook-dir=/usr/share/mmdebstrap/hooks/jessie-or-older
>  
>  set -- "$@" \
> -   "--include=init,linux-image-$ARCHITECTURE,python3" \
> +   "--include=init,$LINUXIMAGE,python3" \
> '--customize-hook=echo host >"$1/etc/hostname"' \
> '--customize-hook=echo 127.0.0.1 localhost host >"$1/etc/hosts"' \
> '--customize-hook=passwd --root "$1" --delete root' \

It seems to me that the kernel selection should follow what debvm does:

https://sources.debian.org/src/debvm/0.3/share/customize-kernel.sh/#L20

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1073263: buildd.debian.org: Please show who requested the latest action

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Johannes Schauer Marin Rodrigues (2024-06-16 23:10:45)
> On Sat, 15 Jun 2024 22:48:30 +0200 Philipp Kern  wrote:
> > On 6/15/24 6:08 PM, Niels Thykier wrote:
> > > In case it is relevant, I do not have access to the `transactions` table 
> > >   (only the *_public ones):
> > > 
> > > ```
> > > wanna-build=> select * from transactions where package = 'botch' and 
> > > state = 'Dep-Wait';
> > > ERROR:  permission denied for table transactions
> > > ```
> > 
> > I find that very surprising. I think it's because you connected to 
> > wanna-build without privileges. You'd have needed to use 
> > service=wanna-build-privileged to connect to actually ship a username. 
> > You're in wb_all, so you'd have been able to read that table.
> > 
> > > Though, it might be that the answer is that we can solve this via a 
> > > "transactions_public" VIEW. I have no idea how feasible that is.
> > 
> > That view exists now and access to it does not require user auth.
> 
> could you or Philipp maybe hand-hold me so that I can learn how to look up
> this sort of information now? I never did this. :)

okay, so for future-me or anybody else reading this:

ssh wuiet.debian.org "psql service=wanna-build -P pager=off -c \"select * from 
transactions_public where package = 'botch' and state = 'Dep-Wait';\""

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1073509: sbuild-qemu-update works, but increases image allocated size each time

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Francesco Poli (wintermute) (2024-06-16 19:09:08)
> But, the allocated size has significantly grown:
> 
>   $ cd ~/.cache/sbuild/
>   $ ls -altrFs --si
>   total 4.4G
>   4.1k drwx-- 37 $USER $USER 4.1k May  4 16:03 ../
>   4.1k drwxrwx---  2 $USER $USER 4.1k May 13 23:19 build/
>   3.6G -rw-rw  1 $USER $USER  27G Jun  9 22:00 
> OLD_unstable-autopkgtest-amd64.img
>   4.1k drwxrwx---  3 $USER $USER 4.1k Jun 16 18:26 ./
>   832M -rw-rw  1 $USER $USER  27G Jun 16 18:26 
> unstable-autopkgtest-amd64.img
> 
> Now the allocated size is 832 MB, instead of 705 MB !!!
> That could explain how I had reached 3.6 GB, one run of sbuild-qemu-update
> after the other...
> 
> But why does the allocated size increase?
> Maybe there's something about sparse file support that I do not
> fully understand.
> 
> Is there anything that can be done inside sbuild-qemu-update to prevent
> the allocated size from growing indefinitely?
> Apart from periodically regenerating the image from scratch, I mean...

as you suspected this is because of how sparse files work. Whenever you upgrade
something in your image, data gets deleted and new data gets added. The
filesystem driver in the kernel does not zero-out those parts that it deletes
and even if it would, qemu has no idea which blocks of the underlying image
file it should now mark "sparse".

One tool that should reduce size again is e2image from e2fsprogs:

$ e2image -rap old.img new.img

But this requires copying the actual file data. I didn't try it out, but there
is also the "discard" extended option of e2fsck:

$ e2fsck -E discard your.img

Lastly, I do not know if the zerofree tool has support for sparse files? Maybe
try running it on your FS and see what happens. :)

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1073259: libyojson-ocaml-dev should depend on yojson-tools

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting julien.pu...@gmail.com (2024-06-16 18:37:55)
> Sorry I was away for most of the weekend, but yes, I didn't test my
> last change correctly and broke things.

no problem. I think the breakage was minor.

> I just fixed elpi.

Thank you!

> I'll also take care of coq-serapi. This package is a problem - I wonder
> if I shouldn't have waited some more before packaging it: upstream is
> moving things around in different packages like crazy, so it's bound to
> break too often for my taste and my attention span.

Maybe just file an RC bug against the package. That will prevent it from
transitioning to testing. It's probably smart to only let it transition once it
is ready for a stable release.

> > In summary: I do not think that a Depends from the dev package on the
> > tools package is needed. Adrian, do you agree?
> Not needed!

Thank you! Then I guess you can close this bug.

cheers, josch

signature.asc
Description: signature

Bug#1073263: buildd.debian.org: Please show who requested the latest action

[Johannes Schauer Marin Rodrigues]

Hi,

thanks again Niels for filing a bug for the question I had on IRC. :)

On Sat, 15 Jun 2024 22:48:30 +0200 Philipp Kern  wrote:
> On 6/15/24 6:08 PM, Niels Thykier wrote:
> > In case it is relevant, I do not have access to the `transactions` table 
> >   (only the *_public ones):
> > 
> > ```
> > wanna-build=> select * from transactions where package = 'botch' and 
> > state = 'Dep-Wait';
> > ERROR:  permission denied for table transactions
> > ```
> 
> I find that very surprising. I think it's because you connected to 
> wanna-build without privileges. You'd have needed to use 
> service=wanna-build-privileged to connect to actually ship a username. 
> You're in wb_all, so you'd have been able to read that table.
> 
> > Though, it might be that the answer is that we can solve this via a 
> > "transactions_public" VIEW. I have no idea how feasible that is.
> 
> That view exists now and access to it does not require user auth.

could you or Philipp maybe hand-hold me so that I can learn how to look up this
sort of information now? I never did this. :)

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1073259: libyojson-ocaml-dev should depend on yojson-tools

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Johannes Schauer Marin Rodrigues (2024-06-15 14:03:34)
> So the reason for why there is no a tools package is, that I argued that it
> would be nice if the tools found in /usr/bin would not be part of the -dev
> package but in its own package to decrease the number of dependencies.
> 
> If the -dev package starts depending on the tools package, this advantage 
> would
> be lost.
> 
> How about doing a rebuild of the reverse dependencies of yojson and see what
> breaks? My gut feeling is, that botch is the only one affected by this.
> 
> Julien, do you want to take care of that rebuild or should I?

I found the following reverse dependencies: belenios botch camlp5
camlp5-buildscripts coq-serapi eliom elpi frama-c haxe hol-light js-of-ocaml
js-of-ocaml-ocamlbuild lablgtk3 lambda-term ledit liquidsoap morbig morsmall
nss-passwords nurpawiki ocaml-atd ocaml-base64 ocaml-bos ocaml-ca-certs
ocaml-cohttp ocaml-conduit ocaml-logs ocaml-merlin ocaml-mirage-crypto
ocaml-mtime ocaml-pbkdf ocaml-ptime ocaml-x509 ocplib-simplex ocsigenserver
ocsipersist orpie ppx-deriving-yojson utop wyrd zeroinstall-injector

I built them all using sbuild in unstable and found the following to fail:

botch: #1073199
coq-serapi: 1073269
elpi: #1073275

Gianfranco just NMU-ed botch, so #1073199 should be taken care of. Julien
maintains elpi, so they probably can figure out how to fix this. The build log
of coq-serapi might indicate that something in the last yojson upload (which
included an upstream version bump) broke it. Can you investigate?

In summary: I do not think that a Depends from the dev package on the tools
package is needed. Adrian, do you agree?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1073275: FTBFS in unstable due to make test

[Johannes Schauer Marin Rodrigues]

Source: elpi
Version: 1.18.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

during running of the tests, the package build fails, specifically:

KO   trace-browser-elab (trace elaboration)  elpi-trace-elaborator
KO   trace-browser-elab-broken1 (recoverable broken trace elaboration) 
elpi-trace-elaborator
KO   trace-browser-elab-chr (trace elaboration)  elpi-trace-elaborator
KO   trace-browser-elab-cut (trace elaboration)  elpi-trace-elaborator
KO   trace-browser-elab-findall (trace elaboration) elpi-trace-elaborator
KO   trace-browser-w-elab (trace elaboration)elpi-trace-elaborator
KO   trace-browser2-elab (trace elaboration) elpi-trace-elaborator
KO   trace-browser3-elab (trace elaboration) elpi-trace-elaborator
KO   trace-browser4-elab (trace elaboration) elpi-trace-elaborator

Full log attached.

Thanks!

cheers, josch
sbuild (Debian sbuild) 0.85.0 (04 January 2023) on salat

+==+
| elpi (amd64) Sat, 15 Jun 2024 12:30:49 + |
+==+

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

Unpacking /home/josch/.cache/sbuild/unstable-amd64.tar to 
/tmp/tmp.sbuild.u1sSqKPNOc...
I: NOTICE: Log filtering will replace 'sbuild-unshare-dummy-location' with 
'<>'
I: NOTICE: Log filtering will replace 'build/elpi-AxtKGU/resolver-wQbB4N' with 
'<>'

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

Get:1 http://deb.debian.org/debian unstable InRelease [198 kB]
Get:2 http://deb.debian.org/debian unstable/main amd64 Packages [9934 kB]
Fetched 10.1 MB in 1s (9855 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

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


Check APT
-

There are no deb-src lines in your sources.list
Automatically adding to EXTRA_REPOSITORIES: deb-src 
http://deb.debian.org/debian/ sid main

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

Hit:1 http://deb.debian.org/debian unstable InRelease
Get:2 http://deb.debian.org/debian sid InRelease [198 kB]
Get:3 http://deb.debian.org/debian sid/main Sources [10.6 MB]
Fetched 10.8 MB in 1s (8909 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Checking available source versions...

Download source files with APT
--

Reading package lists...
NOTICE: 'elpi' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/ocaml-team/elpi.git
Please use:
git clone https://salsa.debian.org/ocaml-team/elpi.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 2637 kB of source archives.
Get:1 http://deb.debian.org/debian sid/main elpi 1.18.2-2 (dsc) [2310 B]
Get:2 http://deb.debian.org/debian sid/main elpi 1.18.2-2 (tar) [2630 kB]
Get:3 http://deb.debian.org/debian sid/main elpi 1.18.2-2 (diff) [4560 B]
Fetched 2637 kB in 0s (44.2 MB/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 'build/elpi-AxtKGU/elpi-1.18.2' with 
'<>'
I: NOTICE: Log filtering will replace 'build/elpi-AxtKGU' with '<>'

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


Setup apt archive
-

Merged Build-Depends: atdts (>= 2.9.1), camlp5 (>= 8.00.02), debhelper-compat 
(= 13), dh-ocaml (>= 1.2), gnuplot-nox, libansi-terminal-ocaml-dev, 
libatdgen-ocaml-dev (>= 2.9.1), libcmdliner-ocaml-dev, libmenhir-ocaml-dev, 
libppx-deriving-ocaml-dev, libppxlib-ocaml-dev, libre-ocaml-dev, lua5.1, 
menhir, ocaml-dune, time, build-essential, fakeroot
Filtered Build-Depends: atdts (>= 2.9.1), camlp5 (>= 8.00.02), debhelper-compat 
(= 13), dh-ocaml (>= 1.2), gnuplot-nox, libansi-terminal-ocaml-dev, 
libatdgen-ocaml-dev (>= 2

Bug#1073269: FTBFS in unstable with Error: Unbound type constructor Result.result

[Johannes Schauer Marin Rodrigues]

Source: coq-serapi
Version: 8.19.0+0.19.3-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

coq-serapi FTBFS in unstable with the following error:

/usr/bin/make build
make[2]: Entering directory '/<>'
dune build --root . --only-packages=coq-serapi @install
File "serlib/ser_constrexpr.mli", line 106, characters 85-98:
106 | val with_declaration_ast_of_yojson : Yojson.Safe.t -> 
(with_declaration_ast, string) Result.result

   ^
Error: Unbound type constructor Result.result
File "serlib/ser_feedback.mli", line 25, characters 57-70:
25 | val doc_id_of_yojson : Yojson.Safe.t -> (doc_id, string) Result.result
  ^
Error: Unbound type constructor Result.result
File "serlib/ser_goptions.mli", line 31, characters 69-82:
31 | val option_value_of_yojson : Yojson.Safe.t -> (option_value, string) 
Result.result
  
^
Error: Unbound type constructor Result.result
File "serlib/ser_genredexpr.mli", line 30, characters 61-74:
30 | val glob_red_flag_of_yojson : (Yojson.Safe.t -> ('a, string) 
Result.result) -> Yojson.Safe.t -> ('a glob_red_flag,
 string) Result.result
  ^
Error: Unbound type constructor Result.result
File "serlib/ser_glob_term.mli", line 34, characters 63-76:
34 | val glob_sort_of_yojson : Yojson.Safe.t -> (glob_sort, string) 
Result.result

^
Error: Unbound type constructor Result.result
File "serlib/ser_pp.mli", line 26, characters 45-58:
26 | val of_yojson : Yojson.Safe.t -> (t, string) Result.result
  ^
Error: Unbound type constructor Result.result
File "serlib/ser_xml_datatype.mli", line 25, characters 52-65:
25 | val gxml_of_yojson : (Yojson.Safe.t -> ('a, string) Result.result) -> 
Yojson.Safe.t -> ('a gxml, string) Result.re
sult
 ^
Error: Unbound type constructor Result.result
File "serlib/ser_dAst.ml", line 34, characters 62-75:
34 | let thunk_of_yojson : type a b. (Yojson.Safe.t -> (a, string) 
Result.result) -> (Yojson.Safe.t -> (b, string) Resu
lt.result) -> Yojson.Safe.t -> ((a,b) thunk, string) Result.result =
   ^
Error: Unbound type constructor Result.result


Full build log attached.

Thanks!

cheers, josch
sbuild (Debian sbuild) 0.85.0 (04 January 2023) on salat

+==+
| coq-serapi (amd64)   Sat, 15 Jun 2024 12:28:25 + |
+==+

Package: coq-serapi
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

Unpacking /home/josch/.cache/sbuild/unstable-amd64.tar to 
/tmp/tmp.sbuild.K1Xrqr4TDO...
I: NOTICE: Log filtering will replace 'sbuild-unshare-dummy-location' with 
'<>'
I: NOTICE: Log filtering will replace 'build/coq-serapi-MOPvT6/resolver-iw1YuS' 
with '<>'

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

Get:1 http://deb.debian.org/debian unstable InRelease [198 kB]
Get:2 http://deb.debian.org/debian unstable/main amd64 Packages [9934 kB]
Fetched 10.1 MB in 1s (9112 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

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


Check APT
-

There are no deb-src lines in your sources.list
Automatically adding to EXTRA_REPOSITORIES: deb-src 
http://deb.debian.org/debian/ sid main

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

Hit:1 http://deb.debian.org/debian unstable InRelease
Get:2 http://deb.debian.org/debian sid InRelease [198 kB]
Get:3 http://deb.debian.org/debian sid/main Sources [10.6 MB]
Fetched 10.8 MB in 1s (8562 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Read

Bug#1073259: libyojson-ocaml-dev should depend on yojson-tools

[Johannes Schauer Marin Rodrigues]

Quoting Johannes Schauer Marin Rodrigues (2024-06-15 13:49:49)
> Control: merge -1 1073199

Sorry, I mixed this up (and luckily the bts stopped me from merging).

So the reason for why there is no a tools package is, that I argued that it
would be nice if the tools found in /usr/bin would not be part of the -dev
package but in its own package to decrease the number of dependencies.

If the -dev package starts depending on the tools package, this advantage would
be lost.

How about doing a rebuild of the reverse dependencies of yojson and see what
breaks? My gut feeling is, that botch is the only one affected by this.

Julien, do you want to take care of that rebuild or should I?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1073259: libyojson-ocaml-dev should depend on yojson-tools

[Johannes Schauer Marin Rodrigues]

Control: merge -1 1073199

Hi,

Quoting Adrian Bunk (2024-06-15 12:58:19)
> Package: libyojson-ocaml-dev
> Version: 2.2.1-1
> Severity: serious
> Tags: ftbfs
> Control: affects -1 src:botch
> 
> https://buildd.debian.org/status/fetch.php?pkg=botch&arch=ppc64el&ver=0.24-3%2Bb1&stamp=1718448612&raw=0
> 
> ...
> + ydump
> ./tools/native.sh: 512: ydump: not found
> ...
> 
> 
> Packages (build) depending on libyojson-ocaml-dev and users upgrading
> to trixie might see breakage when depending on or installing
> libyojson-ocaml-dev no longer provides the ydump tool.
> 
> There is likely no good reason against libyojson-ocaml-dev depending
> on yojson-tools.

This is a duplicate of 1073199.

As I've already told Gianfranco in the other bug, I'm on a short vacation. Feel
free to NMU.

Julien, as you have introduced this situation, the offer to NMU botch for me
also goes to you.

I'll likely only be able to take care of this on Tuesday or later.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1073199: botch: please update from libyojson-ocaml-dev to new yojson-tools package

[Johannes Schauer Marin Rodrigues]

Hi,

I'm on vacation right now with very limited internet.

If you like, please feel free to NMU.

Thanks!

cheers, josch

Quoting Gianfranco Costamagna (2024-06-14 14:36:58)
> Hello, we should also add it to build-depends:
> 
> --- botch-0.24/debian/control   2024-06-14 14:01:13.0 +0200
> +++ botch-0.24/debian/control   2024-06-14 14:35:36.0 +0200
> @@ -36,6 +36,7 @@
>libgraph-easy-perl  ,
>graphviz,
>black   ,
> + yojson-tools,
>   Build-Depends-Indep:
>discount ,
>graphviz ,
> 
> G.
> 
> On Fri, 14 Jun 2024 14:06:43 +0200 Gianfranco Costamagna 
>  wrote:
> > Package: botch
> > Version: 0.24-3
> > Severity: serious
> > Tags: patch
> > 
> > 
> > Hello, new yojson 2.2.1-1 created a new yojson-tools package, making this 
> > package fail
> > it's own autopkgtests due to missing tools (ydump)
> > 
> > I think the best way to move forward is to update the dependency of your 
> > package
> > 
> >* Depend on yojson-tools instead of old libyojson-ocaml-dev
> >  to fix missing ydump tool (split from libyojson-ocaml-dev)
> >  This fixes autopkgtests
> > 
> > 
> > Thanks for considering the patch.
> > 
> > --- botch-0.24/debian/control 2024-06-10 12:40:37.0 +0200
> > +++ botch-0.24/debian/control 2024-06-14 14:01:13.0 +0200
> > @@ -60,7 +60,7 @@
> >python3-pygraphviz (>= 1.4~rc1),
> >zutils,
> >dpkg-dev,
> > - libyojson-ocaml-dev,
> > + yojson-tools,
> >   # libjs-jquery-tablesorter and libjs-jquery are needed to look at the 
> > generated
> >   # HTML with javascript bling
> >   Recommends:

signature.asc
Description: signature

Bug#877356: marked as pending in yojson

[Johannes Schauer Marin Rodrigues]

Hi Julien,

Quoting Julien Puydt (2024-06-11 09:08:45)
> Bug #877356 in yojson reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/ocaml-team/yojson/-/commit/95876ac4654931a798b6310479780fb863e91a4b

thank you for addressing this bug. But this now makes packages which B-D on
libyojson-ocaml-dev FTBFS if they require the ydump tool. Example:

https://buildd.debian.org/status/package.php?p=botch

Did you do a rebuild of all the reverse dependencies of libyojson-ocaml-dev but
just forgot to file a bug against botch that it now has to switch its build
dependency to yojson-tools?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1030668: dinstall could run more often (every hour?)

[Johannes Schauer Marin Rodrigues]

Hi,

On Mon, 6 Feb 2023 12:45:17 +0100 Bastian Blank  wrote:
> > The bigger picture is: packages are not part of the Debian build
> > infrastructure (buildd, piuparts, etc) for hours and this blocks many
> > development activities.
> 
> They are.  The buildd use incoming.d.o with accepted packages as
> additional source.

maybe let me use this topic to ask a maybe a little bit tangential question.

For a few days I have been involved in fixing the autopkgtest of my package
mmdebstrap to make it work with Helmut's recent merged-/usr uploads of bash,
dash, util-linux and glibc. My workflow is: fix a thing, upload, see if ci.d.n
is happy, fix bug, repeat. This takes multiple dinstalls and thus multiple days
of work for me. This is not a nice experience for me as a contributor because
instead of being able to sit down and fix the thing, I have to spread my work
across multiple days. I'm aware that there are multiple possible fixes to this:

 1. add support for using incoming as a apt source to ci.d.n
 2. set up my own copy of ci.d.n (difficult as i'm on a slow arm cortex a53 
system with 3.7 GB ram)
 3. ask far a shell on ci.d.n from elbrus
 4. add support for apt pinning to autopkgtest on salsaci

I must admit I'm not that frustrated by the six hour dinstall time as while it
is not optimal, it is something I find myself having accepted as the way that
Debian just works. So whatever.

But here comes my tangential question: I have my package (mmdebstrap) which
seems to require overall 29 seconds to build on the builds. The buildd queues
are empty. I upload an hour before the next dinstall. Then it takes 20 minutes
for the ACCEPTED mail to arrive after my dput (why this long?) and then it
takes another half an hour before the buildds even register that there is a new
binary package to be built (why this long?), then it builds in 29 seconds, 10
minutes before the next dinstall it's finished. It still misses it.

So my question: for a package that takes 29 seconds to build and empty buildd
queues. How long before the official dinstall times do I have to upload so that
my package makes it? It is very frustrating to upload an hour in advance, plan
my time for the day accordingly, only to then see it fail. This waiting time
and unpredictability is what makes Debian development extremely frustrating for
me. I do not understand why processing such a tiny package is taking a full
hour. Maybe things would be a bit better if I would at least be able to predict
what is going on at a given time. I literally told my family: hey can I have
some free time later to work on Debian and now it's not going to happen. This
is not a problem of only 4 dinstalls per day but it's a problem of not knowing
what is going on and why. Maybe this can be improved?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1072986: test empty-sources.list fails because it overwrites sources.list

[Johannes Schauer Marin Rodrigues]

Source: mmdebstrap
Version: 1.5.1-2
Severity: normal

Hi,

the test empty-sources.list, as part of the test, overwrites
/etc/apt/sources.list in a setup-hook, thus removing the setup done by
debian/tests/sourcesfilter which runs before. This effect can be seen in
autopkgtest results with this diff:

5194s + diff -u tar1.txt -
5194s --- tar1.txt  2024-06-11 07:56:55.297824379 +
5194s +++ - 2024-06-11 09:05:51.096355647 +
5194s @@ -2353,8 +2353,6 @@
5194s  ./usr/share/info/diffutils.info.gz
5194s  ./usr/share/info/dir
5194s  ./usr/share/info/find-maint.info.gz
5194s -./usr/share/info/find.info-1.gz
5194s -./usr/share/info/find.info-2.gz
5194s  ./usr/share/info/find.info.gz
5194s  ./usr/share/info/grep.info.gz
5194s  ./usr/share/info/gzip.info.gz
5194s @@ -2815,6 +2813,7 @@
5194s  ./usr/share/locale/ka/LC_MESSAGES/Linux-PAM.mo
5194s  ./usr/share/locale/ka/LC_MESSAGES/coreutils.mo
5194s  ./usr/share/locale/ka/LC_MESSAGES/diffutils.mo
5194s +./usr/share/locale/ka/LC_MESSAGES/findutils.mo
5194s  ./usr/share/locale/ka/LC_MESSAGES/gnutls30.mo
5194s  ./usr/share/locale/ka/LC_MESSAGES/grep.mo
5194s  ./usr/share/locale/ka/LC_MESSAGES/libidn2.mo

Which exactly matches the difference between testing and unstable of findutils
right now:

diff -u <(curl --silent 
http://ftp.de.debian.org/debian/pool/main/f/findutils/findutils_4.9.0-6_arm64.deb
 | dpkg-deb --fsys-tarfile - | tar tv | awk '{print $6}' | sort) <(curl 
--silent 
http://ftp.de.debian.org/debian/pool/main/f/findutils/findutils_4.10.0-2_arm64.deb
  | dpkg-deb --fsys-tarfile - | tar tv | awk '{print $6}' | sort)
--- /dev/fd/63  2024-06-11 12:16:24.925627829 +0200
+++ /dev/fd/62  2024-06-11 12:16:24.925627829 +0200
@@ -15,8 +15,6 @@
 ./usr/share/doc/findutils/README.gz
 ./usr/share/doc/findutils/TODO
 ./usr/share/info/
-./usr/share/info/find.info-1.gz
-./usr/share/info/find.info-2.gz
 ./usr/share/info/find.info.gz
 ./usr/share/info/find-maint.info.gz
 ./usr/share/locale/
@@ -77,6 +75,9 @@
 ./usr/share/locale/ja/
 ./usr/share/locale/ja/LC_MESSAGES/
 ./usr/share/locale/ja/LC_MESSAGES/findutils.mo
+./usr/share/locale/ka/
+./usr/share/locale/ka/LC_MESSAGES/
+./usr/share/locale/ka/LC_MESSAGES/findutils.mo
 ./usr/share/locale/ko/
 ./usr/share/locale/ko/LC_MESSAGES/
 ./usr/share/locale/ko/LC_MESSAGES/findutils.mo

Thanks!

cheers, josch

Bug#1068119: Solution for 1068119 - compile error for s390-tools 2.16.0-2

[Johannes Schauer Marin Rodrigues]

Control: affects -1 + mmdebstrap

Hi,

On Mon, 27 May 2024 12:07:11 +0200 Steffen Eiden  wrote:
> this issue is already fixed upstream since v2.22.0.
> 
> Do one of:
> - apply the upstream fix [1,2]
> - update your package to at least v2.22.0
> 
> 
> The upstream fix disables the warning similar to the kernel[3] (see 
> commit description) as there is no better solution for this as of now.
> 
> I can ensure the code is correct and does no weird things (see lkml).
> There is also a s390-tools upstream discussion regarding this issue.[4]
> 
> 
> Steffen Eiden
> s390-tools upstream-maintainer

based on Steffen's input, I just did a 0-day NMU of s390-tools as this RC bug
is older than 7 days and there was no maintainer activity on the bug for 7 days
and there does not seem to be a packaging VCS where a fix could maybe be found
already.

I also had to cherry-pick another commit from upstream fixing another build
failure with OpenSSL 3.0, namely 8723dbce048add87ce10fe8c72eea75c4f828ef8

This package affects the /usr-move transition because due to this FTBFS, it is
not possible to rebuild s390-tools on unstable with new packages for the 64-bit
time_t transition and that in turn makes apt select the wrong packages in the
mmmdebstrap autopkgtest which we need to succeed to transition util-linux,
bash, dash, glibc and base-files to testing.

The debdiff is attached.

Thanks!

cheers, joschdiff -Nru s390-tools-2.16.0/debian/changelog s390-tools-2.16.0/debian/changelog
--- s390-tools-2.16.0/debian/changelog	2021-08-18 09:26:50.0 +0200
+++ s390-tools-2.16.0/debian/changelog	2024-06-11 11:15:24.0 +0200
@@ -1,3 +1,12 @@
+s390-tools (2.16.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patches from upstream to fix FTBFS (closes: #1068119)
+ - 0001-genprotimg-boot-disable-Warray-bounds-for-now.patch
+ - 0001-genprotimg-add-OpenSSL-3.0-support.patch
+
+ -- Johannes Schauer Marin Rodrigues   Tue, 11 Jun 2024 11:15:24 +0200
+
 s390-tools (2.16.0-2) unstable; urgency=medium
 
   * Add missing build-dependency on libglib2.0-dev. (Closes: #992249)
diff -Nru s390-tools-2.16.0/debian/patches/0001-genprotimg-add-OpenSSL-3.0-support.patch s390-tools-2.16.0/debian/patches/0001-genprotimg-add-OpenSSL-3.0-support.patch
--- s390-tools-2.16.0/debian/patches/0001-genprotimg-add-OpenSSL-3.0-support.patch	1970-01-01 01:00:00.0 +0100
+++ s390-tools-2.16.0/debian/patches/0001-genprotimg-add-OpenSSL-3.0-support.patch	2024-06-11 11:15:06.0 +0200
@@ -0,0 +1,151 @@
+From 8723dbce048add87ce10fe8c72eea75c4f828ef8 Mon Sep 17 00:00:00 2001
+From: Marc Hartmayer 
+Date: Wed, 23 Jun 2021 13:16:25 +
+Subject: [PATCH] genprotimg: add OpenSSL 3.0 support
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Add OpenSSL 3.0 support while still supporting OpenSSL 1.1.0 and newer. For this
+set the OPENSSL_API_COMPAT user defined macro to OpenSSL 1.1.0 (see
+https://www.openssl.org/docs/manmaster/man7/OPENSSL_API_COMPAT.html) so we don't
+see any deprecation warnings when using OpenSSL 3.0. In addition, add an
+compatibility layer for OpenSSL since some OpenSSL API functions were constified
+with OpenSSL 3.0.
+
+Fixes: https://github.com/ibm-s390-linux/s390-tools/issues/112
+Reviewed-by: Patrick Steuer 
+Signed-off-by: Marc Hartmayer 
+Signed-off-by: Jan Höppner 
+---
+ genprotimg/src/Makefile   |  1 +
+ genprotimg/src/utils/crypto.c | 15 ++--
+ genprotimg/src/utils/openssl_compat.h | 33 +++
+ 4 files changed, 43 insertions(+), 7 deletions(-)
+ create mode 100644 genprotimg/src/utils/openssl_compat.h
+
+diff --git a/genprotimg/src/Makefile b/genprotimg/src/Makefile
+index a71bb1e..0e811d6 100644
+--- a/genprotimg/src/Makefile
 b/genprotimg/src/Makefile
+@@ -29,6 +29,7 @@ $(bin_PROGRAM)_OBJS := $($(bin_PROGRAM)_SRCS:.c=.o)
+ 
+ ALL_CFLAGS += -std=gnu11 -DPKGDATADIR=$(PKGDATADIR) \
+ 	$(GLIB2_CFLAGS) $(LIBCRYPTO_CFLAGS) $(LIBCURL_CFLAGS) \
++	-DOPENSSL_API_COMPAT=0x1010L \
+ 	$(WARNINGS) \
+ 	$(NULL)
+ ALL_CPPFLAGS += $(INCLUDE_PARMS)
+diff --git a/genprotimg/src/utils/crypto.c b/genprotimg/src/utils/crypto.c
+index 2e4750b..087de37 100644
+--- a/genprotimg/src/utils/crypto.c
 b/genprotimg/src/utils/crypto.c
+@@ -31,6 +31,7 @@
+ 
+ #include "buffer.h"
+ #include "curl.h"
++#include "openssl_compat.h"
+ #include "crypto.h"
+ 
+ #define DEFINE_GSLIST_MAP(t2, t1)	\
+@@ -1438,7 +1439,7 @@ static const char *get_first_dp_url(DIST_POINT *dp)
+ 	return NULL;
+ }
+ 
+-static gboolean insert_crl(X509_NAME *name, X509_CRL *crl)
++static gboolean insert_crl(const X509_NAME *name, X509_CRL *crl)
+ {
+ 	g_autofree gchar *key = NULL;
+ 
+@@ -1453,7 +1454,7 @@ static gboolean insert_crl(X509_NAME *name, X509_CRL *crl)
+ }
+ 
+ /* Caller is responsible for free'ing */
+-static X509_CRL *lookup_c

Bug#1063645: Aw: Re: markdown: missing required debian/rules targets build-arch and/or build-indep

[Johannes Schauer Marin Rodrigues]

Quoting Bastian Germann (2024-06-10 09:30:20)
> "Johannes Schauer Marin Rodrigues":
> > Do you have recommendations? I just need a drop-in replacement for markdown
> > into stdin, html on stdout. Nothing fancy.
> I would suggest discount or python3-markdown.

Brilliant! That tip was gold! All I did was this to fix the issue in my
package:

--- a/debian/control
+++ b/debian/control
@@ -37,7 +37,7 @@ Build-Depends-Arch:
  graphviz,
  black   ,
 Build-Depends-Indep:
- markdown ,
+ discount ,
  graphviz ,
 Vcs-Browser: https://salsa.debian.org/debian/botch
 Vcs-Git: https://salsa.debian.org/debian/botch.git


Much easier than fixing d/rules of src:markdown. ;)

signature.asc
Description: signature

Bug#1063645: markdown: missing required debian/rules targets build-arch and/or build-indep

[Johannes Schauer Marin Rodrigues]

On Sat, 8 Jun 2024 19:10:28 +0200 Bastian Germann  wrote:
> If you think about fixing this to keep a reverse dependency in Debian:

That's me.

> Please consider porting the reverse dep to some other markdown implementation
> that is still maintained.

Do you have recommendations? I just need a drop-in replacement for markdown
into stdin, html on stdout. Nothing fancy.

signature.asc
Description: signature

Bug#1041359: missing daemonize causes failed to connect to `/var/guix/daemon-socket/socket'

[Johannes Schauer Marin Rodrigues]

Hi,

On Mon, 17 Jul 2023 16:25:58 -0700 Vagrant Cascadian  wrote:
> On 2023-07-18, Simon Josefsson wrote:
> > Hi.  I was trying to build guile-gnutls via guix in a debian12
> > container, and the sequence below happened.  Is there a missing
> > dependency on daemonize?
> ...
> > # guix build -f guix.scm
> > guix build: error: failed to connect to `/var/guix/daemon-socket/socket': 
> > No such file or directory
> > # /etc/init.d/guix-daemon start
> > /etc/init.d/guix-daemon: line 35: daemonize: command not found
> > # service guix-daemon start
> > /etc/init.d/guix-daemon: line 35: daemonize: command not found
> > # apt-get install daemonize
> > # service guix-daemon start
> > # guix build -f guix.scm
> > updating checkout of '/guile'...
> > ...
> > successfully built 
> > /gnu/store/wza4ydc3hcalql66m3w8f6xr2s4sm6vf-guile-gnutls-3.7.12-git.drv
> > /gnu/store/jq6zvcadd1wnv1yirhp3xr378l6g9n8c-guile-gnutls-3.7.12-git
> 
> It is mentioned in /usr/share/doc/guix/README.Debian.

is it? I ran into the same issue and I did read guix.README.Debian which does
not cover this situation. There is a section called "Using with sysvinit" but
that does not apply here because no sysvinit is involved, right?

> I am of mixed mind on doing more than that... with the debian defaults,
> it is not needed, so it seems a bit much to add it to Depends or even
> Recommends.

In my opinion the argument goes the other way round: if a potential dependency
is already installed on most systems then adding a Depends on it does not hurt
because it will make no difference. On the other hand, very minimal systems
that do not have the package installed will benefit from such a dependency as
without it, the package cannot function.

It seems though that the situation has changed a bit now in 2024 and the guix
package is installing a native systemd service file which does not require the
daemonize tool anymore?

About systemd-sysusers: there is no policy requirement to add a dependency if
your package ships files in /usr/lib/sysusers.d in the same way as there is no
requirement to add a dependency on cron if the package ships a cronjob in
/etc/cron.d. Maybe as a datapoint, if src:guix were to run
dh_installsystemduser as part of the build, then it would add the following to
${misc:Depends}:

systemd | systemd-standalone-sysusers | systemd-sysusers

Another thing to ask: is there a common-enough use-case with which the package
can be used without systemd-sysusers (or some of its real providers)?

Maybe similarly, if one does not have the package "netbase" installed, running
"guix pull" will fail with:

guix substitute: warning: ci.guix.gnu.org: host not found: Servname not 
supported for ai_socktype

This is because without "netbase" the file /etc/services will not exist. So why
is the guix package not depending on "netbase"? You may also argue: any
reasonable system will have "netbase" installed (it is Priority: important
after all). But if that is so, then adding a dependency on netbase will not
hurt either, right? The package "netbase" is not marked as Essential:yes so if
using guix cannot reasonable by done without /etc/services then it should
depend on the package providing it, no? This is a similar argument as for
depending on systemd-sysusers in the way as it is done by dh_installsystemduser
above.

What do you think?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1072732: update-shells: duplicates entries when a package includes both aliased and canonical shells

[Johannes Schauer Marin Rodrigues]

Hi,

On Sat, 8 Jun 2024 18:10:04 +0200 Helmut Grohne  wrote:
> On Fri, Jun 07, 2024 at 10:09:04AM +0200, Helmut Grohne wrote:
> > My recent bash upload changes it's shells.d snippet to include both
> > aliased and canonical shells, which is right in principle, but it causes
> > update-shells to duplicate /usr/bin/bash in /etc/shells. While that's
> > not breaking anything yet, it's also not nice and kudos to Johannes for
> > spotting it.
> > 
> > It also is easy to fix with the attached patch. Would you kindly apply
> > it?
> 
> I fear this aspect currently breaks mmdebstrap's autopkgtests, so this
> is an rc bug somewhere. While it isn't technically rc for debianutils, I
> hope that the simplest way forward is to just upload debianutils. If you
> disagree with this assessment, we'll have to adapt mmdebstrap's
> autopkgtests until this bug is fixed, which also works, but is kinda
> meh. So I am tentatively raising it to rc severity for debianutils
> hoping that you agree and let you downgrade in case you disagree. Thanks for
> considering.

please CC me on the decision, so that I know how I should upload the next
version of mmdebstrap. :)

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1031276: randomness on armel, armhf mipsel resulting in unreproducible man-db index.db files

[Johannes Schauer Marin Rodrigues]

Hi Nicolas,

Quoting Nicolas Mora (2024-06-05 16:14:55)
> Sergey from upstream sent me a patch that should fix the problem. The patch
> initializes allocated blocks with 0 to avoid pseudo-randomness in data.
> 
> Can you test this patch before I upload a new package to unstable? I could
> upload to experimental first for example.

I applied your patch to gdbm from your packaging git (your pristine-tar branch
seems to be missing the delta for the latest upstream version) and executed the
tests from my initial bug report again. With your patch the problem is gone.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1031276: randomness on armel, armhf mipsel resulting in unreproducible man-db index.db files

[Johannes Schauer Marin Rodrigues]

Hi Nicolas,

On Tue, 14 Feb 2023 14:09:31 +0100 Johannes Schauer Marin Rodrigues 
 wrote:
> here is a test script that shows the problem:
> 
> $ printf "#:len=6\nZm9vYmFy\n#:len=6\nZm9vYmFy\n" > index.dump
> $ gdbm_load index.dump index1.db
> $ gdbm_load index.dump index2.db
> $ md5sum index1.db index2.db
> 
> The md5sums of index1.db and index2.db will differ despite both being created
> from index.dump.

more than one year later this is still a problem. Could you maybe have a look
or communicate this issue with upstream?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1072218: apt dist-upgrade fails to install essential packages but exits successfully

[Johannes Schauer Marin Rodrigues]

Package: apt
Version: 2.6.1
Severity: wishlist

Control: affects -1 + mmdebstrap

Hi David,

do you remember our conversation in #debian-dpkg from 2018?

 } elsif ($options->{variant} eq 'apt') {
 # if we just want to install Essential:yes packages, apt and their
 # dependencies then we can make use of libapt treating apt as
 # implicitly essential. An upgrade with the (currently) empty status
 # file will trigger an installation of the essential packages plus 
apt. 
 #
 # 2018-09-02, #debian-dpkg on OFTC, times in UTC+2
 # 23:39 < josch> I'll just put it in my script and if it starts
 #breaking some time I just say it's apt's fault. :P
 # 23:42 < DonKult> that is how it usually works, so yes, do that :P 
(<- 
 #  and please add that line next to it so you can
 #  remind me in 5+ years that I said that after I 
wrote 
 #  in the bugreport: "Are you crazy?!? Nobody in his
 #  right mind would even suggest depending on it!")
 @dl_debs = run_apt_download_progress({
 APT_ARGV => ['dist-upgrade'],
 dryrun   => $options->{dryrun},
 },
 );

Well, it is now even six years later. It is time!

The problem first showed up yesterday in the sbuild autopkgtest for riscv:

https://ci.debian.net/data/autopkgtest/testing/riscv64/s/sbuild/47087233/log.gz

Log is also attached for when it gets deleted from ci.d.n but the important
bits are these:

  MarkInstall util-linux:riscv64 < none -> 2.40.1-2 @un uN Ib > FU=0
  Installing libblkid1:riscv64 as PreDepends of util-linux:riscv64
MarkInstall libblkid1:riscv64 < none -> 2.40.1-2 @un uN > FU=0
  Installing libcap-ng0:riscv64 as PreDepends of util-linux:riscv64
MarkInstall libcap-ng0:riscv64 < none -> 0.8.5-1 @un uN > FU=0
  Installing libcrypt1:riscv64 as PreDepends of util-linux:riscv64
MarkInstall libcrypt1:riscv64 < none -> 1:4.4.36-4 @un uN > FU=0
  Installing libmount1:riscv64 as PreDepends of util-linux:riscv64
MarkInstall libmount1:riscv64 < none -> 2.40.1-2 @un uN > FU=0
  Installing libpam0g:riscv64 as PreDepends of util-linux:riscv64
MarkInstall libpam0g:riscv64 < none -> 1.5.3-7 @un uN Ib > FU=0
Installing libaudit1:riscv64 as Depends of libpam0g:riscv64
  libaudit1:riscv64 Depends on libaudit-common:riscv64 < none | 
1:3.1.2-2 @un uH > (>= 1:3.1.2-2.1) can't be satisfied!
  libpam0g:riscv64 Depends on libaudit1:riscv64 < none @un H > (>= 
1:2.2.1) can't be satisfied! (dep)
util-linux:riscv64 PreDepends on libpam0g:riscv64 < none @un H > (>= 
0.99.7.1) can't be satisfied! (dep)
[...]
Setting up usrmerge (39) ...
Can't exec "mountpoint": No such file or directory at 
/usr/lib/usrmerge/convert-usrmerge line 431.
Failed to execute mountpoint -q /lib/modules/: No such file or directory
E: usrmerge failed.
dpkg: error processing package usrmerge (--install):
 installed usrmerge package post-installation script subprocess returned 
error exit status 1

Because apt decides not to install util-linux, the usrmerge postinst fails.
This all boils down to mmdebstrap using the funny "apt dist-upgrade" trick to
let apt choose all the Essential:yes packages plus itself for the mmdebstrap
"apt" chroot variant.

How hard would it be to let apt dist-upgrade fail if it is unable to install an
Essential:yes package?

This bug is certainly wishlist and might as well be marked as wontfix without
much value being lost. But I thought that given your comment back in 2018
including your spot-on prediction (only off by one year!) I should absolutely
share this with you. :)

Thanks!

cheers, josch


47087233.gz
Description: application/gzip

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Peter Pentchev (2024-05-30 10:33:08)
> > thank you for having discussed this change on d-devel and for adding
> > documentation to NEWS and release notes to announce this change. I also
> > think it is sensible to roll this only out on new installations and to keep
> > the behaviour on existing setups. Thank you for implementing that as well.
> > 
> > That being said, maybe some Perl wizard knows how to do a flock on a 
> > directory
> > in Perl?
> 
> I wouldn't call myself a Perl wizard by a long stretch, but I can give it a 
> try :)
> 
> >  I tried this:
> > 
> > use Fcntl qw(LOCK_EX);
> > opendir(my $handle, ".") or die "opendir: $!";
> [snip]
> 
> Here lies your problem. The flock(2) syscall works on file descriptors,
> the things returned by open(2), not on the dirent structures returned by
> opendir(3). So you need something like this:
> 
> use v5.10;  # I really should switch to at least 5.16 if not 5.24
> use strict;
> use warnings;
> 
> use Fcntl qw(O_RDONLY O_DIRECTORY LOCK_EX);
> 
> my $dirname = "/tmp/to-be-locked";
> sysopen(my $handle, "/tmp/to-be-locked", O_RDONLY | O_DIRECTORY) or
> die "Could not open $dirname: $!\n";
> flock($handle, LOCK_EX) or
> die "Could not lock $dirname: $!\n";
> 
> say "locked, it seems";
> sleep(3600);'
> 
> I only put the sleep() part so I could check using lsof that
> the directory was indeed locked. And yeah, the v5.10 part is a leftover
> from the days (...until a month or two ago...) when I still had to
> support stock CentOS 7 systems; I really should train my fingers to
> put 5.24 there.
> 
> Hope that helps!

it absolutely does! Thank you! I was misled by `perldoc -f flock` which states
that it works on filehandles. I'll add your name to the git commit message
unless you object.  :)

I also found another issue with this change in systemd. After the upload to
unstable, 76 out of 264 mmdebstrap tests on jenkins.debian.net started to fail:

https://jenkins.debian.net/job/mmdebstrap-jenkins-worker/692/consoleText

The problem is, that debootstrap wants to mknod which will not work on a tmpfs
mounted with nodev:

+ debootstrap --no-merged-usr --variant=buildd oldstable /tmp/tmp.nWmx8YeAh3 
http://127.0.0.1/debian
/usr/sbin/debootstrap: 1840: cannot create /tmp/tmp.nWmx8YeAh3/test-dev-null: 
Permission denied
E: Cannot install into target '/tmp/tmp.nWmx8YeAh3' mounted with noexec or nodev

Maybe this affects more CI scripts and test setups which attempt to create a
temporary chroot with debootstrap in /tmp.

The fix which is documented in systemd NEWS makes everything work again:

--customize-hook='touch "$1/etc/systemd/system/tmp.mount"'

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1072205: prevent re-using package versions for NMUs

[Johannes Schauer Marin Rodrigues]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
User: reproducible-bui...@lists.alioth.debian.org
Usertags: infrastructure
User: ftp.debian@packages.debian.org
Usertags: dak

Hi,

the binary package bash 5.2.15-2+b3 was uploaded to the archive twice. Once to
bookworm and once to sid but with differing content. Here is a diff of their
d/changelog:

@@ -1,6 +1,6 @@
-bash (5.2.15-2+b3) bookworm; urgency=low, binary-only=yes
+bash (5.2.15-2+b3) sid; urgency=low, binary-only=yes
 
   * Binary-only non-maintainer upload for arm64; no source changes.
   * Rebuild for outdated Built-Using (glibc/2.36-9)
 
- -- arm Build Daemon (arm-ubc-03)   
Fri, 29 Mar 2024 13:22:36 +
+ -- arm Build Daemon (arm-ubc-02)   
Thu, 13 Jul 2023 09:12:53 +

This is not only confusing for apt (it will not be able to figure out which of
the two is installed because dpkg does not keep track of package hashes) but it
is also problematic for reproducible builds because the buildinfo file records
packages by their name/architecture/version tuple and relies on those to be
unique throughout the history of Debian.

This example with bash is especially problematic since bash is Essential:yes so
there will now be a large portion of buildinfo files where it is not possible
to figure out with which of the two differing bash packages the sources were
compiled.

snapshot.d.o also shows the issue and could probably be used to get an idea how
many packages are affected:

http://snapshot.debian.org/package/bash/5.2.15-2/#bash_5.2.15-2:2b:b3

Maybe this issue is blocked by #620356?

Thanks!

cheers, josch

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Luca Boccassi (2024-05-28 01:54:08)
> Thanks for the useful input, the following has been done:
> 
> - existing installations pre-trixie will get an orphaned tmpfiles.d in
> /etc/ that keeps the existing behaviour unchanged (no cleanup of
> /var/tmp)
> - openssh and tmux have been fixed to provide a tmpfiles.d exception
> to retain their respective files
> - the /tmp/ description in debian-installer has been updated to note
> it is a tmpfs by default (via a commit in partman-basicfilesystems,
> will upload if nobody gets around to it before Trixie's freeze)
> - two paragraphs have been provided for the release notes ticket
> - the changes are also noted in NEWS, with instructions on how to
> override locally
> - as mentioned, the latest upload to unstable makes /tmp/ a tmpfs by
> default and for new installations 10+ days old files in /tmp/ and 30+ days
> old files in /var/tmp/ are cleaned up daily

thank you for having discussed this change on d-devel and for adding
documentation to NEWS and release notes to announce this change. I also think
it is sensible to roll this only out on new installations and to keep the
behaviour on existing setups. Thank you for implementing that as well.

That being said, maybe some Perl wizard knows how to do a flock on a directory
in Perl? I tried this:

use Fcntl qw(LOCK_EX);
opendir(my $handle, ".") or die "opendir: $!";
flock($handle, LOCK_EX) or die "flock: $!";

And got this:

flock() on unopened filehandle $handle at test.pl line 8.
(Are you trying to call flock() on dirhandle $handle?)
flock: Bad file descriptor at test.pl line 8.

Wrapping $handle in fileno() doesn't make a difference either. Perl sources
seem to indicate that directory handles are "evil_fh"?

https://sources.debian.org/src/perl/5.38.2-4/util.c/?hl=3783#L3783

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1071031: ezurio-qcacld-2.0-dkms: several module build failures

[Johannes Schauer Marin Rodrigues]

Quoting Andreas Beckmann (2024-05-28 10:57:37)
> On 28/05/2024 10.16, Johannes Schauer Marin Rodrigues wrote:
> > But I wonder, the autopkgtest results now say (for example for arm64):
> > 
> > 657s I: Summary:
> > 657s I: PASS ezurio-qcacld-2.0/0.0~git20230623.2cd31b6 6.7.12-arm64
> > 657s I: SKIP ezurio-qcacld-2.0/0.0~git20230623.2cd31b6 6.7.12-cloud-arm64
> > 657s I: PASS ezurio-qcacld-2.0/0.0~git20230623.2cd31b6 6.7.12-rt-arm64
> > 
> > As a result, the whole test is marked as "skipped" and not "successful", so 
> > I
> 
> No. The neutral state comes from autopkgtest-pkg-dkms being 
> "superficial". As this only tests building the module but not its 
> functionality, this is only some kind of smoketest and thus has to be 
> marked "superficial". It is now possible to have "isolation-machine" 
> tests that could test module functionality (see e.g. dm-writeboost-dkms) 
> but not if this requires special hardware.

Okay, thank you!

> So there is probably no migration boost possible for most -dkms packages. But
> at least we should be able to catch build failures on new kernels earlier.
> (But that will need some work on britney as a new kernel upload does not yet
> trigger all -dkms packages.)

I don't know how the field "Testsuite: autopkgtest-pkg-dkms" gets implemented
in practice, but when just using debian/tests/control, one can add this to let
another package foo trigger the tests:

Features: test-name=hint-testsuite-triggers
Test-Command: false
Depends: foo
Restrictions: hint-testsuite-triggers

This is for example done for the package debvm:

https://sources.debian.org/src/debvm/0.3/debian/tests/control/#L15

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1071031: ezurio-qcacld-2.0-dkms: several module build failures

[Johannes Schauer Marin Rodrigues]

Hi Andreas,

I noticed that you are one of the dkms uploaders, so maybe you can answer a
follow-up question? :)

Quoting Johannes Schauer Marin Rodrigues (2024-05-27 23:45:08)
> Quoting Andreas Beckmann (2024-05-27 18:52:58)
> > On 27/05/2024 18.32, Johannes Schauer Marin Rodrigues wrote:
> > > I'm inclined to just restrict the kernel to amd64, arm64 and riscv64 as 
> > > the
> > > relevant hardware is unlikely (or rather impossible) to be found on other
> > > architectures. Or do you think that this would be a bed "solution"?
> > 
> > No objections.
> > 
> > Either make the package Architecture:  instead of all or try
> > BUILD_EXCLUSIVE_ARCH="" in dkms.conf
> > (directive exists, but I've never used it and AFAIK no other Debian 
> > package does use it; maybe needs kernel architectures instead of Debian 
> > architectures)
> > or if you can anchor it on some CONFIG_* option
> > BUILD_EXCLUSIVE_CONFIG="CONFIG_FOO !CONFIG_BAR"
> > (it's an AND-ed list, no OR possible)
> > 
> > You may need to add debian/tests/autopkgtest-pkg-dkms.conf with
> > architecture = 
> > if the package is not arch:all as autodep8 may not (be able to) take the
> > architecture list of the binary packages into account.
> 
> the package is already using:
> 
> BUILD_EXCLUSIVE_CONFIG="CONFIG_WIRELESS"
> 
> which prevents building it for the cloud kernel, for example. I read a bit 
> into
> the dkms.in sources and found that BUILD_EXCLUSIVE_ARCH is a bash regex, so I
> set it up like tihs now:
> 
> BUILD_EXCLUSIVE_ARCH="^(aarch64|x86_64|riscv64)$"
> 
> The architectures seem to be what "uname -m" is printing.

this seems to have done the trick:

https://tracker.debian.org/pkg/ezurio-qcacld-2.0-dkms

But I wonder, the autopkgtest results now say (for example for arm64):

657s I: Summary:
657s I: PASS ezurio-qcacld-2.0/0.0~git20230623.2cd31b6 6.7.12-arm64
657s I: SKIP ezurio-qcacld-2.0/0.0~git20230623.2cd31b6 6.7.12-cloud-arm64
657s I: PASS ezurio-qcacld-2.0/0.0~git20230623.2cd31b6 6.7.12-rt-arm64

As a result, the whole test is marked as "skipped" and not "successful", so I
do not get the few days migration bonus. The module is not meant to be built
for the cloud kernel, so can I somehow tell the dkms autopkgtest that so that
it only tries to build it on the kernels where it makes sense and thus the
whole test becomes "green" and not "yellow"?

It's of course no big deal if there is no way. :)

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1071031: ezurio-qcacld-2.0-dkms: several module build failures

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Andreas Beckmann (2024-05-27 18:52:58)
> On 27/05/2024 18.32, Johannes Schauer Marin Rodrigues wrote:
> > I'm inclined to just restrict the kernel to amd64, arm64 and riscv64 as the
> > relevant hardware is unlikely (or rather impossible) to be found on other
> > architectures. Or do you think that this would be a bed "solution"?
> 
> No objections.
> 
> Either make the package Architecture:  instead of all or try
> BUILD_EXCLUSIVE_ARCH="" in dkms.conf
> (directive exists, but I've never used it and AFAIK no other Debian 
> package does use it; maybe needs kernel architectures instead of Debian 
> architectures)
> or if you can anchor it on some CONFIG_* option
> BUILD_EXCLUSIVE_CONFIG="CONFIG_FOO !CONFIG_BAR"
> (it's an AND-ed list, no OR possible)
> 
> You may need to add debian/tests/autopkgtest-pkg-dkms.conf with
> architecture = 
> if the package is not arch:all as autodep8 may not (be able to) take the
> architecture list of the binary packages into account.

the package is already using:

BUILD_EXCLUSIVE_CONFIG="CONFIG_WIRELESS"

which prevents building it for the cloud kernel, for example. I read a bit into
the dkms.in sources and found that BUILD_EXCLUSIVE_ARCH is a bash regex, so I
set it up like tihs now:

BUILD_EXCLUSIVE_ARCH="^(aarch64|x86_64|riscv64)$"

The architectures seem to be what "uname -m" is printing.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1072049: please provide a link to the artifacts on the page displaying the log

[Johannes Schauer Marin Rodrigues]

Source: debci
Severity: wishlist

Hi,

when I stored artifacts for my autopkgtest job, I somehow expected the
link to download the artifacts to be shown next to the log:

https://ci.debian.net/packages/r/reform-setup-wizard/testing/s390x/47038806/

Because this is the page one is shown when clicking on failed results
via tracker.d.o

Thanks!

cheers, josch

Bug#1071031: ezurio-qcacld-2.0-dkms: several module build failures

[Johannes Schauer Marin Rodrigues]

Hi Andreas,

On Mon, 13 May 2024 10:32:23 +0200 Andreas Beckmann  wrote:
> The module fails to build for several architectures and kernel versions:
> 
> Linux 6.6.*:
> https://ci.debian.net/packages/e/ezurio-qcacld-2.0-dkms/testing/amd64/45828215/#L3674
> 243s 
> /var/lib/dkms/ezurio-qcacld-2.0/0.0~git20230623.2cd31b6/build/CORE/HDD/src/wlan_hdd_cfg80211.c:
>  In function ‘__wlan_hdd_cfg80211_change_beacon’:
> 243s 
> /var/lib/dkms/ezurio-qcacld-2.0/0.0~git20230623.2cd31b6/build/CORE/HDD/src/wlan_hdd_cfg80211.c:19956:48:
>  error: invalid use of undefined type ‘struct cfg80211_ap_update’
> 
> struct cfg80211_ap_update was introduced in Linux 6.7, so I'd recommend
> to add
> 
>   # struct cfg80211_ap_update was added in "wifi: cfg80211: split struct
>   # cfg80211_ap_settings" bb55441c57ccc5cc2eab44e1a97698b9d708871d 
> (v6.7-rc1)
>   BUILD_EXCLUSIVE_KERNEL_MIN="6.7"
> 
> to dkms.conf.

thank you, this seems sensible!

> 
> i386, Linux 6.7.*:
> ERROR: modpost: "__udivdi3" 
> [/var/lib/dkms/ezurio-qcacld-2.0/0.0~git20230623.2cd31b6/build/wlan.ko] 
> undefined!
> 
> This probably affects more 32-bit platforms.
> 
> IIRC __udivdi3 is a compiler generated function call for 
>   (long long) a / (long long) b
> for architectures that don't have native support for long long
> arithmetic. This symbol is part of libgcc_s, but that cannot be linked
> into the kernel for obvious reasons.
> I do not know the solution for this case, but this is something affecting
> more out-of-tree kernel modules.

I'm inclined to just restrict the kernel to amd64, arm64 and riscv64 as the
relevant hardware is unlikely (or rather impossible) to be found on other
architectures. Or do you think that this would be a bed "solution"?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1071736: sbuild --chroot-mode=unshare fails when /etc/resolv.conf is a symlink /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Helmut Grohne (2024-05-24 14:12:38)
> while working with debusine.debian.net, I ran into a rather crazier kind
> of issue with the unshare backend. It seems like debusine.debian.net
> creates a chroot.tar where resolv.conf is a symbolic link:
> 
> | lrwxrwxrwx 0/0   0 2024-05-20 17:15 ./etc/resolv.conf -> 
> ../run/systemd/resolve/stub-resolv.conf
> 
> Notably, /run/systemd/resolve does not exist inside the tar nor does
> sbuild run systemd-resolved nor systemd-tmpfiles for creating this
> location. When building, the unshare backend tries to bind mount
> /etc/resolv.conf:
> 
> | --: 13: cannot create /tmp/tmp.sbuild.OQ0pOU6LQg/etc/resolv.conf: Directory 
> nonexistent
> https://debusine.debian.net/artifact/427489/hostname_3.23+nmu2_amd64-2024-05-24T10:06:30Z.build
> 
> This fails, because mount attempts to dereference the symbolic link and
> finds that an intermediate directory does not exist. As a result, this
> fails and network generally does not work resulting in all sorts of
> badness.

I'm not sure where you see bind-mounting /etc/resolv.conf being done in the
$network_setup code. If network is enabled, it reads:

[ -f /etc/resolv.conf ] && cat /etc/resolv.conf > 
"$rootdir/etc/resolv.conf" || echo "nameserver 127.0.0.53" > 
"$rootdir/etc/resolv.conf";

and when it's disabled:

ip link set lo up;> "$rootdir/etc/resolv.conf";

> Technically speaking, you can bind mount onto a symbolic link. You just
> cannot do so using the mount(2) API nor the mount(1) command. Unless you
> pass MOVE_MOUNT_T_SYMLINKS to move_mount(2), it will not dereference a
> symlink being pointed at. I'm not sure we want to go this extra mile
> though.
> 
> On the debusine side, I think we want to work around this issue in some
> way to avoid imposing a high version constraint in sbuild. I am
> reporting it here as it kinda is a bug (up to your judgement) and it
> helps having the diagnosis written down.

in unshare mode, we are always working with an ephemeral chroot. Would there be
any downside to sbuild just first running "rm -f $rootdir/etc/resolv.conf" and
then re-creating it as a real file in the $network_setup snippet of
_get_exec_argv() in lib/Sbuild/ChrootUnshare.pm?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1071861: plakativ: prepare for next python3-fitz version

[Johannes Schauer Marin Rodrigues]

Hi,

On Sat, 25 May 2024 16:48:08 +0200 Bastian Germann  wrote:
> python3-fitz's exported module is going to be renamed from fitz to fitz_old
> with the next unstable revision (already in experimental). Please prepare for
> the rename.

I found this for context: https://github.com/pymupdf/PyMuPDF/discussions/2680

According to that document:

> The rebased implementation will behave identically to the classic
> implementation, and will not require any changes to user code.

or:

> You can try the rebased implementation with import fitz_new as fitz (no other
> changes to your code are needed).

or:

> Users of PyMuPDF will be able to carry on using PyMuPDF throughout the
> migration without making any changes to their code.

So I don't understand why I have to rename the import.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Aurelien Jarno (2024-05-20 11:49:32)
> > > > That's all legacy stuff and I really don't want to touch it anymore.
> > > > Going from the other side, maybe libc6.postinst could use something
> > > > more reliable than ischroot()? Is systemd-detect-virt able to figure
> > > > out the situation a bit better?
> > > Nope.
> > What's the output? With SYSTEMD_LOG_LEVEL=debug exported
> In sbuild using unshare chroot running in a VM:
> 
> | SYSTEMD_LOG_LEVEL=debug /usr/bin/systemd-detect-virt
> | Failed to read $container of PID 1, ignoring: Permission denied
> | Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
> | Found container virtualization none.
> | Virtualization QEMU found in DMI (/sys/class/dmi/id/sys_vendor)
> | UML virtualization not found in /proc/cpuinfo. 
> | Virtualization XEN not found, /proc/xen does not exist
> | Virtualization found, CPUID=KVMKVMKVM
> | Found VM virtualization kvm
> | kvm

would it help (and be correct) if PID 1 in sbuild unshare mode would have the
"container" environment variable set to something? And/or if sbuild unshare
mode would create the file /run/systemd/container with some content?

I'd need input from somebody who knows how containers (if this is one) are
supposed to work. :)

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Chris Hofstaedtler (2024-05-20 10:38:04)
> * Johannes Schauer Marin Rodrigues  [240520 07:35]:
> > [..] But maybe it [glibc's postinst] should be doing some
> > more involved checks about what PID 1 is? It could then make sure to only 
> > call
> > systemd telinit if systemd is pid 1. [..]
> 
> Well, that would probably suck. Putting the knowledge when to call
> telinit, and a specific telinit, into a ton of different things
> makes all those things hard to get right, hard to update, the usual.
> 
> I've checked the sysvinit and the systemd implementations now, and
> they are not that different. Both try to talk to their respective
> pid1 daemons first using their respective communication socket.
> 
> But then, if that doesn't work, they diverge:
> - sysvinit's telinit just gives up
> - systemd's telinit, *as an explicit fallback*, sends signals.
> 
> systemd's telinit (aka systemctl) helpfully exits if it detects
> being in a chroot, before doing any of that.
> 
> IWSTM systemd's telinit could, if called as telinit, not do the
> fallback to stick with sysvinit's behaviour?
> 
> As a bonus, sysvinit's telinit could also gain the chroot check, and glibc's
> postinst (and other places) can become simpler again.

via irc, jochen also pointed out: telinit could be the component which checks
what PID 1 actually is and only do its thing after it confirmed that it is
indeed an init system like systemd that is providing PID 1?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines

[Johannes Schauer Marin Rodrigues]

Quoting Helmut Grohne (2024-05-20 07:17:54)
> Hi Chris,
> 
> On Mon, May 20, 2024 at 01:02:32AM +0200, Chris Hofstaedtler wrote:
> > "..., when using telinit from systemd-sysv"
> > 
> > It would seem like a reasonable assumption that systemd-sysv's
> > telinit uses systemd-specific stuff, like SIGTERM.
> 
> That also is an interesting angle to it. sbuild didn't ask for systemd-sysv
> to be installed.

this might shift the bug back to glibc postinst, no? Currently, it just checks
the exit of ischroot before calling telinit. But maybe it should be doing some
more involved checks about what PID 1 is? It could then make sure to only call
systemd telinit if systemd is pid 1. And sysvinit telinit if sysvinit is pid 1
and not call telinit at all in unknown cases. Is it too much to ask for glibc
postinst to know about the PID 1 providers?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1071238: please consider cherry-picking set -e pipefail support from upstream

[Johannes Schauer Marin Rodrigues]

Package: dash
Version: 0.5.12-6
Severity: wishlist
Tags: patch

Hi,

please consider cherry-picking this patch from upstream git:

https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=6347b9fc52d742f36a0276cdea06cd9ad1f02c77

It even works fine when backported to bookworm dash :)

Before:

josch@reform:/tmp/dash-0.5.12$ dash
$ set -o pipefail
dash: 1: set: Illegal option -o pipefail

After:

josch@reform:/tmp/dash-0.5.12$ dash
$ set -o pipefail
$ echo $?
0

Thanks!

cheers, josch


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf, i386, amd64

Kernel: Linux 6.5.0-0.deb12.4-reform2-arm64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dash depends on:
ii  debianutils  5.7-0.5~deb12u1
ii  dpkg 1.21.22
ii  libc62.36-9+deb12u7

dash recommends no packages.

dash suggests no packages.

-- no debconf information

Bug#1071000: sbuild-qemu: runs lintian on .changes file with Distribution != changelog target and lintian complains

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Francesco Poli (2024-05-14 00:13:31)
> > Quoting Francesco Poli (wintermute) (2024-05-12 21:06:24)
> [...]
> > > Please note that my current setup with pbuilder does not have this issue:
> > > pdebuild generates a .changes file with 'Distribution: UNRELEASED'
> > > and with the latest changelog entry correctly quoted (with 'UNRELEASED'
> > > after the version number parenthesis), and hence lintian is happy...
> > 
> > Wait... how is Lintian happy with UNRELEASED as the changelog entry?
> 
> After digging Lintian code for a while (sorry, my Perl knowledge is just a
> smattering, and it is also a bit rusty at the time of writing!), I found the
> following [code]
> 
> # issue only when not mentioned in the Distribution field
> if ((any { $_ eq 'UNRELEASED' } @changesdists)
> && none { $_ eq 'UNRELEASED' } @distributions) {
> $self->hint('unreleased-changes');
> return;
> }
> 
> [code]: 
> <https://salsa.debian.org/lintian/lintian/-/blob/69b9209b02ab1a9e2d40d83931541ab6629f9226/lib/Lintian/Check/Fields/Distribution.pm#L135>
> 
> It seems to me that the 'unreleased-changes' tag is issued, if the
> distribution found in the Changes field is 'UNRELEASED' and the
> distribution found in the Distribution field is not 'UNRELEASED'.
> Or am I completely off-track?

yes, this is how it works. For details see bug #542747 which is also referenced
in the description of the unreleased-changes tag. More details also here:

https://salsa.debian.org/lintian/lintian/-/commit/25be3ba45884334e7e07c7643b5e4fd4ad5a21ee#note_182777

> On Sun, 12 May 2024 23:10:14 +0200 Johannes Schauer Marin Rodrigues wrote:
> [...]

> 
> [...]
> > The only difference between sbuild and pbuilder should be this:
> > 
> > >   W: $PKG_NAME: changelog-distribution-does-not-match-changes-file 
> > > unreleased != unstable [usr/share/doc/$PKG_NAME/changelog.gz:1]
> > 
> > The reason for that difference is, that sbuild-qemu calls sbuild with the -d
> > option and that overwrites the distribution field. Christian, why does
> > sbuild-qemu use the -d option?
> > 
> > But this lintian error should also be present with pbuilder:
> > 
> > >   E: $PKG_NAME changes: unreleased-changes
> > 
> > Can you clarify?
> 
> I checked by running lintian again on the .changes file generated by
> pdebuild:
> 
>   $ lintian ${PKG_NAME}_${VERSION}_${ARCH}.changes
>   
>   $ lintian -EviIL +pedantic ${PKG_NAME}_${VERSION}_${ARCH}.changes
> 
> These commands produce no output.
> 
> Assuming the above analysis of what the Perl code of Lintian actually
> does is correct, it seems the reason is that both Distribution and
> Changes have 'UNRELEASED' as distribution:
> 
>   $ grep UNRELEASED ${PKG_NAME}_${VERSION}_${ARCH}.changes
>   Distribution: UNRELEASED
>$PKG_NAME ($VERSION) UNRELEASED; urgency=medium
> 

What you observe is not specific to sbuild-qemu. You run into this when you use
the -d or --dist option with sbuild. As the man page describes, the option will
set the Distribution field of the produced .changes file to the specified
distribution name. This is not necessarily the same value as the top of
debian/changelog lists.

In general, you should avoid using -d or --dist with sbuild. But I see that
sbuild-qemu always adds this option to the sbuild call. I am unable to say why
it does that. Maybe Christian can clarify?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1071078: Skip creation of start-stop-daemon compat symlink if /sbin does not exist

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Guillem Jover (2024-05-14 10:24:09)
> When I proposed suppressing the creation of the symlink I had in mind and had
> locally the first approach, because it's less noisy, and I assume users on
> those kind of systems will have logic somewhere to handle that case anyway.

sure, works for me! Thank you! :)

> But I've been thinking that this still seems wrong from a conceptual PoV, in
> that I think base-files should be unpacked as one of, if not the first
> package as part of the bootstrapping protocol, as it encodes the structure
> and metadata for the base filesystem. I think next would be base-passwd as
> that also defines the metadata for the filesystem.
> 
> For example the symlink to dir and dir to symlink avoidance behavior
> in dpkg would be one reason for this, another is that directory
> metadata does not get updated if the directory exists, so the first
> unpack wins.
> 
> I realize that we have continuously talked about wanting to avoid
> encoding this kind of ordering in external tools, and this information
> should be part of the packages themselves (which I still think is the
> right approach). But I think we still could extend the packaging
> and/or possibly the bootstrap protocol to cover this case.
> 
> One option would be to add dependencies within the bootstrap set on
> both of these packages, but that goes counter to the no-depends on
> essential packages, and would not be safe against other external
> packages that might conflict with metadata definitions in base-files,
> but it would work for the specific dpkg issue, and perhaps that would
> be the better immediate fix. Another could be to mark these two base-*
> packages somehow so that the bootstrap tools know in a generic way
> that they need to unpack them first. I guess a field could be used,
> something like the following comes to mind:
> 
>   base-files
> Bootstrap: fsys-tree
> 
>   base-passwd
> Bootstrap: fsys-meta
> 
> (or Bootstrap-Phase or Bootstrap-Order, or …).
> 
> Where I think the order should be:
> 
>   fsys-tree → fsys-meta → rest of essential + dependencies
> 
> This does not solve the other bootstrap problem we've had in the past
> with base-files requiring passwd information from base-passwd before
> that has been unpacked, but I guess that might partially go away once
> we can declare optional paths and template-based initialization
> through fsys metadata so that the base-files maintscript can disappear
> completely. Although an external dpkg will still have a similar problem
> as base-files currently does, and will need to either assume some name
> to id mappings or use the ones from outside the chroot, but meh.
> 
> (But perhaps the solution to that last bit is for base-files to declare
> the user/groups it requires as dpkg sysusers out of previously agreed
> definitions from base-passwd, then that would make it all self-contained.)

Please note that the issue I encountered was *without* base-files installed so
this issue only exists in completely unsupported situations. Thus I think that
the fact that you now added support for it is not an argument for needing
dependencies between essential:yes packages.

Personally I prefer a new field over hard-coding package names but I prefer
even more not needing either of those. You gave the example of base-files
needing information from base-passwd and while this is correct, this dependency
can be avoided by hardcoding the needed information from base-passwd into
base-files at build time. I think helmut has proposed that in the past.

Thanks!

cheers, josch

signature.asc
Description: signature