date:20230311


On 2023-03-11 14:02, Alejandro Colomar wrote:

we should use "%s" (if we go the way of snprintf(3)).


Yes, thanks for catching that. However, I came up with a better way that 
avoids snprintf (and strlcpy) entirely both here and the other place I 
used snprintf.


Attached is a revised set of patches that addresses the comments you 
made and embodies my followups.From 324bb0e914b5470650df02bd7b64e963665d44c1 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 11 Mar 2023 00:01:02 -0800
Subject: [PATCH 1/8] Simplify change_field by using strcpy

* lib/fields.c (change_field): Since we know the string fits,
use strcpy rather than strlcpy.

Signed-off-by: Paul Eggert 
---
 lib/fields.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lib/fields.c b/lib/fields.c
index 0b5f91b2..8801bce6 100644
--- a/lib/fields.c
+++ b/lib/fields.c
@@ -100,7 +100,6 @@ void change_field (char *buf, size_t maxsize, const char *prompt)
 			cp++;
 		}
 
-		strlcpy (buf, cp, maxsize);
+		strcpy (buf, cp);
 	}
 }
-
-- 
2.37.2

From b13ffb86dcd10e8160eee10bd286fc73937c3e8b Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 11 Mar 2023 13:41:54 -0800
Subject: [PATCH 2/8] Omit unneeded change_field test

* fields.c (change_field): Omit unnecessary test.

Signed-off-by: Paul Eggert 
---
 lib/fields.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/fields.c b/lib/fields.c
index 8801bce6..fa5fd156 100644
--- a/lib/fields.c
+++ b/lib/fields.c
@@ -96,7 +96,7 @@ void change_field (char *buf, size_t maxsize, const char *prompt)
 		*cp = '\0';
 
 		cp = newf;
-		while (('\0' != *cp) && isspace (*cp)) {
+		while (isspace (*cp)) {
 			cp++;
 		}
 
-- 
2.37.2

From 090722a20765cf9a248050524143fce5b68cfe8c Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 11 Mar 2023 13:43:36 -0800
Subject: [PATCH 3/8] Fix change_field buffer underrun

* lib/fields.c (change_field): Don't point
before array start; that has undefined behavior.

Signed-off-by: Paul Eggert 
---
 lib/fields.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/fields.c b/lib/fields.c
index fa5fd156..640be931 100644
--- a/lib/fields.c
+++ b/lib/fields.c
@@ -91,8 +91,9 @@ void change_field (char *buf, size_t maxsize, const char *prompt)
 		 * entering a space.  --marekm
 		 */
 
-		while (--cp >= newf && isspace (*cp));
-		cp++;
+		while (newf < cp && isspace (cp[-1])) {
+			cp--;
+		}
 		*cp = '\0';
 
 		cp = newf;
-- 
2.37.2

From 4982d5f2fe2f2c339568996ebb17a99200d2f106 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 11 Mar 2023 00:02:45 -0800
Subject: [PATCH 4/8] Prefer strcpy to strlcpy when either works

* lib/gshadow.c (sgetsgent): Use strcpy not strlcpy,
since the string is known to fit.

Signed-off-by: Paul Eggert 
---
 lib/gshadow.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/gshadow.c b/lib/gshadow.c
index c17af67f..ca14449a 100644
--- a/lib/gshadow.c
+++ b/lib/gshadow.c
@@ -128,7 +128,7 @@ void endsgent (void)
 		sgrbuflen = len;
 	}
 
-	strlcpy (sgrbuf, string, len);
+	strcpy (sgrbuf, string);
 
 	cp = strrchr (sgrbuf, '\n');
 	if (NULL != cp) {
-- 
2.37.2

From 54fac7560f87a134c4d3045ce7048f4819c4e492 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 11 Mar 2023 00:38:24 -0800
Subject: [PATCH 5/8] Avoid silent truncation of console file data

* libmisc/console.c (is_listed): Rework so that there is no
fixed-size buffer, and no need to use fgets or strlcpy or strtok.
Instead, the code works with arbitrary-sized input,
without silently truncating data or mishandling NUL
bytes in the console file.

Signed-off-by: Paul Eggert 
---
 libmisc/console.c | 41 -
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/libmisc/console.c b/libmisc/console.c
index 7e2132dd..8264e1a3 100644
--- a/libmisc/console.c
+++ b/libmisc/console.c
@@ -24,7 +24,6 @@
 static bool is_listed (const char *cfgin, const char *tty, bool def)
 {
 	FILE *fp;
-	char buf[1024], *s;
 	const char *cons;
 
 	/*
@@ -43,17 +42,17 @@ static bool is_listed (const char *cfgin, const char *tty, bool def)
 	 */
 
 	if (*cons != '/') {
-		char *pbuf;
-		strlcpy (buf, cons, sizeof (buf));
-		pbuf = &buf[0];
-		while ((s = strtok (pbuf, ":")) != NULL) {
-			if (strcmp (s, tty) == 0) {
+		size_t ttylen = strlen (tty);
+		for (;;) {
+			if (strncmp (cons, tty, ttylen) == 0
+			&& (cons[ttylen] == ':' || !cons[ttylen])) {
 return true;
 			}
-
-			pbuf = NULL;
+			cons = strchr (cons, ':');
+			if (!cons)
+return false;
+			cons++;
 		}
-		return false;
 	}
 
 	/*
@@ -70,21 +69,22 @@ static bool is_listed (const char *cfgin, const char *tty, bool def)
 	 * See if this tty is listed in the console file.
 	 */
 
-	while (fgets (buf, sizeof (buf), fp) != NULL) {
-		/* Remove optional trailing '\n'. */
-		buf[strcspn (buf, "\n")] = '\0';
-		if (strcmp (buf, tty) == 0) {
-			(void) fclose (fp);
-			return true;
+	const char *tp = tty;
+	bool listed

Bug#1032818: leptonlib: New version 1.83.1

2023-03-11 Thread David Ward


Source: leptonlib

Leptonica version 1.83.1 was released on January 26, 2023.

https://github.com/DanBloomberg/leptonica/releases/tag/1.83.1
https://github.com/DanBloomberg/leptonica/releases/download/1.83.1/leptonica-1.83.1.tar.gz

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config


On 2023-03-11 14:39, Alejandro Colomar wrote:

I wonder
if the patch is really "simplifying".


It depends on how one measures simplicity. The reader will need to know 
strftime's API regardless; requiring the reader to also know strlcpy's 
API makes the reader's job harder.


Also, it's less machine code to call just the one function (if one cares 
about simplicity of debugging :-).


If you still prefer calling two different functions instead of just one, 
feel free to modify it to use plain strcpy. strlcpy isn't needed here as 
the destination buffers are all big enough. To be honest though I like 
it the way it is (though it could use a comment; I'll add that).

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config


On 2023-03-11 13:49, Alejandro Colomar wrote:

+: mempcpy (full_tty, "/dev/", sizeof"/dev/" - 1)),

This is a great use case for stpcpy(3).


I came up with a slightly better approach, that needs neither mempcpy 
nor stpcpy. I plan to send it along soon.

Bug#1032622: cups-ipp-utils: Please enable translation of ippeveps(7)

2023-03-11 Thread Thorsten Alteholz


Hi Helge,

On Sat, 11 Mar 2023, Helge Kreutzmann wrote:

What ETA would you like me to send, i.e. when would the upload happen?


I don't have any further plans with the package. As long as there is no 
new RC bug, I will upload when you are ready.


  Thorsten

Bug#1032816: Add pkg.debianhelper.nonls build profile

2023-03-11 Thread David (Plasma) Paul

Let me know if there's anything you'd like me change or clarify.

-- 
Plasma
>From 8695f76d923b518bbd64971cf3da4e9e06d09371 Mon Sep 17 00:00:00 2001
From: "David (Plasma) Paul" 
Date: Sat, 11 Mar 2023 18:13:18 -0600
Subject: [PATCH] Add  build profile

Closes: #1032816
---
 debian/changelog | 4 
 debian/control   | 2 +-
 debian/rules | 4 
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index bf50f143..dab2f054 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -7,6 +7,10 @@ debhelper (13.11.5~2.gbp4a55fa) UNRELEASED; urgency=medium
 (Closes: #1028159)
   * Update on German translation of pages (Closes: #1028564)
 
+  [ David "Plasma" Paul ]
+  * Add  build profile (Closes: #1032816)
+(See also #709557)
+
  -- Niels Thykier   Sat, 04 Mar 2023 14:07:03 +0100
 
 debhelper (13.11.4) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 4a63b296..21aaeb76 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Build-Depends: dpkg-dev (>= 1.18.0~),
libtest-pod-perl ,
man-db ,
perl:any,
-   po4a,
+   po4a ,
 Rules-Requires-Root: no
 Standards-Version: 4.6.1
 Testsuite: autopkgtest-pkg-perl
diff --git a/debian/rules b/debian/rules
index fb4e5201..4bf56339 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,6 +9,10 @@
 # We disable autoreconf to avoid build-depending on it (it does
 # nothing for debhelper and it keeps the set of B-D smaller)
 
+ifneq (,$(filter pkg.debhelper.nonls,$(DEB_BUILD_PROFILES)))
+export USE_NLS=no
+endif
+
 PERL ?= perl
 
 %:
-- 
2.30.2

Bug#1028155: systemd-networkd resolves issue

2023-03-11 Thread LeJacq, Jean Pierre

The core issue is that the nginx is starting before the IPv6 address is bound.

systemd-networkd has a specific service, systemd-networkd-wait-online.service, 
that will force all online services to wait until the network interfaces are 
configured.

After switching to systemd-networkd from ifupdown, nginx now comes up 
reliably.

I'm not sure if this is a bug in nginx. It may be worth an addition to the 
documentation about this potential issue.

-- 
JP


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

Bug#1032817: [INTL:ro] Romanian debconf templates translation of myodbc

Package: myodbc
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «myodbc» file.

Thanks,
Remus-Gabriel

myodbc_debconf_ro.po
Description: Binary data

Bug#1032815: FIXED (Configuration error)

2023-03-11 Thread Greg Deitrick

The file /etc/network/interfaces contained a block that defined a network
connection for the wifi adapter.  Eliminating that block and rebooting
restored the desired behavior.

Bug#1032655: psi-plus segfaults

2023-03-11 Thread Stefan Kropp

On Fri, Mar 10, 2023 at 03:45:38PM +0100, Lee Garrett wrote:
> psi-plus currently simply segfaults on a stock bookworm installation:
> 
> $ psi-plus 
> [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
> (unknown:0, unknown)
> [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
> (unknown:0, unknown)
> [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
> (unknown:0, unknown)
> [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
> (unknown:0, unknown)
> Segmentation fault

On my bookworm system, I also get libpng warnings, but no segfault.

Maybe a backtrace in gdb can help to get more information.

Bug#1032814: ca-certificates.crt does not contain exactly one certificate or CRL

Package: ca-certificates
Version: 20230311

We get this warning:
Setting up ca-certificates (20230311) ...
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt, it does not contain exactly one 
certificate or CRL

Maybe there is an answer in
https://gitlab.alpinelinux.org/alpine/ca-certificates/-/issues/2

Bug#1032815: network-manager: nmcli finds no wifi APs while wifi network connected and working

2023-03-11 Thread Greg Deitrick

Package: network-manager
Version: 1.42.4-1
Severity: important
X-Debbugs-Cc: greg.deitr...@gmail.com

Dear Maintainer,

1. Gnome / Settings / Wi-Fi reports "No Wi-Fi Adapter Found"
2. The command, ' nmcli device wifi list ' reports no available wifi APs
Consequently, wifi connections cannot be managed by Gnome nor by nmcli

However, at the same time:
1.  Wifi network connection is working.
2.  There is no wired ethernet port on this computer.
3.  The command "ping www.google.com" indicates successful transmission.
4.  A second computer in the same location reports 4 active wifi networks with 
signal strengths from 59 to 100.
 
This occurred immediately after a fresh install of 
debian-bookworm-DI-alpha2-amd64-netinst.iso onto a Framework Laptop 12th gen.  
The wifi network connection was configured during this install and used during 
the install.  Only the base system was installed initially.  After the first 
boot apt-get update/upgrade was performed and the system was rebooted.  Then 
tasksel was used to install a desktop environment and gnome.

Prior to this install, this computer was running Ubuntu 22.04 for over 4 
months.  During this time Gnome managed the wifi network connection as expected.
The problem persisted after upgrading network-manager from the version in 
bookworm to the version in unstable.

Some possibly helpful output:

$ nmcli device wifi list
IN-USE  BSSID  SSID  MODE  CHAN  RATE  SIGNAL  BARS  SECURITY 

$ nmcli device show
GENERAL.DEVICE: lo
GENERAL.TYPE:   loopback
GENERAL.HWADDR: 00:00:00:00:00:00
GENERAL.MTU:65536
GENERAL.STATE:  100 (connected (externally))
GENERAL.CONNECTION: lo
GENERAL.CON-PATH:   
/org/freedesktop/NetworkManager/ActiveConnection/1
IP4.ADDRESS[1]: 127.0.0.1/8
IP4.GATEWAY:--
IP6.ADDRESS[1]: ::1/128
IP6.GATEWAY:--
IP6.ROUTE[1]:   dst = ::1/128, nh = ::, mt = 256

GENERAL.DEVICE: wlp166s0
GENERAL.TYPE:   wifi
GENERAL.HWADDR: 8C:F8:C5:EE:01:C9
GENERAL.MTU:1500
GENERAL.STATE:  10 (unmanaged)
GENERAL.CONNECTION: --
GENERAL.CON-PATH:   --
IP4.ADDRESS[1]: 192.168.1.36/24
IP4.GATEWAY:192.168.1.1
IP4.ROUTE[1]:   dst = 192.168.1.0/24, nh = 0.0.0.0, mt 
= 0
IP4.ROUTE[2]:   dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 0
IP4.ROUTE[3]:   dst = 169.254.0.0/16, nh = 0.0.0.0, mt 
= 1000
IP6.ADDRESS[1]: fe80::8ef8:c5ff:feee:1c9/64
IP6.GATEWAY:--
IP6.ROUTE[1]:   dst = fe80::/64, nh = ::, mt = 256

$ lshw -C network
  *-network 
   description: Wireless interface
   product: Wi-Fi 6 AX210/AX211/AX411 160MHz
   vendor: Intel Corporation
   physical id: 0
   bus info: pci@:a6:00.0
   logical name: wlp166s0
   version: 1a
   serial: 8c:f8:c5:ee:01:c9
   width: 64 bits
   clock: 33MHz
   capabilities: pm msi pciexpress msix bus_master cap_list ethernet 
physical wireless
   configuration: broadcast=yes driver=iwlwifi driverversion=6.1.0-5-amd64 
firmware=72.daa05125.0 ty-a0-gf-a0-72.uc ip=192.168.1.36 latency=0 link=yes 
multicast=yes wireless=IEEE 802.11
   resources: irq:16 memory:7a20-7a203fff

$ lsmod | grep iwl
iwlmvm385024  0
mac80211 1175552  1 iwlmvm
iwlwifi   360448  1 iwlmvm
cfg80211 1134592  3 iwlmvm,iwlwifi,mac80211
rfkill 36864  9 iwlmvm,bluetooth,cfg80211

$ sudo dmesg | grep iwl
[4.558340] iwlwifi :a6:00.0: enabling device ( -> 0002)
[4.570738] iwlwifi :a6:00.0: firmware: direct-loading firmware 
iwlwifi-ty-a0-gf-a0-72.ucode
[4.570752] iwlwifi :a6:00.0: api flags index 2 larger than supported by 
driver
[4.570767] iwlwifi :a6:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.36
[4.571101] iwlwifi :a6:00.0: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[4.571153] iwlwifi :a6:00.0: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[4.571168] iwlwifi :a6:00.0: loaded firmware version 72.daa05125.0 
ty-a0-gf-a0-72.ucode op_mode iwlmvm
[4.689001] iwlwifi :a6:00.0: Detected Intel(R) Wi-Fi 6 AX210 160MHz, 
REV=0x420
[4.865896] iwlwifi :a6:00.0: firmware: direct-loading firmware 
iwlwifi-ty-a0-gf-a0.pnvm
[4.865972] iwlwifi :a6:00.0: loaded PNVM version 64acdc51
[4.884369] iwlwifi :a6:00.0: Detected RF GF, rfid=0x10d000
[4.961304] iwlwifi :a6:00.0: base HW address: 8c:f8:c5:ee:01:c9
[4.995420]

Bug#1032813: add space after comma

Package: openssl
Version: 3.0.8-1
Severity: minor
File: /usr/bin/c_rehash

There should be a space after this comma:
Setting up ca-certificates (20230311) ...
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one 
certificate or CRL
  ^here
else it violates English grammar, and by the way looks like one long filename 
to some people.

Bug#1011497: xserver-xorg: Segfault in OsLookupColor when drawing lines in Inkscape

2023-03-11 Thread Mateusz Latusek


  
  
This seems to have been fixed with November or December update to
xserver-xorg-core. Thanks.

M.
-- 
  

  

  
  matlibhax.com/~matlib

Bug#1011497: xserver-xorg: Segfault in OsLookupColor when drawing lines in Inkscape

2023-03-11 Thread Mateusz Latusek

This seems to have been fixed with November or December update to 
xserver-xorg-core. Thanks.

Bug#1032082: sox: After security update, sox reports WAV file bits per sample is zero

2023-03-11 Thread Helmut Grohne

Control: tags -1 + confirmed

Hi,

On Sat, Mar 11, 2023 at 05:31:37PM +0100, Salvatore Bonaccorso wrote:
> > We encounter an error that occurs after upgrading to 
> > 14.4.2+git20190427-2+deb11u1,
> > and disappears when downgrading to version 14.4.2+git20190427-2.
> > Both sox and soxi report an error for wave files with GSM codec,
> > that were created using libsndfile.
> > 
> > $ soxi test.wav
> > soxi FAIL formats: can't open input file `test.wav': WAV file bits per 
> > sample is zero
> > 
> > After the error, it does not futher process the file.
> > Previously, it would output information about the file or process it 
> > (convert it).
> > 
> > The bits per sample in the wave file header is indeed zero.
> > The number of bits per sample is dynamic for the GSM codec.
> > Previously sox and soxi would parse and handle such files without problems.

Thanks for the report.

> Can you confirm, does that happens as well with the unstable version
> (where the patches should be identical)?

I see no reason why this issue should be specific to a particular
release.

> Is there a minimal testcase available allowed to share on the bug or a
> way to construct one?

The clues provided are already good. For compressed codecs such as GSM,
there is no reasonable wBitsPerSample value, which is why it is set to
0. When I wrote the patch, I did not see this use case nor did any test
case expose it. The actual zero-division happens in a branch specific to
uncompressed formats and this is where the check really belongs
(src/wav.c:961 in unstable). I'll update unstable by Monday.

$ sox -t raw -r 44100 -e signed-integer -b 8 /dev/null -t wav -e gsm-full-rate 
bug.wav
$ sox bug.wav fail.wav
sox FAIL formats: can't open input file `bug.wav': WAV file bits per sample is 
zero
$

Helmut

Bug#1032812: Allow user to influence Content-Transfer-Encoding

Package: reportbug
Version: 11.6.0
Severity: minor

Allow user to influence Content-Transfer-Encoding.
Don't just leave it up to the whims of the program.

$ < /dev/null HOME=/dev/null reportbug ca-certificates --template|grep Encoding
Content-Transfer-Encoding: base64
$ < /dev/null HOME=/dev/null reportbug reportbug   --template|grep Encoding
Content-Transfer-Encoding: 7bit

For instance, the user might want a template readable by another
program, without needing to add a decoding checking step.

Bug#1032811: Document when --output=FILE won't work

Package: reportbug
Version: 11.6.0
Severity: minor

Man page says:

   -o FILE, --output=FILE
  Instead of sending an email, redirect it to the specified  file‐
  name.

  The  output file is a full dump of the email message, so it con‐
  tains both headers and mail body. If you want to  use  it  as  a
  template  to create a new bug report, see the --resume-saved op‐
  tion.

OK, but there should be some mention of when it won't work:

$ HOME=/dev/null reportbug --template ca-certificates --output=/tmp/z|wc - 
/tmp/z
Thank you for using reportbug
127 1439410 -
wc: /tmp/z: No such file or directory
127 1439410 total
$ HOME=/dev/null reportbug ca-certificates --output=/tmp/z --template|wc - 
/tmp/z
Thank you for using reportbug
127 1439410 -
wc: /tmp/z: No such file or directory
127 1439410 total

In fact there could even be some STDERR output too, saying what is going on.

Bug#1032810: [INTL:ro] Romanian debconf templates translation of muse

Package: muse
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «muse» file.

Thanks,
Remus-Gabriel

muse_debconf_ro.po
Description: Binary data

Bug#1031696: Use of symbolic links in non-free ISO images breaks file system transposition support

2023-03-11 Thread James Addison

Package: debian-cd
Followup-For: Bug #1031696

Thank you again Thomas.

I've opened a merge request at 
https://salsa.debian.org/images-team/debian-cd/-/merge_requests/30

My Debian mirror is still under construction, hence the 'draft' status for
the merge request (to indicate that I'm not certain whether the changes are
ready yet, but would like to share work-in-progress).

The commit message contains an effort to explain what's going on; please
consider that message as reviewable and open to feedback too.

Tired, and time for some sleep here.  I'd like to request that we try not to
forget something that Pete mentioned incidentally, which is that a similar
issue affects symlinked documentation in debian-cd images.

This bug could potentially be a good opportunity to fix that at the same time,
if we truly have found the cause and can verify a fix.

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config



On 3/11/23 23:38, Paul Eggert wrote:
> On 2023-03-11 13:59, Alejandro Colomar wrote:
>> If the function is allowed
>> to dereference, then NULL is not allowed, but if the values are
>> uninitialized, then reading any of them should also trigger UB, no?
> 
> Sure, but the standard says that strftime reads only the struct tm 
> members needed to interpret the format. If the format contains no 
> conversion specs, strftime reads no struct tm members and thus there is 
> no UB even if the struct tm is entirely uninitialized.

Yeah, my point then is that if you don't read members, you don't even
need to dereference.  However, I see that glibc takes a copy, which is
a reason to dereference without reading any values.  So, yes, you're
right ;)

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config



On 3/11/23 23:34, Paul Eggert wrote:
> On 2023-03-11 14:18, Alejandro Colomar wrote:
> 
>> What I'm not sure is that strftime(3) requires nonnull.
> 
> glibc's strftime implementation segfaults if you pass a null pointer, so 
> we can't pass NULL regardless of whether the strftime API in time.h uses 
> __attribute__ ((nonnull))'.

Hmm, please fix the API :-)

So, yes, then that dummy seems to be necessary.  However, then I wonder
if the patch is really "simplifying".  I think strlcpy(3) was simpler.

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config


On 2023-03-11 13:59, Alejandro Colomar wrote:

If the function is allowed
to dereference, then NULL is not allowed, but if the values are
uninitialized, then reading any of them should also trigger UB, no?


Sure, but the standard says that strftime reads only the struct tm 
members needed to interpret the format. If the format contains no 
conversion specs, strftime reads no struct tm members and thus there is 
no UB even if the struct tm is entirely uninitialized.

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config


On 2023-03-11 14:18, Alejandro Colomar wrote:


What I'm not sure is that strftime(3) requires nonnull.


glibc's strftime implementation segfaults if you pass a null pointer, so 
we can't pass NULL regardless of whether the strftime API in time.h uses 
__attribute__ ((nonnull))'.

Bug#1032809: ITP: python3-cogapp -- Cog content generation tool. Small bits of computation for static files

2023-03-11 Thread Dima Kogan

Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: python3-cogapp
  Version : 3.3.0
  Upstream Author : Ned Batchelder
* URL or Web page : https://github.com/nedbat/cog
* License : MIT
  Description : python3-cogapp

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

Hi Paul,

On 3/11/23 23:08, Paul Eggert wrote:
> On 2023-03-11 13:59, Alejandro Colomar wrote:
>> Unless the standard specifically allows us to do so, but I can't find
>> anything clear.
> 
> It's pretty clear if you're a time nerd like me. :-)

:-)

> The standard for 
> strftime says "The appropriate characters are determined using the 
> LC_TIME category of the current locale and by the values of zero or more 
> members of the broken-down time structure pointed to by timeptr, as 
> specified in brackets in the description. If any of the specified values 
> are outside the normal range, the characters stored are unspecified."
> 
> The "zero" means that if no conversion specs are present in the format 
> string, then no struct tm members are examined, and it's therefore OK 
> for all members to be uninitialized if no conversion specs are present.

Hmmm, might make sense.  I'm thinking of the following code:

int foo(bool x, int *_Nonnull i)
{
if (!x)
return *i;

return 42;
}

Some compiler might decide to read-ahead the contents of *i knowing that
it can't be NULL.  If x is true, then it just discards that value.  Since
the compiler is allowed to perform UB if it knows that it can't affect
observable behavior, it should be fine.  If you pass NULL, then it would
crash.

What I'm not sure is that strftime(3) requires nonnull.  I didn't find it
in the C17 text.  glibc doesn't seem to use nonnull attributes for it:

$ grepc strftime /usr/include/
/usr/include/time.h:100:
extern size_t strftime (char *__restrict __s, size_t __maxsize,
const char *__restrict __format,
const struct tm *__restrict __tp) __THROW;


Cheers,

Alex

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032808: [INTL:ro] Romanian debconf templates translation of munin

Package: munin
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «munin» file.

Thanks,
Remus-Gabriel

munin_debconf_ro.po
Description: Binary data

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config


On 2023-03-11 13:59, Alejandro Colomar wrote:

Unless the standard specifically allows us to do so, but I can't find
anything clear.


It's pretty clear if you're a time nerd like me. :-) The standard for 
strftime says "The appropriate characters are determined using the 
LC_TIME category of the current locale and by the values of zero or more 
members of the broken-down time structure pointed to by timeptr, as 
specified in brackets in the description. If any of the specified values 
are outside the normal range, the characters stored are unspecified."


The "zero" means that if no conversion specs are present in the format 
string, then no struct tm members are examined, and it's therefore OK 
for all members to be uninitialized if no conversion specs are present.

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

Hi Paul,

On 3/11/23 20:29, Paul Eggert wrote:
> From 522b2db5619bd26631bd444d208768f740c2fdba Mon Sep 17 00:00:00 2001
> From: Paul Eggert 
> Date: Sat, 11 Mar 2023 10:34:21 -0800
> Subject: [PATCH 6/6] Fix su silent truncation
> 
> * src/su.c (check_perms): Do not silently truncate user name.
> Use snprintf instead of strlcpy as the latter doesn't buy much here
> and this avoids depending on strlcpy.
> 
> Signed-off-by: Paul Eggert 
> ---
>  src/su.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/src/su.c b/src/su.c
> index 9c134a9b..740d31f9 100644
> --- a/src/su.c
> +++ b/src/su.c
> @@ -658,7 +658,14 @@ static /*@only@*/struct passwd * check_perms (void)
>   SYSLOG ((LOG_INFO,
>"Change user from '%s' to '%s' as requested by PAM",
>name, tmp_name));
> - strlcpy (name, tmp_name, sizeof(name));
> + int tmp_namelen = snprintf (name, sizeof name, tmp_name);

This will likely trigger a warning about using a variable for the format
string.  Are you sure it's can't have conversion specifiers?  Otherwise,
we should use "%s" (if we go the way of snprintf(3)).

But I suggest adding error using strlcpy(3), since it reads much simpler,
and adding error checking to it.  Anyway, we can't stop depending on
libbsd until we find a solution for readpassphrase(3bsd).

Cheers,

Alex

> + if (! (0 <= tmp_namelen && tmp_namelen < sizeof name)) {
> + fprintf (stderr, _("Overlong user name '%s'\n"),
> +  tmp_name);
> + SYSLOG ((LOG_NOTICE, "Overlong user name '%s'",
> +  tmp_name));
> + su_failure (caller_tty, true);
> + }
>   pw = xgetpwnam (name);
>   if (NULL == pw) {
>   (void) fprintf (stderr,
> @@ -1213,4 +1220,3 @@ int main (int argc, char **argv)
>  
>   return (errno == ENOENT ? E_CMD_NOTFOUND : E_CMD_NOEXEC);
>  }
> -
> -- 
> 2.37.2
> 


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

On 3/11/23 22:52, Paul Eggert wrote:
> On 2023-03-11 13:31, Alejandro Colomar wrote:
>> What's this &dummy exactly for?
> 
> It avoids undefined behavior. A call like strftime (buf, sizeof buf, 
> "XXX", NULL) has undefined behavior, as near as I can make out.

Ahh, sure, it makes sense.  Didn't consider that.

> It's OK 
> that the dummy is uninitialized.

It's not so trivial to arrive to this conclusion.  If the function is
not allowed to dereference the pointer if the fmt string doesn't
require it, then NULL should be allowed.  If the function is allowed
to dereference, then NULL is not allowed, but if the values are
uninitialized, then reading any of them should also trigger UB, no?

Unless the standard specifically allows us to do so, but I can't find
anything clear.  Maybe it would be safer to bzero(3) it.

What do you think?

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config


On 2023-03-11 13:31, Alejandro Colomar wrote:

What's this &dummy exactly for?


It avoids undefined behavior. A call like strftime (buf, sizeof buf, 
"XXX", NULL) has undefined behavior, as near as I can make out. It's OK 
that the dummy is uninitialized.

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

Hi Paul,

On 3/11/23 20:29, Paul Eggert wrote:
> From 70985857d6d24262fc57a10bd62e6dbc642dda70 Mon Sep 17 00:00:00 2001
> From: Paul Eggert 
> Date: Sat, 11 Mar 2023 10:07:32 -0800
> Subject: [PATCH 5/6] Fix is_my_tty overruns and truncations
> 
> * libmisc/utmp.c: Include mempcpy.h.
> (is_my_tty): Declare the parameter as a char array not char *,
> as it is not necessarily null-terminated.  Avoid a read overrun
> when reading ut_utname.  Do not silently truncate the string
> returned by ttyname; instead, do not cache an overlong ttyname,
> as the behavior is correct in this case (albeit slower).
> Use snprintf instead of strlcpy as the latter doesn't buy much here
> and this avoids depending on strlcpy.
> 
> Signed-off-by: Paul Eggert 
> ---
>  libmisc/utmp.c | 50 --
>  1 file changed, 28 insertions(+), 22 deletions(-)
> 
> diff --git a/libmisc/utmp.c b/libmisc/utmp.c
> index ff6acee0..9d40470e 100644
> --- a/libmisc/utmp.c
> +++ b/libmisc/utmp.c
> @@ -21,39 +21,45 @@
>  #include 
>  
>  #include "alloc.h"
> +#include "mempcpy.h"
>  
>  #ident "$Id$"
>  
> +enum { UT_LINE_LEN = sizeof (getutent ()->ut_line) };
>  
>  /*
>   * is_my_tty -- determine if "tty" is the same TTY stdin is using
>   */
> -static bool is_my_tty (const char *tty)
> +static bool is_my_tty (const char tty[UT_LINE_LEN])
>  {
> - /* full_tty shall be at least sizeof utmp.ut_line + 5 */
> - char full_tty[200];
> - /* tmptty shall be bigger than full_tty */
> - static char tmptty[sizeof (full_tty)+1];
> -
> - if ('/' != *tty) {
> - (void) snprintf (full_tty, sizeof full_tty, "/dev/%s", tty);
> - tty = &full_tty[0];
> - }
> -
> - if ('\0' == tmptty[0]) {
> - const char *tname = ttyname (STDIN_FILENO);
> - if (NULL != tname)
> - (void) strlcpy (tmptty, tname, sizeof tmptty);
> - }
> -
> + /* A null-terminated copy of tty, prefixed with "/dev/" if tty
> +is not absolute.  There is no need for snprintf, as sprintf
> +cannot overrun.  */
> + char full_tty[sizeof "/dev/" + UT_LINE_LEN];
> + (void) sprintf (('/' == *tty
> +  ? full_tty

I think it might be easier to read if we conditionally call stpcpy(3),
and then a simple sprintf(3) catenated to it.

> +  : mempcpy (full_tty, "/dev/", sizeof "/dev/" - 1)),

This is a great use case for stpcpy(3).  It's in POSIX.1-2008, which is
a base requirement for shadow since recently, so we can use it.

Cheers,

Alex

> + "%.*s", UT_LINE_LEN, tty);
> +
> + /* Cache of ttyname, valid if tmptty[0].  */
> + static char tmptty[UT_LINE_LEN + 1];
> +
> + const char *tname;
>   if ('\0' == tmptty[0]) {
> - (void) puts (_("Unable to determine your tty name."));
> - exit (EXIT_FAILURE);
> - } else if (strncmp (tty, tmptty, sizeof (tmptty)) != 0) {
> - return false;
> + tname = ttyname (STDIN_FILENO);
> + if (! tname) {
> + (void) puts (_("Unable to determine your tty name."));
> + exit (EXIT_FAILURE);
> + }
> + int tnamelen = snprintf (tmptty, sizeof tmptty, "%s", tname);
> + if (! (0 <= tnamelen && tnamelen < sizeof tmptty)) {
> + tmptty[0] = '\0';
> + }
>   } else {
> - return true;
> + tname = tmptty;
>   }
> +
> + return strcmp (full_tty, tname) == 0;
>  }
>  
>  /*
> -- 
> 2.37.2
> 


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032807: [INTL:ro] Romanian debconf templates translation of mumble

Package: mumble
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «mumble» file.

Thanks,
Remus-Gabriel

mumble_debconf_ro.po
Description: Binary data

Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy

2023-03-11 Thread Soren Stoutner

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : privacybrowser
   Version  : 0.1-1
   Upstream contact : Soren Stoutner 
 * URL  : https://www.stoutner.com/privacy-browser-pc/
 * License  : GPL-3+, GFDL-NIV-1.3+
 * Vcs  : https://salsa.debian.org/sorenstoutner/privacybrowser
   Section  : web

The source builds the following binary packages:

  privacybrowser - web browser that respects your privacy

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/p/privacybrowser/
privacybrowser_0.1-1.dsc

Changes for the initial release:

 privacybrowser (0.1-1) experimental; urgency=low
 .
   * Initial release (closes: #1031755).

Regards,

-- 
Soren Stoutner
so...@stoutner.com


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

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

Hi Paul,

On 3/11/23 20:29, Paul Eggert wrote:
> From 1c8388d1d1831e976cdaa6e6f27bb08bf31aedc5 Mon Sep 17 00:00:00 2001
> From: Paul Eggert 
> Date: Sat, 11 Mar 2023 00:42:29 -0800
> Subject: [PATCH 4/6] Fix crash with large timestamps
> 
> * libmisc/date_to_str.c (date_to_str): Do not crash if gmtime
> returns NULL because the timestamp is far in the future.

Thanks :)

> Instead, use a dummy struct tm * to pacify any pedantic runtime.
> Simplify by always calling strftime, instead of sometimes strftime
> and sometimes strlcpy.
> 
> Signed-off-by: Paul Eggert 
> ---
>  libmisc/date_to_str.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/libmisc/date_to_str.c b/libmisc/date_to_str.c
> index f3b9dc76..4b3a4f48 100644
> --- a/libmisc/date_to_str.c
> +++ b/libmisc/date_to_str.c
> @@ -35,13 +35,12 @@
>  
>  void date_to_str (size_t size, char buf[size], long date)
>  {
> - time_t t;
> + time_t t = date;
> + struct tm *tm = gmtime (&t);
> + struct tm dummy;
>  
> - t = date;
> - if (date < 0) {
> - (void) strlcpy (buf, "never", size);
> - } else {
> - (void) strftime (buf, size, "%Y-%m-%d", gmtime (&t));
> - buf[size - 1] = '\0';
> - }
> + (void) strftime (buf, size,
> +  date < 0 ? "never" : tm ? "%Y-%m-%d" : "future",
> +  tm ? tm : &dummy);

What's this &dummy exactly for?

Cheers,

Alex

> + buf[size - 1] = '\0';
>  }
> -- 
> 2.37.2
> 


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027954: cppad: binary-all FTBFS

2023-03-11 Thread s3v

Dear Maintainer,

I think debian/libcppad-doc.docs needs to be adjusted to reflect changes in
documentation file names:

- doc.omh was renamed to doc.xrst [1] which was then renamed tocppad.xrst [2] 
which
  was then renamed to user_guide.xrst [3]

- omh directory was renamed to xrst [1]

Kind Regards

[1] 
https://github.com/coin-or/CppAD/commit/f054e4abb22551dd3685f95e587137f78a5c9504
[2] 
https://github.com/coin-or/CppAD/commit/278d8dbf63b42130f25acf03d5dbefdf6200a107
[3] 
https://github.com/coin-or/CppAD/commit/5a139ae40b5ee0bde2474a5fc0c17ead3365effb

Bug#1032734: OOM when unlocking encrypted root in initramfs

2023-03-11 Thread Guilhem Moulin

Control: tag -1 - moreinfo
Control: severity -1 important
Control: retitle -1 Argon2 memory cost is not future proof and might OOM on 
dist-upgrade on memory-constrained systems

On Sat, 11 Mar 2023 at 14:53:37 -0500, Jérôme Charaoui wrote:
>> Jérôme, what memory cost is the keyslot using?  (Paste the output of
>> `cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:`.)
>
> - 8< -
> # cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:
> PBKDF:  argon2i
> Time cost:  4
> Memory: 787907
> Threads:1
> - >8 -
> […]
> So, I think what's happening is that the first VM may have been created with
> a different (larger) memory configuration, and was reduced at a later point
> in time. I don't have absolute certainty of this, but it would very well
> explain the discrepancy in memory cost.

I'm very sure it's the case: buster, bullseye, bookworm (and everything
in between) never set the memory cost to more than half the physical
memory.  So it's just not possible to end up with such a high memory
cost on a machine with only 1GiB RAM.  Memory-hard KDF parameters are
non portable and this is a feature not a bug :-)  Upon hardware change
one needs to run the benchmark again via cryptsetup-luksChangeKey(8) or
similar to tune the parameters to the new system; and downgrading
hardware needs to be done with care as folks who bootstrap images for
RPI-like boards are surely aware.

It's a coincidence that you triggered the OOM-killer only after the post
dist-upgrade reboot, you were already likely close to memory exhaustion
after reducing memory.

> I there any way we could make the cryptsetup-initramfs hook aware of this,
> and emit a warning if it finds that the encrypted root lacks a keyslot with
> appropriate (low-enough) memory cost?

I don't think the hook is the place for that: 1/ it might not have
access to the header where this information resides, 2/ it doesn't know
beforehand which keyslot will be used, and 3/ the issue is not specific
to cryptsetup-initramfs.  There is an upstream commit on the main branch
that adds a warning to libcryptsetup, might cherry-pick that to bookworm
instead.

Anyway, lowering this to sub-RC now that it's demystified.  In your case
the root issue (KDF parameter portability) is wontfix/notabug, but I'm
hijacking this to point out that KDF parameters are not future proof.
(This is what the forwarded upstream bug points to, and what I initially
thought you might be experiencing.)  Things work fine out of the box on
minimal systems (also with <1GiB RAM), but several releases down the
road we might ship a kernel or early boot daemons requiring a lot more
memory, and the KDF *will* exhaust memory at that point.  The upstream
fix in !490 (neither in bookworm nor sid yet) improves things a bit but
really is only buying time.  Milan suggested that systems with little
RAM are probably better off using a non-memory-hard KDF.  Perhaps
upstream could be convinced to have different defaults depending on the
amount of physical memory, if not then perhaps it could be done in
partman-crypto (I personally wouldn't feel comfortable carrying such a
patch in src:cryptsetup or have defaults that are unaligned with
upstream or other distros).  Won't help with existing keyslots though.

-- 
Guilhem.

signature.asc
Description: PGP signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

Hi Paul,

On 3/11/23 20:29, Paul Eggert wrote:
> From 7e88c5914c1fab6c4d88e1ca39d6b6319e7ee768 Mon Sep 17 00:00:00 2001
> From: Paul Eggert 
> Date: Sat, 11 Mar 2023 00:02:45 -0800
> Subject: [PATCH 2/6] Prefer memcpy to strlcpy when either works
> 
> memcpy is standardized and should be faster here.
> * lib/gshadow.c (sgetsgent): Use memcpy not strlcpy,
> since the string is known to fit.
> 
> Signed-off-by: Paul Eggert 
> ---
>  lib/gshadow.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/gshadow.c b/lib/gshadow.c
> index c17af67f..1976c9a9 100644
> --- a/lib/gshadow.c
> +++ b/lib/gshadow.c
> @@ -128,7 +128,7 @@ void endsgent (void)
>   sgrbuflen = len;
>   }
>  
> - strlcpy (sgrbuf, string, len);
> + memcpy (sgrbuf, string, len);

While this one is less of a concern, and memcpy(3) is faster than
strcpy(3), I think I'd also use strcpy(3) here.  Also, the 'len'
variable seems confusing, since it's really a size.

Cheers,
Alex

>  
>   cp = strrchr (sgrbuf, '\n');
>   if (NULL != cp) {
> -- 
> 2.37.2
> 

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

Hi Paul,

On 3/11/23 20:29, Paul Eggert wrote:
> From d40e2f92f3e50d13d87393bd30b2b4b20b89a2d6 Mon Sep 17 00:00:00 2001
> From: Paul Eggert 
> Date: Sat, 11 Mar 2023 00:01:02 -0800
> Subject: [PATCH 1/6] Fix undefined behavior in change_field
> 
> * lib/fields.c (change_field): Do not ever compute &newf[-1],
> as behavior is undefined.  Since we know that the string fits,
> use memcpy rather than strlcpy.

I'd separate the UB fix, from the transformation to memcpy(3),
in two separate commits, since they are conceptually unrelated.

> 
> Signed-off-by: Paul Eggert 
> ---
>  lib/fields.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/lib/fields.c b/lib/fields.c
> index 0b5f91b2..3b119502 100644
> --- a/lib/fields.c
> +++ b/lib/fields.c
> @@ -90,17 +90,17 @@ void change_field (char *buf, size_t maxsize, const char 
> *prompt)
>* makes it possible to change the field to empty, by
>* entering a space.  --marekm
>*/
> + char *bp = newf;
>  
> - while (--cp >= newf && isspace (*cp));
> - cp++;
> + while (newf < cp && isspace (cp[-1])) {
> + cp--;
> + }
>   *cp = '\0';
>  
> - cp = newf;
> - while (('\0' != *cp) && isspace (*cp)) {
> - cp++;
> + while (isspace (*bp)) {
> + bp++;
>   }
>  
> - strlcpy (buf, cp, maxsize);
> + memcpy (buf, bp, cp + 1 - bp);

Regarding this transformation, I'd prefer transforming to strcpy(3).
It avoids the manual `cp + 1 - bp` calculation.

Thanks for the review and patches!

Cheers,
Alex

>   }
>  }
> -
> -- 
> 2.37.2
> 


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032590: Intermediate certficate support

2023-03-11 Thread Bernhard Schmidt

Am 11.03.23 um 14:51 schrieb Sakirnth Nagarasa:

Hi,

On 3/10/23 08:55, Bernhard Schmidt wrote:

I will upload a 3.2.1-3 within the next hours to cherry-pick this, could
you please test the resulting binary and report back? I will then apply
for a freeze exception.

Thank you for uploading the new version. I quickly tested the new binary
in our setup, Freeradius can not bind to ldap server anymore with
version 3.2.1-3.

Meh :-(

TLS: can't connect: (unknown error code).
Sat Mar 11 14:28:38 2023 : Error: rlm_ldap (ldap): Bind with (anonymous)
to ldaps://${LDAP_SERVER}:636 failed: Can't contact LDAP server
Sat Mar 11 14:28:38 2023 : Debug: rlm_ldap: Closing libldap handle

TLS issue, sounds related to my cherry-picked patch.

Unfortunately there are a lot of patches between 3.2.1 and 3.2.2, and
the commit message aren't always as descriptive as they could be.

https://github.com/FreeRADIUS/freeradius-server/compare/release_3_2_1...release_3_2_2

https://github.com/FreeRADIUS/freeradius-server/commit/d23987cbf55821dc56ab70d5ce6af3305cf83289
https://github.com/FreeRADIUS/freeradius-server/commit/3d08027f30c6d9c1eaccf7d60c68c8f7d78017c3

are likely candidates.

Just to make sure, could you quickly verify which of these versions are
broken as well in your setup?

- 3.2.1-1 from testing
- 3.2.1-2 from http://snapshot.debian.org/package/freeradius/3.2.1%2Bdfsg-2/
- 3.2.2-1~exp1 from experimental (just uploaded, might take a few hours
to appear in the archive)

Bernhard

Bug#1032805: [INTL:ro] Romanian debconf templates translation of mtink

Package: mtink
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «mtink» file.

Thanks,
Remus-Gabriel

mtink_debconf_ro.po
Description: Binary data

Bug#1032804: [INTL:ro] Romanian debconf templates translation of msmtp

Package: msmtp
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «msmtp» file.

Thanks,
Remus-Gabriel

msmtp_debconf_ro.po
Description: Binary data

Bug#1032168: meson: autopkgtest fills disk completely

2023-03-11 Thread Jussi Pakkanen

On Thu, 9 Mar 2023 at 13:54, Paul Gevers  wrote:

> Of course I expect you can also just use a porterbox which are there for
> this reason: https://wiki.debian.org/PorterBoxHowToUse

I have requested access to those but nothing has happened as of yet
and I have no idea how long that processing is going to take.

Bug#1032803: ruby-rack: CVE-2023-27530

2023-03-11 Thread Salvatore Bonaccorso

Source: ruby-rack
Version: 2.2.4-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ruby-rack.

CVE-2023-27530[0]:
| A DoS vulnerability exists in Rack

Bug#1032802: [INTL:ro] Romanian debconf templates translation of mrtg

Package: mrtg
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «mrtg» file.

Thanks,
Remus-Gabriel

mrtg_debconf_ro.po
Description: Binary data

Bug#1032662: elpa-debian-el: deb-view fails on zstd compressed debs

2023-03-11 Thread Sven Joachim

On 2023-03-11 07:49 -0800, David Bremner wrote:

> Sven Joachim  writes:
>
> Control: severity -1 wishlist
>
>> Package: elpa-debian-el
>> Version: 37.10
>> Severity: normal
>>
>> Visiting zstd compressed .deb files in deb-view mode-fails with a tar
>> error, here is a backtrace after toggling debug-on-error.
>
> Hi Sven;
>
> At least until Debian is using zstd this seems like a feature request to
> me, setting the severity (and hopefully expectations) appropriately.

No packages in Debian are using zstd compression, but Ubuntu switched to
it as default in 2021.  So there are a lot of packages out in the wild
there, and on Ubuntu derivatives deb-view.el is basically useless.

Anyway, my expectations are not too high as nobody currently takes care
of {debian,dpkg-dev}-el.  My recommendation to use dpkg-deb to extract
the data.tar.* archive (see #878900) still stands, but I don't know
if/when I will be able to develop a patch for that.

Cheers,
   Sven

Bug#1032734: OOM when unlocking encrypted root in initramfs

2023-03-11 Thread Jérôme Charaoui


Tagging ‘moreinfo’ then.  I can definitely see how one can reproduce
this theoretically (and possibly in the future when the kernel's memory
requirement increase high enough), and mentioned that in the upstream
bug, but I'm unable to find a reproducer after dist-upgrading bullseye
systems to bookworm (all created from d-i's debian-11.6.0-amd64-netinst.iso,
and “Encrypted LVM” partition scheme, on VMs with 1024M RAM).

Jérôme, what memory cost is the keyslot using?  (Paste the output of
`cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:`.)  Would also be
interested to see by how much the amount of memory available to
cryptsetup has changed before and after the uprade.  Please edit
/usr/share/initramfs-tools/scripts/local-top/cryptroot and add `free` at
the begining of the setup_mapping() function (patch attached).  My own
findings are as follows (again on a minimal netinst system without
changing any default).  cryptsetup isn't even close to memory
exhaustion.


Memory cost:

- 8< -
# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:
PBKDF:  argon2i
Time cost:  4
Memory: 787907
Threads:1
- >8 -

Free memory:

- 8< -
Loading Linux 6.1.0-5-amd64 ...
Loading initial ramdisk ...
  totalusedfree  shared  buff/cache 
available
Mem: 993756   74720  725012  60  194024 
660412

Swap: 0   0   0
- >8 -

I've also tested on another of my virtual machines that has 1GiB of RAM 
and got another result, closer to what you got in your experimentation:


- 8< -
# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:
PBKDF:  argon2i
Time cost:  6
Memory: 499912
Threads:1
- >8 -

So, I think what's happening is that the first VM may have been created 
with a different (larger) memory configuration, and was reduced at a 
later point in time. I don't have absolute certainty of this, but it 
would very well explain the discrepancy in memory cost.


Also, I think I agree with your assessment that in the memory usage 
increase of the kernel may be involved: between the two releases, 
according to your numbers it appears to have increased nearly 25% (!). 
So it could also explain why it (probably very nearly) worked under 
bullseye.


I there any way we could make the cryptsetup-initramfs hook aware of 
this, and emit a warning if it finds that the encrypted root lacks a 
keyslot with appropriate (low-enough) memory cost?



Thanks,

-- Jérôme

Bug#1032801: [INTL:ro] Romanian debconf templates translation of motion

Package: motion
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «motion» file.

Thanks,
Remus-Gabriel

motion_debconf_ro.po
Description: Binary data

Bug#1031696: Use of symbolic links in non-free ISO images breaks file system transposition support

2023-03-11 Thread Thomas Schmitt

Hi,

James Addison wrote:
> My interpretation of the commands and output in your comment is that both
> genisoimage and xorriso can translate hardlinks from a source filesystem
> into deduplicated file references in a written ISO filesystem

With genisoimage we only know empirically. With libisofs under xorriso
i can tell that a red-black-tree of device and inode numbers is used to
match hard links. This is well tested by Debian ISOs because already now
the Linux kernels are hard link siblings.
E.g. in firmware-bookworm-DI-alpha1-amd64-netinst.iso 15 MB are won:
  Report layout: xt , Startlba ,   Blocks , Filesize , ISO image path
  File data lba:  0 ,35982 , 3761 ,  7700896 , 
'/install.amd/gtk/vmlinuz'
  File data lba:  0 ,35982 , 3761 ,  7700896 , '/install.amd/vmlinuz'
  File data lba:  0 ,35982 , 3761 ,  7700896 , 
'/install.amd/xen/vmlinuz'

If genisoimage would not deduplicate some hardlinks then the ISO would
simply become larger but stay functional for the boot paths which
debian-cd prepares and also for the file copying method which Pete Batard
wants to get enabled.

This method is intended for booting via EFI from USB stick. In general i
support Pete Batard's goal to have bootable ISOs ready for it, regardless
whether it is a wish or the fix of a regression.
(I looked into firmware-11.6.0-amd64-netinst.iso and found its /firmare
directory filled with symbolic links and one sub directory ./deb11.)

The file extraction method is supposed to be a behavioral pattern of
experienced users of MS-Windows. Let's be inviting to them or else they
might install Debian on WSL.

Have a nice day :)

Thomas

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

I looked into this, and five of the shadow package's six uses of strlcpy 
are wrong, i.e., they are associated with silent truncation or buffer 
overrun/underrun or dereferencing NULL in nearby code. This isn't 
surprising, as strlcpy is commonly used in code that has been 
slapdashedly hacked to try to make it safer, and in my experience code 
that that has been modified in that way is usually wrong.


Proposed patches attached.

Although there is one correct use of strlcpy, the correct use (in 
sgetsgent) is equivalent to memcpy so there is no need for strlcpy there 
(see patch 0002).
From d40e2f92f3e50d13d87393bd30b2b4b20b89a2d6 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 11 Mar 2023 00:01:02 -0800
Subject: [PATCH 1/6] Fix undefined behavior in change_field

* lib/fields.c (change_field): Do not ever compute &newf[-1],
as behavior is undefined.  Since we know that the string fits,
use memcpy rather than strlcpy.

Signed-off-by: Paul Eggert 
---
 lib/fields.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/lib/fields.c b/lib/fields.c
index 0b5f91b2..3b119502 100644
--- a/lib/fields.c
+++ b/lib/fields.c
@@ -90,17 +90,17 @@ void change_field (char *buf, size_t maxsize, const char *prompt)
 		 * makes it possible to change the field to empty, by
 		 * entering a space.  --marekm
 		 */
+		char *bp = newf;
 
-		while (--cp >= newf && isspace (*cp));
-		cp++;
+		while (newf < cp && isspace (cp[-1])) {
+			cp--;
+		}
 		*cp = '\0';
 
-		cp = newf;
-		while (('\0' != *cp) && isspace (*cp)) {
-			cp++;
+		while (isspace (*bp)) {
+			bp++;
 		}
 
-		strlcpy (buf, cp, maxsize);
+		memcpy (buf, bp, cp + 1 - bp);
 	}
 }
-
-- 
2.37.2

From 7e88c5914c1fab6c4d88e1ca39d6b6319e7ee768 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 11 Mar 2023 00:02:45 -0800
Subject: [PATCH 2/6] Prefer memcpy to strlcpy when either works

memcpy is standardized and should be faster here.
* lib/gshadow.c (sgetsgent): Use memcpy not strlcpy,
since the string is known to fit.

Signed-off-by: Paul Eggert 
---
 lib/gshadow.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/gshadow.c b/lib/gshadow.c
index c17af67f..1976c9a9 100644
--- a/lib/gshadow.c
+++ b/lib/gshadow.c
@@ -128,7 +128,7 @@ void endsgent (void)
 		sgrbuflen = len;
 	}
 
-	strlcpy (sgrbuf, string, len);
+	memcpy (sgrbuf, string, len);
 
 	cp = strrchr (sgrbuf, '\n');
 	if (NULL != cp) {
-- 
2.37.2

From a1c2e046d52042cf60ff7196a9d9a972573290bd Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 11 Mar 2023 00:38:24 -0800
Subject: [PATCH 3/6] Avoid silent truncation of console file data

* libmisc/console.c (is_listed): Rework so that there is no
fixed-size buffer, and no need to use fgets or strlcpy or strtok.
Instead, the code works with arbitrary-sized input,
without silently truncating data or mishandling NUL
bytes in the console file.

Signed-off-by: Paul Eggert 
---
 libmisc/console.c | 41 -
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/libmisc/console.c b/libmisc/console.c
index 7e2132dd..8264e1a3 100644
--- a/libmisc/console.c
+++ b/libmisc/console.c
@@ -24,7 +24,6 @@
 static bool is_listed (const char *cfgin, const char *tty, bool def)
 {
 	FILE *fp;
-	char buf[1024], *s;
 	const char *cons;
 
 	/*
@@ -43,17 +42,17 @@ static bool is_listed (const char *cfgin, const char *tty, bool def)
 	 */
 
 	if (*cons != '/') {
-		char *pbuf;
-		strlcpy (buf, cons, sizeof (buf));
-		pbuf = &buf[0];
-		while ((s = strtok (pbuf, ":")) != NULL) {
-			if (strcmp (s, tty) == 0) {
+		size_t ttylen = strlen (tty);
+		for (;;) {
+			if (strncmp (cons, tty, ttylen) == 0
+			&& (cons[ttylen] == ':' || !cons[ttylen])) {
 return true;
 			}
-
-			pbuf = NULL;
+			cons = strchr (cons, ':');
+			if (!cons)
+return false;
+			cons++;
 		}
-		return false;
 	}
 
 	/*
@@ -70,21 +69,22 @@ static bool is_listed (const char *cfgin, const char *tty, bool def)
 	 * See if this tty is listed in the console file.
 	 */
 
-	while (fgets (buf, sizeof (buf), fp) != NULL) {
-		/* Remove optional trailing '\n'. */
-		buf[strcspn (buf, "\n")] = '\0';
-		if (strcmp (buf, tty) == 0) {
-			(void) fclose (fp);
-			return true;
+	const char *tp = tty;
+	bool listed = false;
+	for (int c; 0 <= (c = getc (fp)); ) {
+		if (c == '\n') {
+			if (tp && !*tp) {
+listed = true;
+break;
+			}
+			tp = tty;
+		} else if (tp) {
+			tp = *tp == c && c ? tp + 1 : NULL;
 		}
 	}
 
-	/*
-	 * This tty isn't a console.
-	 */
-
 	(void) fclose (fp);
-	return false;
+	return listed;
 }
 
 /*
@@ -105,4 +105,3 @@ bool console (const char *tty)
 
 	return is_listed ("CONSOLE", tty, true);
 }
-
-- 
2.37.2

From 1c8388d1d1831e976cdaa6e6f27bb08bf31aedc5 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 11 Mar 2023 00:42:29 -0800
Subject: [PATCH 4/6] Fix crash with large timestamps

* libmisc/date_to_str.c (date_to_str): Do not crash if gmtime
returns NULL because the timestamp is far

Bug#1032800: [INTL:ro] Romanian debconf templates translation of mopidy

Package: mopidy
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «mopidy» file.

Thanks,
Remus-Gabriel

mopidy_debconf_ro.po
Description: Binary data

Bug#1032799: please drop transitional package ubuntu-core-launcher from src:snapd

Package: ubuntu-core-launcher
Version: 2.57.6-1+b3
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package ubuntu-core-launcher (from the source 
package snapd) after the release of bookworm, it has been released with buster 
and bullseye already...


Description: Transitional package for snapd
Package: ubuntu-core-launcher
Version: 2.37.4-1+deb10u1
Version: 2.49-1+deb11u2
Version: 2.57.6-1+b3

Thanks for maintaining snapd!


-- 
cheers,
Holger

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

Moral, truth, long term- and holistic thinking seem to mean nothing to us. The
emperors are naked. Every single one. It turns out our whole society is just
one big nudist party. (Greta Thunberg in early 2020 about the world reacting to
the corona crisis but not reacting appropriatly to the climate crisis.)


signature.asc
Description: PGP signature

Bug#1032798: please drop transitional package verbiste-el from src:verbiste

Package: verbiste-el
Version: 0.1.47-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package verbiste-el (from the source package 
verbiste) after the release of bookworm, it has been released with buster and 
bullseye already...


Description: transitional package, verbiste-el to elpa-verbiste
Package: verbiste-el
Version: 0.1.45-5
Version: 0.1.47-1

Thanks for maintaining verbiste!


-- 
cheers,
Holger

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

I'm looking forward to Corona being a beer again and Donald a duck.


signature.asc
Description: PGP signature

Bug#1032734: OOM when unlocking encrypted root in initramfs

2023-03-11 Thread Guilhem Moulin

Control: found -1 2:2.1.0-5+deb10u2
Control: tag -1 moreinfo

Hi kibi,

On Sat, 11 Mar 2023 at 15:16:01 +0100, Cyril Brulebois wrote:
> Guilhem Moulin  (2023-03-11):
>> On Sat, 11 Mar 2023 at 08:26:27 -0500, Jérôme Charaoui wrote:
>>> Today I upgraded a small KVM machine with a LUKS2 encrypted root and 1GiB of
>>> RAM to bookworm, and was very surprised to be confronted with an OOM
>>> immediately upon entering my LUKS password in the initramfs prompt:
>>> […]
>>> The problem appears to be perhaps related to #924560, but in this instance,
>>> the issue causing an unbootable system post-upgrade.
>>
>> No, this is related to #1028250 and 
>> https://gitlab.com/cryptsetup/cryptsetup/-/issues/802#note_1287298872 .
>> Don't think we can do anything in src:cryptsetup for existing volumes
>> unfortunately.  You might need to manually lower the parameters of your
>> PBKDF.
>
> Existing systems failing to boot after an upgrade doesn't seem to be
> “only” important to me…

I fail to see how that's different from an existing resource-constrained
system (sarge recommends for 64MiB RAM for desktop i386) being unusable
after dist-upgrading to a more recent Debian release.  Granted I haven't
tried it, but I very much doubt GNOME would still work with that little
memory :-)

Anyway, while it definitely isn't ideal (not very future proof) that the
key slots were created with a memory cost close to the whole available
memory, there is actually not that much difference in resident set size
before and after the upgrade.  The test environment is a VM with 1024M
RAM, and initialized with d-i's debian-10.12.0-amd64-netinst.iso and
“Encrypted LVM” partition scheme.  In my case the PBKDF benchmark chose
the following parameters (close to half the amount of physical memory
indeed):

~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:
PBKDF:  argon2i
Time cost:  4
Memory: 504962
Threads:2

## buster (cryptsetup 2:2.1.0-5+deb10u2, linux 4.19+105+deb10u18)
~# command time cryptsetup luksOpen --test-passphrase /dev/vda5 <<> Lowering the severity, because this shouldn't block the transition of -2
>> into bookworm (which fixes an unrelated and arguably much more severe RC
>> bug).
>
> That's not really how RC bugs work: bugs aren't less RC because it makes
> sense for a specific version to migrate…
>
> Either the bug appeared specifically in the version it was filed against,
> and it makes sense to block the migration since that's a new RC bug in
> that particular version, and the RC-ness stays.
>
> Or the bug was already there in the version currently in testing, and that
> means that's not a regression, and the RC-ness stays. You only need to
> record the bug as also being found in the previous version (possibly
> plural) to make sure britney knows it's not a regression.

Ah cool didn't know that, thanks for the information.  Marking this as
found all the way back to buster then.  I'm indeed able to trigger the
OOM-killer on a buster system when I artificially fill the memory so the
memory cost exceeds what remains.  Furthermore I don't see what can be
done about existing keyslots, and that includes everything created since
buster.

> Sure, we can discuss the severity of the bug I filed. But #1032734 really
> can't be “just” important.

Tagging ‘moreinfo’ then.  I can definitely see how one can reproduce
this theoretically (and possibly in the future when the kernel's memory
requirement increase high enough), and mentioned that in the upstream
bug, but I'm unable to find a reproducer after dist-upgrading bullseye
systems to bookworm (all created from d-i's debian-11.6.0-amd64-netinst.iso,
and “Encrypted LVM” partition scheme, on VMs with 1024M RAM).

Jérôme, what memory cost is the keyslot using?  (Paste the output of
`cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:`.)  Would also be
interested to see by how much the amount of memory available to
cryptsetup has changed before and after the uprade.  Please edit
/usr/share/initramfs-tools/scripts/local-top/cryptroot and add `free` at
the begining of the setup_mapping() function (patch attached).  My own
findings are as follows (again on a minimal netinst system without
changing any default).  cryptsetup isn't even close to memory
exhaustion.

## bullseye (cryptsetup 2:2.3.7-1+deb11u1, linux 5.10.162-1)
~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:
PBKDF:  argon2i
Time cost:  4
Memory: 499892
Threads:2
~# systemctl reboot
Loading Linux 5.10.0-21-amd64 ...
Loading initial ramdisk ...
  totalusedfree  shared  buff/cache   
available
Mem: 999776   39276  843280  52  117220 
 777124
Swap: 0   0   0
Please unlock disk vda5_crypt:
1.90user 0.18syste

Bug#1032786: greetd: Authentication error due to _greety user having shell=/usr/sbin/nologin

2023-03-11 Thread Denis M

Separate issue is this warning

warning: PAM 'greetd' service missing, falling back to 'login'

After looking into the code of greetd I can tell it is triggered by
the absence of the file /etc/pam.d/greet. This file is provided by a
separate package in arch linux[1], perhaps the debian package should
provide a similar file too. However, just copying their file wasn't
enough. I get another error:

Mar 11 20:28:34 boy systemd[1]: Started greetd.service - Greeter daemon.
Mar 11 20:28:34 boy greetd[734]: PAM _pam_load_conf_file: unable to
open config for /etc/pam.d/system-local-login
Mar 11 20:28:34 boy greetd[734]: PAM _pam_load_conf_file: unable to
open config for /etc/pam.d/system-local-login
Mar 11 20:28:34 boy greetd[734]: PAM _pam_load_conf_file: unable to
open config for /etc/pam.d/system-local-login
Mar 11 20:28:34 boy greetd[734]: error: authentication error:
pam_acct_mgmt: PERM_DENIED
Mar 11 20:28:34 boy greetd[733]: unable to start greeter: session
start failed: authentication error: pam_acct_mgmt: PERM_DENIED


[1]: https://aur.archlinux.org/cgit/aur.git/tree/greetd.pam?h=greetd

Bug#1032663: ITP: eludris -- A simple CLI to help you with setting up and managing your Eludris instance

2023-03-11 Thread Gunnar Wolf

Please explain briefly in your package description what is an Eludris
instance and why it might be useful or interesting to a Debian user
who stumbles upon your package!

Oliver Wilkes dijo [Fri, Mar 10, 2023 at 04:43:19PM +]:
> Package: wnpp
> Severity: wishlist
> Owner: Oliver Wilkes 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name : eludris
> Version : 0.3.2
> Upstream Author : Oliver Wilkes 
> * URL : https://github.com/eludris/eludris/tree/main/cli/
> * License : MIT
> Programming Lang: Rust
> Description : A simple CLI to help you with setting up and managing your
> Eludris instance
> 
> Located at https://github.com/eludris/eludris/tree/main/cli, this is a
> package for creating an Eludris instance with ease. It is officially
> supported and maintained by Eludris and reduces the barrier to entry for new
> instance owners.
> 
> ### Why is this package useful/relevant?
> 
> This CLI provides an easy way for users to create their own Eludris instance
> from scratch. There are currently no alternatives as Eludris is relatively
> new and this is an 'official' CLI.
> 
> ### How do you plan to maintain it?
> 
> I am not all too sure how this works as this is my first time packaging for
> Debian. I plan to maintain it solo for now, unless if anyone has any better
> suggestions as to what team to maintain it under.
> 

--

Bug#1031696: Use of symbolic links in non-free ISO images breaks file system transposition support

2023-03-11 Thread James Addison

Followup-For: Bug #1031696

On Sat, 11 Mar 2023 18:10:22 +0100, Thomas Schmitt wrote:
>   ifneq (,$(filter i386 amd64 arm64 hppa,$(ARCHES)))

> Surely i386, amd64, and arm64 get their published Debian ISOs made
> by xorriso.

I think your expectation is correct there, yes: looking further into the
commit history, xorriso became the default[1] for i386/amd64 a while ago, in
March 2013.

> So let's test hardlink handling in genisoimage:
> 
>   $ ls -l /u/test/hardlinks
>   total 88
>   -rw-r--r-- 2 thomas thomas 42786 Nov 14  2005 hardlink_x
>   -rw-r--r-- 2 thomas thomas 42786 Nov 14  2005 x
>   $ genisoimage -o test2.iso -R /u/test/hardlinks
>   ...
>   196 extents written (0 MB)
> 
> We inspect the resulting ISO by xorriso:
> 
>   $ xorriso -indev test2.iso -find / -type f -exec report_lba --
>   ...
>   Report layout: xt , Startlba ,   Blocks , Filesize , ISO image path
>   File data lba:  0 ,   25 ,   21 ,42786 , '/hardlink_x'
>   File data lba:  0 ,   25 ,   21 ,42786 , '/x'
>   $
> 
> Both files in the ISO refer to the same block range starting at 2048-byte
> block 25 up to block 45. So in the ISO, they are deduplicated
> 
> Now for a bit of kernel slapstick:
> 
>   $ sudo mount test2.iso /mnt/iso
>   mount: /mnt/iso: WARNING: source write-protected, mounted read-only.
>   $ ls -li /mnt/iso
>   1479 -rw-r--r-- 2 thomas thomas 42786 Nov 14  2005 hardlink_x
>   1483 -rw-r--r-- 2 thomas thomas 42786 Nov 14  2005 x
> 
> Note the link count 2 in combination with the differing inode numbers.
> (The link count stems from Rock Ridge field PX. By mistake i mentoned it
> as "PN" in my previous mail.)
> 
> The false link count does not hamper restoring of the files:
> 
>   $ cp -r /mnt/iso /u/test/hardlinks_restored
>   $ ls -li  /u/test/hardlinks_restored
>   total 88
>   8913418 -rw-r--r-- 1 thomas thomas 42786 Mar 11 17:38 hardlink_x
>   8913419 -rw-r--r-- 1 thomas thomas 42786 Mar 11 17:38 x
> 
> So the files are independent after being restored by Debian 11 to ext4.
> 
> The same happens with an ISO made by xorriso:
> 
>   $ xorriso -as mkisofs -o test.iso -R /u/test/hardlinks
>   ...
>   $ xorriso -indev test.iso -find / -type f -exec report_lba
>   ...
>   Report layout: xt , Startlba ,   Blocks , Filesize , ISO image path
>   File data lba:  0 ,   33 ,   21 ,42786 , '/hardlink_x'
>   File data lba:  0 ,   33 ,   21 ,42786 , '/x'
> 
>   $ sudo mount test.iso /mnt/iso
>   ...
>   $ cp -r /mnt/iso /u/test/hardlinks_restored
>   $ ls -li  /u/test/hardlinks_restored
>   total 88
>   8913418 -rw-r--r-- 1 thomas thomas 42786 Mar 11 17:47 hardlink_x
>   8913419 -rw-r--r-- 1 thomas thomas 42786 Mar 11 17:47 x
> 
> Just to prove that the restored files are really not hardlinked:
> 
>   $ echo some_tail_bytes >> /u/test/hardlinks_restored/x
>   $ ls -li  /u/test/hardlinks_restored
>   total 88
>   8913418 -rw-r--r-- 1 thomas thomas 42786 Mar 11 17:47 hardlink_x
>   8913419 -rw-r--r-- 1 thomas thomas 42802 Mar 11 17:48 x
>   $

Thank you very much for doing this and sharing the results.

My interpretation of the commands and output in your comment is that both
genisoimage and xorriso can translate hardlinks from a source filesystem into
deduplicated file references in a written ISO filesystem, and that simple
copying of those files from the filesystem when mounted creates unlinked,
separate copies of them, as would be suitable to create a UEFI boot drive using
only a standard file explorer (as included in most-or-perhaps-all operating
systems and without requiring the user to provide custom options when
performing the copy).

If that's correct then I might have some follow-up suggestions, but I'd like to
get a general sense of agreement from folks on the details before that.

[1] - 
https://salsa.debian.org/images-team/debian-cd/-/commit/b77a268aa291ea3cdb3811da474b67fd7073c2cf

Bug#1032654: [Aptitude-devel] Bug#1032654: aptitude: missing message about the Debian bookworm change concerning non-free-firmware

2023-03-11 Thread Axel Beckert

Control: clone -1 -2
Control: retitle -2 aptitude: "aptitude -u" does not show download warnings 
emitted by "aptitude update" after the successful download of package lists.
Control: clone -1 -3
Control: retitle -3 aptitude: "aptitude update" does not show all NOTICE level 
messages if apt would change the default messages threshold to NOTICE
Control: severity -3 minor
Control: submitter -3 !
Control: clone -1 -4
Control: retitle -4 aptitude: apt's message threshold level should be 
configurable in aptitude (especially for the TUI), maybe via --log-level?
Control: severity -4 wishlist
Control: submitter -4 !
Control: severity -1 minor
Control: tag -1 + wontfix

Hi Vincent,

thanks for making us aware of the subtle difference between apt and
aptitude with regards to warnings and notices.

> This message should have been displayed by aptitude.

Did you test "aptitude update" or "aptitude -u" or both? It's not
clear from your bug report so far. (They behave differently in this
hindsight as I found out while digging into this topic, see below.)

> Without it, the user who uses aptitude only may never be aware of
> this change […]

This is wrong. Without doubt this type of information will be part of
the release notes — which is usually the _primary_ source for these
type of changes. I'm actually surprised that apt added such a message.

Besides that, the apt developers decided to output this only as LOW
severity message on the "notice" level (prefix by "N:" and in normal
font face; AFAIK the lowest level).

Aptitude shows "error" messages from apt to the user, but only those
at the "WARNING" level or above (or at least only from somewhere above
the "NOTICE" level). It is currently unclear to me if this is
historically grown as apt (not aptitude) defines the _default_ message
threshold by apt in /usr/include/apt-pkg/error.h as "WARNING" in at
least three places. I at least currently assume that this is what
aptitude uses when it calls DumpErrors. According the apt's changelog,
"WARNING" was for quite some time also the lowest possible message
level. ("NOTICE" and "DEBUG" levels got added in 0.7.26~exp8.)

I also do see some sense to suppress some less important messages in
aptitude: All those messages would cause popup window in the TUI mode
which the user has to acknowledge (aka "to click away"). That can get
very annoying if there are too many low severity messages. So IMHO
it's not so bad that aptitude only shows more important messages.
Besides, it's the default threshold from apt.

Then again, "aptitude -u" does not show any of the warnings (or
notices) I currently get with "aptitude update", so "aptitude -u" only
seems to cause popups of warnings which are caused directly during the
download and not after a successful download. Cloning this as a
separate bug report.

Anyway, back to the original topic. So I edited
/usr/include/apt-pkg/error.h temporarily and replaced all but the
first occurence (which is the definition) of WARNING with NOTICE and
then compiled aptitude against it. aptitude update indeed
showed notices now. But to my surprise not all of them, just this one:

  N: Skipping acquire of configured file 'main/binary-i386/Packages' as 
repository 'file:/var/cache/apt-build/repository apt-build InRelease' doesn't 
support architecture 'i386'

Not yet sure if this is a bug in the way how the missing notices are
generated in apt or if it is a bug in aptitude not coping with the
changed default message threshold. Likely needs deeper investigation
(or better overview of the code), probably by Manuel. (I already put
hours in investigating this IMHO rather minor issue, just to
understand a bit how the innards of messages inside apt and aptitude
are working.) Filing as yet another separate bug report against
aptitude (for now at least), but with severity minor, as it currently
does only show up after a hypothetical modification in apt.

I'm also surprised that, despite the default threshold in
/usr/include/apt-pkg/error.h is WARNING, both, "apt update" and
"apt-get update" show notices. So the apt developers changed the
thresholds for both CLI frontends individually? Weird.

And JFTR: "aptitude update" does show the WARNING level messages from
apt about "Key is stored in legacy trusted.gpg keyring
(/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for
details." which apt also shows in a bold font face compared to
seemingly not important messages like these about the
non-free-firmware repo. (Not "aptitude -u", though.)

Admittedly the message level threshold of aptitude should be user
configurable so that every user/admin can adjust their own TUI popup
annoyance level.

Actually I would have expected to see those notices on
--log-level=info, but I didn't and from the code it also seems that
this option has no influence on how aptitude uses apt's DumpErrors().

Anyway, despite I uncovered some more severe issues while trying to
understand how apt's and aptitude's message handling works int

Bug#1030730: qtquickcontrols-opensource-src FTBFS on hppa

2023-03-11 Thread Dmitry Shachnev

Hi Helge!

On Mon, Feb 06, 2023 at 10:12:37PM +0100, Helge Deller wrote:
> Package: qtquickcontrols-opensource-src
> Tags: ftbfs, hppa
> Version:  5.15.8-2
>
> qtquickcontrols-opensource-src FTBFS on hppa with this testcase failure:
> FAIL!  : qtquickcontrols::Tests_TreeView::test_pressAndHold() Compared values 
> are not the same
>Actual   (): 0
>Expected (): 1
>Loc: [/<>/tests/auto/controls/data/tst_treeview.qml(274)]
> 
> see:
> https://buildd.debian.org/status/fetch.php?pkg=qtquickcontrols-opensource-src&arch=hppa&ver=5.15.8-2&stamp=1675556283&raw=0
> 
> Looking at debian/rules file I see:
> $(MAKE) install INSTALL_ROOT=$(CURDIR)/test_root
> ifneq (,$(filter $(DEB_HOST_ARCH),mips mips64el mipsel powerpc ppc64 riscv64 
> s390x))
> # mips*: segmentation fault, see #868745
> # powerpc, ppc64: some failures in extras::Tests_Picture and 
> extras::Tests_StatusIndicator
> # riscv64: failure in 
> qtquickcontrols::Tests_TreeView::test_pressAndHold
> # s390x: some failures in qtquickcontrols::Tests_TableView and 
> qtquickcontrols::Tests_TreeView
> -xvfb-run -a -s "-screen 0 1024x768x24 +extension RANDR +extension 
> RENDER +extension GLX" \
> dh_auto_test --no-parallel -- 
> QML2_IMPORT_PATH=$(CURDIR)/test_root/usr/lib/$(DEB_HOST_MULTIARCH)/qt5/qml
> else
> 
> so, "riscv64" fails the same testcase.
> I don't know the backgrounds why riscv64 fails, but I assume adding "hppa" to 
> the ifneq() like this:
> ifneq (,$(filter $(DEB_HOST_ARCH),mips mips64el mipsel powerpc ppc64 riscv64 
> s390x hppa))
> might fix (or avoid) the FTBFS.

I see that someone forced the package to build without the tests, so
now it's available in the hppa archive. But have you checked that the
produced package is usable?

Does Qt QML engine work on hppa, or there are issues caused by stack
growing up?

If you think it works, then I will be happy to disable the tests there.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1030936: vlc: crash on start playing

2023-03-11 Thread Sebastian Ramacher

On 2023-03-11 17:51:37 +0300, Vladimir Stavrinov wrote:
> On Tue, Feb 14, 2023 at 4:13 PM Sebastian Ramacher  
> wrote:
> >
> > Control: reassign -1 0.0.8-1
> 
> Sorry if I don't understand something, but today I've unexpectedly
> discovered that the driver  You reassigned to, that is
> nvidia-vaapi-driver, isn't installed on my system. When I've tried to
> install it I encountered the conflict:
> 
> Unpacking nvidia-vaapi-driver:amd64 (0.0.8-1) ...
> dpkg: error processing archive
> /var/cache/apt/archives/nvidia-vaapi-driver_0.0.8-1_amd64.deb
> (--unpack):
>  trying to overwrite
> '/usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so', which is also in
> package vdpau-va-driver:amd64 0.7.4-7
> 
> After removing the vdpau-va-driver and installing nvidia-vaapi-driver
> the problem was gone. So although now I personally do not have this
> problem, the problem as such remains. The file being the subject of
> the conflict is the only binary code file in both packages. So I see
> the one of the two ways to solve the problem:
> 
> 1. Either reassign this bug to vdpau-va-driver
> 2. Or remove vdpau-va-driver from the repository and change
> accordingly all being affected packages dependency to point to
> nvidia-vaapi-driver.

vdpau-va-driver was removed from the archive in August 2019 and is
neither part of bullseye and bookworm.

Cheers
-- 
Sebastian Ramacher

Bug#1032793: grsync: Password not asked for

2023-03-11 Thread Mark Rognss

Package: grsync
Version: 1.3.0-1+b1
Severity: important
X-Debbugs-Cc: longwal...@yahoo.ca

Dear Maintainer,

I changed sources.list to Bookworm and did full upgrade.  Went real smooth.
Previous full upgrade (2 years ago) to Buster was clean upgrade, added a SSD.

 When using grsyc to sync with DNS-323 nas (Alt-F) it did not proceed.  No pop
up window asking for password.

Starting grsync via terminal -the gui appears. When the same  session is
selected, the request for password is shown in the terminal.   This occurs when
using LXQT

The same occurs in Sway, the password pop up does not occur, however grsync
will ask for password in terminal and complete successfully.

I have been utilizing grsync with this computer and NAS since stretch.

Outcome expected was that a pop up would occur.


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

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

Versions of packages grsync depends on:
ii  libc6   2.36-8
ii  libglib2.0-02.74.6-1
ii  libgtk-3-0  3.24.36-4
ii  libpango-1.0-0  1.50.12+ds-1
ii  rsync   3.2.7-1

Versions of packages grsync recommends:
ii  lxqt-openssh-askpass [ssh-askpass]  1.2.0-1

grsync suggests no packages.

-- no debconf information
 DATADATA - Sat Mar 11 11:51:24 2023

** Launching RSYNC command:
rsync -r -t -o -v --progress --delete --ignore-existing -s --exclude lost+found 
--exclude Sync/.stversions --exclude .stversion --exclude .Trash-100 --exclude 
DATA/tmp/BUP-BKWRM /DATA root@192.168.1.210://mnt/sdb2

Permission denied, please try again.
Permission denied, please try again.
root@192.168.1.210: Permission denied (publickey,password).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(231) [sender=3.2.7]
Rsync process exit status: 255

Bug#1032792: please drop transitional package libuim-data from src:uim

Package: libuim-data
Version: 1:1.8.8-9.2
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package libuim-data (from the source package uim) 
after the release of bookworm, it has been released with buster and bullseye 
already...


Description: transitional package for uim-data
Package: libuim-data
Version: 1:1.8.8-4+deb10u5
Version: 1:1.8.8-9
Version: 1:1.8.8-9.2

Thanks for maintaining uim!


-- 
cheers,
Holger

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

The greatest danger in times of turbulence is not the turbulence;
it is to act with yesterdays logic. (Peter Drucker)


signature.asc
Description: PGP signature

Bug#1032790: please drop transitional package x11proto-core-dev from src:xorgproto

Package: x11proto-core-dev
Version: 2022.1-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package x11proto-core-dev (from the source package 
xorgproto) after the release of bookworm, it has been released with buster and 
bullseye already...


Description: transitional dummy package
Package: x11proto-core-dev
Version: 2018.4-4
Version: 2020.1-1
Version: 2022.1-1

Thanks for maintaining xorgproto!


-- 
cheers,
Holger

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

This is the year of gpg on the desktop! (Gunnar Wolf)


signature.asc
Description: PGP signature

Bug#1032791: please drop transitional package skytools3-ticker from src:pgqd

Package: skytools3-ticker
Version: 3.5-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package skytools3-ticker (from the source package 
pgqd) after the release of bookworm, it has been released with buster and 
bullseye already...


Description: Transitional package to pull in pgqd
Package: skytools3-ticker
Version: 3.3-2
Version: 3.3-5
Version: 3.5-1

Thanks for maintaining pgqd!


-- 
cheers,
Holger

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

Encryption is binary. Either something is end to end encrypted or it's not.
If there are backdoors, they will be open to anyone eventually and thus
encryption with backdoors is like there's no encryption at all.
 Privacy and thus encryption are human rights.


signature.asc
Description: PGP signature

Bug#1032789: please drop transitional package idle3 from src:python3-defaults

Package: idle3
Version: 3.11.2-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package idle3 (from the source package 
python3-defaults) after the release of bookworm, it has been released with 
buster and bullseye already...


Description: IDE for Python using Tkinter (transitional package)
Package: idle3
Version: 3.11.2-1
Version: 3.7.3-1
Version: 3.9.2-3

Thanks for maintaining python3-defaults!


-- 
cheers,
Holger

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

"I know what you're thinking" used to be an idiom but now it's a business model.


signature.asc
Description: PGP signature

Bug#1032788: please drop transitional package python3-dicom from src:pydicom

Package: python3-dicom
Version: 2.3.1-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package python3-dicom (from the source package 
pydicom) after the release of bookworm, it has been released with buster and 
bullseye already...


Description: transitional package for python3-pydicom
Package: python3-dicom
Version: 1.2.1-1
Version: 2.0.0-1
Version: 2.3.1-1

Thanks for maintaining pydicom!


-- 
cheers,
Holger

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

Smart things make us dumb.


signature.asc
Description: PGP signature

Bug#1032787: vfu: cat not open file with special characters in it's name

2023-03-11 Thread Anonymous 648

Package: vfu
Version: 5.07-1~bpo11+1
Severity: normal
X-Debbugs-Cc: gmtmpa...@gmail.com

Dear Maintainer,

1) Create files with special characters in names:
touch 'aa bb.txt'  
touch 'aa$bb.txt'
touch 'aa%bb.txt'

2) Configuration from vfu.conf:
ux=EDIT TEXT,ENTER,.txt.TXT.conf.CONF.log.LOG.cfg.CFG.,xterm -e vim "%f"  1> 
/dev/null 2> /dev/null &
see=*,see '%f' 1> /dev/null 2> /dev/null &

Configuration from .mailcap:
text/plain; batcat --paging=always '%s'; edit=vim '%s'; compose=vim '%s'; 
needsterminal

3) When I am trying to open these files using "right arrow" - nothing
happens. If I use "ENTER" for opening these files - everything works ok



-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages vfu depends on:
ii  bzip2  1.0.8-4
ii  libc6  2.31-13+deb11u5
ii  libgcc-s1  10.2.1-6
ii  libpcre2-32-0  10.36-2+deb11u1
ii  libpcre2-8-0   10.36-2+deb11u1
ii  libstdc++6 10.2.1-6
ii  libyascreen0   1.97-1~bpo11+1
ii  unzip  6.0-26+deb11u1

vfu recommends no packages.

vfu suggests no packages.

-- no debconf information

Bug#1032786: greetd: Authentication error due to _greety user having shell=/usr/sbin/nologin

2023-03-11 Thread Denis M

Package: greetd
Version: 0.9.0-1
Severity: normal

Dear Maintainer,


   * What led up to the situation?

I installed greetd using 'apt install greetd' onto the system
with little graphical environment present. I haven't installed
any DE yet, only Xorg.


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

After installation I rebooted the system and had usual linux
terminal login screen which is probably wrong. (I haven't used
greetd before I don't really know what to expect.)


   * What was the outcome of this action?

That's what I've seen in the journald -u greetd:

Mar 11 18:28:38 boy greetd[797]: warning: PAM 'greetd' service missing, 
falling back to 'login'
Mar 11 18:28:38 boy greetd[798]: pam_unix(login:session): session 
opened for user _greetd(uid=102) by (uid=0)
Mar 11 18:28:38 boy greetd[806]: pam_unix(login:auth): check pass; user 
unknown
Mar 11 18:28:38 boy greetd[806]: pam_unix(login:auth): authentication 
failure; logname= uid=0 euid=0 tty= ruser= rhost=
Mar 11 18:28:42 boy greetd[806]: error: authentication error: 
pam_authenticate: AUTH_ERR
Mar 11 18:28:42 boy greetd[797]: client loop failed: i/o error: Broken 
pipe (os error 32)

   * What outcome did you expect instead?

Instead I expected to see no errors in the log and have a
functional greeter on startup. I'm still not sure what this
should mean though.


   * Potential fix

I searched similar errors on the internet. There are not many pages
about it. But it seems that _greetd user should have
shell=/usr/bin/bash. When I changed its hell this way in
/etc/passwd the error disappeared.


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

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

Versions of packages greetd depends on:
ii  adduser3.131
ii  libc6  2.36-8
ii  libgcc-s1  12.2.0-14
ii  libpam0g   1.5.2-6

greetd recommends no packages.

Versions of packages greetd suggests:
pn  wlgreet  

-- no debconf information

Best regards,
Denis M.

Bug#1032785: mipsel: gdb fails to find symbols in rust binary

2023-03-11 Thread Fabian Grünbichler

Package: gdb
Version: 13.1-2
Severity: important
Control: affects -1 src:rustc

basically a follow-up to #1031946 - there are at least two more rustc
test cases that fail with gdb 13.1 (but used to work with gdb 12.1),
this time only affecting mipsel.

I extracted the test cases in the existing reproducer repository[0], you
will need a mipsel machine (/VM) with rustc and cargo installed (I used
1.63 from bookworm).

I'll work around the issue for now by allowing rustc to build in
experimental even with these test cases failing, but a rebuild of rustc
on mipsel in bookworm would (likely) fail until this is fixed properly.

0: https://salsa.debian.org/fg/rustc-gdb-1031745/-/blob/main/README-mips.md
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031946

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

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

Versions of packages gdb depends on:
ii  libbabeltrace1  1.5.11-1+b2
ii  libc6   2.36-8
ii  libdebuginfod1  0.188-2.1
ii  libexpat1   2.5.0-1
ii  libgcc-s1   12.2.0-14
ii  libgmp102:6.2.1+dfsg1-1.1
ii  libipt2 2.0.5-1
ii  liblzma55.4.1-0.2
ii  libmpfr64.2.0-1
ii  libncursesw66.4-2
ii  libpython3.11   3.11.2-5
ii  libreadline88.2-1.3
ii  libsource-highlight4v5  3.1.9-4.2+b2
ii  libstdc++6  12.2.0-14
ii  libtinfo6   6.4-2
ii  libxxhash0  0.8.1-1
ii  libzstd11.5.4+dfsg2-4
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.36-8

Versions of packages gdb suggests:
pn  gdb-doc
pn  gdbserver  

-- no debconf information

Bug#1017646: Ready to implement

2023-03-11 Thread Soren Stoutner

Don,

I think we have finally reached a stage where we are ready to implement this.

To make things simpler for the packagers, we are using a virtual package and 
an unversioned path for the conversion tool so that language packagers don’t 
have to make modifications to their packages when the versions of Qt change in 
Debian.

All you should need to do is the following:

1.  Build-depends on `convert-bdic`.
2.  Use /usr/bin/convert-bdic to do the dictionary conversion.
3.  Place the .bdic files in /usr/share/hunspell-bdic.

Thanks,

Soren

-- 
Soren Stoutner
so...@stoutner.com

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

Bug#1032784: kdeconnect: App Segfaults sending from Pixel to laptop

2023-03-11 Thread Steve

Package: kdeconnect
Version: 22.12.3-1
Severity: normal
X-Debbugs-Cc: marathon.duran...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
   After transferring 13 jpeg files, I tried with 6 larger video files.

   * What was the outcome of this action?
   kdeconnect segfaulted after 1 or 2 files sent.
   
   * What outcome did you expect instead?
   Well obviously for the transfer to complete. :=)


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

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

Versions of packages kdeconnect depends on:
ii  fuse33.14.0-2
ii  kio  5.103.0-1
ii  kpeople-vcard0.1-3
ii  libc62.36-8
ii  libfakekey0  0.3+git20170516-2
ii  libkf5configcore55.103.0-1
ii  libkf5configwidgets5 5.103.0-1
ii  libkf5coreaddons55.103.0-1
ii  libkf5dbusaddons55.103.0-1
ii  libkf5guiaddons5 5.103.0-1
ii  libkf5i18n5  5.103.0-1
ii  libkf5iconthemes55.103.0-1
ii  libkf5kcmutils5  5.103.0-3
ii  libkf5kiocore5   5.103.0-1
ii  libkf5kiofilewidgets55.103.0-1
ii  libkf5kiogui55.103.0-1
ii  libkf5kiowidgets55.103.0-1
ii  libkf5notifications5 5.103.0-1
ii  libkf5people55.103.0-1
ii  libkf5pulseaudioqt3  1.3-2+b1
ii  libkf5service-bin5.103.0-1
ii  libkf5service5   5.103.0-1
ii  libkf5solid5 5.103.0-1
ii  libkf5waylandclient5 4:5.103.0-1
ii  libkf5widgetsaddons5 5.103.0-1
ii  libkf5windowsystem5  5.103.0-1
ii  libqca-qt5-2 2.3.5-2
ii  libqca-qt5-2-plugins 2.3.5-2
ii  libqt5core5a 5.15.8+dfsg-3
ii  libqt5dbus5  5.15.8+dfsg-3
ii  libqt5gui5   5.15.8+dfsg-3
ii  libqt5multimedia55.15.8-2
ii  libqt5network5   5.15.8+dfsg-3
ii  libqt5qml5   5.15.8+dfsg-3
ii  libqt5quick5 5.15.8+dfsg-3
ii  libqt5quickcontrols2-5   5.15.8+dfsg-2
ii  libqt5waylandclient5 5.15.8-2
ii  libqt5widgets5   5.15.8+dfsg-3
ii  libqt5x11extras5 5.15.8-2
ii  libstdc++6   12.2.0-14
ii  libwayland-client0   1.21.0-1
ii  libx11-6 2:1.8.4-2
ii  libxtst6 2:1.2.3-1.1
ii  plasma-framework 5.103.0-1
ii  qml-module-org-kde-kirigami2 5.103.0-1
ii  qml-module-org-kde-kquickcontrolsaddons  5.103.0-1
ii  qml-module-org-kde-people5.103.0-1
ii  qml-module-qt-labs-platform  5.15.8+dfsg-2
ii  qml-module-qtgraphicaleffects5.15.8-2
ii  qml-module-qtmultimedia  5.15.8-2
ii  qml-module-qtqml 5.15.8+dfsg-3
ii  qml-module-qtquick-controls2 5.15.8+dfsg-2
ii  qml-module-qtquick-dialogs   5.15.8-2
ii  qml-module-qtquick-layouts   5.15.8+dfsg-3
ii  qml-module-qtquick-particles25.15.8+dfsg-3
ii  qml-module-qtquick-window2   5.15.8+dfsg-3
ii  qml-module-qtquick2  5.15.8+dfsg-3
ii  sshfs3.7.3-1.1

kdeconnect recommends no packages.

kdeconnect suggests no packages.

-- no debconf information

Bug#1032783: please drop transitional package x11proto-record-dev from src:xorgproto

Package: x11proto-record-dev
Version: 2022.1-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package x11proto-record-dev (from the source 
package xorgproto) after the release of bookworm, it has been released with 
buster and bullseye already...


Description: transitional dummy package
Package: x11proto-record-dev
Version: 2018.4-4
Version: 2020.1-1
Version: 2022.1-1

Thanks for maintaining xorgproto!


-- 
cheers,
Holger

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

We are done with ‘world leaders’. Countries are on fire. Cities are drowning.
People are dying. This is what scientists and activists have been warning the
world and politicians about. It’s here. We ARE facing the impacts of the
climate crisis. Forget about the future, it’s now.
fridays for future - https://nitter.net/fff_digital/status/1304520941012242432


signature.asc
Description: PGP signature

Bug#1032782: please drop transitional package x11proto-present-dev from src:xorgproto

Package: x11proto-present-dev
Version: 2022.1-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package x11proto-present-dev (from the source 
package xorgproto) after the release of bookworm, it has been released with 
buster and bullseye already...


Description: transitional dummy package
Package: x11proto-present-dev
Version: 2018.4-4
Version: 2020.1-1
Version: 2022.1-1

Thanks for maintaining xorgproto!


-- 
cheers,
Holger

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

First they came for the journalists, we don't know what happened after that.


signature.asc
Description: PGP signature

Bug#1032781: please drop transitional package x11proto-randr-dev from src:xorgproto

Package: x11proto-randr-dev
Version: 2022.1-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package x11proto-randr-dev (from the source 
package xorgproto) after the release of bookworm, it has been released with 
buster and bullseye already...


Description: transitional dummy package
Package: x11proto-randr-dev
Version: 2018.4-4
Version: 2020.1-1
Version: 2022.1-1

Thanks for maintaining xorgproto!


-- 
cheers,
Holger

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

blockchaineinträge sind wie liebesschlösser an brückengeländern. ja, die
dinger haben eine gewisse security, aber das anhängen ist ein rein
symbolischer akt, ohne garantie, dass es ernst gemeint ist. was bleibt ist
kitsch, dessen kosten auf die gemeinschaft abgewälzt werden. (@mspro)


signature.asc
Description: PGP signature

Bug#1031696: Use of symbolic links in non-free ISO images breaks file system transposition support

2023-03-11 Thread Thomas Schmitt

Hi,

James Addison wrote:
> it looks like the selection of CD image
> creation tool is configured per-architecture here:
> https://salsa.debian.org/images-team/debian-cd/-/blob/5aebb6794a3b8b2393663fb643e35eb8e510c9a4/Makefile#L24

I wish i would understand the clause
  ifneq (,$(filter i386 amd64 arm64 hppa,$(ARCHES)))

Surely i386, amd64, and arm64 get their published Debian ISOs made
by xorriso. hppa seems to have switched to xorriso between Debian 10 and
11. sparc64 10.0 is genisoimage, ppc64el 10.8.0 is xorriso,
armhf 10.1.0 is xorriso ...
powerpc needs HFS and thus its ISO is made by genisoimage.

So let's test hardlink handling in genisoimage:

  $ ls -l /u/test/hardlinks
  total 88
  -rw-r--r-- 2 thomas thomas 42786 Nov 14  2005 hardlink_x
  -rw-r--r-- 2 thomas thomas 42786 Nov 14  2005 x
  $ genisoimage -o test2.iso -R /u/test/hardlinks
  ...
  196 extents written (0 MB)

We inspect the resulting ISO by xorriso:

  $ xorriso -indev test2.iso -find / -type f -exec report_lba --
  ...
  Report layout: xt , Startlba ,   Blocks , Filesize , ISO image path
  File data lba:  0 ,   25 ,   21 ,42786 , '/hardlink_x'
  File data lba:  0 ,   25 ,   21 ,42786 , '/x'
  $

Both files in the ISO refer to the same block range starting at 2048-byte
block 25 up to block 45. So in the ISO, they are deduplicated

Now for a bit of kernel slapstick:

  $ sudo mount test2.iso /mnt/iso
  mount: /mnt/iso: WARNING: source write-protected, mounted read-only.
  $ ls -li /mnt/iso
  1479 -rw-r--r-- 2 thomas thomas 42786 Nov 14  2005 hardlink_x
  1483 -rw-r--r-- 2 thomas thomas 42786 Nov 14  2005 x

Note the link count 2 in combination with the differing inode numbers.
(The link count stems from Rock Ridge field PX. By mistake i mentoned it
as "PN" in my previous mail.)

The false link count does not hamper restoring of the files:

  $ cp -r /mnt/iso /u/test/hardlinks_restored
  $ ls -li  /u/test/hardlinks_restored
  total 88
  8913418 -rw-r--r-- 1 thomas thomas 42786 Mar 11 17:38 hardlink_x
  8913419 -rw-r--r-- 1 thomas thomas 42786 Mar 11 17:38 x

So the files are independent after being restored by Debian 11 to ext4.

The same happens with an ISO made by xorriso:

  $ xorriso -as mkisofs -o test.iso -R /u/test/hardlinks
  ...
  $ xorriso -indev test.iso -find / -type f -exec report_lba
  ...
  Report layout: xt , Startlba ,   Blocks , Filesize , ISO image path
  File data lba:  0 ,   33 ,   21 ,42786 , '/hardlink_x'
  File data lba:  0 ,   33 ,   21 ,42786 , '/x'

  $ sudo mount test.iso /mnt/iso
  ...
  $ cp -r /mnt/iso /u/test/hardlinks_restored
  $ ls -li  /u/test/hardlinks_restored
  total 88
  8913418 -rw-r--r-- 1 thomas thomas 42786 Mar 11 17:47 hardlink_x
  8913419 -rw-r--r-- 1 thomas thomas 42786 Mar 11 17:47 x

Just to prove that the restored files are really not hardlinked:

  $ echo some_tail_bytes >> /u/test/hardlinks_restored/x
  $ ls -li  /u/test/hardlinks_restored
  total 88
  8913418 -rw-r--r-- 1 thomas thomas 42786 Mar 11 17:47 hardlink_x
  8913419 -rw-r--r-- 1 thomas thomas 42802 Mar 11 17:48 x
  $

Have a nice day :)

Thomas

Bug#1032706: [pkg-lxc-devel] Bug#1032706: lxc-snapshot cannot restore containers with loop storage backend

2023-03-11 Thread Mathias Gibbens

Hi Mario,

  I'm currently on travel with not-so-great network connectivity, so I
haven't been able to reproduce this on my travel laptop, but will
attempt to do so when I'm back from my trip.

  I expect that this issue will have to be forwarded to the lxc
developers; if you want to do so you can submit an issue at
https://github.com/lxc/lxc/issues, otherwise I'll so after reproducing
the issue myself.

  To help ensure I'll be following exactly what you did, could you
share the commands you used to setup the loop storage backend, the
creation of the container, snapshoting, and attempted restoration of
that snapshot?

Thanks,
Mathias


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

Bug#1028208: plasma-discover: Program terminated with signal SIGSEGV

2023-03-11 Thread Aurélien COUDERC

control: reassign -1 libpackagekitqt5-1 1.1.0-1

Bug#1032780: please drop transitional package xul-ext-treestyletab from src:tree-style-tab

Package: xul-ext-treestyletab
Version: 3.5.20-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package xul-ext-treestyletab (from the source 
package tree-style-tab) after the release of bookworm, it has been released 
with buster and bullseye already...


Description: Show browser tabs like a tree - transitional package
Package: xul-ext-treestyletab
Version: 2.7.23-1
Version: 3.5.20-1

Thanks for maintaining tree-style-tab!


-- 
cheers,
Holger

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

We need to learn to live with cholera. What is the alternative? Breaking up
all streets, building drainage with toilets in every building? (@tadeas_)


signature.asc
Description: PGP signature

Bug#1032778: please drop transitional package pyotherside from src:pyotherside

Package: pyotherside
Version: 1.6.0-2
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package pyotherside (from the source package 
pyotherside) after the release of bookworm, it has been released with buster 
and bullseye already...


Description: transitional dummy package
Package: pyotherside
Version: 1.5.3-1
Version: 1.5.9-2
Version: 1.6.0-2

Thanks for maintaining pyotherside!


-- 
cheers,
Holger

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

„Faschisten hören niemals auf, Faschisten zu sein
Man diskutiert mit ihnen nicht, hat die Geschichte gezeigt“...


signature.asc
Description: PGP signature

Bug#1032779: please drop transitional package libwagon-java from src:wagon

Package: libwagon-java
Version: 3.5.3-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package libwagon-java (from the source package 
wagon) after the release of bookworm, it has been released with buster and 
bullseye already...


Description: Artifact transport abstraction used in Maven (transitional package)
Package: libwagon-java
Version: 3.3.1-2
Version: 3.3.4-1
Version: 3.5.3-1

Thanks for maintaining wagon!


-- 
cheers,
Holger

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

I have a joke about trickle down economics. 99% of you won’t ever get it.


signature.asc
Description: PGP signature

Bug#1032777: please drop transitional package x11proto-fonts-dev from src:xorgproto

Package: x11proto-fonts-dev
Version: 2022.1-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package x11proto-fonts-dev (from the source 
package xorgproto) after the release of bookworm, it has been released with 
buster and bullseye already...


Description: transitional dummy package
Package: x11proto-fonts-dev
Version: 2018.4-4
Version: 2020.1-1
Version: 2022.1-1

Thanks for maintaining xorgproto!


-- 
cheers,
Holger

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

Ich bin so alt, ich hab im Kindergarten noch Aschenbecher getöpfert.
(@joanalistin)


signature.asc
Description: PGP signature

Bug#1032776: please drop transitional package libtiff5-dev from src:tiff