Bug#918316: nocache: diff for NMU version 1.1-1.1

[Christoph Biedl]

Control: tags 918316 + patch pending

Dear maintainer,

to fix the issues with this package, I've prepared an NMU for nocache
(versioned as 1.1-1.1), debdiff below. An upload to DELAYED/5 will
follow shortly. Please feel free to tell me if I should delay it
longer.

Regards,

Christoph
diff -Nru nocache-1.1/debian/changelog nocache-1.1/debian/changelog
--- nocache-1.1/debian/changelog2019-01-04 04:37:54.0 +0100
+++ nocache-1.1/debian/changelog2024-06-09 18:35:07.0 +0200
@@ -1,3 +1,14 @@
+nocache (1.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Cherry-pick upstream commit "Cap the number of FDs nocache tracks
+und thus bound its memory usage" so nocache still is usable with
+increased file limits. Closes: #918316
+  * Replace test command during build with "true" so timeouts are not
+a problem. Closes: #918316 (again)
+
+ -- Christoph Biedl   Sun, 09 Jun 2024 
18:35:07 +0200
+
 nocache (1.1-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru 
nocache-1.1/debian/patches/1546932589.v1.1-2-gb3016b5.cap-the-number-of-fds-nocache-tracks-und-thus-bound-its-memory-usage.patch
 
nocache-1.1/debian/patches/1546932589.v1.1-2-gb3016b5.cap-the-number-of-fds-nocache-tracks-und-thus-bound-its-memory-usage.patch
--- 
nocache-1.1/debian/patches/1546932589.v1.1-2-gb3016b5.cap-the-number-of-fds-nocache-tracks-und-thus-bound-its-memory-usage.patch
1970-01-01 01:00:00.0 +0100
+++ 
nocache-1.1/debian/patches/1546932589.v1.1-2-gb3016b5.cap-the-number-of-fds-nocache-tracks-und-thus-bound-its-memory-usage.patch
2024-06-09 18:23:12.0 +0200
@@ -0,0 +1,78 @@
+Subject: Cap the number of FDs nocache tracks und thus bound its memory usage
+Origin: upstream, commit v1.1-2-gb3016b5 
<https://github.com/Feh/nocache/commit/v1.1-2-gb3016b5>
+Author: Julius Plenz 
+Date: Tue Jan 8 18:29:49 2019 +1100
+
+This implements option 2 layed out in issue #38.
+
+Also fix an embarassing off-by-one error.
+
+--- a/README
 b/README
+@@ -132,6 +132,11 @@
+ $ nocache -f cat ~/file.mp3
+ $ env NOCACHE_FLUSHALL=1 make test
+ 
++By default `nocache` will only keep track of file descriptors less than 1
++million that are opened by your application, in order to bound its memory
++consumption. If you want to change this threshold, you can supply the
++environment variable `NOCACHE_MAX_FDS` and set it to a higher (or lower) 
value.
++
+ 
+ Alternate Approaches
+ 
+--- a/nocache.c
 b/nocache.c
+@@ -75,6 +75,9 @@
+ static char *env_flushall = "NOCACHE_FLUSHALL";
+ static char flushall;
+ 
++static char *env_max_fds = "NOCACHE_MAX_FDS";
++static rlim_t max_fd_limit = 1 << 20;
++
+ #define DEBUG(...) \
+ do { \
+ if(debugfp != NULL) { \
+@@ -89,8 +92,16 @@
+ char *error;
+ struct rlimit rlim;
+ 
++if((s = getenv(env_max_fds)) != NULL)
++max_fd_limit = atoll(s);
++
+ getrlimit(RLIMIT_NOFILE, );
+ max_fds = rlim.rlim_max;
++if(max_fds > max_fd_limit)
++max_fds = max_fd_limit;
++
++if(max_fds == 0)
++return;  /* There's nothing to do for us here. */
+ 
+ init_mutexes();
+ /* make sure to re-initialize mutex if forked */
+@@ -398,7 +409,7 @@
+ {
+ sigset_t mask, old_mask;
+ 
+-if(fd >= max_fds)
++if(fd >= max_fds - 1)
+ return;
+ 
+ /* We might know something about this fd already, so assume we have missed
+--- /dev/null
 b/t/maxfd.t
+@@ -0,0 +1,14 @@
++#!/bin/sh
++
++NR=0
++
++. ./testlib.sh
++
++echo 1..3
++
++t "echo test > testfile.$$ && ../cachestats -q testfile.$$" "file is cached"
++t "while ../cachestats -q testfile.$$; do ../cachedel testfile.$$ && sleep 1; 
done" "file is not cached any more"
++t "env NOCACHE_MAX_FDS=1 LD_PRELOAD=../nocache.so cat testfile.$$ >/dev/null 
&& ../cachestats -q testfile.$$" "file is in cache because it has an FD > 1"
++
++# clean up
++rm -f testfile.$$
diff -Nru nocache-1.1/debian/patches/series nocache-1.1/debian/patches/series
--- nocache-1.1/debian/patches/series   2019-01-02 23:28:53.0 +0100
+++ nocache-1.1/debian/patches/series   2024-06-09 18:23:04.0 +0200
@@ -0,0 +1 @@
+1546932589.v1.1-2-gb3016b5.cap-the-number-of-fds-nocache-tracks-und-thus-bound-its-memory-usage.patch
diff -Nru nocache-1.1/debian/rules nocache-1.1/debian/rules
--- nocache-1.1/debian/rules2019-01-04 03:36:05.0 +0100
+++ nocache-1.1/debian/rules2024-06-09 18:26:20.0 +0200
@@ -18,5 +18,5 @@
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 #  -NOCACHE_NR_FADVISE=2 dh_auto_test -v
## #916415
-   timeout 11 ./nocache apt show coreutils 1>>/dev/null
+   timeout 11 ./nocache true
 endif


signature.asc
Description: PGP signature

Bug#918316: nocache: FTBFS in sid

[Christoph Biedl]

Control: severity serious

As systemd increased the limits again¹, nocache is now unusable. It's
the

| apt: nocache.c:148: init_mutexes: Assertion `fds_lock != NULL' failed.

issue, triggered as simple as issuing "nocache true" - unless the system
has several Gigabytes of RAM. As systemd certainly will not move,
nocache has to. I'll check out the upstream change and will prepare an
NMU upon success.

Christoph

¹ 
https://lists.debian.org/msgid-search/a77c773c1e8cbeadeefbd30f21e7bbeb21a9d9bc.ca...@debian.org


signature.asc
Description: PGP signature

Bug#1071321: tagging 1071321

[Christoph Biedl]

Christoph Biedl wrote...

> (and why does the BTS¹ not show Étienne's
> message?).

Never mind, just a race condition.


signature.asc
Description: PGP signature

Bug#1071321: tagging 1071321

[Christoph Biedl]

Étienne Mollier wrote...


> If that helps, the symbols strlcat and strlcpy have been added
> to the glibc 2.38, so I believe it should be safe to remove the
> following symbols without soname bump:

Just came here to say the same (and why does the BTS¹ not show Étienne's
message?). There might be a small chance this breaks packages due to
slight implementation differences - but that's what testing and
autopkgtests are for.

Christoph (affected by this bug via tcpreplay)

¹ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071321


signature.asc
Description: PGP signature

Bug#1071693: sbsign should check certificate's expiration

[Christoph Biedl]

Package: sbsigntool
Version: 0.9.4-3.1+b1
Severity: normal
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Greetings,

it was a bit surprising to learn sbsign will happily sign EFI images
even if the certificate, provided via the --cert parameter, has expired.
While this possibly will not affect functionality, it might still cause
surprising and hard-to-debug issues later.

How to repeat:

Provide an EFI image (e.g. grubx64.efi) as "kernel", and run

-
#!/bin/sh

image='kernel'

if [ ! -f "$image" ]; then
echo "E: Copy some EFI image to '$image' first"
exit 1
fi

# Generate signing key and certificate
# chronic (from moreutils), just to avoid noise
chronic \
faketime "2023/1/2" \
openssl req \
-batch \
-new \
-subj "/CN=Root CA" \
-newkey RSA:4096 \
-nodes \
-keyout root.key \
-x509 \
-days 180 \
-sha256 \
-extensions v3_ca \
-out root.crt.pem

# Show the expiration date
openssl x509 -noout -enddate -in root.crt.pem

sbsign \
--key root.key --cert root.crt.pem --output "$image.signed" "$image"
-

Expected: sbsign should at least warn about an expired certificate, or
even refuse operation.

Observed: sbsign just signs the image.


How to fix (draft):

The patch attached is rather a proof of concept: It checks the
expiration date, warns if it's less than 365 days in the future, and
exits non-zero if it's less than 30 days, or even already expired.

Todo:

* Make the thresholds configurable via command line options.
* Documentation, including "Setting the thresholds to 0 (zero) disables
  the check".
* Check the certificate(s) provided via --addcert.

Regards,

Christoph

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

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

Versions of packages sbsigntool depends on:
ii  libc6   2.38-11
ii  libssl3t64  3.2.1-3
ii  libuuid12.40.1-1

sbsigntool recommends no packages.

sbsigntool suggests no packages.

-- no debconf information

--- a/src/sbsign.c
+++ b/src/sbsign.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -156,6 +157,8 @@
 	struct sign_context *ctx;
 	uint8_t *buf, *tmp;
 	int rc, c, sigsize;
+	int maxttl_warn = 365, maxttl_crit = 30;
+	time_t now = time(NULL);
 	EVP_PKEY *pkey;
 
 	ctx = talloc_zero(NULL, struct sign_context);
@@ -255,6 +258,29 @@
 	if (!cert)
 		return EXIT_FAILURE;
 
+	ASN1_TIME *notafter = X509_getm_notAfter(cert);
+	int expired = ASN1_TIME_cmp_time_t(notafter, now);
+	if (maxttl_crit > 0) {
+		if (expired == -1) {
+			fprintf(stderr, "critical, certificate %s has expired\n", certfilename);
+			return EXIT_FAILURE;
+		}
+		time_t time_crit = now + 86400*maxttl_crit;
+		if (ASN1_TIME_cmp_time_t(notafter, time_crit) == -1) {
+			fprintf(stderr, "critical, certificate %s will expire in less than %d days\n", certfilename, maxttl_crit);
+			return EXIT_FAILURE;
+		}
+	}
+	if (maxttl_warn > 0) {
+		if (expired == -1) {
+			fprintf(stderr, "warning, certificate %s has expired\n", certfilename);
+		} else {
+			time_t time_warn = now + 86400*maxttl_warn;
+			if (ASN1_TIME_cmp_time_t(notafter, time_warn) == -1)
+fprintf(stderr, "warning, certificate %s will expire in less than %d days\n", certfilename, maxttl_warn);
+		}
+	}
+
 	const EVP_MD *md = EVP_get_digestbyname("SHA256");
 
 	/* set up the PKCS7 object */


signature.asc
Description: PGP signature

Bug#1071335: upstream commits

[Christoph Biedl]

Control: tags 1071335 pending

James Cameron wrote...

> You may be interested in these upstream commits;
> 
> b01478d ("Fix some parts of macro expansion are not guarded")
> 0194b80 ("strerror and memset require string.h")

Thanks a lot for having an eye on the Debian packaging. As you'd expect,
version 1.5 builds fine again, will do some more checks and upload
during the weekend.

Christoph


signature.asc
Description: PGP signature

Bug#1070331: RFS: nq/0.5-0.1 [NMU] -- Lightweight queue system

[Christoph Biedl]

Preuße, Hilmar wrote...

> On 03.05.2024 22:29, Christoph Biedl wrote:
> > Hilmar Preusse wrote...

> > > * Bump Standards and dh compat version, no changes needed.
> >
> > I'm a little surprised why you would change that in a NMU.
> >
> Well, this was reported by lintian. As they were no further changes needed,
> I though it would be a good idea.

Likely there are different opinions here - I prefer to make changes in an NMU
as small as possible. And was about to break my own rule by suggesting
an autopkgtest in #1038937.

> > > * Add "Conflicts: fq".
> >
> > We have a problem. Conflicts: is not enough, with both nq and fq
> > providing /usr/bin/fq, they are in violation of policy 10.1:
> >
> > | Two different packages must not install programs with different
> > | functionality but with the same filenames.
> >
>
> Thanks for pointing this out. The solution in the pull request (which
> introduced the Conflict) looked weird, but in the end #1005961 was solved
> the same (wrong) way, hence I thought it would be OK.

Yeah, to be honest, earlier I had assumed Conflicts: was sufficient to
deal with such a file name clash, too. Only to learn it the hard way in
#919697 policy is pretty straight in that regard.

And I'm not sure policy is the best way to handle this but changing it
is a different story.

> As I'm not the maintainer of either of these package I don't really feel
> responsible to solve the conflict. At first I'd reopen the bug above and
> state it as wrongly solved quoting the policy entry.

That would be necessary - although I don't know how to solve this in a
sensible way.

Sorry for disturbing your best intentions to bring nq back in shape -
but this problem will not disappear by ignoring it.

Christoph


signature.asc
Description: PGP signature

Bug#1070331: RFS: nq/0.5-0.1 [NMU] -- Lightweight queue system

[Christoph Biedl]

Hilmar Preusse wrote...

> Changes since the last upload:
> 
>  nq (0.5-0.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>  .
>* New upstream version (Closes: #1038937).

>* Bump Standards and dh compat version, no changes needed.

I'm a little surprised why you would change that in a NMU.

>* Add upstream metadata file.
>* Add "Conflicts: fq".

We have a problem. Conflicts: is not enough, with both nq and fq
providing /usr/bin/fq, they are in violation of policy 10.1:

| Two different packages must not install programs with different
| functionality but with the same filenames.

Christoph


signature.asc
Description: PGP signature

Bug#1038937: nq package out of date with upstream, 0.5 was released more than a year ago

[Christoph Biedl]

Control: tags 1038937 pending

E Harris wrote...

> nq 0.5 was released March 26, 2022 and contains several bug fixes and 
> improvements.
> nq 0.3.1 was released March 7, 2018, and is what is in all of stable, 
> testing, and unstable.
> Please update this package.

Upon request by upstream and following the statements given in
,
also there's the LowNMU flag ... I'll upload 0.5-0.1 in the next days.
To improve quality and as it was a no-brainer, I'll also add an autopkgtest.

Christoph



signature.asc
Description: PGP signature

Bug#1069915: file: wrong Breaks/Replaces in libmagic-mgc

[Christoph Biedl]

Control: tags 1069915 pending

Steve Langasek wrote...

> The time_t transition automation scripts incorrectly changed the versioned
> Breaks/Replaces against old libmagic1 to point to libmagic1t64, which
> clearly never had a package version (<< 1:5.28-4~).

... and your fellow maintainer didn't notice either.

> The attached patch fixes this mistake, although since the version in
> oldoldstable is 1:5.35-4+deb10u2, perhaps you would prefer to drop the
> fields instead.

Indeed, this was needed in 2016, will remove it in the next upload.

Christoph


signature.asc
Description: PGP signature

Bug#1068730: Fails to build from source since removal of liblz4-tool

[Christoph Biedl]

Source: systemd
Severity: serious
Tags: patch
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Greetings,

systemd build-depends on liblz4-tool but that package is no longer build
from src:lz4 (since 1.9.4-2, uploaded about a week ago). Just replacing
the dependency with lz4 seems to fix this problem (build passes, didn't
check further).

Cheers,

Christoph

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

Kernel: Linux 6.6.23 (SMP w/8 CPU threads)
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)



signature.asc
Description: PGP signature

Bug#1068640: clevis-initramfs: clevis early boot DNS fail, no resolv.conf created by ipconfig

[Christoph Biedl]

anon2529 wrote...

> The early boot fails to unlock a volume automatically. We get a
> prompt to unlock a volume (it's a swap volume) but clevis is
> unable to unlock it automatically because it cannot resolve
> the Tang server's hostname.

That ought to be fixed in clevis 20 (not uploaded yet, will do in the
next days). If you have the skills and the time, you could try to
backport

https://github.com/latchset/clevis/commit/bebb037d664185769c12cd061c2221c2d2bdb432

Christoph


signature.asc
Description: PGP signature

Bug#1067237: ngircd: missing ssl security patch in debian's ngircd package

[Christoph Biedl]

Control: tags 1067237 pending

jose wrote...

> The master branch of the upstream ngircd changelog informs about an 
> SSL security related patch [1] that is missing in the -26-1 ngircd debian
> package patches.

Thanks, this is on radar and I'm in contact with upstream on how to deal
with this.

Christoph


signature.asc
Description: PGP signature

Bug#1067838: Please provide a trivial working example

[Christoph Biedl]

Package: libresolv-wrapper
Version: 1.1.8-2+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Greetings,

while looking for a way to overload hostname resolution as non-root
(part of a test suite and/or autopkgtest), I came across your package.
However, *nothing* works, not even in the stable releases.

Assuming this is rather a "you're holding it wrong" than a grave bug in
libresolv-wrapper, I guess usage is not as easy as it seems. So can
you please provide an as-simple-as-possible example, in the tradition
of "Hello, world"?

It could be like

echo "A server1.example.com 192.0.2.1" >/tmp/hosts
LD_PRELOAD=libresolv_wrapper.so \
RESOLV_WRAPPER_HOSTS=/tmp/hosts \
$MAGIC

where the output signalizes the hostname server1.example.com was indeed
resolved into the given IP address.

These are the things I've tried without success:

* getent hosts server1.example.com
* host server1.example.com
* wget -O /dev/null http://server1.example.com/
* the actual application, using a gnutls linkage

According to strace, libresolv_wrapper.so is loaded but there is no
access to the mocked hosts file.

According to ltrace, none of the RESOLV_WRAPPER_* variables are checked
via getenv.

Not a big surpise then: Setting RESOLV_WRAPPER_DEBUGLEVEL had no effect
either.

Using , the above checks work except
for the second one. However, this project is not in Debian.

Christoph

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

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

Versions of packages libresolv-wrapper depends on:
ii  libc6  2.37-15.1

libresolv-wrapper recommends no packages.

libresolv-wrapper suggests no packages.

-- no debconf information



signature.asc
Description: PGP signature

Bug#1067457: jose: CVE-2023-50967

[Christoph Biedl]

Control: forwarded 1067457 https://github.com/latchset/jose/issues/151


signature.asc
Description: PGP signature

Bug#1066850: don't hard-code the name of the shared library

[Christoph Biedl]

Control: tags 1066850 -moreinfo +pending

Matthias Klose wrote...

> On 14.03.24 21:38, Christoph Biedl wrote:

> > Do you have an idea, an existing solution how to do that?

> dep := $(shell dpkg-query '-f${Depends}' -W libmagic-dev | sed
> 's/.*\(libmagic[a-z0-9]*\).*/\1/')
> echo "magic:Depends=$(dep)" >> debian/python3-magic.substvars
> 
> and add ${magic:Depends} to the control file.

Thanks, this is usable information.

Christoph


signature.asc
Description: PGP signature

Bug#1066850: don't hard-code the name of the shared library

[Christoph Biedl]

After getting some help in IRC, I guess the problem boils down to:

1. All architectures provide the t64 variant (libmagic1t64).
2. Some architectures no longer provide the old variant (libmagic1), for
   example armhf.
3. Therefore, the install dependency of python3-magic must be the t64 variant.

> and derive the name of the shared library package from the
> libmagic-dev package.

Now replacing one hardcoded binary library dependency with a different
one is not quite the brightest move as this will introduce work should
the libmagic ABI ever change (hasn't happened in 20 years but still).
So it was nicer to do this dynamically during build. That step however
is optional.

Do you have an idea, an existing solution how to do that?

So far I found two ways, and dislike both:

* Derive from apt-cache:

override_dh_gencontrol:
perl -MDebian::Debhelper::Dh_Lib -e \
'addsubstvar ("python3-magic", "misc:Depends", $$ARGV[0])' \
"$$(apt-cache show libmagic-dev | awk '($$1=="Depends:"){print 
$$2}' | head -n 1)"
dh_gencontrol $@

Querying the apt database from inside a package build feels like a layer
violation.

* Abuse dpkg-shlibdeps:

override_dh_gencontrol:
dpkg-shlibdeps -e /usr/bin/file -Tdebian/python3-magic.substvars
dh_gencontrol $@

(Some tweaks to debian/control needed as well.)

This also introduces an install dependency on libc6, and my gut feeling
tells me this was the point to make python3-magic arch:any.

So, is all this worth the efforts? FWIW, I maintain the libmagic
package as well, so being lazy now will just hurt me later.

Christoph


signature.asc
Description: PGP signature

Bug#1066850: don't hard-code the name of the shared library

[Christoph Biedl]

Control: tags 1066850 moreinfo

Matthias Klose wrote...

> Package: src:python-magic
> Version: 2:0.4.27-2
> Severity: serious
> Tags: sid trixie
>
> the package build-depends on libmagic1, and depends on it. The name was
> recently changed to libmagic1t64.

This is not a real problem as libmagic1t64 provides libmagic1, so the
dependency can still be resolved.

> Please don't hard-code it, but try to b-d
> on libmagic-dev, (...)

About the build dependency src:python-magic -> libmagic1:

So that is ugly, and using libmagic-dev is a simple fix for it. Will do
in the next uplad.

> and derive the name of the shared library package from the
> libmagic-dev package.

Are you still talking about the build dependency here? Then it's no
issue as the -dev dependency will take care of that.


Question: What is the justifcation for the bug severity? To me, it
is rather "minor".

Christoph


signature.asc
Description: PGP signature

Bug#1066134: FTBFS due -Werror=implicit-function-declaration

[Christoph Biedl]

Control: merge 1066134 1065940

Ups, that had already been reported.


signature.asc
Description: PGP signature

Bug#1066134: FTBFS due -Werror=implicit-function-declaration

[Christoph Biedl]

Christoph Biedl wrote...

> So, assuming this is the cause here, the fix is pretty simple:
(...)
> +#ifdef INET6
>  if (if6_is_up)
> sif6down(0);
> +#endif

This was silently done as part of

commit 80b8744eb42c7493794f3e3fe0bf1ce14f53e6dd
Author: Eivind Næss 
Date:   Fri Aug 6 09:14:02 2021 -0700

Changing INET6 to PPP_WITH_IPV6CP and adding configure option

http://git.ozlabs.org/?p=ppp.git;a=blobdiff;f=pppd/sys-linux.c;h=94e5a19ed4c67cc44f97b2257c3b0d57b4ed15a0;hp=0ffc4277b2aa4b661fae8faac27ca450596f6599;hb=80b8744;hpb=a6622771e2dc03a2682c86c4bcf6bf6ae9e85df7

Christoph



signature.asc
Description: PGP signature

Bug#1066134: FTBFS due -Werror=implicit-function-declaration

[Christoph Biedl]

Source: ppp
Version: 2.4.9-1+1.1
Severity: serious
Tags: patch upstream ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Hi Chris,

ppp no longer builds in unstable here, tested in a minimal chroot. A
build in a testing chroot passes.

sys-linux.c: In function ‘sys_cleanup’:
sys-linux.c:357:9: error: implicit declaration of function ‘sif6down’; did 
you mean ‘sifdown’? [-Werror=implicit-function-declaration]
  357 | sif6down(0);
  | ^~~~
  | sifdown

Comparing the build logs, this is obviously caused by adding
-Werror=implicit-function-declaration to the default build options.

But looking closer, it seems sif6down is declared only of INET6 is
defined, and while all other *6 invocations are guarded accordingly in
sys-linux.c, this one is not. I'm a little disturbed why the code can
even be linked then.

So, assuming this is the cause here, the fix is pretty simple:

--- a/pppd/sys-linux.c
+++ b/pppd/sys-linux.c
@@ -353,8 +353,10 @@
if_is_up = 0;
sifdown(0);
 }
+#ifdef INET6
 if (if6_is_up)
sif6down(0);
+#endif

 /*
  * Delete any routes through the device.

This matches what sys-solaris.c does. Also, pppd 2.5.0 in
experimental seems to do something like this (PPP_WITH_IPV6CP).
The build now passes, I haven't checked further.

All the best,

Christoph

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



signature.asc
Description: PGP signature

Bug#1065435: aptitude: FTBFS on armhf and armel (probably -Werror=implicit-function-declaration related)

[Christoph Biedl]

Axel Beckert wrote...

> Citing from https://buildd.debian.org/status/package.php?p=aptitude:
(...)
> /usr/include/cppunit/TestAssert.h:161:6: note:   template argument 
> deduction/substitution failed:
> ../../tests/test_misc.cc:187:5: note:   deduced conflicting types for 
> parameter ‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long int’})
>   187 | CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);
>   | ^
> make[3]: *** [Makefile:869: test_misc.o] Error 1
(...)

This happens on armel, armhf, powerpc, and hppa. Guess which
architectures I'm using ... also, aptitude is configured as b-d resolver
here for a reason but the last, pre-t64 version is no longer
installable. So I'm somewhat stuck.

Therefore, any progress on this? Do you need help? I didn't get very far
at a first glance, aptitude's build dependencies are currently
uninstallable, at least in arm{el,hf}.

Christoph


signature.asc
Description: PGP signature

Bug#748880: closed by Steven Robbins (Re: ghostscript-doc: "Raw 'bit' devices" section missing in Devices.htm)

[Christoph Biedl]

> I'm not qualified to write the upstream documentation.  Suggest you open a 
> bug 
> in the upstream bugzilla: https://bugs.ghostscript.com/

This is one of the tasks of a package maintainer:

| If it's an upstream problem, you have to forward it to the upstream
| author.
[
"Bug housekeeping"
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html
]

... and I'm very glad about that rule because it leaves the job to those
who are acquainted with upstream, their bugtracker, unwritten social
rules and so on.

Christoph


signature.asc
Description: PGP signature

Bug#1065870: Please add a hint to patch-not-forwarded-upstream

[Christoph Biedl]

Package: lintian
Version: 2.117.0
Severity: wishlist
Tags: patch
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Dear maintainer,

a few times too often I got annoyed by a "patch-not-forwarded-upstream"
warning from lintian where that wasn't actually sensible. Looking into
the lintian sources, then again into DEP-3, I realized lintian parses
the Origin: information, and people like previous-me could benefit if
lintian was a bit more clear about this.

So, I'm suggesting to enhance the Description with something like

If the patch was actually taken from upstream, prefix the Origin:
information with "upstream" or "backport", as documented in DEP-3

Kind regards,

Christoph


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

Versions of packages lintian depends on:
ii  binutils2.42-3
ii  bzip2   1.0.8-5+b2
ii  diffstat1.66-1
ii  dpkg1.22.5
ii  dpkg-dev1.22.5
ii  file1:5.45-3
ii  gettext 0.21-14+b1
ii  gpg 2.2.40-1.1+b1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.16.0-1
ii  libapt-pkg-perl 0.1.40+b5
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b3
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b3
ii  libclone-perl   0.46-1+b2
ii  libconfig-tiny-perl 2.30-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.37-1+b2
ii  libdata-dpath-perl  0.59-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-3
ii  libdevel-size-perl  0.83-2+b3
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.5
ii  libemail-address-xs-perl1.05-1+b3
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.025-1
ii  libipc-run3-perl0.049-1
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b3
ii  libperlio-utf8-strict-perl  0.010-1+b2
ii  libproc-processtable-perl   0.636-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1+b2
ii  libsereal-encoder-perl  5.004+ds-1+b2
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-2
ii  libterm-readkey-perl2.38-2+b3
ii  libtext-levenshteinxs-perl  0.03-5+b3
ii  libtext-markdown-discount-perl  0.16-1+b2
ii  libtext-xslate-perl 3.5.9-2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b3
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2+b2
ii  liburi-perl 5.27-1
ii  libwww-mechanize-perl   2.18-1
ii  libwww-perl 6.76-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b3
ii  libyaml-libyaml-perl0.89+ds-1+b1
ii  lzip [lzip-decompressor]1.24.1-1
ii  lzop1.04-2
ii  man-db  2.12.0-3
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.38.2-3.2
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.6.0-0.2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.61-1

-- no debconf information



signature.asc
Description: PGP signature

Bug#1065101: ngircd: Depends on libident, which is NBS

[Christoph Biedl]

Control: tags 1065101 pending

Boyuan Yang wrote...

> Package ngircd depends on binary package libident, but this package has
> been renamed to libident0 due to time64 transition. Please fix the binary
> dependency relationship accordingly. You may need to rebuild the package.

The fix for #1065703 needs to reach unstable first.

Christoph


signature.asc
Description: PGP signature

Bug#1065703: t64 transition broke build of other packages

[Christoph Biedl]

Source: libident
Severity: serious
Tags: patch
Version: 0.32-2
X-Debbugs-Cc: by...@debian.org, efing...@packages.debian.org, 
vor...@debian.org, debian.a...@manchmal.in-ulm.de

Control: block 1065100 by -1
Control: block 1065101 by -1

For libident, the t64 transition was done in a slightly different way:
Instead of appending t64, the library package was renamed from libident
to libident0.

While technically being a library transition, the usual steps were
obviously not done, especially: Rebuilding the reverse build
dependencies to check for possible problems. Instead some bugs were
filed against those packages, severity serious. This is at least about:

efingerd: #1065100 (maintainer Cc'ed)
ngircd: #1065101 (maintained by yours truly)

If those test rebuilds had been done, the following error could not have
been overseen (for efingerd, likewise ngircd):

(...)
   dh_makeshlibs
   dh_shlibdeps
dpkg-shlibdeps: error: no dependency information found for 
/lib/x86_64-linux-gnu/libident.so.0 (used by debian/efingerd/usr/sbin/efingerd)
Hint: check if the library actually comes from a package.
dh_shlibdeps: error: dpkg-shlibdeps -Tdebian/efingerd.substvars 
debian/efingerd/usr/sbin/efingerd returned exit code 25
dh_shlibdeps: error: Aborting due to earlier error

After spending some hours in the related tooling to understand the root
cause without avail, I suggest to modernize src:libident by replacing
.shlibs with .symbols. If solves the problem for me, and it's how things
should be done anyway.

Aside, the change also triggers an "unused-override" from lintian.

Christoph
diff --git a/debian/libident0.shlibs b/debian/libident0.shlibs
deleted file mode 100644
index f0da07c..000
--- a/debian/libident0.shlibs
+++ /dev/null
@@ -1 +0,0 @@
-libident0 0 libident0 (>= 0.32)
diff --git a/debian/libident0.symbols b/debian/libident0.symbols
new file mode 100644
index 000..550c842
--- /dev/null
+++ b/debian/libident0.symbols
@@ -0,0 +1,15 @@
+libident.so.0 libident0 #MINVER#
+* Build-Depends-Package: libident-dev
+ id_close@Base 0.32
+ id_open@Base 0.32
+ id_open_addr@Base 0.32
+ id_parse@Base 0.32
+ id_query@Base 0.32
+ id_strdup@Base 0.32
+ id_strtok@Base 0.32
+ id_version@Base 0.32
+ ident_free@Base 0.32
+ ident_id@Base 0.32
+ ident_lookup@Base 0.32
+ ident_query@Base 0.32
+ ident_query_addr@Base 0.32


signature.asc
Description: PGP signature

Bug#1065415: grub2: Work around possible failure in cpio_test

[Christoph Biedl]

Source: grub2
Version: 2.12-1
Severity: normal
Tags: patch

Dear Maintainer,

Hello,

while rebuilding grub, I encountered two issues from the test suite.
Perhaps I've already reported them but cannot find any traces of that.


One is, things go downhill in util/grub-shell if an environment
variable "debug" is set, but it seems this was fixed in newer versions
of grub (no longer found with 2.12-1, currently in testing).


Still open however: There is a limitation in cpio, it cannot deal with
an user ID above 2^21-1. If the build is done using a bigger ID, it
will just fail:

FAIL: cpio_test
===
(...)
cpio: ./: value uid 3123456 out of allowed range 0..2097151
cpio: sdir/: value uid 3123456 out of allowed range 0..2097151
cpio: sdir/2.img: value uid 3123456 out of allowed range 0..2097151
(...)

Fix, as attached: Probe for that situation, and exit gracefully.

Another solution might be using fakeroot then.

Kind regards,

Christoph

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

--- a/tests/cpio_test.in
+++ b/tests/cpio_test.in
@@ -7,6 +7,12 @@
exit 99
 fi
 
+uid="$(id -u)"
+if [ "$uid" -gt 2097151 ]; then
+   echo "User ID $uid is too big to run cpio tests"
+   exit 77
+fi
+
 "@builddir@/grub-fs-tester" cpio_bin
 "@builddir@/grub-fs-tester" cpio_odc
 "@builddir@/grub-fs-tester" cpio_newc


signature.asc
Description: PGP signature

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

[Christoph Biedl]

Chris Hofstaedtler wrote...

> You are welcome to write a new tool or implement all the missing
> parts in deborphan and deal with users thinking deborphan is a magic
> tool that knows everything and its output can be used by
> non-thinking humans. Various people in the past have suggested its
> "trivial" and "obvious" how it should work, yet we don't seem to
> have a lot of these tools that are not "partially right but also
> wrong a lot".

That's not my point.

When we remove a package from Debian, we create a situation where
users lose a feature, and it is our task to keep the inconvenience
low.

For many packages we don't even have to care - packages with an
embedded version number like libraries or python have a natural
replacement, and in general it's drawn in automatically. Packages that
no longer work (dropped kernel feature, retired API usage), well, too
bad. Packages with a low popcon count, two digits at most, tell, too
bad as well.

Packages like deborphan (popcon high four digits) fall in neither
category. Users want it, big scale. So If you think is no longer good
for the job - I trust your judgement - the remaining task is to provide
users guidance how they get this job done in the future. And that should
be part of the initial RM request without being asked for.


You pointed to the release notes. The two methods suggested there fail
miserably: On an unstable chroot here, not updated without a week, so
before the beginning of the t64 transition, deborphan reports:

  # deborphan
  libb2-1
  libcanberra0
  libhiredis0.14
  liblua5.2-0
  libmpdec3
  libnewt0.52
  libpcre3
  libsigsegv2

Which alternative tool provides this list?

The suggested alternative "apt list" - note I have to enhance the
expression since my internal distribtion is okay as well:

  # apt list '?narrow(?installed, ?not(?or(?origin(Debian),?origin(local'
  Listing... Done
  #

So, nope. Also, 38 times slower.

The suggested "apt-forktracker" seems to do the same thing as the "apt
list" command, without being extensible for other origins. So, nope.
Also, 56 times slower.


Perhaps it can be done using debfoster, but that requires some
configuration which I didn't understand in a quick test.

The last thing I found was "apt list '?garbage'" - but this lists more
packages, and I fail to see the difference. Also, 38 times slower.


This is the kind of research users of deborphan will have to to,
or they look into the net, and will possibly not get the best adivce.


My objections against removing deborphan are mostly nostalgic ones as it
served me well for more than 20 years. Quite frankly, not a real point.
So, I can live without deborphan - if it was let go with dignity. Which
means I can have a different tool that serves the purpose, being telling
me which packages can be removed from the system because they are just
cruft from old times.

My point is solely about not giving users good advice how the get
deborphan's job done. And not giving it in the first place.

Christoph


signature.asc
Description: PGP signature

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

[Christoph Biedl]

Chris Hofstaedtler wrote...

> please remove deborphan. It is stuck, featurewise, in a very old time
> and does not support many currently available dpkg features properly
> (multi-arch, versioned provides, etc).

FWIW, deborphan is part of my regular workflow, and while you claim
it has defects, it works for me pretty well.

> Given the C codebase and lack of any patches so far I do not see that
> deborphan will ever get these features, and we have other tools
> available that work, do not mess with dpkg internals and are actually
> maintained.

One day I'm going to propose to make the following a policy about
removing a package: A phrase like "alternatives exist" without further
explanation should result in an immediate -done/wontfix for lack of
information. As this is in violation of the social contract #4.

So: What are the alternatives? How do they work? Are they a drop-in
replacment or do they introduce new dependencies? Are there feature that
will be no longer supported?

Leaving users in the void about this is just bad style.

Christoph


signature.asc
Description: PGP signature

Bug#1065101: ngircd: Depends on libident, which is NBS

[Christoph Biedl]

Boyuan Yang wrote...

> Package ngircd depends on binary package libident, but this package has
> been renamed to libident0 due to time64 transition. Please fix the binary
> dependency relationship accordingly. You may need to rebuild the package.

Well, that is broken anyway at the moment:

(...)
|  dh_shlibdeps -a
|   dpkg-shlibdeps: warning: diversions involved - output may be incorrect
|diversion by libpam0t64 from: /lib/x86_64-linux-gnu/libpam.so.0
|   dpkg-shlibdeps: warning: diversions involved - output may be incorrect
|diversion by libpam0t64 to: /lib/x86_64-linux-gnu/libpam.so.0.usr-is-merged
|   dpkg-shlibdeps: error: no dependency information found for 
/lib/x86_64-linux-gnu/libident.so.0 (used by debian/ngircd/usr/sbin/ngircd)
|   Hint: check if the library actually comes from a package.
|   dh_shlibdeps: error: dpkg-shlibdeps -Tdebian/ngircd.substvars 
debian/ngircd/usr/sbin/ngircd returned exit code 2
|   dh_shlibdeps: error: Aborting due to earlier error
|   make: *** [debian/rules:8: binary] Error 25
|   dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2

So I guess the best thing to do right now is to wait until the dust around
this t64 story has settled.

Christoph


signature.asc
Description: PGP signature

Bug#1060922: Status of debian-ports

[Christoph Biedl]

Julien Cristau wrote...

> The snapshot infrastructure currently can't cope with -ports imports,
> as they take longer than the interval between pushes, for reasons.
> We'll turn it back on when we can.

Thanks for the update. If you think people can help you with that,
please let us know.

My current archive has sufficient capacity until the end of the year.

Christoph


signature.asc
Description: PGP signature

Bug#1063829: ITP: tftp-proxy -- proxy to redirect TFTP requests to HTTP

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian.a...@manchmal.in-ulm.de

* Package name: tftp-proxy
  Version : 1.0.0
  Upstream Contact: Arnoud Vermeer 
* URL : https://github.com/openfibernet/tftp-proxy
* License : Apache-2.0
  Programming Lang: Go
  Description : A TFTP server that proxies request to an HTTP
backend if a file is not found.

 This program is basically a minimalistic TFTP server. As an extra
 however, it will forward request that cannot be served to a
 configurable HTTP backend.
 .
 This is useful in a network where the actual TFTP server is relatively
 far away: Due to the simple design of TFTP, already 40ms of latency
 result in a very poor performance, tftp-proxy can shortcut that to
 network speed.
 .
 Additionally, the requests may be directed to a caching HTTP server.



signature.asc
Description: PGP signature

Bug#1062804: Improve documentation on "Tracking"

[Christoph Biedl]

Package: reprepro
Version: 5.3.1-4
Severity: minor
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Hello,

While looking for a way to include .buildinfo and .changes, I learned
about the tracking feature of reprepro. Things are working fine now, but
the ride was a bit bumpy.

So I'd like you to improve the manpage (reprepro.1) ...

Re-format the section on that topic for better readabilitly. I'm not at
all profund in .roff (and would rather switch do asciidoc, drop me a
line if you need help with that), but still: Make sure the "And any
number of the following" sentence sticks out, possibly by indenting the
keep/all/minimal items.

Clarify the default behaviour - how does reprepro behave if Tracking:
is not set? I don't know.

Explain how to add more options, might be as simple as

-And any number of the following (or none):
+And any number of the following (or none), separated by space:

Suggest to run "retrack" on all codenames as else remove/removesrc on
existing packages will fail for missing tracking information. And that
message ... see next point.

... and last, but not least, fix the wording in tracking.c:873 (and :907):

-"Could not found tracking data for %s_%s in %s to remove old files from it.\n",
+"Could not find tracking data for %s_%s in %s to remove old files from it.\n",

(assuming this is supposed to be the message).

Kind regards,

Christoph

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

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

Versions of packages reprepro depends on:
ii  libarchive13   3.7.2-1
ii  libbz2-1.0 1.0.8-5+b2
ii  libc6  2.37-14
ii  libdb5.3   5.3.28+dfsg2-4+b1
ii  libgpg-error0  1.47-3
ii  libgpgme11 1.18.0-4+b1
ii  liblzma5   5.4.5-0.3
ii  zlib1g 1:1.3.dfsg-3+b1
ii  zstd   1.5.5+dfsg2-2

Versions of packages reprepro recommends:
ii  apt  2.7.10

Versions of packages reprepro suggests:
ii  gpg-agent [gnupg-agent]  2.2.40-1.1+b1
pn  inoticoming  
ii  lzip 1.24~rc2-1
ii  pinentry-curses  1.2.1-3

-- no debconf information


signature.asc
Description: PGP signature

Bug#1062002: ngircd: Testsuite fails with openssl 3.2

[Christoph Biedl]

Sebastian Andrzej Siewior wrote...

> The testsuite fails with openssl 3.2. Please find attached upstream
> commit 287770666008b ("Test suite: Update for OpenSSL 3.x") which fixes
> the issue.

Thanks. As upstream is about to do another release, this issue will
resolve automatically. If however you plan to upload to unstable
really soon, making ngircd FTBFS, go ahead and drop me a line, I'll
do what's necessary then.

Christoph


signature.asc
Description: PGP signature

Bug#1060922: Status of debian-ports

[Christoph Biedl]

Christoph Biedl wrote...

> Looking at
>
> https://snapshot.debian.org/archive/debian-ports/
>
> it seems debian-ports was not updated for almost half a year now. If
> that was just an error, please fix it. If it was discontinued by
> intention, please place according notices - or better, re-consider your
> decision: For release architectures, there's at least archive.d.o to
> access some older versions of packages, although in a two-year interval
> only. For the ports, there's plain nothing.

Having snapshots of the debian ports is important to me. As there was no
officical reaction of any kind, I've started running my own archive,
using filesystem snapshots. However, I do not intend to make this a
public service as I lack the ressources to do this in a sane way, also
this would only be understood as a competition, life is to short for
that.

It you, future reader, need access to a particular file, drop me a line.
As processing will have to be done by hand, answers might take a while.

Christoph


signature.asc
Description: PGP signature

Bug#977716: RFP: llhttp -- parser for HTTP messages

[Christoph Biedl]

Control: retitle 977716 ITP: llhttp -- parser for HTTP messages
Control: tags 977716 pending

Christoph Biedl wrote...

> * Package name: llhttp
>   Version : 3.0.0

9.3.1 already

> The http-parser library has declared unmaintained by upstream[1],
> and this one here suggested as a solution to migrate to. Although
> probably not a simple drop-in replacement, Debian should abandon
> http-parser in favour of that one here in the long run.
>
> However, I do not wish to do the maintainership on my own. There's a lot
> of node.js involved, an area I don't feel competent do deal with.

As first projects have started migrating but nobody else has stepped up
in the past three years, and - last but not least - this seems doable ...
will take this package, still wouldn't mind if anybody else volunteers
for it.

Christoph


signature.asc
Description: PGP signature

Bug#1060922: Status of debian-ports

[Christoph Biedl]

Package: snapshot.debian.org
Severity: normal
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Greetings,

Looking at

https://snapshot.debian.org/archive/debian-ports/

it seems debian-ports was not updated for almost half a year now. If
that was just an error, please fix it. If it was discontinued by
intention, please place according notices - or better, re-consider your
decision: For release architectures, there's at least archive.d.o to
access some older versions of packages, although in a two-year interval
only. For the ports, there's plain nothing.

Christoph



signature.asc
Description: PGP signature

Bug#1060798: IPC::Run3::run3 eats the calling process' stdin

[Christoph Biedl]

Package: libipc-run3-perl
Version: 0.048-3
Severity: important
Tags: upstream
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Greetings,

Summary: When a Perl application uses IPC::Run3::run3, any unread data
on stdin is lost.

The problem has been around for a long time, I can confirm it's already
there in Debian 8 ("jessie"). My gut feeling tells me I had already 
reported that, but I cannot find any traces of that (upstream page is
not barrier-free so I cannot check there). Also, his caused quite some
data loss in one of my programs, so possibly the severity
should be even higher.

In a nutshell, if a Perl program reads from stdin, and then decides to
peruse IPC::Run3::run3, anything that is still in the input buffer is
silently discarded. It's seems it does not appears on called program's
stdin, it's just gone. Data that arrives later will be processed as usual.

How to repeat:

Use this program1, it just generates a few text lines:
-
#!/usr/bin/perl

use 5.010;
use strict;
use warnings;

my $s = join ("\n", 0..10);
print "$s\n";
-

This is program2, it reads from STDIN, prints each line, and calls
"date" if the input is "6":
-
#!/usr/bin/perl

use 5.010;
use strict;
use warnings;

use IPC::Run3;

while (defined (my $line = )) {
chomp ($line);
print "$line\n";
if ($line eq '6') {
my $out = '';
run3 (
[ 'date' ],
\undef,
\$out,
\$out,
);
print $out;
}
}
-

Then run:

./program1 | program2

Expected:
-
0
1
2
3
4
5
6

7
8
9
10
-

Got:
-
0
1
2
3
4
5
6

-

FWIW, IPC::Run::run works as expected, try
-
#!/usr/bin/perl

use 5.010;
use strict;
use warnings;

use IPC::Run;

while (defined (my $line = )) {
chomp ($line);
print "$line\n";
if ($line eq '6') {
my $out = '';
IPC::Run::run (
[ 'date' ],
\undef,
\$out,
\$out,
);
print $out;
}
}
-

Honestly, I haven't tried to fix this - in my experience subprocesses
and pipes are areas where it's fairly easy to do things wrong. Which is
why I prefer to delegate that task to some library.

So if all else fails, please place a big fat warning into IPC::Run3's
manpage to avoid other people get hit by this, too.

Christoph


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

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

Versions of packages libipc-run3-perl depends on:
ii  perl  5.38.2-3

libipc-run3-perl recommends no packages.

libipc-run3-perl suggests no packages.

-- no debconf information



signature.asc
Description: PGP signature

Bug#1060146: libnews-article-nocem-perl: Signature hash hardcoded to SHA1

[Christoph Biedl]

This topic is getting a bit bigger, perhaps let me sort first what
issues we're talking about here. So to summarize the longer text that
follows:

1. News::Article::NoCeM may embed an invalid hash algorithm declaration,
   depending on the gpg program used by PGP::Sign, and possibly other
   reasons.
2. News::Article::NoCeM uses a detached signature as an inline signature.
   This is at least bad style, and possibly fragile.
3. There are issues with NoCeMs messages in general:
   * For various reasons, they should better be multipart messages.
   * The specification is rather vague on signing.
   * There might be need to define good and acceptable hash algorithms.
4. Last, but certainly not least: The problem of very old PGP programs.

This here should mostly about the first item as this is real issue, and
something I'd like to see fixed in Debian 13 ("trixie") - I doubt it's
that urgent somebody would want to handle this in a point release.

The second is something of robustness although I'm not aware of any
actual problems caused by this. If it's easy to do, sure thing.

The rest should better be discussed elsewhere (news.admin.*,
inn-workers or whatever fits).


Russ Allbery wrote...

> I think this is a bug in News::Article::NoCeM.  It is constructing an
> inline signed document using PGP::Sign's pgp_sign function, but pgp_sign
> creates detached signatures.  Detached and inline signatures are subtly
> different, which has historically been the cause of all sorts of pain and
> suffering trying to deal with OpenPGP signatures.

#TIL

Now I'm wondering how many people know these signatures are different
things. I did not so I will not blame anyone for mixing them.

> This is explicitly called out in the PGP::Sign manual page, although it
> should be clearer since it implies the only issues are with whitespace
> munging, but it seems like there are more issues than just that.

Well, there's (emphasis mine)

| PGP::Sign - Create *detached* PGP signatures for data, securely

... but this doesn't help if people aren't even aware there is a
difference.

> I'm not sure where that leaves this bug, though.  It's quite
> understandable that News::Article::NoCeM doesn't want to implement the
> annoying logic of figuring out the correct flags to call GnuPG, but if the
> expectation for NoCeM messages is that they use inline signatures (which I
> believe is the case, although ideally they should use multipart/signed and
> application/pgp-signature), PGP::Sign doesn't do that.

All I know about a specification of NoCeM messages is Tim Skirvin's FAQ
at [1]. Which does not go into detail about the actual signature
format. So we're left with perl-nocem and derive something like a
specification from there. And yes, perl-nocem expects an inline
signature. Enhancing it to process multipart message is not impossible
but it would take years until installations out there have followed.

> I do have other
> use cases for inline signatures currently, so I am not completely opposed
> to adding that support, although the more correct thing for me to do with
> those other use cases would be to switch to multipart/signed instead.  At
> least the last time I looked, inline signatures were very poorly
> documented and standardized.

Of course I will not object if you would enhance PGP::Sign to properly
create inline signatures :-)  But I read between the lines you'd prefer
to move into a different direction.

So perhaps doing this inside News::Article::NoCeM might be an option as
well, none that I like, though. But that for upstream to decide, I've
invited them to join this discussion.

> It's possible that this specific bug could be fixed if there were a way to
> pass the desired hash algorithm into the sign() method of PGP::Sign so
> that News::Article::NoCeM can force SHA-1 as a hash algorithm, thus making
> the signature match the headers.  You suggested that in your original
> message.  That's a bit more within the remit of PGP::Sign and I feel more
> comfortable supporting that.  But I fear that may not be a full fix, since
> there's still the detached versus inline signature mismatch that I think
> is quite likely to produce more problems in the future.

As I'm already taking a lot of your time, mind to explain what problems
you are seeing here? If that might break NoCeM processing in general,
we should take precautions.

> (And of course
> there's also the problem that News::Article::NoCeM really should be using
> SHA-256, but that raises backwards compatibility issues.  There are a lot
> of ancient PGPs out there in Usenet world.)

It looks like perl-nocem was written for GnuPG only. Are there any
other implementations that handle NoCeMs? My impression is news admins
who want to process NoCeMs must install GnuPG.

And the NoCeMs I generate, with SHA512, were - once the Hash: header
was correct - handled without a 

Bug#1060146: libnews-article-nocem-perl: Signature hash hardcoded to SHA1

[Christoph Biedl]

Russ Allbery wrote...

> Christoph Biedl  writes:
>
> > * Omitting the hash declaration is not an option either, perl-nocem
> >   fails then.
>
> I'm somewhat surprised by this, as my impression was that these Hash lines
> are optional and GnuPG did the right thing if they were omitted entirely
> (although you do still need a blank line).

That impression was on my side as well, and later the surprise. It would
habe been a quick solution.

It seems that pseudo-header is mandatory but I haven't checked further:
https://sources.debian.org/src/gnupg2/2.2.40-1.1/g10/sig-check.c/?hl=188#L188

So, a blank line doesn't help. The message by gpgv is

| gpgv: Signature made Fri Jan  5 18:21:01 2024 UTC
| gpgv:using RSA key 87FB8F9D33883045A832B4FFD90D76CC97A7B20D
| gpgv: WARNING: signature digest conflict in message
| gpgv: Can't check signature: General error

and this leads to an error message from perl-nocem:

| Article : unknown error (ID D90D76CC97A7B20D)

where "WARNING: signature digest conflict in message" is the same as
I had seen in the first place, when there was the hardcoded "SHA1".

For completeness, this is gpgv 2.2.40-1.1, from Debian 12 ("bookworm").
Also, neither the NoCeM message nor the key are publicly available.

> I have not looked into this in
> detail, but I thought the hash algorithm was also present in metadata
> inside the signature itself.

It is indeed present there, I used pgpdump to reveal the hash algorithm
is actually SHA512. So this is a design decision I don't quite follow,
but possibly there is or was a need to do things that way.

(...)

> perl-nocem itself doesn't seem to care and just copies the whole input
> into a temporary file for GnuPG.  What's the nature of the failure?  Is
> GnuPG failing to validate the resulting file if the hash algorithm is
> omitted?

See above.

Christoph


signature.asc
Description: PGP signature

Bug#1060146: libnews-article-nocem-perl: Signature hash hardcoded to SHA1

[Christoph Biedl]

Package: libnews-article-nocem-perl
Version: 0.09-3
Severity: important
Tags: upstream
X-Debbugs-Cc: libpgp-sign-p...@packages.debian.org, 
debian.a...@manchmal.in-ulm.de

Greetings,

At the moment, NoCeM messages generated using News::Article::NoCeM
declare a hard-coded signature hash algorithm SHA1:

|  $self->add_body("-BEGIN PGP SIGNED MESSAGE-");
|  $self->add_body("Hash: SHA1");
[ll.202]

This broke NoCeM processing here as the actual algorithm used was
SHA512, and the verification in INN2's perl-nocem fails then (took a
while to find out as the only way to debug perl-nocem is strace, and
there was only a warning about a hash algorithm mismatch. But changing
the above line made the problem go away).

Following the robustness principle, the fix should be here, in
News::Article::NoCeM. That however will be a bit delicate as I doubt
this will be easy.

Some *bad* ideas:

* In my setup, signing is done using gpg (i.e. gpg2). Perhaps enforcing
  gpg1 resolves the issue - I haven't checked - but that's not the
  direction we should go.

* Enforcing SHA1 in the signing might be doable (but not easy), still,
  no. That algorithm should be phased out.

* Hard-coding a different algorithm is a no-go, for bad style to start
  with.

* News::Article::NoCeM could inspect the generated signature and
  act accordingly. This adds a lot of code and feels pretty wrong.

* Omitting the hash declaration is not an option either, perl-nocem
  fails then.

So I guess this will require some co-ordination with PGP::Sign (Cc'd).

It seems the latter does not provide an option to define the hash
algorithm, unless perhaps via GnuPG's configuration file. That's
somehting News::Article::NoCeM could do by switching to the OO interface
of PGP::Sign. But at the same time, this voids a nonoutspoken goal of
making GPG::Sign backend-agnostic (having more than gpg1 and gpg2 was
desireable but that's something for another day).

Another solution I can think of: PGP::Sign could, as an option, already
provide the marker lines with a correct pseudo header about the hash
algorithm, so News::Article::NoCeM does not have to do this. Or at
least signalize the proper value. But there's nothing of that kind as
far as I can see.


But these are just thoughts - I'm looking for a robust way to generate
NoCeMs and if that goal is met, I care little how this is actually done.

Christoph

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

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

Versions of packages libnews-article-nocem-perl depends on:
ii  libnews-article-perl  1.27-12
ii  libpgp-sign-perl  1.04-1
ii  perl  5.36.0-7+deb12u1

libnews-article-nocem-perl recommends no packages.

libnews-article-nocem-perl suggests no packages.

-- no debconf information



signature.asc
Description: PGP signature

Bug#1059975: gkrellm-radio: Please move from liblircclient-dev to liblirc-dev

[Christoph Biedl]

Control: tags 1059975 pending

Gianfranco Costamagna wrote...

> In order to achieve this we found a total of 8 packages still using the old 
> one,
> so I'm asking you to update it and let us drop that old cruft from src:lirc.

Sure thing. Force-ping me if this is still open within in two weeks
from now.

Christoph


signature.asc
Description: PGP signature

Bug#1056676: /usr/share/wireshark/manuf is gone

[Christoph Biedl]

Bálint Réczey wrote...

> Technically it is possible, but is there a use case where "tshark -G"
> is not sufficient already?

That would be good enough, thanks. So, problem solved for me, feel free
to close or to wait until somebody else complains about any other file
now missing.

Oh, and just in case anybody else stumbles across this: To get the
actual manufacturer list, "tshark -G manuf" does the trick.

Christoph


signature.asc
Description: PGP signature

Bug#1056960: aoetools: Installs files into /lib, /sbin

[Christoph Biedl]

Control: tags 1056960 pending

Chris Hofstaedtler wrote...

> your package aoetools installs some files into /lib and /sbin. I
> understand this was to support split-/usr installs in the past.

Telling stories, this was a deliberate change by an earlier maintainer
of aoetools. I wanted to revert that anyway, but the tne moratorium
happenened. Good thing this is history now.

> For the ongoing UsrMerge effort [1], these directories should become
> "empty", IOW packages should not install into these directories, but
> instead into /usr.

[1] Dangling footnote error :-)

Sure thing, and just another bit: I noticed qualified program names in
the init script that could see an adjustment as well. So in case you're
scanning the entire archive for adjustments like here, you might want to
point at such places as well. Adside from that, I'll remove these full
paths, in the spirit of policy 6.1.

> I think aoetools could move these files now. I am guessing that aoetools
> would not see backports; if it did, please note that such changes must be
> reverted for bookworm (or earlier).

Backports are not planned but thanks for the reminder.

Christoph


signature.asc
Description: PGP signature

Bug#1056898: pptpd: Build failures with ppp-2.5.0

[Christoph Biedl]

Control: tags 1056898 pending

Chris Boot wrote...

> Please could you try the patch and test the pptpd-logwtmp.so pppd
> plugin, and upload the package to unstable?

Test is looking good, I've also sent upstream a notice about that.

> I'll upgrade the bug to RC when I upload ppp-2.5.0 to unstable.

Okay, just let me know when it's a good time to upload an updated
pptpd package.

Christoph



signature.asc
Description: PGP signature

Bug#1056676: /usr/share/wireshark/manuf is gone

[Christoph Biedl]

Package: libwireshark-data
Version: 4.2.0-1
Severity: normal
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Greetings,

ealier version of the libwireshark-data package shipped a file
/usr/share/wireshark/manuf that holds a list of MAC vendors. However,
it's no longer present in 4.2.0-1, along with several other files.

Was that done by intention? Briefly looking into upstream it seems the
raw data is still there but some additional step are needed to build
the data file.

Anyway, can you bring it back?

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#1056279: Symlinks in /usr/lib/molly-guard/ are gone after upgrade

[Christoph Biedl]

Christoph Biedl wrote...

> after upgrading from 0.7.2 to 0.8.1, the symlinks in /usr/lib/molly-guard/
> are gone.

It was suggested in IRC this might be the effect of another package's
upgrade. I find that unlikely since no other package should touch
/usr/lib/molly-guard/ - still, here's the upgrade list after that I
found the change:

2023-11-19 18:50:51 upgrade bsdutils:ppc64 1:2.39.2-5 1:2.39.2-6
2023-11-19 18:50:53 upgrade coreutils:ppc64 9.1-1 9.4-2
2023-11-19 18:50:55 upgrade libsmartcols1:ppc64 2.39.2-5 2.39.2-6
2023-11-19 18:50:56 upgrade util-linux-extra:ppc64 2.39.2-5 2.39.2-6
2023-11-19 18:50:57 upgrade util-linux:ppc64 2.39.2-5 2.39.2-6
2023-11-19 18:51:04 upgrade mount:ppc64 2.39.2-5 2.39.2-6
2023-11-19 18:51:05 upgrade systemd-dev:all 254.5-1 255~rc2-2
2023-11-19 18:51:06 upgrade libblkid1:ppc64 2.39.2-5 2.39.2-6
2023-11-19 18:51:07 upgrade libuuid1:ppc64 2.39.2-5 2.39.2-6
2023-11-19 18:51:08 upgrade libfdisk1:ppc64 2.39.2-5 2.39.2-6
2023-11-19 18:51:09 upgrade libmount1:ppc64 2.39.2-5 2.39.2-6
2023-11-19 18:51:10 upgrade systemd:ppc64 254.5-1 255~rc2-2
2023-11-19 18:51:13 upgrade libsystemd-shared:ppc64 254.5-1 255~rc2-2
2023-11-19 18:51:14 upgrade libsystemd0:ppc64 254.5-1 255~rc2-2
2023-11-19 18:51:15 upgrade molly-guard:all 0.7.2 0.8.1

Note: The timestamp of /usr/lib/molly-guard/ fits here:
drwxr-xr-x 2 root root 4096 2023-11-19 18:52:08.994207913 +0100 
/usr/lib/molly-guard/

2023-11-19 18:52:08 upgrade systemd-sysv:ppc64 254.5-1 255~rc2-2
2023-11-19 18:52:09 upgrade libdb5.3:ppc64 5.3.28+dfsg2-3 5.3.28+dfsg2-4
2023-11-19 18:52:10 upgrade zlib1g:ppc64 1:1.2.13.dfsg-3 1:1.3.dfsg-2
2023-11-19 18:52:12 upgrade libelf1:ppc64 0.189-4 0.190-1
2023-11-19 18:52:13 upgrade libtirpc-common:all 1.3.3+ds-1 1.3.4+ds-1
2023-11-19 18:52:14 upgrade libtirpc3:ppc64 1.3.3+ds-1 1.3.4+ds-1
2023-11-19 18:52:16 upgrade iproute2:ppc64 6.5.0-5 6.6.0-1
2023-11-19 18:52:19 upgrade libgpg-error0:ppc64 1.47-2 1.47-3
2023-11-19 18:52:20 upgrade udev:ppc64 254.5-1 255~rc2-2
2023-11-19 18:52:21 upgrade libudev1:ppc64 254.5-1 255~rc2-2
2023-11-19 18:52:23 upgrade mawk:ppc64 1.3.4.20230808-1 1.3.4.20231102-1
2023-11-19 18:52:23 upgrade fdisk:ppc64 2.39.2-5 2.39.2-6
2023-11-19 18:52:24 upgrade vim-nox:ppc64 2:9.0.2087-1 2:9.0.2103-1
2023-11-19 18:52:25 upgrade vim:ppc64 2:9.0.2087-1 2:9.0.2103-1
2023-11-19 18:52:26 upgrade vim-common:all 2:9.0.2087-1 2:9.0.2103-1
2023-11-19 18:52:28 upgrade vim-runtime:all 2:9.0.2087-1 2:9.0.2103-1
2023-11-19 18:52:32 upgrade autopkgtest:all 5.31 5.31.1
2023-11-19 18:52:33 upgrade bsdextrautils:ppc64 2.39.2-5 2.39.2-6
2023-11-19 18:52:35 upgrade libglib2.0-0:ppc64 2.78.1-3 2.78.1-4
2023-11-19 18:52:36 upgrade libio-socket-ssl-perl:all 2.083-1 2.084-1
2023-11-19 18:52:37 upgrade libmaxminddb0:ppc64 1.7.1-1 1.8.0-1
2023-11-19 18:52:38 upgrade libsasl2-modules-db:ppc64 2.1.28+dfsg1-3 
2.1.28+dfsg1-4
2023-11-19 18:52:38 upgrade libsasl2-2:ppc64 2.1.28+dfsg1-3 2.1.28+dfsg1-4
2023-11-19 18:52:39 upgrade pci.ids:all 0.0~2023.08.10-1 0.0~2023.09.22-1

Hope this is helpful,

Christoph



signature.asc
Description: PGP signature

Bug#1056279: Symlinks in /usr/lib/molly-guard/ are gone after upgrade

[Christoph Biedl]

Package: molly-guard
Version: 0.8.1
Severity: grave
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Greetings,

after upgrading from 0.7.2 to 0.8.1, the symlinks in /usr/lib/molly-guard/
are gone. As this happened on a second machine today, I reckon it's not
a coincidence.


Current state:

# ls -l /usr/lib/molly-guard/
total 8
-rwxr-xr-x 1 root root   99  5. Okt 00:17 coldreboot
-rwxr-xr-x 1 root root 3365 11. Nov 23:02 molly-guard


Old state:

# ls -l /usr/lib/molly-guard/
total 7
-rwxr-xr-x 1 root root   99  5. Okt 00:17 coldreboot
lrwxrwxrwx 1 root root   14 30. Sep 12:34 halt -> /bin/systemctl
-rwxr-xr-x 1 root root 2847  9. Jul 2019  molly-guard
lrwxrwxrwx 1 root root   14 30. Sep 12:34 poweroff -> /bin/systemctl
lrwxrwxrwx 1 root root   14 30. Sep 12:34 reboot -> /bin/systemctl
lrwxrwxrwx 1 root root   14 30. Sep 12:34 shutdown -> /bin/systemctl


This is the upgrade log:

Preparing to unpack .../molly-guard_0.8.1_all.deb ...
No diversion 'diversion of /sbin/pm-hibernate by molly-guard', none removed.
No diversion 'diversion of /sbin/pm-suspend by molly-guard', none removed.
No diversion 'diversion of /sbin/pm-suspend-hybrid by molly-guard', none 
removed.
Adding 'diversion of /usr/sbin/halt to /usr/lib/molly-guard/halt by molly-guard'
Leaving 'diversion of /sbin/halt to /lib/molly-guard/halt by molly-guard'
Adding 'diversion of /usr/sbin/poweroff to /usr/lib/molly-guard/poweroff by 
molly-guard'
Leaving 'diversion of /sbin/poweroff to /lib/molly-guard/poweroff by 
molly-guard'
Adding 'diversion of /usr/sbin/reboot to /usr/lib/molly-guard/reboot by 
molly-guard'
Leaving 'diversion of /sbin/reboot to /lib/molly-guard/reboot by molly-guard'
Adding 'diversion of /usr/sbin/shutdown to /usr/lib/molly-guard/shutdown by 
molly-guard'
Leaving 'diversion of /sbin/shutdown to /lib/molly-guard/shutdown by 
molly-guard'
Adding 'diversion of /usr/sbin/coldreboot to /usr/lib/molly-guard/coldreboot by 
molly-guard'
Leaving 'diversion of /sbin/coldreboot to /lib/molly-guard/coldreboot by 
molly-guard'
Removing 'diversion of /usr/sbin/pm-hibernate to /lib/molly-guard/pm-hibernate 
by molly-guard'
Adding 'diversion of /usr/sbin/pm-hibernate to 
/usr/lib/molly-guard/pm-hibernate by molly-guard'
Removing 'diversion of /usr/sbin/pm-suspend to /lib/molly-guard/pm-suspend by 
molly-guard'
Adding 'diversion of /usr/sbin/pm-suspend to /usr/lib/molly-guard/pm-suspend by 
molly-guard'
Removing 'diversion of /usr/sbin/pm-suspend-hybrid to 
/lib/molly-guard/pm-suspend-hybrid by molly-guard'
Adding 'diversion of /usr/sbin/pm-suspend-hybrid to 
/usr/lib/molly-guard/pm-suspend-hybrid by molly-guard'
Unpacking molly-guard (0.8.1) over (0.7.2) ...
dpkg: warning: unable to delete old directory '/lib/molly-guard': Directory not 
empty
Setting up molly-guard (0.8.1) ...


The resultat is a major problem, hence the severity: Trying to shut down
or reboot just triggers an error:

# shutdown -P
E: not a regular file: /usr/lib/molly-guard/shutdown

(Workaround: Manually restore the links.)

Looking into the maintainer scripts, I see some changes were done. Can
you please re-check they to the right thing?

Regards,

Chri- "diversions are a nightmare" stoph


signature.asc
Description: PGP signature

Bug#1055808: fsck at boot always skipped due to APM_EMULATION kernel option

[Christoph Biedl]

Package: e2fsprogs
Version: 1.47.0-2+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Greetings,

Summary: If the APM_EMULATION kernel option is enabled (and built-in),
fsck during boot may be skipped all the time.

Longer story: One day I noticed some virtual machines have huge "mount
count" values, and "next check after" at a date far in the past. (I have
enable_periodic_fsck set.) After some research I learned I had (by
accident) enabled the APM_EMULATION kernel option. So /proc/apm exists
but has more or less static content[1]. The important part is is_on_batt
in e2fsck/unix.c which reads the AC status as 0xff ("unknown"), and
effectively treats this as "on battery".

So may I ask you to re-visit that check in that regard? I'll disable
that option anyway, other people still might get into trouble because
of that.

All the best,
Christoph

[1] proc_apm_show in drivers/char/apm-emulation.c
Example output: "1.13 1.2 0x02 0xff 0xff 0xff -1% -1 ?"

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

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

Versions of packages e2fsprogs depends on:
ii  libblkid12.39.2-5
ii  libc62.37-12
ii  libcom-err2  1.47.0-2+b1
ii  libext2fs2   1.47.0-2+b1
ii  libss2   1.47.0-2+b1
ii  libuuid1 2.39.2-5
ii  logsave  1.47.0-2+b1

Versions of packages e2fsprogs recommends:
pn  e2fsprogs-l10n  

Versions of packages e2fsprogs suggests:
ii  e2fsck-static  1.47.0-2+b1
pn  fuse2fs
pn  gpart  
ii  parted 3.6-3

-- Configuration Files:
/etc/mke2fs.conf changed [not included]

-- no debconf information



signature.asc
Description: PGP signature

Bug#1053418: RM: libppd -- ROM; Dead upstream, binary package name collision

[Christoph Biedl]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: lib...@packages.debian.org, g...@packages.debian.org, 
till.kamppe...@gmail.com, debian.a...@manchmal.in-ulm.de
Control: affects -1 + src:libppd

Greetings,

As previously announced in #1052056 ("Intent To Remove: src:libppd"),
I'm asking you to remove the libppd package from Debian unstable.

The ressons boil down to:

First, upstream is dead, last release was in 2002-ish (by looking at
the latest timestamp in the orig.tar).

Second, some binary package names collide with a different libppd
implementation provided by CUPS. Several months ago I made an attempt to
resolve this by renaming the package here, but I gave up on this -
besides some obstacles I've changed my mind and doubt all this was worth
the efforts. (An RM for that libppd-legacy package will follow shortly.)


There is one reverse dependency outstide src:libppd, it's the gpr
package. It's likewise upstream-dead and dropped out of testing
recently for other reasons, and I doubt it's going to come back. The
maintainer was included in the Intent To Remove above, no reaction.

Christoph (maintainer of src:libppd)


signature.asc
Description: PGP signature

Bug#1053395: Resolving valgrind dependency, take 2

[Christoph Biedl]

Package: pv
Version: 1.8.0-2
Severity: wishlist
Tags: patch
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Hi there,

thanks for resolving the valgrind dependency issue for armel and a few
more release archs. Unfortunatly, there are several port archs where pv
still fails to build. As a solution, may I ask you to build-depend on
valgrind-if-available instead? That solved the problem on all archs I
rebuild pv - except x32 which has other issues, and for quite some time
already.

Christoph


signature.asc
Description: PGP signature

Bug#1052683: ITP: railway -- GUI application for searching train journeys

[Christoph Biedl]

Arnaud Ferraris wrote...

> * Package name: railway
>   Version : 2.0.0
>   Upstream Contact: Julian Schmidhuber 
> * URL : https://gitlab.com/schmiddi-on-mobile/railway
> * License : GPL
>   Programming Lang: Rust
>   Description : GUI application for searching train journeys
>
> Railway is a graphical application allowing one to look up travel information
> for many different railways, all without needing to navigate through different
> websites.

As Deutsche Bahn is currently disimproving their timetable website big
scale, I'm quite interested in having this. Let me know if you're
looking for testers.

And aside, if you happen to bump into upstream, it would be great if
that application could honor $https_proxy, or allow running behind a
proxy by other means - using tsocks as a soxifier didn't work. And I
could use an export of a selected journey in some machine-readable
format.

Christoph


signature.asc
Description: PGP signature

Bug#1052632: clevis FTBFS when systemd.pc changes systemdsystemunitdir

[Christoph Biedl]

Control: tags 1052632 moreinfo

Helmut Grohne wrote...

> We want to change the value of systemdsystemunitdir in systemd.pc to
> point below /usr. clevis' upstream build system consumes this value, but
> the debian packaging hard codes its current value. When it changes,
> clevis will fail to build from source. Consider applying the attached
> patch to avoid that.

While I'm certainly willing to help with everything that helps to end
the usrmerge mess, I'm a little confused when comparing this with the
recent changes requested in #1052278

Mind to give a hint what I should do? Drop the version in experimental
and use that one instead? Or ...?

Christoph



signature.asc
Description: PGP signature

Bug#1052421: ITP: control -- Python Control Systems Library

[Christoph Biedl]

Kurva Prashanth wrote...

> * Package name: control
>   Version : 0.9.4
>   Upstream Author :  >
> * URL : http://python-control.org/

While I cannot judge whether this package is a sensible addition to
Debian - I strongly ask you to re-consider the package name as "control"
can apply to many different areas, and is therefore not helping when
trying to figure if that package helps in a particular situation.
Also, as there's the debian/control file in each source package, this
will create some confusion and possibly even to users asking you for
help with their packaging.

Just from the above website, perhaps something like
python-feedback-control-systems or a bit shorter variant would be more
appropriate. I might be wrong.

Christoph


signature.asc
Description: PGP signature

Bug#1052255: libmagic1:amd64: magic.5: warnings and errors from "mandoc -T lint"

[Christoph Biedl]

Control: reopen 1052255

Closed that one by accident, sorry for the mess.



signature.asc
Description: PGP signature

Bug#1052255: libmagic1:amd64: magic.5: warnings and errors from "mandoc -T lint"

[Christoph Biedl]

Control: reopen 1052255D 

Closed that one by accident, sorry for the mess.


signature.asc
Description: PGP signature

Bug#1052278: clevis-systemd: move systemd units from / to /usr

[Christoph Biedl]

Control: tags 1052278 pending

Helmut Grohne wrote...

> we're trying to finalize the /usr-merge transition. In the process, I
> ask you to move the remaining files from / to /usr. In your source
> package, only two files are affected and both are systemd units. Such a
> move violates the file move moratorium. If you restructure this package
> after applying this patch, please upload to experimental first. dumat[1]
> will look for problems and file an RC bug. For further information,
> please refer to https://wiki.debian.org/UsrMerge and
> https://subdivi.de/~helmut/dep17.html or consider asking.

After some clarification behind the curtain, I'll upload an according
version to experimental in the next hours.

Thanks for work on unmessing the usrmerge story.

Christoph


signature.asc
Description: PGP signature

Bug#1052056: Intent To Remove: src:libppd

[Christoph Biedl]

Source: libppd
Version: 2:0.10-9
Severity: important
X-Debbugs-Cc: g...@packages.debian.org, debian.a...@manchmal.in-ulm.de, 
till.kamppe...@gmail.com

The libppd package is very old software with little use (maximum popcon
is 148 for libppd0). As far as I understand, it was created by taking
bits from a (today horribly outdated) version of CUPS, added some value
and called it a day.

Years passed, and among other annoyances, there is now a package name
clash on libppd-dev, it could be provided by CUPS as well, and already
does in Ubuntu.

To resolve that problem I tried renaming the binary packages to
something with a "legacy" in it, after some discussion with Till
Kamppeter (CC'id) - that approach however wasn't quite well received. So
instead I now intent to remove src:libppd entirely, I doubt it will be a
great loss.

The last reverse dependency of libppd is gpr (Cc'ed) which doesn't quite
have a huge popcon counter either and is about to be removed sooner or
later for depending on gtk2, see https://bugs.debian.org/1050359

If you have objections, please voice them now. Current plan is to file
the RM in about a week.

Christoph, maintainer of src:libppd



signature.asc
Description: PGP signature

Bug#1051083: Please fix autopkgtest regression with file 1.45

[Christoph Biedl]

Source: nutsqlite
Version: 2.0.6-3
Severity: important
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Bonjour,

the latest upstream version of the file package introduced a detection
of SQLite write-ahead shared memory files. As a result, the autopkgtest
of nutsqlite breaks when using that version (1:5.45-1, currently in
experimental).

autopkgtest log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/n/nutsqlite/37303558/log.gz

Please change run-unit-test

| test "$(file nut.db-shm | awk '{print $2}')" = 'data'

to something that, for the time being, can handle both this and the
future output of file(1), the first one can go away in the future.

It might be something like (untested):

```
test "$(file nut.db-shm | awk '{print $2}')" = 'data' ||
test "$(file nut.db-wal | awk '{print $2, $3, $4, $5}')" = 'SQLite Write-Ahead 
Log shared memory,'
```

This regression will prevent the file package from migrating to testing,
so I'd appreciate if implementing this wouldn't take too long.

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#1042953: smokeping: Recommends non-existing package 'echoping'

[Christoph Biedl]

Control: tags 1042953 + patch pending

IOhannes m zmölnig (Debian/GNU) wrote...

> The current version of smokeping in Debian (2.7.3-4.1) still depends on
> 'echoping' which was removed from the archives on 2020-08-07, so the
> last release that shipped it was buster (currently: old-old-stable).

For reference: The removal bug against echoping was
https://bugs.debian.org/1002897 and ultimately the removal was on 2022-01-02,
according to https://ftp-master.debian.org/removals-2022.txt

> Please remove this dependency (as it violates Debian policy §2.2.1, see
> https://www.debian.org/doc/debian-policy/ch-archive.html#the-main-archive-area)

Since echoping is optional in smokeping and I'm glad to confirm that
package otherwise does what it's supposed to do, the fix is trivial, so
here we go:

Dear maintainer,

to fix the issues with this package, I've prepared an NMU for smokeping
(versioned as 2.7.3-4.2), debdiff below. An upload to DELAYED/5 will
follow shortly. Please feel free to tell me if I should delay it
longer.

Regards,

Christoph
diff -Nru smokeping-2.7.3/debian/changelog smokeping-2.7.3/debian/changelog
--- smokeping-2.7.3/debian/changelog2022-10-15 12:46:49.0 +0200
+++ smokeping-2.7.3/debian/changelog2023-09-02 11:50:51.0 +0200
@@ -1,3 +1,11 @@
+smokeping (2.7.3-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove recommendation on echoping which is no longer in Debian.
+Closes: #1042953
+
+ -- Christoph Biedl   Sat, 02 Sep 2023 
11:50:51 +0200
+
 smokeping (2.7.3-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru smokeping-2.7.3/debian/control smokeping-2.7.3/debian/control
--- smokeping-2.7.3/debian/control  2022-04-24 20:44:58.0 +0200
+++ smokeping-2.7.3/debian/control  2023-09-02 11:41:39.0 +0200
@@ -49,7 +49,6 @@
 Recommends: apache2 | httpd-cgi
  , libsocket6-perl
  , dnsutils
- , echoping
  , ${misc:Recommends}
 Suggests: curl
  , libauthen-radius-perl


signature.asc
Description: PGP signature

Bug#1050426: u3-tool: Please add loong64 to architecture list

[Christoph Biedl]

Control: tags 1050426 pending

JiaLing Zhang wrote...

> Please add loong64 to architecture list. I can confirm this could build in 
> loong64 .

Will do. Testing a stick on that architecture would be the icing on the
cake but I'm aware these stick are really hard to get these days. Still
it's prudent to assume things will just work fine.

Christoph


signature.asc
Description: PGP signature

Bug#856877: Bug#983423: Bug#856877: schroot: Please mount a new instance of /dev/pts

[Christoph Biedl]

Simon McVittie wrote...

> 2½ years later, updating a debootstrap merge request reminded me that this
> is unresolved. I see schroot now has a new maintainer and a new upstream:
> please consider applying the patch proposed here to set up a working
> /dev/ptmx and /dev/console in more situations.

Thanks, I'll have a look into that.

> I don't currently have a codeberg account set up, so I haven't proposed
> this at the new upstream yet. I'll try to do that and mark this bug as
> forwarded.

That wouldn't be necessary as it's the same people anyway.

Christoph


signature.asc
Description: PGP signature

Bug#999946: syslog-ng: depends on obsolete pcre3 library

[Christoph Biedl]

Matthew Vernon wrote...

> Your package still depends on the old, obsolete PCRE3[0] libraries
> (i.e. libpcre3-dev). (...)

Greetings,

now that syslog-ng has dropped out of testing a few weeks ago, I'd
really like to see this issue resolved.

It seems the latest upstream release 4.3.1 has the necessary changes
included, but with the Debian version (3.38.1) *that* far behind trying
to cherry-pick is not a good idea, I've tried and failed.

Instead I suggest to move forward to 4.3.1. The attached debdiff
contains the changes needed for the debian/ directory to make the build
pass and make at least the syslog-ng-core package work with some
limitations, see below.

Please take this as a suggestion. If I should make this a full NMU, let
me know. It might take a while, though. And frankly, I sadly lack the
ressources to become a co-maintainer.

Issues and open tasks:

* Re-visit all the changes, some were rather wild-guessed.
* Update shipped configuration, currently there are warnings:

| WARNING: Configuration file format is too old, syslog-ng is running in 
compatibility mode. Please update it to use the syslog-ng 4.3 format at your 
time of convenience. To upgrade the configuration, please review the warnings 
about incompatible changes printed by syslog-ng, and once completed change the 
@version header at the top of the configuration file; config-version='3.38'
| WARNING: Your configuration file uses an obsoleted keyword, please update 
your configuration; keyword='stats_freq', change='Use the stats() block. E.g. 
stats(freq(1));', location='/etc/syslog-ng/syslog-ng.conf:10:4'

* autopkgtest fails here
  * "basic" possibly just because there's another syslog running.
  * "testinitscript" because it assumes a /tmp/autopkgtest-reboot that
does not exist.
* Remove kfreebsd references, it's history (sadly)

Cheers,

Christoph
diff --git a/debian/changelog b/debian/changelog
index 016dea9..2e45d4d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+syslog-ng (4.3.1-0.1) unstable; urgency=high
+
+  * Non-maintainer upload
+  * New upstream version 4.3.1
+  * Switch to the pcre2 library. Closes: #999946
+
+ -- Christoph Biedl   Sun, 30 Jul 2023 
12:04:27 +0200
+
 syslog-ng (3.38.1-5) unstable; urgency=medium
 
   * Build without Criterion support.
diff --git a/debian/control b/debian/control
index f8a6c90..3bbd4a2 100644
--- a/debian/control
+++ b/debian/control
@@ -20,7 +20,7 @@ Build-Depends: debhelper (>= 10~),
libbson-dev,
libjson-c-dev | libjson0-dev,
libwrap0-dev,
-   libpcre3-dev,
+   libpcre2-dev,
libcap-dev [linux-any],
libsystemd-dev [linux-any],
libhiredis-dev,
diff --git a/debian/not-installed b/debian/not-installed
index 801ef60..dbce7c8 100644
--- a/debian/not-installed
+++ b/debian/not-installed
@@ -3,3 +3,4 @@ usr/share/syslog-ng/include/scl/hdfs/plugin.conf
 usr/share/syslog-ng/include/scl/elasticsearch/elastic-java.conf
 usr/lib/syslog-ng/syslog-ng/libtest/libsyslog-ng-test.a
 usr/lib/*/pkgconfig/syslog-ng-test.pc
+usr/bin/syslog-ng-update-virtualenv
diff --git 
a/debian/patches/0001-Replace-direct-md5sum-file-access-with-dpkg-verify-c.patch
 
b/debian/patches/0001-Replace-direct-md5sum-file-access-with-dpkg-verify-c.patch
deleted file mode 100644
index 2fafa27..000
--- 
a/debian/patches/0001-Replace-direct-md5sum-file-access-with-dpkg-verify-c.patch
+++ /dev/null
@@ -1,25 +0,0 @@
-From: Attila Szalay 
-Date: Sat, 3 Sep 2022 22:45:40 +0100
-Subject: Replace direct md5sum file access with dpkg --verify calls
-
-Closes: #905680

- contrib/syslog-ng-debun | 5 -
- 1 file changed, 4 insertions(+), 1 deletion(-)
-
-diff --git a/contrib/syslog-ng-debun b/contrib/syslog-ng-debun
-index 7a7bb2e..49c5f0b 100755
 a/contrib/syslog-ng-debun
-+++ b/contrib/syslog-ng-debun
-@@ -963,7 +963,10 @@ debun_extra_debian () {
-   printf "\nDebian specific checks\n"
-   printf "Check package files integrity\n"
-   cd /
--  md5sum --quiet -c /var/lib/dpkg/info/syslog-ng*.md5sums && printf 
"Package files are intact\n"
-+  for package in $(dpkg -l syslog-ng\* | grep "ii" | awk -F " " '{print 
$2}')
-+  do
-+  dpkg --verify ${package} && printf "Package ${package} files 
are intact\n"
-+  done
-   printf "list syslog-related packages\n"
-   dpkg -l |grep syslog > ${tmpdir}/deb.packages
- }
diff --git a/debian/patches/series b/debian/patches/series
index 70fa123..e9fa1bb 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1 @@
-0001-Replace-direct-md5sum-file-access-with-dpkg-verify-c.patch
 0002-Update-control-file-path.patch
diff --git a/debian/rules b/debian/rules
index 4ca7f75..fd4a6d2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -114,6 +114,7 @@ o

Bug#1043458: libhttp-parser-dev multi-arch hints

[Christoph Biedl]

Control: tags 1043458 pending

Jan Smets wrote...

> Can you please add the Multi-Arch hints to the debian/control file.

Sure thing.

Christoph


signature.asc
Description: PGP signature

Bug#1040467: file: /sys/firmware/acpi/bgrt/image strange behaviour

[Christoph Biedl]

Control: tags 1040467 upstream

fr...@gmail.com wrote...

> UEFI systems make the boot logo accessible for reading at the path 
> /sys/firmware/acpi/bgrt/image
>
> The file can be displayed directly using for example:
> $ feh /sys/firmware/acpi/bgrt/image
>
> Strange things happen when you copy this file elsewhere:
> $ cp /sys/firmware/acpi/bgrt/image /tmp/image
>
> and then run `file` on it:
> $ file /sys/firmware/acpi/bgrt/image /tmp/image
> /sys/firmware/acpi/bgrt/image: data
> /tmp/image:PC bitmap, Windows 3.x format, 434 x 432 x 24, 
> image size 565056, cbSize 565110, bits offset 54

While that particular sysfs file does not exist on my system, there's
already enough clue to get an idea what is happening here, and you
already almost got it:

(...)
> If you then diff those logfiles, you can notice that that
> /tmp/sys-firmware-acpi-bgrt-image.log only uses nbytes=4096, whereas
> /tmp/tmp-image.log uses nbytes=565110.

This difference comes from the read() syscall file/libmagic does to get
the file content: When reading a file in /sys/, that call only reads
4096 bytes and returns an according result. However, some bits used to
identify the file are likely beyond that limit. To confirm, try file on
the first 4096 bytes only, this should again result in "data", or:

$ dd if=/tmp/image bs=4096 count=1 | file -
data

As a workaround, you could again use file(1) in a pipe, i.e.

$ 

signature.asc
Description: PGP signature

Bug#1038750: file.1: a few remarks and editorial fixes for the manual

[Christoph Biedl]

Control: tags 1038750 confirmed
Control: forwarded 1038750 
https://mailman.astron.com/pipermail/file/2023-July/001201.html

Bjarni Ingi Gislason wrote...

> here are some notes and fixes for the man page.

Thanks, now forwarded upstream where applicable, the rest fixed locally.

Christoph


signature.asc
Description: PGP signature

Bug#1041041: file: superflous 0 prepended to serial number in ntfs filesystem detection

[Christoph Biedl]

Control: tags 1041041 confirmed
Control: forwarded 1041041 
https://mailman.astron.com/pipermail/file/2023-July/001200.html

sowg09+39vc9e5tpgdtw@cs.email wrote...

(...)

> I propose that `file` should either drop the leading 0, so that it
> shows 34f5ee1202469ff7, or it should put an 'x' after the leading
> zero, like 0x34f5ee1202469ff7 similarly to how it does it for FAT32
> filesystems.

Well spotted, now forwarded to upstream.

Cheers,

Christoph


signature.asc
Description: PGP signature

Bug#1040924: clevis-udisks2: Depends on NBS libblockdev-crypto2

[Christoph Biedl]

Michael Biebl wrote...

> If (bookworm-) backports are a concern, you might also use something like
> this
> 
> -libblockdev-crypto2,
> +udisks2 (>= 2.10) | libblockdev-crypto2,

Thanks for the suggestion, will adjust the still-not-yet-happened upload.

Christoph


signature.asc
Description: PGP signature

Bug#1040924: clevis-udisks2: Depends on NBS libblockdev-crypto2

[Christoph Biedl]

Control: Tags 1040924 +pending

Jeremy Bícha wrote...

> Yes, it's a transition. Sorry that it didn't follow the recommended procedure.

Thanks for the clarification. New version is underway, I'd like to do
some thourough testing, though.

Christoph


signature.asc
Description: PGP signature

Bug#1040924: clevis-udisks2: Depends on NBS libblockdev-crypto2

[Christoph Biedl]

Control: tags 1040924 moreinfo

Jeremy Bícha wrote...

> clevis-udisks2 depends on libblockdev-crypto2 which is no longer built
> by libblockdev in Unstable. Please update the manual dependency to
> libblockdev-crypto3

I fail to understand what is happening here. Is this supposed to be a
transition? Then it didn't quite follow the procedure as outlined in
https://wiki.debian.org/Teams/ReleaseTeam/Transitions

Christoph


signature.asc
Description: PGP signature

Bug#1040668: bullseye-pu: package tang/8-3+deb11u1

[Christoph Biedl]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@packages.debian.org
Control: affects -1 + src:tang

This is the bullseye version of #1040646

[ Reason ]
Fix https://security-tracker.debian.org/tracker/CVE-2023-1672 for
Debian 11 ("bullseye"), tagged "no-dsa (minor)" by the security team.

The problem of creating key material without restrictive file
permissions probably existed upstream since always. Up to and including
Debian 10 ("buster") however, this situation was caught by enforcing
restrictive permissions on the key directory.

With Debian 11 ("bullseye") a change in the creation of that directory
caused it to be created with a too permissive mode.

[ Impact ]
Without the change being accepted, the directory that holds the private
key would stay world-readable. Also this would continue to put users at
risk who configured a different key directory but did not enforce
restrictive access permissions.

[ Tests ]
No automated tests I'm aware of. Of course I did a manual test, and the
outcome matched the expectations.

[ Risks ]
The changes are small and rather straight-forward. I'd be surprised if
they introduce problems.

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

[ Changes ]
* Assert restrictive permissions of the key directory in Debian's
  postinst.
  For regular users and new instaaltions.
* Upstream's change to create the key file with restrictive
  permissions.
  Mostly for users who configure a different key directory.
* Recommend a key rotation in setups where this seems wise, add
  some details in NEWS.Debian.
* Make the key rotation program executable as it should always
  have been.

Regards,

Christoph

diff -Nru tang-8/debian/changelog tang-8/debian/changelog
--- tang-8/debian/changelog 2021-12-16 20:47:10.0 +0100
+++ tang-8/debian/changelog 2023-07-08 12:41:29.0 +0200
@@ -1,3 +1,14 @@
+tang (8-3+deb11u2) bullseye; urgency=high
+
+  * Fix CVE-2023-1672:
+- Cherry-pick "Fix race condition when creating/rotating keys"
+- Assert restrictive permissions on tang's key directory
+In existing multi-user bullseye installations, rotating the keys
+is suggested.
+  * Make the tangd-rotate-keys program executable
+
+ -- Christoph Biedl   Sat, 08 Jul 2023 
12:41:29 +0200
+
 tang (8-3+deb11u1) bullseye-security; urgency=high
 
   * Fix data leak [CVE-2021-4076]
diff -Nru 
tang-8/debian/patches/bullseye/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
 
tang-8/debian/patches/bullseye/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
--- 
tang-8/debian/patches/bullseye/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
   1970-01-01 01:00:00.0 +0100
+++ 
tang-8/debian/patches/bullseye/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
   2023-07-08 12:41:29.0 +0200
@@ -0,0 +1,73 @@
+Subject: Fix race condition when creating/rotating keys (#123)
+Origin: v13-3-g8dbbed1 <https://github.com/latchset/tang/commit/v13-3-g8dbbed1>
+Upstream-Author: Sergio Correia 
+Date: Wed Jun 14 10:53:20 2023 -0300
+
+When we create/rotate keys using either the tangd-keygen and
+tangd-rotate-keys helpers, there is a small window between the
+keys being created and then the proper ownership permissions being
+set. This also happens when there are no keys and tang creates a
+pair of keys itself.
+
+In certain situations, such as the keys directory having wide open
+permissions, a user with local access could exploit this race
+condition and read the keys before they are set to more restrictive
+permissions.
+
+To prevent this issue, we now set the default umask to 0337 before
+creating the files, so that they are already created with restrictive
+permissions; afterwards, we set the proper ownership as usual.
+
+Issue reported by Brian McDermott of CENSUS labs.
+
+Fixes CVE-2023-1672
+
+
+Reviewed-by: Sergio Arroutbi 
+Signed-off-by: Sergio Correia 
+
+--- a/src/keys.c
 b/src/keys.c
+@@ -17,6 +17,7 @@
+  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+  */
+ 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -304,6 +305,9 @@
+ const char** hashes = supported_hashes();
+ const char* alg[] = {"ES512", "ECMR", NULL};
+ char path[PATH_MAX];
++
++/* Set default umask for file creation. */
++umask(0337);
+ for (int i = 0; alg[i] != NULL; i++) {
+ json_auto_t* jwk = jwk_generate(alg[i]);
+ if (!jwk) {
+--- a/src/tangd-keygen
 b/src/tangd-keygen
+@@ -27,6 +27,9 @

Bug#1040646: bookworm-pu: package tang/11-2

[Christoph Biedl]

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

[ Reason ]
Fix https://security-tracker.debian.org/tracker/CVE-2023-1672 for
Debian 12 ("bookworm"), tagged "no-dsa (minor)" by the security team.

The problem of creating key material without restrictive file
permissions probably existed upstream since always. Up to and including
Debian 10 ("buster") however, this situation was caught by enforcing
restrictive permissions on the key directory.

With Debian 11 ("bullseye") a change in the creation of that directory
caused it to be created with a too permissive mode. That will be
addressed in a separature upload that requires more testing.

For Debian 12 ("bookworm"), this request here, stricter permissions were
already implemented and they are enforced during upgrade, however with a
small window during installation of the package.

[ Impact ]
The small time window as mentioned above will stay. Also this would
continue to put users at risk who configured a different key directory
but did not enforce restrictive access permissions.

[ Tests ]
None that I'm aware of.

[ Risks ]
The changes are small and rather straight-forward. I'd be surprised if
they introduce problems.

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

[ Changes ]
* Assert restrictive permissions of the key directory in Debian's
  postinst.
  For regular users and new instaaltions.
* Upstream's change to create the key file with restrictive
  permissions.
  Mostly for users who configure a different key directory.

Regards,

Christoph

diff -Nru tang-11/debian/changelog tang-11/debian/changelog
--- tang-11/debian/changelog2022-10-15 15:00:56.0 +0200
+++ tang-11/debian/changelog2023-07-08 12:49:07.0 +0200
@@ -1,3 +1,11 @@
+tang (11-2+deb12u1) bookworm; urgency=medium
+
+  * Fix CVE-2023-1672. Closes: #1038119
+- Cherry-pick "Fix race condition when creating/rotating keys"
+- Assert restrictive permissions on tang's key directory
+
+ -- Christoph Biedl   Sat, 08 Jul 2023 
12:49:07 +0200
+
 tang (11-2) unstable; urgency=medium
 
   * Tighten access permissions of the key directory
diff -Nru 
tang-11/debian/patches/bookworm/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
 
tang-11/debian/patches/bookworm/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
--- 
tang-11/debian/patches/bookworm/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
  1970-01-01 01:00:00.0 +0100
+++ 
tang-11/debian/patches/bookworm/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
  2023-07-08 12:49:07.0 +0200
@@ -0,0 +1,66 @@
+Subject: Fix race condition when creating/rotating keys (#123)
+Origin: v13-3-g8dbbed1 <https://github.com/latchset/tang/commit/v13-3-g8dbbed1>
+Upstream-Author: Sergio Correia 
+Date: Wed Jun 14 10:53:20 2023 -0300
+
+When we create/rotate keys using either the tangd-keygen and
+tangd-rotate-keys helpers, there is a small window between the
+keys being created and then the proper ownership permissions being
+set. This also happens when there are no keys and tang creates a
+pair of keys itself.
+
+In certain situations, such as the keys directory having wide open
+permissions, a user with local access could exploit this race
+condition and read the keys before they are set to more restrictive
+permissions.
+
+To prevent this issue, we now set the default umask to 0337 before
+creating the files, so that they are already created with restrictive
+permissions; afterwards, we set the proper ownership as usual.
+
+Issue reported by Brian McDermott of CENSUS labs.
+
+Fixes CVE-2023-1672
+
+
+Reviewed-by: Sergio Arroutbi 
+Signed-off-by: Sergio Correia 
+
+--- a/src/keys.c
 b/src/keys.c
+@@ -307,6 +307,9 @@
+ {
+ const char* alg[] = {"ES512", "ECMR", NULL};
+ char path[PATH_MAX];
++
++/* Set default umask for file creation. */
++umask(0337);
+ for (int i = 0; alg[i] != NULL; i++) {
+ json_auto_t* jwk = jwk_generate(alg[i]);
+ if (!jwk) {
+--- a/src/tangd-keygen.in
 b/src/tangd-keygen.in
+@@ -38,6 +38,10 @@
+ [ $# -eq 3 ] && sig=$2 && exc=$3
+ 
+ THP_DEFAULT_HASH=S256 # SHA-256.
++
++# Set default umask for file creation.
++umask 0337
++
+ jwe=$(jose jwk gen -i '{"alg":"ES512"}')
+ [ -z "$sig" ] && sig=$(echo "$jwe" | jose jwk thp -i- -a 
"${THP_DEFAULT_HASH}")
+ echo "$jwe" > "

Bug#1038119: tang: CVE-2023-1672

[Christoph Biedl]

Salvatore Bonaccorso wrote...

> CVE-2023-1672[0]:
> | Fix race condition when creating/rotating keys
> 
> Please adjust the affected versions in the BTS as needed.

As I'm very short of time today, first in words only:

* Debian sid will see a new upstream version (containing the fixes)
  in the next hours.
* Debian 12 ("bookworm") and 11 ("Bullseye") will be fixed via an
  upcoming point release.
* Debian 10 ("buster") is *not* affected, tight permissions of the
  directory holding the keys were asserted.

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#1035465: tmpfs.5 refers to removed kernel option CONFIG_TRANSPARENT_HUGE_PAGECACHE

[Christoph Biedl]

Package: manpages
Version: 6.03-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Dear maintainer,

the tmpfs.5 manpages states in the description of the huge= mount option:

| Set the huge table memory allocation policy for all files in this
| instance (if CONFIG_TRANSPARENT_HUGE_PAGECACHE is enabled).

That kernel option was removed more than three years ago, in commit
v5.6-11468-g396bcc5299c2 ("mm: remove CONFIG_TRANSPARENT_HUGE_PAGECACHE").
Reading the commit message, it's possibly sufficient to refer to
CONFIG_TRANSPARENT_HUGEPAGE instead, but I might be completely wrong
here.

This problem still exists in upstream version 6.04.

Christoph

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


signature.asc
Description: PGP signature

Bug#612863: devscripts: please preserve timestamps in the dget script

[Christoph Biedl]

Christoph Biedl wrote...

> James Vega wrote...
> 
> > On Fri, Feb 11, 2011 at 08:03:40AM +, Aníbal Monsalve Salazar wrote:
> > > Please preserve timestamps in the dget script. I'm using the patch
> > > below to pass the -N option to wget. I don't know the corresponding
> > > option for curl.
> > 
> > What use is this in the context of dget?
> 
> Call it compability with apt-get source which does preserve the
> timestamps.
> 
> Or just eye-candy.
> 
> Or, although rather personal: An .orig.tar.gz with a timestamp of more
> or less "now" is an alarm sign to me: In the past I saw that only if
> that tar ball was re-generated, something that was very likely not
> intended.
> 
> > Also, your patch doesn't change the current behavior at all
> > since wget ignores -N when -O is being used (which dget does).
> 
> Indeed, dget using wget always worked as expected here, read:
> timestamps were preserved. Aníbal, I suspect you have an .wgetrc
> interfering, causing you to suggest "-N".
> 
> The trouble for me started when curl was installed and preferred by
> dget, since the "-R" (long form is better: "--remote-time") option is
> needed for curl. I'm not including the trivial patch, however it works
> for me.

Seems this was resolved in 2.23.0 after the request came up again in
#1020914

Christoph


signature.asc
Description: PGP signature

Bug#1034353: mime-type: image/jpeg instead of image/jls

[Christoph Biedl]

Control: tags 1034353 confirmed upstream

Mathieu Malaterre wrote...

> % wget -O filelogo.jls
> "https://bugs.astron.com/file_download.php?file_id=214=bug;
> % file --mime-type filelogo.jls
> filelogo.jls: image/jpeg
> 
> However upstream claims this is fixed since 5.41, some kind of regression ?

Upstream regression, bisect led to

commit 19d5ac6c83fb5d0d9a3868f0f6f2709b1f11882f
Author: Christos Zoulas 
Date:   Sat Aug 28 12:30:52 2021 +

restore jpeg strength to beat msdos boot sector

Christoph


signature.asc
Description: PGP signature

Bug#1031684: python-magic: new upstream version available 0.4.27

[Christoph Biedl]

Control: tags 1031684 moreinfo

Hans-Christoph Steiner wrote...

> There is a new bugfix version available from upstream.  It would be
> nice to have that in bookworm, and there is still time before the hard
> freeze if it is uploaded now.  I can contribute there if that is
> needed to make this happen.

The delta between 0.4.26 (in Debian) and 0.4.27 upstream is minimal,
just a version number bump. If there's anything else after the 0.4.27
release that justifies another upload, let me know.

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#1031206: Typo in logrotate snippet

[Christoph Biedl]

Package: redis
Version: 5:7.0.8-2
Severity: minor
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Greetings,

it seems redis 5:7.0.8-2 wanted to add the "delaycompress" keyword to
the logrotate snippet but a missing letter will void that.

You're not alone, though:
https://codesearch.debian.net/search?q=compess=1

Cheers,

Christoph



signature.asc
Description: PGP signature

Bug#1031077: Should resolve error codes to text when sending e-mail

[Christoph Biedl]

Package: watchdog
Version: 5.16-1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Today, for the first time in years, watchdog was able to send an e-mail
before resetting the system - I guess usually this is triggered that
fast the message doesn't get through.

But that message wasn't really helpful:

| Message from watchdog:
| The system will be rebooted because of error 253!

A glance into the manpage (I was faster checking the sources, though)
is needed to resolve that into a textual description. However, there's
already a function "wd_strerror" that does this job.

So that one could be used in "send_email" to provide more helpful
messages. Or did I miss a reason to not do this?

Christoph



signature.asc
Description: PGP signature

Bug#1022180: shim: non-standard gcc used for build (gcc-10)

[Christoph Biedl]

user debian-rele...@lists.debian.org
usertags 1022180 + bsp-2023-01-ch-stcergue
thank you

@maintainer:

Excuse my bluntness, but is there a reason to *not* just replace "10"
with "12" as shown below, and previously done in commit 334e9afa
("Switch to using gcc-10 rather than gcc-9. Closes: #978521")?
The resulting shimx64.efi boots fine here.

Christoph

--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends: debhelper-compat (= 12),
   sbsigntool,
   openssl,
   libelf-dev,
-  gcc-10,
+  gcc-12,
   dos2unix,
   pesign (>= 0.112-5),
   xxd,
diff --git a/debian/rules b/debian/rules
index 6228fcc..c630fa7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -45,7 +45,7 @@ COMMON_OPTIONS += \
VENDOR_DBX_FILE=$(DBX_LIST) \
EFIDIR=$(distributor) \
CROSS_COMPILE=$(DEB_HOST_GNU_TYPE)- \
-   CC=$(DEB_HOST_GNU_TYPE)-gcc-10 \
+   CC=$(DEB_HOST_GNU_TYPE)-gcc-12 \
$(NULL)

 $(DBX_LIST): $(DBX_HASHES)



signature.asc
Description: PGP signature

Bug#934923: clevis: [dracut-initqueue] cryptsetup: command not found

[Christoph Biedl]

Christoph Biedl wrote...

> After finally sorting things out: Unlocking in early userland using
> dracut works like a charm here, both with tang and tpm pins.

Still cannot reproduce, and no update in years. Hence closing.


signature.asc
Description: PGP signature

Bug#908117: RFP: yq -- yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.

[Christoph Biedl]

Varac wrote...

> * Package name: yq
>   Version : 2.1.2
>   Upstream Author : Mike Farah 
> * URL : http://mikefarah.github.io/yq/

Hello everybody,

it's been a while ... bookworm freeze is getting closer, and I'd like to
find a solution for the current problems providing an "yq" program to
handle yaml documents.

To sum it up:

* This ITP originally was about an implementation in Go ("go", by
  mikefarah)
  Pros:
  + (Possibly) faster
  + The first one in this thread
* There is another implementation in pure Python ("python", by kislyuk)
  Pros:
  + Simple
  + By design behaviour identical to jq
* The respective upstream are not willing to resolve the name clash

In the meantime, there is a new player around, called "fq"
, a somewhat Swiss army knife wrt
supported formats. Written in Go as well, it is available in bookworm.
Backporting to bullseye is at least not trivial.


Now my main interest was to have something as /usr/bin/yq, not just for
me but for everybody.

Ideas:

1. Co-existence

Debian ships both variants but with different binary names like "yq-go",
"yq-python" or "yq-mikefarah" and "yq-kislyuk". Using Debian's
alternatives system, user can set their preferred variant.

Pros:
+ Provides all flavours

Cons:
- Maintainance overhead
- Users might be confused because /usr/bin/yq is not what they expect
  (generic problem with alternatives)

2. Giving up the Go variant in favour of fq, ship only "python"

Assuming "go" and fq overlap a lot, one might argue there's little use
in providing both. So there would by "python" as the "yq" program for
the simple use cases, everybody else please refer to fq.

Pros:
+ Packaging "python" should be simple and backportable

Cons:
- Anything specific to "go" is not available.

3. (your idea here)


Thoughts?

Christoph

¹ Fun story, years ago I implemented a little brother of "python", a
  simple Perl script that reads YAML and pipes it to jq. Not at all
  proud of it, and I'll be happy to ditch it.



signature.asc
Description: PGP signature

Bug#849782: .apk files not consistently detected

[Christoph Biedl]

Control: tags 849782 pending

Hans-Christoph Steiner wrote...

> APKs can be a totally standard JAR with a valid JAR signature, and they
> can be assembled with any tool that can make a valid ZIP archive with a
> valid JAR signature.  The vast majority of APKs are made with the same
> toolchain, e.g. the Android SDK. (...)

The next upload of file (1:5.44-2) should happen within the next week and will
see massive improvement of APK file detection. That should also solve the
problems here. If not, please reopen then.

Christoph



signature.asc
Description: PGP signature

Bug#1026920: New upstream version of file/libmagic breaks autopkgtest

[Christoph Biedl]

Control: tags 1026920 patch

Christoph Biedl wrote...

> It took a few hours to realize locale setting ruin your day. I could
> reproduce that only with LC_ALL=C, and then bisecting led to:
> 
> commit f448f3e5c37de8c285ac14b032b2bdcea82fc08b
> Author: Christos Zoulas 
> Date:   Sat May 28 01:04:57 2022 +
> 
> PR/351: CathyKMeow: octalify unprintable characters in filenames 
> unless raw.

... and there is a command-line option to bypass this.

So this should do the trick, worked for me:

--- a/lib/Lintian/Index/FileTypes.pm
+++ b/lib/Lintian/Index/FileTypes.pm
@@ -72,7 +72,7 @@ sub add_file_types {
 my @files = grep { $_->is_file } @{$self->sorted_list};
 my @names = map { $_->name } @files;
 
-my @command = qw(file --no-pad --print0 --print0 --);
+my @command = qw(file --raw --no-pad --print0 --print0 --);
 
 my %file_types;
 

Cheers,

Christoph


signature.asc
Description: PGP signature

Bug#1026920: New upstream version of file/libmagic breaks autopkgtest

[Christoph Biedl]

Louis-Philippe Véronneau wrote...

> Lintian runs file (more precisely, `file --no-pad --print0 --print0 --`)
> to get the "file_type" value of files [1].

Very exhausting debugging¹ reveals lintian has that file_type set to the
empty string. Obviously this causes ...

> Then, for all the files in "/usr/share/man/", it verifies .gz files are indeed
> gz-compressed with this perl regex match [2]:
> 
> if ($item->file_type !~ m/gzip compressed data/)

... this check to fail, and things go downhill from there.

> I built the test files Lintian uses for the autopkgtest and when
> I run file 1:5.43-3 on it, I do get an output that should match that regex:
> 
> -
> foo@bar:/tmp/foo/usr/share/man/man1# file -v
> > file-5.43
> > magic file from /etc/magic:/usr/share/misc/magic
> 
> foo@bar:/tmp/foo/usr/share/man/man1# file "鳥の詩.1.gz"
> > \351\263\245\343\201\256\350\251\251.1.gz: gzip compressed data, max 
> > compression, from Unix, original size modulo 2^32 145
> -

It took a few hours to realize locale setting ruin your day. I could
reproduce that only with LC_ALL=C, and then bisecting led to:

commit f448f3e5c37de8c285ac14b032b2bdcea82fc08b
Author: Christos Zoulas 
Date:   Sat May 28 01:04:57 2022 +

PR/351: CathyKMeow: octalify unprintable characters in filenames unless 
raw.

> My perl-foo is pretty bad, but I guess we should be trying to espace or 
> sanitize that value?

Problem is, since that change file(1) no longer returns the file as it
was given on the command line, and therefore add_file_types assigns the
file type to the wrong file, while the real one gets nothing at all.
.oO (from __rant__ import "use strict; use warning;")

Next I'll try

--- a/lib/Lintian/Index/FileTypes.pm
+++ b/lib/Lintian/Index/FileTypes.pm
@@ -98,6 +98,7 @@ sub add_file_types {
 }
 
 while (defined(my $path = shift @lines)) {
+$path =~ s/(\\[0-7]{3})/chr oct ($1)/eg;
 
 my $type = shift @lines;

but testing will take a while¹. I wasn't surprised if this
fails from some utf-8 vs. binary string mismatches.

Beside from that, the issue became more pressing now that file 1:5.44-1
is in unstable, blocked by this one from transitioning to testing. Which
is why I spent several hours¹ on this.

Christoph

¹ As I am in a way responsible for this situation, I agree I am
  also obliged to help resolving it. However, can you please provide a
  faster way to reproduce the failing test? Currently I am rebuilding
  and running autopkgtest, with a loop taking 50 minutes.


signature.asc
Description: PGP signature

Bug#1026988: ruby-ruby-magic-static: diff for NMU version 0.5.4-1.1

[Christoph Biedl]

Control: severity 1026988 serious
Control: tags 1026988 + patch pending

Dear maintainer,

with yesterday's upload of file 1:5.44-1 to unstable your package now
fails to build from source.

To fix the issues, I've prepared an NMU for ruby-ruby-magic-static
(versioned as 0.5.4-1.1), debdiff below. An upload to DELAYED/6 will
follow shortly. Please feel free to tell me if I should delay it longer.

Additionally, https://github.com/kwilczynski/ruby-magic/issues/38 is
about this upstream.

Regards,

Christoph

diff -Nru ruby-ruby-magic-static-0.5.4/debian/changelog 
ruby-ruby-magic-static-0.5.4/debian/changelog
--- ruby-ruby-magic-static-0.5.4/debian/changelog   2022-05-01 
23:36:22.0 +0200
+++ ruby-ruby-magic-static-0.5.4/debian/changelog   2023-01-11 
18:53:56.0 +0100
@@ -1,3 +1,10 @@
+ruby-ruby-magic-static (0.5.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Adjust PARAM_BYTES_MAX for change in file 5.44. Closes: #1026988
+
+ -- Christoph Biedl   Wed, 11 Jan 2023 
18:53:56 +0100
+
 ruby-ruby-magic-static (0.5.4-1) unstable; urgency=medium
 
   * Team upload
diff -Nru 
ruby-ruby-magic-static-0.5.4/debian/patches/adjust-for-new-file-bytes-max-value.patch
 
ruby-ruby-magic-static-0.5.4/debian/patches/adjust-for-new-file-bytes-max-value.patch
--- 
ruby-ruby-magic-static-0.5.4/debian/patches/adjust-for-new-file-bytes-max-value.patch
   1970-01-01 01:00:00.0 +0100
+++ 
ruby-ruby-magic-static-0.5.4/debian/patches/adjust-for-new-file-bytes-max-value.patch
   2023-01-11 18:52:25.0 +0100
@@ -0,0 +1,17 @@
+Subject: Fix test breakage introduced with file 5.44
+Author: Christoph Biedl 
+Date: 2023-01-11
+Bug-Debian: https://bugs.debian.org/1026988
+Forwarded: https://github.com/kwilczynski/ruby-magic/issues/38
+
+--- a/test/test_magic.rb
 b/test/test_magic.rb
+@@ -205,7 +205,7 @@
+   end
+ 
+   def test_magic_get_parameter_with_PARAM_BYTES_MAX
+-assert_equal(1024 * 1024, @magic.get_parameter(Magic::PARAM_BYTES_MAX))
++assert_equal(1024 * 1024 * 7, 
@magic.get_parameter(Magic::PARAM_BYTES_MAX))
+   end
+ 
+   def test_magic_get_parameter_lower_boundary
diff -Nru ruby-ruby-magic-static-0.5.4/debian/patches/series 
ruby-ruby-magic-static-0.5.4/debian/patches/series
--- ruby-ruby-magic-static-0.5.4/debian/patches/series  2022-05-01 
23:36:22.0 +0200
+++ ruby-ruby-magic-static-0.5.4/debian/patches/series  2023-01-11 
18:44:05.0 +0100
@@ -1,2 +1,3 @@
 relax-mini-portile2-dependency.patch
 0002-test_magic-ignore-GC-compaction-test-on-unsupported-.patch
+adjust-for-new-file-bytes-max-value.patch


signature.asc
Description: PGP signature

Bug#1026976: Upcoming test suite regression due to changes in file/libmagic

[Christoph Biedl]

Control: reassign 1026976 file 1:5.43-2
Control: tags 1026976 pending

Christoph Biedl wrote...

> As I understand it, this is result of how t/fixtures/pyzip/pyzip.in is
> described by file(1):
> 
> - a /usr/bin/python3 script executable (binary data)
> + Zip archive, with extra data prepended

Thanks to FC Stegerman, this has been fixed upstream. So this bug now
belongs into the domain of the file package, and will be fixed in the
next upload.

Christoph


signature.asc
Description: PGP signature

Bug#1027424: transition: libppd

[Christoph Biedl]

Paul Gevers wrote...

> On 31-12-2022 10:06, Christoph Biedl wrote:
>
> > So src:libppd has been renamed to src:libppd-legacy, and has entered
> > experimental yesterday. While doing so, I've fixed a longstanding
> > mismatch in the soname version, hence the new number libppd-legacy*1*.
>
> I'm wondering what this means for users of the library that don't have
> packages in the Debian archive. If some downstream (including the non
> publicly published ones) (build) depend on the old library, they suddenly
> get weird failures, right?

Correct.

Install-dependencies will fail for a missing libppd.so.1.0.1, just like
after any other transition (Till's libppd will use a different
soversion).

Build-dependencies will fail to build as the new libppd is not a drop-in
replacement. Till did some investigation in that direction, result boils
down to "Providing a compatability layer was possible but is some work",
while odds are low anyone will benefit from this, see below.

So, in the case of a failing re-build, users will need to learn about
the reason and how to deal with it. I've asked Till to embed an
according pointer in the packages' descriptions (debian/control) so
they'll have a clue.

However, I would be fairly surprised if that ever happens. This is very
old software and it is mostly unmaintained - last (legacy) libppd
upstream release was in 2005. Therefore I assume any third-party package
switched to something different in the meantime. I am not aware of any,
and a little research didn't show anything in that direction. Looking
for "libppd" usually just points to the new version, provided by
OpenPrinting.

Our alternative would have been to make the new libppd somehow fit
around the old one, stupid work, and with constant risk people will pick
the wrong one - something I consider way more likely to happen than
failing builds of some rather hypothetical third-party packages based
on legacy libppd.

> At the extreme bare minimum, this needs documentation in the release notes,
> but I wonder if we consider this enough.

Release notes will never hurt, thanks for reminding me about those. And
in the particular situation I'm confident this is enough. If you can
think of more safety nets I could provide, let me know.

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#1027424: transition: libppd

[Christoph Biedl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: lib...@packages.debian.org, Till Kamppeter 

Control: affects -1 + src:libppd

Greetings,

possible this is not a regular transition, but in exchange I guess it
should be pretty smooth and simple ...

So some background: There are major changes coming in the area of
printing using CUPS, driven by Till Kamppeter (Cc'd), and among other
things this will introduce a library "libppd" to interact with PPD
(PostScript Printer Description) files. That one however will clash with
an existing libppd, maintained by yours truly, and after some discussion
with Till we figured the sane way was to move that old library out of
the way, name-wise.

So src:libppd has been renamed to src:libppd-legacy, and has entered
experimental yesterday. While doing so, I've fixed a longstanding
mismatch in the soname version, hence the new number libppd-legacy*1*.


Now about the formal transition procedure: There is exactly one reverse
build-dependency, src:gpr, I've already filed #1027408 for the
required changes. Taking care of this is on my list.

That should be all - if you need more information, just let me know.

Kind regards,

Christoph

Ben file:

title = "libppd";
is_affected = .depends ~ "libppd0" | .depends ~ "libppd-legacy1";
is_good = .depends ~ "libppd-legacy1";
is_bad = .depends ~ "libppd0";



signature.asc
Description: PGP signature

Bug#1027408: Adjust for changes in libppd

[Christoph Biedl]

Source: gpr
Version: 0.15deb-2
Severity: important
Tags: patch

Hello,

In order to clean the aisle wrt package and file names, the libppd
library has been renamed to libppd-legacy, and your package needs an
adjustment. The patch below does the job but is otherwise minimal,
following the spirit of an NMU (it was much saner but more intrusive to
switch to debhelper sequence style, bump debhelper to 9+, and adjust
configure.ac intead).

The existing libppd-dev and libppd0 package will go away soon, I will
raise to severity to serious as grp will FTBFS then, and upload a fix
according to the NMU guidelines. Sorry if this appears being pushy, all
this should be done before transition freeze on January 12th.

Regards,

Christoph

diff --git a/debian/control b/debian/control
index f3e5e95..5ea83dc 100644
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,7 @@
 Source: gpr
 Section: utils
 Priority: optional
-Build-Depends: debhelper (>= 8), po-debconf, gettext, autotools-dev, libtool, 
libppd-dev (>= 0.10), libgtk2.0-dev (>= 2.6), libpopt-dev, zlib1g-dev
+Build-Depends: debhelper (>= 8), po-debconf, gettext, autotools-dev, libtool, 
libppd-legacy-dev (>= 0.10), libgtk2.0-dev (>= 2.6), libpopt-dev, zlib1g-dev
 Maintainer: A Mennucc1 
 Standards-Version: 3.9.1.0
 
diff --git a/debian/patches/series b/debian/patches/series
index 1cec446..0256a73 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
 0002-show-name-of-default-printer.patch
 0003-use-non-deprecated-combo-boxes.patch
 autostuff-2011
+use-legacy-libppd.patch
diff --git a/debian/patches/use-legacy-libppd.patch 
b/debian/patches/use-legacy-libppd.patch
new file mode 100644
index 000..fd85974
--- /dev/null
+++ b/debian/patches/use-legacy-libppd.patch
@@ -0,0 +1,38 @@
+Subject: Follow renaming of libppd to libppd-legacy
+Author: Christoph Biedl  
+Date: 2022-12-27
+Forwarded: not-needed
+
+--- a/configure
 b/configure
+@@ -6383,13 +6383,13 @@
+ done
+ 
+ 
+-  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ppd_file_new in 
-lppd" >&5
+-$as_echo_n "checking for ppd_file_new in -lppd... " >&6; }
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ppd_file_new in 
-lppd-legacy" >&5
++$as_echo_n "checking for ppd_file_new in -lppd-legacy... " >&6; }
+ if ${ac_cv_lib_ppd_ppd_file_new+:} false; then :
+   $as_echo_n "(cached) " >&6
+ else
+   ac_check_lib_save_LIBS=$LIBS
+-LIBS="-lppd  $LIBS"
++LIBS="-lppd-legacy  $LIBS"
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+ /* end confdefs.h.  */
+ 
+@@ -6424,11 +6424,11 @@
+ #define HAVE_LIBPPD 1
+ _ACEOF
+ 
+-  LIBS="-lppd $LIBS"
++  LIBS="-lppd-legacy $LIBS"
+ 
+ else
+ 
+-as_fn_error $? "Must have libppd installed to compile gpr" "$LINENO" 5
++as_fn_error $? "Must have libppd-legacy installed to compile gpr" 
"$LINENO" 5
+ fi
+ 
+ 


signature.asc
Description: PGP signature

Bug#1026976: Upcoming test suite regression due to changes in file/libmagic

[Christoph Biedl]

Chris Lamb wrote...

> Thanks again for the "new version of file in experimental" bugs; very
> much appreciated.

You're welcome. Given file's volatility, I guess this will not be the
last conversation in that regard ...

> > - a /usr/bin/python3 script executable (binary data)
> > + Zip archive, with extra data prepended
> >
> > Now that looks a bit delicate ... if you think this is something that
> > should be handled in file/libmagic, let me know.
>
> Naturally, as one of the maintainers of strip-nondeterminism, I am
> inclined to believe that this is a minor regression in file. :)

This indeed was the rare where I think a change in file(1), while done
with best intentions, caused more harm than benefit.

> However, this "extra data prepended" doesn't fit well under the rubric
> of "data". Yes, this "#!/usr/bin/python3\n" shebang is definitely
> "data" of a kind, but a shebang isn't really data in that way given
> the special-treatment afforded to it by UNIX systems. Even if this
> noun was replaced by the more general "bytes", the magic nature of the
> shebang would still remain… as would the desire to discriminate
> between pyzip files and other ZIP files with prepended data.
>
> Could another — different — string be emitted in the case that these
> prepended bytes are a shebang? We could potentially look for the file
> starting with #! and for that to take precedence over this new case.

After some more thinking: I suggest you do nothing for the time being
while I take this to upstream. If all else fails, I'll revert the change
for the next upload. By the way, that will be 1:5.44-1, but the changes
to 1:5.43-3 are minimal.

Christoph


signature.asc
Description: PGP signature

Bug#1027031: Upcoming test suite regression due to changes in file/libmagic

[Christoph Biedl]

Source: yara
Version: 4.2.3-1
Severity: important

Hello,

The last upload of file/libmagic (1:5.43-3), currently in experimental)
breaks the yara test suite:

==
==
   yara 4.2.3: ./test-suite.log
==

# TOTAL: 18
# PASS:  17
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test-magic


tests/test-magic.c:24: rule does not match (but should)
FAIL test-magic (exit status: 1)
==

While I did not fully understand how that test works, I reckon it's
about how tests/data/ChipTune.efi is detected:

- MS-DOS executable PE32+ executable (EFI application) x86-64 (stripped to 
external PDB), for MS Windows
+ PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS 
Windows, 4 sections

This will break your package once I upload to unstable, something I want
to do in a week from now. In case you think file should see an
improvement here, let me know.

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#1026988: Upcoming test suite regression due to changes in file/libmagic

[Christoph Biedl]

Source:  ruby-ruby-magic-static
Version: 0.5.4-1
Severity: important

Hello,

The last upload of file/libmagic (1:5.43-3), currently in experimental) also
the ruby-ruby-magic-static test suite:

==
Failure: test_magic_get_parameter_with_PARAM_BYTES_MAX(MagicTest)
/<>/test/test_magic.rb:208:in 
`test_magic_get_parameter_with_PARAM_BYTES_MAX'
 205:   end
 206: 
 207:   def test_magic_get_parameter_with_PARAM_BYTES_MAX
  => 208: assert_equal(1024 * 1024, 
@magic.get_parameter(Magic::PARAM_BYTES_MAX))
 209:   end
 210: 
 211:   def test_magic_get_parameter_lower_boundary
<1048576> expected but was
<7340032>
==

In fact, file's upstream has changed the value. Please, at your own
descretion, relax that check, or adjust it to the new value once I've
uploaded file to unstable - my plan to do this is in about a week.

In case you're courious, the change was:

:
commit d2659ae455c7df7e8c6355dfaaea1180236a2932
Author: Christos Zoulas 
Date:   Sun Oct 2 12:53:28 2022 +

Increase the number of bytes we are looking for (Joerg Jenderek)


Regards,

Christoph



signature.asc
Description: PGP signature

Bug#1005435: gpr: FTBFS: configure: error: Must have libppd installed to compile gpr

[Christoph Biedl]

Control: tags 1005435 pending

Lucas Nussbaum wrote...

> Source: gpr
> Version: 0.15deb-2
> Severity: serious
> Justification: FTBFS

> > configure: error: Must have libppd installed to compile gpr

This was caused by yours truly as a result of updating src:libppd
almost a year ago. Fix is underway.

Christoph


signature.asc
Description: PGP signature

Bug#1026976: Upcoming test suite regression due to changes in file/libmagic

[Christoph Biedl]

Source: strip-nondeterminism
Version: 1.13.0-2
Severity: important

Hello,

possibly you've seen the similar story in diffoscope already: The last
upload of file/libmagic (1:5.43-3, currently in experimental) broke also
the strip-nondeterminism test suite:

==
#   Failed test 'Normalizer found for /tmp/IhdQGJbeMu/pyzip'
#   at t/fixtures.t line 83.
#  got: undef
# expected: anything else

#   Failed test 'Test output /tmp/IhdQGJbeMu/pyzip matched expected 
t/fixtures/pyzip/pyzip.out'
#   at t/fixtures.t line 89.
# Looks like you failed 2 tests of 9.

#   Failed test 't/fixtures/pyzip/pyzip.in'
#   at t/fixtures.t line 101.
strip-nondeterminism: /tmp/IZ0B8oD7YF/encrypted.zip: ignoring encrypted zip file
# Looks like you failed 1 test of 22.
t/fixtures.t ..·
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/22 subtests·
==

As I understand it, this is result of how t/fixtures/pyzip/pyzip.in is
described by file(1):

- a /usr/bin/python3 script executable (binary data)
+ Zip archive, with extra data prepended

Now that looks a bit delicate ... if you think this is something that
should be handled in file/libmagic, let me know.

In case you're courious, the change was:

:

commit a92246be4a8ceff26f0d4fdaa0390fc110146d7d
Author: Christos Zoulas 
Date:   Sun Oct 2 12:34:00 2022 +

Recognize ZIP archives with prepended data by end-of-central-directory 
record
(Michal Gorny)

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#1026920: New upstream version of file/libmagic breaks autopkgtest

[Christoph Biedl]

Package: lintian
Version: 2.115.3
Severity: important

Greeting,

my recent upload of file (1:5.43-3) to experiental broke lintian's autopkgtest.

Possibly this is the relevant section.

# Hints do not match
# 
# --- 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/documentation/manual/files-general/hints.specified.calibrated
# +++ 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/documentation/manual/files-general/hints.actual.parsed
# +files-general (binary): wrong-compression-in-manual-page 
[usr/share/man/man1/é³¥ã®è©©.1.gz]
# 
# Unexpected tags:
#   wrong-compression-in-manual-page
# 
#   Failed test 'Lintian passes for files-general'
#   at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343.

[ 
https://ci.debian.net/data/autopkgtest/unstable/amd64/l/lintian/29591169/log.gz 
]

While I didn't check what precisely went wrong, I reckon it's a slightly
changed output on gz-compressed files.

Can you please check and adjust your tests? I'd like to upload to
unstable in a week or so, and I'd prefer to have no autopkgtest breakage
by then.

Sorry for the mess, and I'm sorry this will happen again - upstream
changes file's output every now and then. The only help I can provide is
to add your package to the list of those that should receive a
notification when uploading a new upstream version, see

https://sources.debian.org/src/file/1%3A5.41-4/debian/README.Maintainer/#L16

If you want lintian to be included, just say the word.

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#1026862: Wrong installation path for tmpfiles.d/tpm2-tss-fapi.conf

[Christoph Biedl]

Package: libtss2-fapi1
Version: 3.2.1-1
Severity: normal

(...)
Setting up libtss2-fapi1:amd64 (3.2.1-1) ...
Failed to read '/usr/lib/tmpfiles.d/tpm2-tss-fapi.conf': Is a directory
(...)

Cause is an old trap, debian/*.install wants a directory only in the
second column. Happens all the time to me as well :)

And therefore, package content:

-rw-r--r-- root/root   432 2022-12-19 07:42 
./usr/lib/tmpfiles.d/tpm2-tss-fapi.conf/tpm2-tss-fapi.conf

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#1026460: libmagic1: Virtual font files are recognized as "COM executable for DOS"

[Christoph Biedl]

Control: tags 1026460 confirmed upstream

Hilmar Preusse wrote...

> Not sure if this is solvable, at the fist glance I found no magic byte
> for vf files.

Things are worse: file(1) /does/ have magic for "TeX virtual font data"
but is *that* weak (only 16 bit, 0xf7 0xca at the start of file) it gets
beaten by the pattern for the dreaded MS-DOS executables (which is plain
nightmare).

After some searching I found the parser for virtual font files in
texk/dvipsk/virtualfont.c starting at line 189. So I could harden the
magic at least a little bit by exploiting the command byte (243, 0xf3)
at offset 0xb the earliest.

Since I had to download the huge texlive-fonts-extra .deb to extract the
reproducer, this at least also brought more than 20k samples to verify
the result. Some .vf files fail the test, and I'd like to ask you
whether they are technically correct:

# From the texlive-bin sources (bullseye)

* texk/web2c/tests/badvpl.vpl (I assume that's not a bug)

# From texlive-fonts-extra_2022.20221123-2_all.deb:

* /usr/share/texlive/texmf-dist/fonts/vf/public/mathdesign/mdbch/mdbchbofc8t.vf
* /usr/share/texlive/texmf-dist/fonts/vf/public/mathdesign/mdbch/mdbchrofc8t.vf

They look fairly broken (error messages inside), perhaps they shouldn't
be there anyway?

* 
/usr/share/texlive/texmf-dist/fonts/vf/public/ebgaramond/EBGaramondInitials-tlf-ts1.vf
* /usr/share/texlive/texmf-dist/fonts/vf/public/gfsbodoni/gbodonio9a.vf
* /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfoit0600.vf
* /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfoit0700.vf
* /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfost0600.vf
* /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfost0700.vf
* /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfotc0600.vf
* /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfotc0700.vf
* /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfott0600.vf
* /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfott0700.vf
* /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfovi0600.vf
* /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfovi0700.vf
* /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfovt0600.vf
* /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfovt0700.vf
* 
/usr/share/texlive/texmf-dist/fonts/vf/public/libertinus-type1/LibertinusSerifInitials-Regular-tlf-ts1.vf

These are pretty small (88 octets at most, usually just 12) so still not
having them detected properly might not be the biggest loss.


While on it, I'll dig a bit further so I can improve detection of other
TeX-related file types where file(1) isn't quite good at the moment,
being

* TeX DVI file
* TeX generic font data
* TeX packed font data

Cheers,

Christoph


signature.asc
Description: PGP signature

Bug#1022565: file: [regression] OpenPGP file MIME type reverted to application/octet-stream

[Christoph Biedl]

Control: forwarded 1022565 
https://mailman.astron.com/pipermail/file/2022-December/000995.html

Paul Wise wrote...

> The detected MIME type of OpenPGP files is now application/octet-stream:

Ups. That's clearly a regression, and a rather weird one. Sent to upstream.

Christoph


signature.asc
Description: PGP signature

Bug#1011921: big5

[Christoph Biedl]

Control: tags 1011921 moreinfo

積丹尼 Dan Jacobson wrote...

> $ file 111D2012841-01.txt
> 111D2012841-01.txt: ISO-8859 text, with CRLF line terminators

Hello,

as you noticed, your file is utf-8. Can you please re-send as don't have
a clue how to proceed?

Regards,

Christoph


signature.asc
Description: PGP signature