Bug#1071573: Status of libnet-ssl-expiredate-perl

[Andrius Merkys]

Control: owner -1 !

Hello,

It is quite important to me to get libnet-ssl-expiredate-perl done ASAP. 
Thus if you do not have any objections, I am going to finalize it.


Andrius

Bug#1071501: Linux NFS client hangs in nfs4_lookup_revalidate

[NeilBrown]

On Mon, 27 May 2024, Richard Kojedzinszky wrote:
> Dear Neil,
> 
> I was running it on arm64, may that be the reason?

That could certainly explain it.  I know x86_64 almost never needs
barriers, though I have seen cases where they matter.  ppc64 is very
sensitive.  A quick search suggests that arm64 does need barriers some
times.
I don't have arm64 hardware to test on but I'm happy with your
test results.

Thanks,
NeilBrown


> 
> Regards,
> Richard
> 
> 
> On May 27, 2024 4:02:32 AM GMT+02:00, NeilBrown  wrote:
> 
> On Sun, 26 May 2024, Richard Kojedzinszky wrote:
> Dear Neil,
> 
> According to my quick tests, your patch seems to fix this bug. Could 
> you 
> also manage to try my attached code, could you also reproduce the bug?
> 
> Thanks for testing.
> 
> I can run your test code but it isn't triggering the bug (90 minutes so
> far).  Possibly a different compiler used for the kernel, possibly
> hardware differences (I'm running under qemu).  Bugs related to barriers
> (which this one seems to be) need just the right circumstances to
> trigger so they can be hard to reproduce on a different system.
> 
> I've made some cosmetic improvements to the patch and will post it to
> the NFS maintainers.
> 
> Thanks again,
> NeilBrown
> 
> 
> 
> Thanks,
> Richard
> 
> 2024-05-24 07:29 időpontban Richard Kojedzinszky ezt írta:
> Dear Neil,
> 
> I've applied your patch, and since then there are no lockups. 
> Before 
> that my application reported a lockup in a minute or two, now it 
> has 
> been running for half an hour, and still running.
> 
> Thanks,
> Richard
> 
> 2024-05-24 01:31 időpontban NeilBrown ezt írta:
> On Fri, 24 May 2024, Richard Kojedzinszky wrote:
> Dear devs,
> 
> I am attaching a stripped down version of the little 
> program which
> triggers the bug very quickly, in a few minutes in my 
> test lab. It
> turned out that a single NFS mountpoint is enough. Just 
> start the
> program giving it the NFS mount as first argument. It 
> will chdir 
> there,
> and do file operations, which will trigger a lockup in a 
> few minutes.
> 
> I couldn't get the go code to run.  But then it is a long 
> time since I
> played with go and I didn't try very hard.
> If you could provide simple instructions and a list of package
> dependencies that I need to install (on Debian), I can give 
> it a try.
> 
> Or you could try this patch.  It might help, but I don't have 
> high
> hopes.  It adds some memory barriers and fixes a bug which 
> would cause 
> a
> problem if memory allocation failed (but memory allocation 
> never 
> fails).
> 
> NeilBrown
> 
> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> index ac505671efbd..5bcc0d14d519 100644
> --- a/fs/nfs/dir.c
> +++ b/fs/nfs/dir.c
> @@ -1804,7 +1804,7 @@ __nfs_lookup_revalidate(struct dentry 
> *dentry, 
> unsigned int flags,
> } else {
> /* Wait for unlink to complete */
> wait_var_event(>d_fsdata,
> -  dentry->d_fsdata != 
> NFS_FSDATA_BLOCKED);
> +  
> smp_load_acquire(>d_fsdata) != NFS_FSDATA_BLOCKED);
> parent = dget_parent(dentry);
> ret = reval(d_inode(parent), dentry, flags);
> dput(parent);
> @@ -2508,7 +2508,7 @@ int nfs_unlink(struct inode *dir, 
> struct dentry 
> *dentry)
> spin_unlock(>d_lock);
> error = nfs_safe_remove(dentry);
> nfs_dentry_remove_handle_error(dir, dentry, error);
> -   dentry->d_fsdata = NULL;
> +   smp_store_release(>d_fsdata, NULL);
> wake_up_var(>d_fsdata);
>  out:
> trace_nfs_unlink_exit(dir, dentry, error);
> @@ -2616,7 +2616,7 @@ nfs_unblock_rename(struct rpc_task 
> *task, struct 
> nfs_renamedata *data)
>  {
> struct dentry *new_dentry = data->new_dentry;
> 
> -   new_dentry->d_fsdata = NULL;
>  

Bug#1071986: raspberrypi-kernel: unable to connect an arduino portenta lite via usb

[David Talmage]

Package: raspberrypi-kernel

Version: 1:1.20230106-1

Severity: important

 

Dear Maintainer,

 

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

 

   * What led up to the situation?

   I bought a usb a to c cable from amazon p/n B09FYVD6B5

   I plugged usb cable from both raspberry pi 2b and 4 between pi and
portenta lite 

https://store-usa.arduino.cc/collections/portenta-family/products/portenta-h
7-lite

 

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

 ineffective)?

   tried 2 different cables (ineffective)

   powered portenta with +5V to the Vin pins on J1 (ineffective)

   upgraded my pi2b to latest install (ineffective)

   tried it on my pi4 (this computer ineffective)

   plugged same cable to my windows 11 computer and the portenta 

  showed up in the device manager as com10 with device id 

  USB\VID_2341_025B_0101_00 (this worked but not

  what I want to do)

 

   * What was the outcome of this action?

   dmesg said usb 1-1-port1: Cannot enable. Maybe the USB cable is bad?

  usb 1-1-port1: attempt power cycle

  usb 1-1-port1: unable to enumerate USB device

 

   * What outcome did you expect instead?

   I expected the usb port to identify the device and connect it to

   a ttyUSB0 or ttyACM0 or some other serial port

 

 

-- System Information:

Debian Release: 11.6

  APT prefers oldstable-updates

  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500,
'oldstable')

Architecture: arm64 (aarch64)

Foreign Architectures: armhf

 

Kernel: Linux 5.15.84-v8+ (SMP w/4 CPU threads; PREEMPT)

Kernel taint flags: TAINT_CRAP

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8

Shell: /bin/sh linked to /usr/bin/dash

Init: systemd (via /run/systemd/system)

 

-- no debconf information

 

 

Bug#1071552: [pkg-gnupg-maint] Bug#1071552: gnupg: Please upgrade GnuPG >= 2.4.4, current GnuPG break Emacs's EasyPG

[Daniel Kahn Gillmor]

Control: affects 1071552 + emacs-el
Control: retitle 1071552 GnuPG 2.2.42+ breaks emacs' EasyPG

On Tue 2024-05-21 13:05:02 +0900, Youhei SASAKI wrote:
> Package: gnupg
> Version: 2.2.43-6
> Severity: critical

I see that Andreas has reduced the severity of 1071552 from 'critical'
to 'important'.  I think that the bugs we're seeing with easypg are
pretty severe.  I would personally mark this bug report "serious",
because i think it is unfit to be merged into testing until the package
can work correctly with EasyPG.

> Current GnuPG package, version 2.2.43, brek Emacs's EasyPG.
> We are no longer able to store encrypted files completely.
>
> Well-kown issue: 
> https://github.com/emacs-mirror/emacs/blob/master/etc/PROBLEMS
> --- quote ---
> *** Saving a file encrypted with GnuPG via EasyPG hangs.
>
> This is known to happen with GnuPG v2.4.1.  The only known workaround
> is to downgrade to a version of GnuPG older than 2.4.1, or upgrade to
> version 2.4.4 and newer, which reportedly solves the problem.  Note
> that GnuPG v2.2.42 and later also has this problem, so you should also
> avoid those later 2.2.4x versions; v2.2.41 is reported to work fine.
> --- quote ---
>
> See also https://dev.gnupg.org/T6481
>
> Please upgrade GnuPG >= 2.4.4 or newer. 

I don't think this is a reasonable solution as of how the 2.4.x branch
is designed right now, and the fact that upstream doesn't appear to
intend the 2.4.x series as a long-term support series either.  My
understanding is that the upstream 2.4.x packages of GnuPG (which are
visible in experimental today) introduce potentially serious
incompatibilities into the OpenPGP ecosystem, and i don't think it's
reasonable for debian to ship those versions until they are producing
things that are compatible with most other OpenPGP implementations.

Sadly, GnuPG upstream appears to be abandoning the OpenPGP standard, and
despite reasonable attempts to convince them to interoperate, i don't
see that changing.

Would anyone be willing to try to backport the patches from upstream's
fixes for T6481 to the 2.2.x series?

  --dkg


signature.asc
Description: PGP signature

Bug#1071501: Linux NFS client hangs in nfs4_lookup_revalidate

[Richard Kojedzinszky]

Dear Neil,

I was running it on arm64, may that be the reason?

Regards,
Richard

On May 27, 2024 4:02:32 AM GMT+02:00, NeilBrown  wrote:
>On Sun, 26 May 2024, Richard Kojedzinszky wrote:
>> Dear Neil,
>> 
>> According to my quick tests, your patch seems to fix this bug. Could you 
>> also manage to try my attached code, could you also reproduce the bug?
>
>Thanks for testing.
>
>I can run your test code but it isn't triggering the bug (90 minutes so
>far).  Possibly a different compiler used for the kernel, possibly
>hardware differences (I'm running under qemu).  Bugs related to barriers
>(which this one seems to be) need just the right circumstances to
>trigger so they can be hard to reproduce on a different system.
>
>I've made some cosmetic improvements to the patch and will post it to
>the NFS maintainers.
>
>Thanks again,
>NeilBrown
>
>
>> 
>> Thanks,
>> Richard
>> 
>> 2024-05-24 07:29 időpontban Richard Kojedzinszky ezt írta:
>> > Dear Neil,
>> > 
>> > I've applied your patch, and since then there are no lockups. Before 
>> > that my application reported a lockup in a minute or two, now it has 
>> > been running for half an hour, and still running.
>> > 
>> > Thanks,
>> > Richard
>> > 
>> > 2024-05-24 01:31 időpontban NeilBrown ezt írta:
>> >> On Fri, 24 May 2024, Richard Kojedzinszky wrote:
>> >>> Dear devs,
>> >>> 
>> >>> I am attaching a stripped down version of the little program which
>> >>> triggers the bug very quickly, in a few minutes in my test lab. It
>> >>> turned out that a single NFS mountpoint is enough. Just start the
>> >>> program giving it the NFS mount as first argument. It will chdir 
>> >>> there,
>> >>> and do file operations, which will trigger a lockup in a few minutes.
>> >> 
>> >> I couldn't get the go code to run.  But then it is a long time since I
>> >> played with go and I didn't try very hard.
>> >> If you could provide simple instructions and a list of package
>> >> dependencies that I need to install (on Debian), I can give it a try.
>> >> 
>> >> Or you could try this patch.  It might help, but I don't have high
>> >> hopes.  It adds some memory barriers and fixes a bug which would cause 
>> >> a
>> >> problem if memory allocation failed (but memory allocation never 
>> >> fails).
>> >> 
>> >> NeilBrown
>> >> 
>> >> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
>> >> index ac505671efbd..5bcc0d14d519 100644
>> >> --- a/fs/nfs/dir.c
>> >> +++ b/fs/nfs/dir.c
>> >> @@ -1804,7 +1804,7 @@ __nfs_lookup_revalidate(struct dentry *dentry, 
>> >> unsigned int flags,
>> >>   } else {
>> >>   /* Wait for unlink to complete */
>> >>   wait_var_event(>d_fsdata,
>> >> -dentry->d_fsdata != NFS_FSDATA_BLOCKED);
>> >> +smp_load_acquire(>d_fsdata) != 
>> >> NFS_FSDATA_BLOCKED);
>> >>   parent = dget_parent(dentry);
>> >>   ret = reval(d_inode(parent), dentry, flags);
>> >>   dput(parent);
>> >> @@ -2508,7 +2508,7 @@ int nfs_unlink(struct inode *dir, struct dentry 
>> >> *dentry)
>> >>   spin_unlock(>d_lock);
>> >>   error = nfs_safe_remove(dentry);
>> >>   nfs_dentry_remove_handle_error(dir, dentry, error);
>> >> - dentry->d_fsdata = NULL;
>> >> + smp_store_release(>d_fsdata, NULL);
>> >>   wake_up_var(>d_fsdata);
>> >>  out:
>> >>   trace_nfs_unlink_exit(dir, dentry, error);
>> >> @@ -2616,7 +2616,7 @@ nfs_unblock_rename(struct rpc_task *task, struct 
>> >> nfs_renamedata *data)
>> >>  {
>> >>   struct dentry *new_dentry = data->new_dentry;
>> >> 
>> >> - new_dentry->d_fsdata = NULL;
>> >> + smp_store_release(_dentry->d_fsdata, NULL);
>> >>   wake_up_var(_dentry->d_fsdata);
>> >>  }
>> >> 
>> >> @@ -2717,6 +2717,10 @@ int nfs_rename(struct mnt_idmap *idmap, struct 
>> >> inode *old_dir,
>> >>   task = nfs_async_rename(old_dir, new_dir, old_dentry, new_dentry,
>> >>   must_unblock ? nfs_unblock_rename : NULL);
>> >>   if (IS_ERR(task)) {
>> >> + if (must_unlock) {
>> >> + smp_store_release(_dentry->d_fsdata, NULL);
>> >> + wake_up_var(_dentry->d_fsdata);
>> >> + }
>> >>   error = PTR_ERR(task);
>> >>   goto out;
>> >>   }
>> 
>

Bug#1071501: [PATCH] NFS: add barriers when testing for NFS_FSDATA_BLOCKED

[NeilBrown]

dentry->d_fsdata is set to NFS_FSDATA_BLOCKED while unlinking or
renaming-over a file to ensure that no open succeeds while the NFS
operation progressed on the server.

Setting dentry->d_fsdata to NFS_FSDATA_BLOCKED is done under ->d_lock
after checking the refcount is not elevated.  Any attempt to open the
file (through that name) will go through lookp_open() which will take
->d_lock while incrementing the refcount, we can be sure that once the
new value is set, __nfs_lookup_revalidate() *will* see the new value and
will block.

We don't have any locking guarantee that when we set ->d_fsdata to NULL,
the wait_var_event() in __nfs_lookup_revalidate() will notice.
wait/wake primitives do NOT provide barriers to guarantee order.  We
must use smp_load_acquire() in wait_var_event() to ensure we look at an
up-to-date value, and must use smp_store_release() before wake_up_var().

This patch adds those barrier functions and factors out
block_revalidate() and unblock_revalidate() far clarity.

There is also a hypothetical bug in that if memory allocation fails
(which never happens in practice) we might leave ->d_fsdata locked.
This patch adds the missing call to unblock_revalidate().

Reported-and-tested-by: Richard Kojedzinszky 

Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071501
Fixes: 3c59366c207e ("NFS: don't unhash dentry during unlink/rename")
Signed-off-by: NeilBrown 
---
 fs/nfs/dir.c | 44 +---
 1 file changed, 29 insertions(+), 15 deletions(-)

diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index ac505671efbd..c91dc36d41cc 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1802,9 +1802,10 @@ __nfs_lookup_revalidate(struct dentry *dentry, unsigned 
int flags,
if (parent != READ_ONCE(dentry->d_parent))
return -ECHILD;
} else {
-   /* Wait for unlink to complete */
+   /* Wait for unlink to complete - see unblock_revalidate() */
wait_var_event(>d_fsdata,
-  dentry->d_fsdata != NFS_FSDATA_BLOCKED);
+  smp_load_acquire(>d_fsdata)
+  != NFS_FSDATA_BLOCKED);
parent = dget_parent(dentry);
ret = reval(d_inode(parent), dentry, flags);
dput(parent);
@@ -1817,6 +1818,26 @@ static int nfs_lookup_revalidate(struct dentry *dentry, 
unsigned int flags)
return __nfs_lookup_revalidate(dentry, flags, nfs_do_lookup_revalidate);
 }
 
+static void block_revalidate(struct dentry *dentry)
+{
+   /* old devname - just in case */
+   kfree(dentry->d_fsdata);
+
+   /* Any new reference that could lead to an open
+* will take ->d_lock in lookup_open() -> d_lookup().
+*/
+   lockdep_assert_held(>d_lock);
+
+   dentry->d_fsdata = NULL;
+}
+
+static void unblock_revalidate(struct dentry *dentry)
+{
+   /* store_release ensures wait_var_event() sees the update */
+   smp_store_release(>d_fsdata, NULL);
+   wake_up_var(>d_fsdata);
+}
+
 /*
  * A weaker form of d_revalidate for revalidating just the d_inode(dentry)
  * when we don't really care about the dentry name. This is called when a
@@ -2501,15 +2522,12 @@ int nfs_unlink(struct inode *dir, struct dentry *dentry)
spin_unlock(>d_lock);
goto out;
}
-   /* old devname */
-   kfree(dentry->d_fsdata);
-   dentry->d_fsdata = NFS_FSDATA_BLOCKED;
+   block_revalidate(dentry);
 
spin_unlock(>d_lock);
error = nfs_safe_remove(dentry);
nfs_dentry_remove_handle_error(dir, dentry, error);
-   dentry->d_fsdata = NULL;
-   wake_up_var(>d_fsdata);
+   unblock_revalidate(dentry);
 out:
trace_nfs_unlink_exit(dir, dentry, error);
return error;
@@ -2616,8 +2634,7 @@ nfs_unblock_rename(struct rpc_task *task, struct 
nfs_renamedata *data)
 {
struct dentry *new_dentry = data->new_dentry;
 
-   new_dentry->d_fsdata = NULL;
-   wake_up_var(_dentry->d_fsdata);
+   unblock_revalidate(new_dentry);
 }
 
 /*
@@ -2679,11 +2696,6 @@ int nfs_rename(struct mnt_idmap *idmap, struct inode 
*old_dir,
if (WARN_ON(new_dentry->d_flags & DCACHE_NFSFS_RENAMED) ||
WARN_ON(new_dentry->d_fsdata == NFS_FSDATA_BLOCKED))
goto out;
-   if (new_dentry->d_fsdata) {
-   /* old devname */
-   kfree(new_dentry->d_fsdata);
-   new_dentry->d_fsdata = NULL;
-   }
 
spin_lock(_dentry->d_lock);
if (d_count(new_dentry) > 2) {
@@ -2705,7 +2717,7 @@ int nfs_rename(struct mnt_idmap *idmap, struct inode 
*old_dir,
new_dentry = dentry;
new_inode = NULL;
} else {
-   new_dentry->d_fsdata = NFS_FSDATA_BLOCKED;
+   

Bug#1071961: mailcap: run-mailcap doesn't properly identifies magic types

[Charles Plessy]

Le Sun, May 26, 2024 at 05:35:28PM +0300, Yair Yarom a écrit :
> 
> The function MagicMimetype always fails because the `command -v file` isn't
> executed inside a shell (rather, perl searches for the "command" binary, and
> fails to find it).

Thanks Yair for the patch.  I confirm it works.

Can you give me a longer explanation why it works?

In any case, I wonder if just searching for /usr/bin/file would make
more sense.  What do you think about it?

Have a nice day,

Charles

Bug#1071501: Linux NFS client hangs in nfs4_lookup_revalidate

[NeilBrown]

On Sun, 26 May 2024, Richard Kojedzinszky wrote:
> Dear Neil,
> 
> According to my quick tests, your patch seems to fix this bug. Could you 
> also manage to try my attached code, could you also reproduce the bug?

Thanks for testing.

I can run your test code but it isn't triggering the bug (90 minutes so
far).  Possibly a different compiler used for the kernel, possibly
hardware differences (I'm running under qemu).  Bugs related to barriers
(which this one seems to be) need just the right circumstances to
trigger so they can be hard to reproduce on a different system.

I've made some cosmetic improvements to the patch and will post it to
the NFS maintainers.

Thanks again,
NeilBrown


> 
> Thanks,
> Richard
> 
> 2024-05-24 07:29 időpontban Richard Kojedzinszky ezt írta:
> > Dear Neil,
> > 
> > I've applied your patch, and since then there are no lockups. Before 
> > that my application reported a lockup in a minute or two, now it has 
> > been running for half an hour, and still running.
> > 
> > Thanks,
> > Richard
> > 
> > 2024-05-24 01:31 időpontban NeilBrown ezt írta:
> >> On Fri, 24 May 2024, Richard Kojedzinszky wrote:
> >>> Dear devs,
> >>> 
> >>> I am attaching a stripped down version of the little program which
> >>> triggers the bug very quickly, in a few minutes in my test lab. It
> >>> turned out that a single NFS mountpoint is enough. Just start the
> >>> program giving it the NFS mount as first argument. It will chdir 
> >>> there,
> >>> and do file operations, which will trigger a lockup in a few minutes.
> >> 
> >> I couldn't get the go code to run.  But then it is a long time since I
> >> played with go and I didn't try very hard.
> >> If you could provide simple instructions and a list of package
> >> dependencies that I need to install (on Debian), I can give it a try.
> >> 
> >> Or you could try this patch.  It might help, but I don't have high
> >> hopes.  It adds some memory barriers and fixes a bug which would cause 
> >> a
> >> problem if memory allocation failed (but memory allocation never 
> >> fails).
> >> 
> >> NeilBrown
> >> 
> >> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> >> index ac505671efbd..5bcc0d14d519 100644
> >> --- a/fs/nfs/dir.c
> >> +++ b/fs/nfs/dir.c
> >> @@ -1804,7 +1804,7 @@ __nfs_lookup_revalidate(struct dentry *dentry, 
> >> unsigned int flags,
> >>} else {
> >>/* Wait for unlink to complete */
> >>wait_var_event(>d_fsdata,
> >> - dentry->d_fsdata != NFS_FSDATA_BLOCKED);
> >> + smp_load_acquire(>d_fsdata) != 
> >> NFS_FSDATA_BLOCKED);
> >>parent = dget_parent(dentry);
> >>ret = reval(d_inode(parent), dentry, flags);
> >>dput(parent);
> >> @@ -2508,7 +2508,7 @@ int nfs_unlink(struct inode *dir, struct dentry 
> >> *dentry)
> >>spin_unlock(>d_lock);
> >>error = nfs_safe_remove(dentry);
> >>nfs_dentry_remove_handle_error(dir, dentry, error);
> >> -  dentry->d_fsdata = NULL;
> >> +  smp_store_release(>d_fsdata, NULL);
> >>wake_up_var(>d_fsdata);
> >>  out:
> >>trace_nfs_unlink_exit(dir, dentry, error);
> >> @@ -2616,7 +2616,7 @@ nfs_unblock_rename(struct rpc_task *task, struct 
> >> nfs_renamedata *data)
> >>  {
> >>struct dentry *new_dentry = data->new_dentry;
> >> 
> >> -  new_dentry->d_fsdata = NULL;
> >> +  smp_store_release(_dentry->d_fsdata, NULL);
> >>wake_up_var(_dentry->d_fsdata);
> >>  }
> >> 
> >> @@ -2717,6 +2717,10 @@ int nfs_rename(struct mnt_idmap *idmap, struct 
> >> inode *old_dir,
> >>task = nfs_async_rename(old_dir, new_dir, old_dentry, new_dentry,
> >>must_unblock ? nfs_unblock_rename : NULL);
> >>if (IS_ERR(task)) {
> >> +  if (must_unlock) {
> >> +  smp_store_release(_dentry->d_fsdata, NULL);
> >> +  wake_up_var(_dentry->d_fsdata);
> >> +  }
> >>error = PTR_ERR(task);
> >>goto out;
> >>}
> 

Bug#1071976: jtreg7: openjdk-11 test failures due to the unsupported class version in jtreg7 components

[Vladimir Petko]

Dear Maintainers,

  Would it be possible to consider a merge request[1] that addresses this issue?

Best Regards,
 Vladimir.

 [1] https://salsa.debian.org/java-team/jtreg7/-/merge_requests/4

Bug#988127: neomutt hangs for minutes while checking S/MIME signed mails

[Carlos Henrique Lima Melara]

Control: forwarded 988127 https://github.com/neomutt/neomutt/issues/3068

Hi Daniel,

On Thu, Feb 01, 2024 at 11:09:50AM +0100, Daniel Gröber wrote:
> Hi all,
> 
> I've done some code review to figure out what we can do to
> workaround/fix this issue since it has annoyed me in the past and I
> just don't even want to use S/MIME ever really.

Thanks for investigating this one, really!

> Some things I found: since I set crypt_use_gpgme=yes gpgme apparently
> handles S/MIME directly (didn't know gpg supported it) and the
> "backend" is /usr/bin/gpgsm.
> 
> So a very nasty hack is to get rid of this issue is to just symlink
> gpgsm to /usr/bin/false somewhere on your $PATH:
> 
> # ln -s /usr/bin/false gpgsm
> 
> Looking at the code I found the original sin to be at
> ncrypt/cryptglue.c:crypt_init:
> 
> #ifdef CRYPT_BACKEND_GPGME
>   if (c_crypt_use_gpgme)
>   {
> crypto_module_register();
> crypto_module_register();
>   }
> #endif
> 
> this makes it so crypt_use_gpgme=yes enables both gpg and smime
> support with no way to disable smime at init or message verification
> time. Not even hooks will help since the crypt module registration
> runs only once.
> 
> IMO this is unacceptable as I have no interest in being exposed to the
> vulnerability surface area of smime despite not having any use for it,
> so I'm planning to propose a patch to neomutt to move the smime
> registration to a seperate rc variable.

I really think this should be handled upstream, so I've forwarded your
findings to them [1].

> Does anybody think the ability to toggle this per-message would be
> useful? I can't think of a compelling reason to want that.

I can't either, but who knows :-)

Cheers,
Charles

[1] https://github.com/neomutt/neomutt/issues/3068#issuecomment-2132481854


signature.asc
Description: PGP signature

Bug#1070474: time sync overflows on ARCH armhf(Debian 12, bookworm) with systemd-timesyncd.service

[Perr Zhang]

  On Sun, 26 May 2024 22:22:52 +0800  Luca Boccassi  wrote --- 
 > Control: tags -1 moreinfo
 > 
 > On Mon, 06 May 2024 09:22:14 +0800 Perr Zhang strongb...@zoho.com>
 > wrote:
 > > Package: systemd, systemd-timesyncd
 > > Version: 252.19-1~deb12u1, 252.22-1~deb12u1
 > > Arch: armhf
 > > Distribution: Debian 12, bookworm
 > > 
 > > Timestamp of rootfs overflows about once a week, with a core dump
 > file(/core) of systemd
 > > the kernel is compiled from upstream by myself, the rootfs is built
 > with debootstrap
 > > 
 > > root@Beetle-fox-Tbox:~# uname -a
 > > Linux Beetle-fox-Tbox 6.1.68 #1 SMP Wed Feb  7 13:15:39 CST 2024
 > armv7l GNU/Linux
 > > root@Beetle-fox-Tbox:~# stat /
 > >   File: /
 > >   Size: 4096  Blocks: 8  IO Block: 4096   directory
 > > Device: 8,118 Inode: 2   Links: 18
 > > Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/   
 > root)
 > > Access: 2024-05-06 01:02:34.504540112 +
 > > Modify: 2119-06-23 05:10:17.491093577 +
 > > Change: 2119-06-23 05:10:17.491093577 +
 > >  Birth: 2024-03-12 06:30:05.0 +
 > > root@Beetle-fox-Tbox:~# stat /core
 > >   File: /core
 > >   Size: 19771392  Blocks: 4784   IO Block: 4096   regular
 > file
 > > Device: 8,118 Inode: 12  Links: 1
 > > Access: (0600/-rw---)  Uid: (    0/    root)   Gid: (    0/   
 > root)
 > > Access: 2024-05-06 01:03:09.107874379 +
 > > Modify: 2119-06-23 05:10:17.721082481 +
 > > Change: 2119-06-23 05:10:17.721082481 +
 > >  Birth: 2119-06-23 05:10:17.491093577 +
 > 
 > What is causing the rootfs timestamp to overflow?

I have patched the kernel to check which process has set system time with:

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 221c8c404973..69cfda0ef000 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "tick-internal.h"
 #include "ntp_internal.h"
@@ -1315,7 +1316,12 @@ int do_settimeofday64(const struct timespec64 *ts)
struct timespec64 ts_delta, xt;
unsigned long flags;
int ret = 0;
+   time64_t sec_year2119 = mktime64(2119, 1, 1, 1, 1, 1);
 
+   if (ts->tv_sec >= sec_year2119) {
+   force_sig(SIGABRT);
+   return -EINVAL; // TODO: maybe we need some printk here
+   }
if (!timespec64_valid_settod(ts))
return -EINVAL;
 
I has tested for about one week, and hasn't catched the process's coredump yet

 > 
 > -- 
 > Kind regards,
 > Luca Boccassi
 > 

Bug#1071984: python3.11.1: some remarks and editorial changes for this man page

[Bjarni Ingi Gislason]

Package: python3.11-minimal
Version: 3.11.9-1
Severity: minor
Tags: patch

Dear Maintainer,

  here are some notes and editorial fixes for the manual.

The patch is in the attachment.

-.-

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "

instead of "nroff -man"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint python3.11.1": (possibly shortened list)

mandoc: python3.11.1:1:2: WARNING: missing date, using "": TH
mandoc: python3.11.1:170:2: WARNING: line scope broken: TP breaks TP
mandoc: python3.11.1:183:85: STYLE: input text line longer than 80 bytes: Run 
Python in isolat...
mandoc: python3.11.1:208:81: STYLE: input text line longer than 80 bytes: as 
the current direc...

-.-.

Change two HYPHEN-MINUSES (code 0x2D) to an em-dash (\(em),
if one is intended.  An en-dash is usually surrounded by a space,
while an em-dash is used without spaces.
"man" (1 byte characters in input) transforms an en-dash (\(en) to one
HYPHEN-MINUS,
and an em-dash to two HYPHEN-MINUSES without considering the space
around it.
If "--" are two single "-" (end of options) then use "\-\-".

python3.11.1:80:.B \--check-hash-based-pycs
python3.11.1:89:.B \--help
python3.11.1:92:.B \--help-env
python3.11.1:95:.B \--help-xoptions
python3.11.1:98:.B \--help-all
python3.11.1:607:\fB\--with-pydebug\fP build option.

-.-.

Mark a full stop (.) and the exclamation mark (!) with "\&",
if it does not mean an end of a sentence.
This is a preventive action,
the paragraph could be reshaped, e.g., after changes.

When typing, one does not always notice when the line wraps after the
period.
There are too many examples of input lines in manual pages,
that end with an abbreviation point.

This marking is robust, and independent of the position on the line.

It corresponds to "\ " in TeX, and to "@:" in Texinfo.


144:and comparing bytes/bytearray with str. (-bb: issue errors)

-.-.

Use the correct macro for the font change of a single argument or
split the argument into two.

265:.IB action:message:category:module:lineno
509:.IB errorhandler
511:.IB errorhandler
546:.IR malloc
556:.IR pymalloc_debug
578:.IB PYTHONTRACEMALLOC=1
594:.IR site-packages

-.-.

Change a HYPHEN-MINUS (code 0x2D) to a minus(-dash) (\-),
if it
is in front of a name for an option,
is a symbol for standard input,
is a single character used to indicate an option,
or is in the NAME section (man-pages(7)).
N.B. - (0x2D), processed as a UTF-8 file, is changed to a hyphen
(0x2010, groff \[u2010] or \[hy]) in the output.

80:.B \--check-hash-based-pycs
89:.B \--help
92:.B \--help-env
95:.B \--help-xoptions
98:.B \--help-all
144:and comparing bytes/bytearray with str. (-bb: issue errors)
251:  -Wdefault  # Warn once per call location
252:  -Werror# Convert to exceptions
253:  -Walways   # Warn every time
254:  -Wmodule   # Warn once per calling module
255:  -Wonce # Warn once per Python process
256:  -Wignore   # Never warn
260:.B -Wi
262:.B -Wignore .
269:.B -W ignore::DeprecationWarning
298:.B -W
301:.B -W
315:-X faulthandler: enable faulthandler
317:-X showrefcount: output the total reference count and number of used
321:-X tracemalloc: start tracing Python memory allocations using the
323:traceback of a trace. Use -X tracemalloc=NFRAME to start tracing 
with a
326:-X importtime: show how long each import takes. It shows module name,
329:application. Typical usage is python3 -X importtime -c 'import 
asyncio'
331:-X dev: enable CPython's "development mode", introducing additional 
runtime
335:   * Add default warning filter, as -W default
343:-X utf8: enable UTF-8 mode for operating system interfaces, overriding 
the default
344:locale-aware mode. -X utf8=0 explicitly disables UTF-8 mode (even 
when it would
347:-X pycache_prefix=PATH: enable writing .pyc files to a parallel tree 
rooted at the
350:-X warn_default_encoding: enable opt-in EncodingWarning for 
'encoding=None'
352:-X no_debug_ranges: disable the inclusion of the tables mapping extra 
location
358:-X frozen_modules=[on|off]: whether or not frozen modules should be 
used.
361:-X int_max_str_digits=number: limit the size of int<->str conversions.
403:.I '-c'.
607:\fB\--with-pydebug\fP build option.

-.-.

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and

Bug#1052365: systemd: DHCP client fails if multiple DHCP servers on network

[Luca Boccassi]

Control: close -1

On Sat, 20 Jan 2024 21:08:16 +0100 Michael Biebl 
wrote:
> On Mon, 25 Sep 2023 06:53:59 -0500 Alexandre Ferreira 
>  wrote:
> > Thank you, I added a PR and it was merged yesterday.
> > sd-dhcp-client: reject NAKs from servers that we did not send an
offer 
> > to (#29290) (https://github.com/systemd/systemd/pull/29290)
> > This change will only be valid for 255. How can we backport it to
252 up 
> > to 254?.
> 
> See bluca's reply at 
> https://github.com/systemd/systemd/pull/29290#issuecomment-1873329561
> 
> If you want to see this fixed for v252-stable, please backport the 
> commit to the v252-stable branch [1], test it and then submit a PR
[2]

This is fixed in testing. If somebody sends a tested PR for v252-stable
it can be fixed there too, but it hasn't happened in 6 months so
closing for now.

-- 
Kind regards,
Luca Boccassi


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

Bug#1061554: Re: Bug#1059995: pdns: flaky autopkgtest (host dependent): pdns.service: Failed to set up IPC namespacing: Resource temporarily unavailable

[Luca Boccassi]

Control: fixed -1 252.26-1~deb12u1
Control: fixed -1 256-1
Control: close -1

On Fri, 26 Jan 2024 11:31:37 +0100 Chris Hofstaedtler 
wrote:
> clone 1059995 -1
> reopen -1
> reassign -1 systemd
> found -1 systemd/254.3-1
> forwarded -1 https://github.com/systemd/systemd/issues/31037
> thanks
> 
> Dear systemd Packagers,
> 
> Paul Gevers noted that src:pdns's autopkgtests fail every so often
> on a large amd64 debci worker and on s390x workers. Apparently a
> similar problem can be seen in src:pdns-recursor's debci runs.
> 
> As there is no pdns(-recursor) code running at this point, this
> seems to be a problem somewhere in the space of systemd <> lxc <>
> apparmor <> kernel.
> 
> I've opened a bug with systemd upstream, unfortunately with very
> little info as I don't know how to provide additional info from
> within a debci run. Help with providing additional info would be
> very welcome.

Root cause for this is the same as #1050256 and will be fixed shortly
and backported. Same as that one, the fix only gracefully falls back
and disables PrivateIPC=, the kernel fix is needed to make the feature
work again.

-- 
Kind regards,
Luca Boccassi


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

Bug#1056166: systemd-homed: `passwd` fails

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> Ah thanks for the pointer to the file, I had missed that
Luca> somehow in the first reply. I see it now: the pam-config for
Luca> unix.so assumes that if something runs before then everything
Luca> is done already.  Unfortunately that assumption is wrong. I'll
Luca> see if I can just hack it and monkey patch common-password in
Luca> the postinst to fix it up for now, as I assume this is some
Luca> load-bearing assumption.

I think if you want to play with it and modify common-password, that's
fine.

I do not think that's appropriate for testing though.

I'm fairly uncomfortable  with a package other than pam touching
common-password in postinst other than through pam-auth-update.
It's fairly unlikely to work and likely to cause problems on upgrade.
I'd be much happier with  (at least for now) simply not auto-configuring
systemd-home and leaving that to the sysadmin.
I appreciate that is not what you want to hear, but:

1) I believe that package a modifying a configuration file of package b
without cooperation of package b is a clear policy violation.

2) common-password is a configuration file of pam.

3) I'd like to understand the situation muchd better and especially why
you need   to be account-type:primary.
I suspect we're going to need to have changes to pam-auth-update.

Bug#806291: systemd: systemctl status ignores -n argument

[Luca Boccassi]

Control: close -1

On Thu, 26 Nov 2015 08:00:16 +0100 Eduard Bloch  wrote:
> Package: systemd
> Version: 228-2
> 
> Dear Maintainer,
> 
>    * What led up to the situation?
> 
> I created a buggy configuration of apt-cacher-ng and wondered why it
did not start. When I run the service from command line, it dumps a
couple of usefull hints to STDERR. I expected to see this in "systemctl
status" output. I saw only ten lines and this contained only useless
cruft, something about "hold-off time over" etc.

This is caused by missing kernel functionality and is already tracked
upstream, nothing we can do downstream, closing.

-- 
Kind regards,
Luca Boccassi


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

Bug#788662: Logged-in user no longer granted permission to removable disks

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Mon, 18 Jan 2021 14:45:17 -0800 Josh Triplett
 wrote:
> On Thu, Jan 14, 2021 at 03:13:31PM +0100, Michael Biebl wrote:
> > Hi Josh
> > 
> > Am 15.06.15 um 17:56 schrieb Josh Triplett:
> > > On Mon, Jun 15, 2015 at 12:36:45PM +0200, Michael Biebl wrote:
> > > > Am 15.06.2015 um 07:34 schrieb Martin Pitt:
> > > > > Hey Josh,
> > > > > 
> > > > > Josh Triplett [2015-06-13 16:23 -0700]:
> > > > > > I plugged in a removable USB disk, and its devices showed
up as root:disk 0660,
> > > > > > with no ACLs.  Normally, I'd expect removable USB disks to
grant
> > > > > > read/write permission to the logged-in user.
> > > > > > ~$ ls -l /dev/sdb*
> > > > > > brw-rw 1 root disk 8, 16 Jun 13 16:17 /dev/sdb
> > > > > > brw-rw 1 root disk 8, 17 Jun 13 16:17 /dev/sdb1
> > > > > 
> > > > > That's expected. As Michael already said, we never explicitly
granted
> > > > > user access to device nodes. Maybe in the past some devices
got that
> > > > > through specific group membership, or you had some custom
udev rules
> > > > > to do that; but throughout the history of pmount, hal,
consolekit,
> > > > > udev etc. in Debian the device nodes themselves weren't user
> > > > > accessible in general. The main exception there that I
remember is
> > > > > Fedora's/Red Hat's ancient console_helper (or something
similar) which
> > > > > actually changed the device nodes themselves. But that was
some decade
> > > > > ago already..
> > > > 
> > > > I checked wheezy, and it had the following rules:
> > > > 91-permissions: SUBSYSTEM=="block", ATTRS{removable}=="1",
GROUP="floppy"
> > > > 91-permissions: SUBSYSTEM=="block",
SUBSYSTEMS=="usb|ieee1394|mmc|pcmcia", GROUP="floppy"
> > > > 
> > > > See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751892
> > > > 
> > > > Maybe we should merge those two bug reports?
> > > 
> > > Merging them seems fine, but I do think this functionality from
wheezy
> > > should be restored.  Not using the "floppy" group or any static
group,
> > > but using the uaccess mechanism.
> > > 
> > > Either that, or there should be a NEWS.Debian entry somewhere
> > > documenting that direct device access by users was removed and
won't
> > > come back for security reasons.  But I don't see an obvious
reason why
> > > removable USB disk devices should not be accessible to users.
> > 
> > I'm looking at older bug reports and I'm wondering what to do about
this
> > one. I guess the time for a NEWS entry has passed.
> > Regarding granting access to "removable" media write access via
uaccess, I'm
> > not strictly against that, I just would prefer this to happen and
be
> > implemented upstream. One problematic issue I can imagine is that
it's not
> > trivial to reliably determine whether a disk is really removable or
not.
> > That said, if you are still interested, would you mind filing an
upstream
> > bug report at https://github.com/systemd/systemd/issues.
> 
> Filed upstream as https://github.com/systemd/systemd/issues/18304 .
> 
> Thank you again for all your work on systemd and udev, including
triage!

As mentioned in the bug report, giving unrestricted access to block
devices to unprivileged users is really not safe on Linux, so this is
not going to happen by default. udev rules can be configured locally
just as well, so one can do that on their own machine if these security
issues are not a problem.

-- 
Kind regards,
Luca Boccassi


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

Bug#1056166: systemd-homed: `passwd` fails

[Luca Boccassi]

On Mon, 27 May 2024 at 00:30, Sam Hartman  wrote:
>
> > "Luca" == Luca Boccassi  writes:
>
> Luca> 
> https://www.freedesktop.org/software/systemd/man/latest/pam_systemd_home.html
>
> It's going to be a long time (a couple of weeks) before I have cycles to
> actually look at systemd-home rather than to answer questions with my
> pam hat on without looking at your application.
> The limits issue you wrote to me about yesterday is ahead in the queue,
> as likely is a new version of krb5.
>
> Luca> Any idea where use_authtok try_first_pass could be coming
> Luca> from? I don't see them defined anywhere in the pam config I am
> Luca> shipping, so I have no idea why pam-auth-update is adding
> Luca> them.
>
> I gave you pointers where to look for these: /usr/share/pam-config/unix
> This is complex enough that someone who both has a good understanding of
> pam and systemd-home is going to need to get involved.
> I can talk about the broader pam context, and some issues people have
> run into in the past, but someone needs to have both systemd-home and
> pam in their heads to definitively decide what systemd-home wants out of
> pam.
> That's not going to  be me any time soon.

Ah thanks for the pointer to the file, I had missed that somehow in
the first reply. I see it now: the pam-config for unix.so assumes that
if something runs before then everything is done already.
Unfortunately that assumption is wrong. I'll see if I can just hack it
and monkey patch common-password in the postinst to fix it up for now,
as I assume this is some load-bearing assumption.

Bug#1056166: systemd-homed: `passwd` fails

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> 
https://www.freedesktop.org/software/systemd/man/latest/pam_systemd_home.html

It's going to be a long time (a couple of weeks) before I have cycles to
actually look at systemd-home rather than to answer questions with my
pam hat on without looking at your application.
The limits issue you wrote to me about yesterday is ahead in the queue,
as likely is a new version of krb5.

Luca> Any idea where use_authtok try_first_pass could be coming
Luca> from? I don't see them defined anywhere in the pam config I am
Luca> shipping, so I have no idea why pam-auth-update is adding
Luca> them.

I gave you pointers where to look for these: /usr/share/pam-config/unix
This is complex enough that someone who both has a good understanding of
pam and systemd-home is going to need to get involved.
I can talk about the broader pam context, and some issues people have
run into in the past, but someone needs to have both systemd-home and
pam in their heads to definitively decide what systemd-home wants out of
pam.
That's not going to  be me any time soon.

Bug#792761: UX issue, handling of endless shutdown loops

[Luca Boccassi]

Control: close -1

On Mon, 27 Jul 2015 21:27:23 +0200 Eduard Bloch  wrote:
> On Mon, 20 Jul 2015 10:13:25 -0300 Felipe Sateler
 wrote:
> 
> > >> I'm afraid 2 is really an upstream issue and not an integration
issue.
> > >> Could you please file that bug upstream?
> > >
> > > Maybe... I will give it a try tonight. However I am sceptical
regarding
> > > "productive" communication with upstream.
> > 
> > Great, let us know when you have filed a bug upstream.
> 
> https://github.com/systemd/systemd/issues/633^
> 
> > > Says that it cannot find an id. Checked:
> > >
> > > $ sudo journalctl --list-boots
> > > -1 39f59f8ebdd644f39aeb46b67eef9bff Sa 2015-07-18 09:12:05
CEST—Mo 2015-07-20 08
> > >  0 39f59f8ebdd644f39aeb46b67eef9bff Mo 2015-07-20 08:39:43
CEST—Mo 2015-07-20 08
> > >
> > > No idea what happened to the logs.
> > 
> > Do you have persistent logging enabled? I think you do not. Please
> > follow the instructions of the README.Debian if you want to enable
it.
> 
> Done, waiting for repro situation...

It's been 9 years without a follow-up, so assuming the issue was solved
elsewhere, closing.

-- 
Kind regards,
Luca Boccassi


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

Bug#1071983: netctl: puts .service files into /

[Chris Hofstaedtler]

Source: netctl
Version: 1.28-1
Severity: serious
Justification: FHS violation

Rebuilding your package in current unstable leads to .service files
being installed into /:

-rw-r--r-- root/root   512 2023-08-06 22:20 ./netctl-auto@.service
-rw-r--r-- root/root   445 2023-08-06 22:20 ./netctl-ifplugd@.service
-rw-r--r-- root/root   284 2023-08-06 22:20 ./netctl-sleep.service
-rw-r--r-- root/root   289 2023-08-06 22:20 ./netctl-wait-online.service
-rw-r--r-- root/root   260 2023-08-06 22:20 ./netctl.service
-rw-r--r-- root/root   316 2023-08-06 22:20 ./netctl@.service

Please investigate and fix this for trixie.

Chris



netctl_1.28-1_arm64-2024-05.build.gz
Description: application/gunzip

Bug#1071982: FTBFS: help2man fails

[Chris Hofstaedtler]

Source: jupyterhub
Version: 3.0.0+ds1-1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: z...@debian.org

Your package currently fails to build, see below and the attached build
log:

PYTHONPATH=debian/jupyterhub/usr/lib/python3.11/dist-packages help2man 
--output=jupyterhub-singleuser.1 --name="Single-user server for Jupyter 
notebooks" --version-string=$(dpkg-parsechangelog -S Version | sed s/-[^-]*$//) 
debian/jupyterhub/usr/bin/j
upyterhub-singleuser
help2man: can't get `--help' info from 
debian/jupyterhub/usr/bin/jupyterhub-singleuser
Try `--no-discard-stderr' if option outputs to stderr
make[1]: *** [debian/rules:14: override_dh_auto_install] Error 1

Bug#770755: systemd: debug shell unusable due to continuous systemd output

[Luca Boccassi]

Control: close -1

On Sun, 23 Nov 2014 21:22:00 +0100 Vincent Danjean
 wrote:
> Package: systemd
> Version: 215-5+b1
> Severity: normal
> 
>   Hi,
> 
>   I enabled systemd debug-shell service on several machines. However,
> each time I needed it (for example to fix a problem with mounted
points,
> see #760848 for an specific example), the timeout output of systemd
before
> going to emergency mode forbid me to use the shell.
>   systemd output should not go continously on a used terminal (such
as the
> one used by debug-shell in particular).

Not an issue anymore as per upstream ticket, closing

-- 
Kind regards,
Luca Boccassi


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

Bug#756953: systemd: wpa_supplicant.service wrong behaviour on target isolate

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Sun, 03 Aug 2014 23:43:50 +0200 debianizzato 
wrote:
> Package: systemd
> Version: 208-6
> Severity: normal
> 
> Dear Maintainer,
> I have already sent a bugreport to wpasupplicant package maintainer:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756847
> and I was suggested to report here.
> 
> Wpa_supplicant service is reset by systemd when I isolate a target.
> I think that it is not a desiderable behaviour.
> 
> I use Gnome 3 in Debian Jessie.
> 
> This is what I did:
> I copied /lib/systemd/system/graphical.target to
/etc/systemd/system/personalizzato.target
> in which I added "mysql" and "apache2" to "Conflicts" in order to not
start those services,
> and added "Wants= accounts-daemon-service" because graphical.target
"Wants" it.
> 
> #  Target di prova
> #
> # Provo a disattivare l' avvio di apache e mysql
> # Aggiungo Wants= accounts-daemon-service perchè graphical.target lo
carica
> 
> [Unit]
> Description=Eredita Graphical Interface
> Documentation=man:systemd.special(7)
> Requires=multi-user.target
> After=multi-user.target
> Conflicts=rescue.target mysql.service apache2.service
> Wants=display-manager.service accounts-daemon.service
> AllowIsolate=yes
> 
> [Install]
> Alias=default.target
> 
> Everything works fine, except that WiFi connection disconnects and
then reconnects.
> I found that it is wpa_supplicant.service that is restarted when
isolating a target.
> 
> I solved this issue simply creating a directory
"/etc/systemd/system/wpa_supplicant.service.d"
> in which I created a personalized.conf file with the following 2
lines:
> 
> [Unit]
> IgnoreOnIsolate=true
> 
> In this way wpa_supplicant is not reset when isolating a target.
> 
> Do you think it is a good solution ?
> wpa_supplicant.service will be patched in that way ?

Yes, if you want a unit to survive into an unrelated isolate, then you
need to mark it as such, or pull it in. This is working as intended.

-- 
Kind regards,
Luca Boccassi


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

Bug#1071563: emacs: Don't let test suite failures block the build

[Rob Browning]

Sean Whitton  writes:

> I think we should move the tests to run under autopkgtest, rather than
> during the build.  Debian's autopkgtest infrastructure, with things like
> blocking migration, is by now quite sophisticated.
>
> On IRC it's also been suggested that we also
>
> - mark dired-test-bug27243-02 as flaky (thanks Arto Jantunen); and
>
> - in the new autopkgtest, don't run the tests in parallel.

I don't have a good overall sense of what's been failing lately, but I
did wonder if just marking that test (and any others that have been
(unnecessary) trouble) as flaky, and going back to not running the tests
in parallel on the autobuilders might be sufficient.

As long as the package tests restrict transitions, moving the tests
there, if we can, may be fine too, but if we could keep the spurious
test failure rate low enough (pretty low) without *too* much effort,
then I think catching failures during the build is somewhat preferable
(in case the error is serious).

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#1071981: pypi2deb: please clean out old package from Suggests:

[Alexandre Detiste]

Package: pypi2deb
Version: 3.20240228
Severity: normal

Hi,

I think that suggesting Nose nowadays is more harmful than harmless.

For the Python2 package they can't hurt,
they are not in the archive anymore.

Greetings


diff --git a/debian/control b/debian/control
index c31d046..bf69bc8 100644
--- a/debian/control
+++ b/debian/control
@@ -23,14 +23,8 @@ Depends: build-essential,
  ${misc:Depends},
  ${python3:Depends},
 Recommends: python3-msgpack,
-Suggests: cython,
-  cython3,
-  python-all-dev,
-  python-nose,
-  python-pytest,
-  python-setuptools,
+Suggests: cython3,
   python3-all-dev,
-  python3-nose,
   python3-pytest,
   python3-setuptools,
   python3-sphinx,

Bug#1056166: systemd-homed: `passwd` fails

[Luca Boccassi]

On Sun, 26 May 2024 at 21:46, Sam Hartman  wrote:
>
>
> Hi.
> I'm not really swapped in on Debian this weekend; dealing with a
> transition for day job.
>
> But quick thoughts.
>
> I'm surprised that systemd-home is a pam auth module.
> That is, I wouldn't expect systemd-home to be able to decide whether you
> have presented valid credentials to log in.
> It may be that it has an account entry point, but it's auth entry point
> is trivial.
>
> pam-auth-update assumes that you don't want to reenter a password.
> So, it assumes the first module in the stack will take a password and
> then we will reuse that.
>
> Similarly for password, you don't want to for example  change the ldap
> and local passwords to different values.
>
>
> compare the auth vs auth-initial password vs password-initial lines in
> /usr/share/pam-configs/unix.
>
>
> Will systemd-home work with  an auth-type of additional rather than
> primary?

You are asking difficult questions I'm afraid, I don't really know
very well how PAM works to be able to answer. What I can tell you is
that users and passwords are definitely defined in homed, as the
purpose is to manage users and homes. Here's the manpage:

https://www.freedesktop.org/software/systemd/man/latest/pam_systemd_home.html

Any idea where use_authtok try_first_pass could be coming from? I
don't see them defined anywhere in the pam config I am shipping, so I
have no idea why pam-auth-update is adding them.

Bug#1071649: mflua.1: some remarks and editorial changes for this man page

[Karl Berry]

Thanks for the report. Do they have a tracking system?

No. bug-help2man forwards directly to Brendan O'Dea's email address.

Bug#1071649: mflua.1: some remarks and editorial changes for this man page

[Preuße]

On 26.05.2024 23:46, Karl Berry wrote:

Hello Karl,


FYI, I sent in a report to bug-help2man. If the output can be made
usable, I'll add it to TL, else maybe give up on help2man and just fix
it by hand as Bjarni wrote originally. We'll see what happens. -k


Thanks for the report. Do they have a tracking system?

The Debian bug I've closed few hours ago, as the issue has been solved 
in Debian...just the way how to solve it does not seem optimal.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061743: Gramps in Debian

[Dr. Tobias Quathamer]

Am 24.05.24 um 21:23 schrieb Ross Gammon:

Hi Tobias,

There are no blockers other than real life getting in the way. I did
start working on 5.2.0 in the experimental branch on Salsa. From memory,
there was a problem with fuzzy patches, and the tedious checking of
copyrights still to do. But I should probably merge the changes into
master, and then import 5.2.2.

If you have some spare cycles you are welcome to help move things along.
I use gbp + quilt.

Regards,

Ross


Hi Ross,

I took some time to update the experimental branch to v5.2.2 and fix 
some FTBFS with the new upstream version. I've pushed my work to Salsa, 
please take a look if you have some time.


The package builds on my machine, although I had to disable a single 
test for now. You'll find it in the newly created patch. Maybe you have 
an idea what's causing the failure, so it can be fixed properly.


I haven't looked at the copyrights for now.

Regards,
Tobias



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071649: mflua.1: some remarks and editorial changes for this man page

[Karl Berry]

FYI, I sent in a report to bug-help2man. If the output can be made
usable, I'll add it to TL, else maybe give up on help2man and just fix
it by hand as Bjarni wrote originally. We'll see what happens. -k

Bug#1071321: marked as done (libdumbnet: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file)

[Florian Ernst]

Hello Bastian,

thanks for taking care and fixing this speedily.

However, I am wondering whether there was a particular need to speed up
fixing this bug that I might have missed and that might need to have
been added to the bug for further consideration / clarification.

After all I, as the maintainer, had already confirmed its existence, had
acknowledged the pointers outlining the fix, and had announced when and
how I was going to deal with it.

Even the lowNMU page states 
| If the package maintainer or maintainer group is active, it is polite to
| let them have a stab at fixing the problem first.

As such, while your NMU has improved the overall state of things, I
indeed consider it impolite. And I wish I had had the chance to fix the
problem myself.

So, was there any such pressing need? And did you perhaps already test
building the reverse build deps as I had planned?

Please understand that I am trying to coordinate here in order to avoid
any duplication of effort or any misunderstandings.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1071979: pinot: FTBFS with exiv2 0.28

[Pino Toscano]

Source: pinot
Version: 1.21-1
Severity: important
Tags: patch ftbfs
Control: forwarded -1 https://github.com/FabriceColin/pinot/pull/11

Hi,

pinot fails to build with the new stable series of the Exiv2 library,
i.e. 0.28.x; that version is available in experimental as of this
writing.

Upstream recently merged a PR to fix this [1]. I extracted the
patch/commit from that upstream PR, and verified that it builds fine
with both Exiv2 0.27 and Exiv2 0.28; you can find it attached to this
bug. Would you review this patch, and upload it so that pinot rebuilds
cleanly once a newer Exiv2 is uploaded to unstable?

[1] https://github.com/FabriceColin/pinot/pull/11

Thanks,
-- 
Pino
>From b52b8184a260e77bc72fea3e8e5bd163cf36b79d Mon Sep 17 00:00:00 2001
From: Pino Toscano 
Date: Sun, 25 Feb 2024 19:40:01 +0100
Subject: [PATCH] Support Exiv2 0.28+

Use the new types for the image pointer and exception class as available
in the new Exiv2 version, keeping the support for older versions.
---
 Tokenize/filters/Exiv2ImageFilter.cc | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Tokenize/filters/Exiv2ImageFilter.cc 
b/Tokenize/filters/Exiv2ImageFilter.cc
index ceac398..6b685b3 100644
--- a/Tokenize/filters/Exiv2ImageFilter.cc
+++ b/Tokenize/filters/Exiv2ImageFilter.cc
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef HAVE_EXIV2_XMP_EXIV2_HPP
 #include 
 #include 
@@ -236,7 +237,11 @@ bool Exiv2ImageFilter::next_document(void)
 
try
{
+#if EXIV2_TEST_VERSION(0,28,0)
+   Exiv2::Image::UniquePtr image = 
Exiv2::ImageFactory::open(m_filePath);
+#else
Exiv2::Image::AutoPtr image = 
Exiv2::ImageFactory::open(m_filePath);
+#endif
if (image.get() == NULL)
{
clog << m_filePath.c_str() << " is not an image" << 
endl;
@@ -388,7 +393,11 @@ bool Exiv2ImageFilter::next_document(void)
}
}
}
+#if EXIV2_TEST_VERSION(0,28,0)
+   catch (Exiv2::Error )
+#else
catch (Exiv2::AnyError )
+#endif
{
clog << "Caught exiv2 exception: " << e << endl;
foundData = false;
-- 
2.43.0

Bug#1071978: node-fetch: Tests failures with node 20

[Jérémy Lal]

Package: node-fetch
Version: 3.3.2+~cs11.4.11-2
Severity: important

node-fetch has 3 test failures with nodejs 20:
https://ci.debian.net/packages/n/node-fetch/testing/amd64/47014955/

I tried to fix them in various ways without success.

Jérémy


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

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

Versions of packages node-fetch depends on:
ii  node-data-uri-to-buffer  6.0.2~0~2024040606-3

node-fetch recommends no packages.

node-fetch suggests no packages.

-- no debconf information

Bug#1062799: glslang-dev: Missing libraries listed in glslang.pc -- fixed.

[Philippe SWARTVAGHER]

Hello,

I realized this bug prevents shaderc from migrating to testing.

Please have a look on my MR
(https://salsa.debian.org/xorg-team/vulkan/glslang/-/merge_requests/6),
which (among other things) fixes this bug.

Thanks,

Philippe.

Bug#1071977: tmux: /lib/x86_64-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.4.current' 404

[Romain Francoise]

Hi,

On Sun, May 26, 2024 at 10:39 PM Marcel Partap  wrote:
> I'm not sure whether this is a purely local issue but it's
>
> tmux: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
> `NCURSES6_TINFO_6.4.current'
> not found (required by tmux)

Has to be a local issue... Are you 100% sure that this tmux binary is
the one shipped in the Debian package? Can you show the path and
SHA256 of the binary? And run ldd on it?

Thanks,
-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1071381: linux-image-6.1.0-15-amd64: (regression) spontaneous freezing on Thinkpad

[mehturt]

I think I have the same problem on my HP Elite Mini 800 G9.
I get exactly the same symptoms as the OP.
I even tried with kernel 6.7 from backports, but got the same problems.
I'm currently running Debian 11 with kernel 5.10.0-29, no issues so far 
(machine is up for about 2 days).
Let me know what information can I provide to help addressing this issue.
m.

--

Sent with [Proton Mail](https://proton.me/) secure email.

Bug#1056166: systemd-homed: `passwd` fails

[Sam Hartman]

Hi.
I'm not really swapped in on Debian this weekend; dealing with a
transition for day job.

But quick thoughts.

I'm surprised that systemd-home is a pam auth module.
That is, I wouldn't expect systemd-home to be able to decide whether you
have presented valid credentials to log in.
It may be that it has an account entry point, but it's auth entry point
is trivial.

pam-auth-update assumes that you don't want to reenter a password.
So, it assumes the first module in the stack will take a password and
then we will reuse that.

Similarly for password, you don't want to for example  change the ldap
and local passwords to different values.


compare the auth vs auth-initial password vs password-initial lines in
/usr/share/pam-configs/unix.


Will systemd-home work with  an auth-type of additional rather than
primary?

Bug#1071977: tmux: /lib/x86_64-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.4.current' 404

[Marcel Partap]

Package: tmux
Version: 3.4-5
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: mpar...@gmx.net

I'm not sure whether this is a purely local issue but it's

tmux: /lib/x86_64-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.4.current'
not found (required by tmux)

tmux:
  Installed: 3.4-5
  Candidate: 3.4-5
  Version table:
 *** 3.4-5 510
500 http://ftp.de.debian.org/debian testing/main amd64 Packages
510 http://ftp.de.debian.org/debian unstable/main amd64 Packages
500 http://http.kali.org/kali kali-rolling/main amd64 Packages
100 /var/lib/dpkg/status
 3.4-5~bpo12+1 100
100 http://ftp.de.debian.org/debian bookworm-backports/main amd64
Packages
 3.3a-3 500
500 http://ftp.de.debian.org/debian stable/main amd64 Packages
500 http://ftp.de.debian.org/debian bookworm/main amd64 Packages
 3.3a-3~bpo11+1 100
100 http://ftp.de.debian.org/debian bullseye-backports/main amd64
Packages
 3.1c-1+deb11u1 500
500 http://ftp.de.debian.org/debian bullseye/main amd64 Packages

libtinfo6:
  Installed: 6.5-2
  Candidate: 6.5-2
  Version table:
 *** 6.5-2 510
500 http://ftp.de.debian.org/debian testing/main amd64 Packages
510 http://ftp.de.debian.org/debian unstable/main amd64 Packages
500 http://http.kali.org/kali kali-rolling/main amd64 Packages
100 /var/lib/dpkg/status
 6.4-4 500
500 http://ftp.de.debian.org/debian stable/main amd64 Packages
500 http://ftp.de.debian.org/debian bookworm/main amd64 Packages
 6.2+20201114-2+deb11u2 500
500 http://ftp.de.debian.org/debian bullseye/main amd64 Packages


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (510, 'unstable'), (509, 'experimental'), (500, 
'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 
'oldstable-security'), (500, 'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages tmux depends on:
ii  libc6   2.38-11
ii  libevent-core-2.1-7t64  2.1.12-stable-8.1+b1
ii  libsystemd0 255.4-1+b1
ii  libtinfo6   6.5-2
ii  libutempter01.2.1-3

tmux recommends no packages.

tmux suggests no packages.

-- debconf-show failed

Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work

[Roland Clobus]

Hello Pascal,

On 25/05/2024 23:49, Pascal Hambourg wrote:

On 25/05/2024 at 22:10, Roland Clobus wrote:


When I run the Debian installer, the missing firmware file is 
correctly identified and installed by 'check-missing-firmware.sh'. 
However, the kernel module is mis-identified as 'usb'.


This is a more generic issue already reported in #1033679

Can you give a try to the attached patches ? They came to late for 
bookworm, maybe it is time to reconsider them.


Your patch series works fine, the firmware is correctly identified and 
loaded. Unfortunately for me, it still needs a reconnect cycle.

See the attached syslog for their effect. (I've used sid)

At 19:30:58 the 'no network card is detected' dialog from the installer 
is shown
At 19:32:30 I disconnected the USB device from KVM (which is attached on 
the host)

At 19:32:45 I reconnected the USB device in KVM
At 19:34:06 the SSID scan shows the available wireless networks


Attached is a patch that allows the module to be identified correctly.
If desired, I can send the patch instead as a merge request on Salsa.


IMO $address should be included in the search pattern. Else if there is 
another device reported as "usb" then your patch will wrongly resolve it 
as r8712u too.


Your patch is better and more generic. It would be a good candidate for 
at least trixie.


However, using 'modprobe -r r8712u' and 'modprobe r8712u' is not 
sufficient to enable the adapter, it still needs a physical reconnect.
In the attached screenshot from the installer (sid) the result of the 
patch is shown. Also in the QEMU environment, I need to disconnect and 
reconnect the USB device from the host.


Looks like a driver/device issue.


Given that within kvm (virt-manager) I can simulate a reconnect, I would 
expect that it can be simulated otherwise, but haven't found a proper 
way yet.


With kind regards,
Roland Clobus
May 26 19:30:27 syslogd started: BusyBox v1.36.1
May 26 19:30:27 kernel: klogd started: BusyBox v1.36.1 (Debian 1:1.36.1-7)
May 26 19:30:27 kernel: [0.00] Linux version 6.8.9-amd64 
(debian-ker...@lists.debian.org) (x86_64-linux-gnu-gcc-13 (Debian 13.2.0-25) 
13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 
6.8.9-1 (2024-05-15)
May 26 19:30:27 kernel: [0.00] Command line: 
BOOT_IMAGE=/install/gtk/vmlinuz vga=788 --- quiet
May 26 19:30:27 kernel: [0.00] BIOS-provided physical RAM map:
May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 
0x-0x0002] usable
May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 
0x0003-0x0004] reserved
May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 
0x0005-0x0009efff] usable
May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 
0x0009f000-0x0009] reserved
May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 
0x0010-0x7e8ecfff] usable
May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 
0x7e8ed000-0x7eb6cfff] reserved
May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 
0x7eb6d000-0x7eb7efff] ACPI data
May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 
0x7eb7f000-0x7ebfefff] ACPI NVS
May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 
0x7ebff000-0x7eff] usable
May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 
0x7f00-0x7fff] reserved
May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 
0xe000-0xefff] reserved
May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 
0xfeffc000-0xfeff] reserved
May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 
0x0001-0x00013fff] usable
May 26 19:30:27 kernel: [0.00] NX (Execute Disable) protection: active
May 26 19:30:27 kernel: [0.00] APIC: Static calls initialized
May 26 19:30:27 kernel: [0.00] e820: update [mem 0x7cc12018-0x7cc1ba57] 
usable ==> usable
May 26 19:30:27 kernel: [0.00] e820: update [mem 0x7cc12018-0x7cc1ba57] 
usable ==> usable
May 26 19:30:27 kernel: [0.00] extended physical RAM map:
May 26 19:30:27 kernel: [0.00] reserve setup_data: [mem 
0x-0x0002] usable
May 26 19:30:27 kernel: [0.00] reserve setup_data: [mem 
0x0003-0x0004] reserved
May 26 19:30:27 kernel: [0.00] reserve setup_data: [mem 
0x0005-0x0009efff] usable
May 26 19:30:27 kernel: [0.00] reserve setup_data: [mem 
0x0009f000-0x0009] reserved
May 26 19:30:27 kernel: [0.00] reserve setup_data: [mem 
0x0010-0x7cc12017] usable
May 26 19:30:27 kernel: [0.00] reserve setup_data: [mem 
0x7cc12018-0x7cc1ba57] usable
May 26 19:30:27 kernel: [0.00] reserve setup_data: [mem 
0x7cc1ba58-0x7e8ecfff] usable
May 26 19:30:27 kernel: 

Bug#1071976: jtreg7: openjdk-11 test failures due to the unsupported class version in jtreg7 components

[Vladimir Petko]

Source: jtreg7
Version: 7.3.1+1-2
Severity: normal

Dear Maintainer,


A number of openjdk-11 jdk tests fail with the following exception (e.g.
test/jdk/java/lang/invoke/BigArityTest.java):


java.util.ServiceConfigurationError:
org.junit.platform.launcher.TestExecutionListener: Provider
org.junit.platform.reporting.open.xml.OpenTestReportGeneratingListener could
not be instantiated
at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:582)
at
java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:804)
at
java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:722)
at java.base/java.util.ServiceLoader$3.next(ServiceLoader.java:1395)
at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
at
java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at
java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
at
org.junit.platform.launcher.core.LauncherFactory.registerTestExecutionListeners(LauncherFactory.java:179)
at
org.junit.platform.launcher.core.LauncherFactory.createDefaultLauncher(LauncherFactory.java:137)
at
org.junit.platform.launcher.core.LauncherFactory.openSession(LauncherFactory.java:98)
at
com.sun.javatest.regtest.agent.JUnitRunner.runWithJUnitPlatform(JUnitRunner.java:141)
at com.sun.javatest.regtest.agent.JUnitRunner.main(JUnitRunner.java:95)
at com.sun.javatest.regtest.agent.JUnitRunner.main(JUnitRunner.java:61)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.UnsupportedClassVersionError:
org/junit/platform/reporting/shadow/org/opentest4j/reporting/events/api/DocumentWriter
has been compiled by a more recent version of the Java Runtime (class file
version 56.0), this version of the Java Runtime only recognizes class file
versions up to 55.0
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1022)
at
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
at
java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800)
at
java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698)
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621)
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:527)
at
org.junit.platform.reporting.open.xml.OpenTestReportGeneratingListener.(OpenTestReportGeneratingListener.java:95)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:780)
... 22 more


This is caused by opentest4j-reporting built without set targetCompatibility.



-- System Information:
Debian Release: trixie/sid
  APT prefers noble-updates
  APT policy: (500, 'noble-updates'), (500, 'noble-security'), (500, 'noble'), 
(100, 'noble-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.0-31-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via 

Bug#970043: Request to help test ia64 build for galera-4

[Otto Kekäläinen]

Thanks Frank and others!

I appreciate your assistance in testing the build. I will proceed to
merge this before the next upload then.


I just wanted to add here the regular Debian Developer's point of
view: after every upload of every package I maintain, I always check
the buildd status, investigate all build failures and try to get them
working. As long as ia64 is among the build targets[1], I feel it is
implied that DDs should try to get the build working. I have been
sending bug reports to upstream and they have helped several times in
making modifications to the source code to make all builds pass.

If you some day in the future think that ia64 work is not valuable use
of a regular DD's use of time, I'd appreciate seeing some announcement
on debian-devel@ for example so that I and others know that we should
invest our limited Debian time in other things.

[1] https://buildd.debian.org/status/package.php?p=galera-4

Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work

[Roland Clobus]

On 25/05/2024 23:34, Cyril Brulebois wrote:

Hoi,

Roland Clobus  (2024-05-25):

Source: hw-detect
Version: 1.160
Severity: normal
Tags: patch d-i


Just to confirm, which linux version was this tested against?


The current kernel from sid: 6.8.9-1
I've used a locally built live image based on sid (live-build) with the 
patched hw-detect.



I have an USB wireless adapter that uses the r8712u kernel module and
that requires firmware from non-free-firmware.

...

I see that's a module from staging, maybe it's not behaving like it
should? At least differently from other modules…


As far as I can see, r8712u entered staging in 2012 and has been there 
since...



I spotted 1422b526fba994cf05fd288a152106563b875fce that fixed a race
condition regarding firmware loading (fix available in v6.6-rc1 and
v6.1.52), maybe there are other similar issues?


In which repo can I find this hash value?


When I disconnect the adapter and reconnect it, the installer is able
to use the adapter properly.

...

I tried several options, but could not get them to work

...>> Do you know a solution (apart from a physical reconnect)?


I'd suggest a search in upstream bugzilla and mailing lists.

I'm adding the kernel maintainers in copy, in case they have better
ideas.


Thanks. I'll try to look some more.

With kind regards,
Roland Clobus


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#970043: Request to help test ia64 build for galera-4

[Frank Scheiner]

Hi Otto,

On 25.05.24 06:24, Otto Kekäläinen wrote:

Hi!

I have a patch to tentatively fix Debian package galera-4 builds on
ia64 at https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/19

Would anybody be interested in helping out and testing if the build
fully passes now?

Details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970043


So, I think your patch solves the build issue for ia64:

Before:
```
[ 98%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/service_thd_check.cpp.o

Checking library symbol visibility (hidden)
005266c0 lDF .text	0220 
_ZNK4asio6detail11timer_queueINS0_18chrono_time_traitsINSt6chrono3_V212steady_clockENS_11wait_traitsIS5_E18wait_duration_msecEl
00524cc0 lDF .text	0060 
_ZN4asio3ssl5error6detail15stream_categoryD1Ev
00523e80 lDF .text	0010 
_ZN4asio6detail10service_idINS0_22deadline_timer_serviceINS0_18chrono_time_traitsINSt6chrono3_V212steady_clockENS_11wait_traitsIS6_EEED1Ev
0054f840 lDF .text	0010 
_ZN4asio6detail10service_idINS0_23reactive_socket_serviceINS_2ip3udpD1Ev
00524ac0 lDF .text	0060 
_ZN4asio5error6detail14netdb_categoryD1Ev
00525200 lDF .text	0060 
_ZN4asio22service_already_existsD1Ev

[...]
make[2]: *** [galera/src/CMakeFiles/galera_smm.dir/build.make:110: 
libgalera_smm.so] Error 1

make[2]: *** Deleting file 'libgalera_smm.so'
make[1]: *** [CMakeFiles/Makefile2:1837: 
galera/src/CMakeFiles/galera_smm.dir/all] Error 2

make[1]: *** Waiting for unfinished jobs
[ 98%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/ist_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/saved_state_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/defaults_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/progress_check.cpp.o

[100%] Linking CXX executable galera_check
[100%] Linking CXX executable check_gcomm
[100%] Built target galera_check
[100%] Built target check_gcomm
make: *** [Makefile:166: all] Error 2
2
Sun May 26 19:22:46 UTC 2024
```

After applying the patch:
```
[...]
[ 98%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/service_thd_check.cpp.o

Checking library symbol visibility (hidden)
Verifying that library is linked with SSL
  NEEDED   libcrypto.so.3
  NEEDED   libssl.so.3
[ 98%] Built target galera_smm
[ 98%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/ist_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/saved_state_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/defaults_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/progress_check.cpp.o

[ 99%] Linking CXX executable check_gcomm
[ 99%] Built target check_gcomm
[100%] Linking CXX executable galera_check
[100%] Built target galera_check
0

real14m26.065s
user82m39.186s
sys 2m8.359s
Sun May 26 19:54:12 UTC 2024
```

In the end I built it on T2 directly from the cloned sources.

Cheers,
Frank

Bug#1071431: libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…

[Sebastian Andrzej Siewior]

On 2024-05-20 12:21:30 [+0200], Jean-Guilhem Cailton wrote:
> Le 20/05/2024 à 10:11, Sebastian Andrzej Siewior a écrit :
> > Okay. This was old testing -> new testing or Bookworm -> testing? Was
> > this "apt upgrade && apt dist-upgrade" or just "apt dist-upgrade" ?
> 
> This was old testing -> new testing.
> This was just "apt full-upgrade".

Okay.

> It seems to me that having both :i386 and :amd64 libraries increases the
> risk of failure, because of the many "apt" steps that can take place between
> the removal of old :amd64 (that may happen close to the treatment of the
> :i386 version, like here for libssl3) and install of t64:amd64. On the
> contrary, when only :amd64 is present, it seems that the replacement install
> closely follows the removal.

how did you have two versions? I couldn't install :amd64 and :i386 of
that package. I tried several bookworm -> testing upgrade but in
bookworm I could install either :i386 or :amd64 version of postgres.
Installing the other version removed the former…
I performed a few upgrades and all succeeded. Anyway to reproduce what
you did?

> Jean-Guilhem

Sebastian

Bug#1071975: dh-make: Don't include 'Multi-Arch: foreign' in debian/control

[Joao Eriberto Mota Filho]

Source: dh-make
Version: 2.202302
Severity: serious
Justification: Multiarch false promises
X-Debbugs-Cc: debian-cr...@lists.debian.org, hel...@subdivi.de, 
chris.obb...@collabora.com

Dear dh-make maintainers,

This bug is related to #1040542 and to commit d411b19 on Salsa[1].

[1] https://salsa.debian.org/debian/dh-make/-/commit/d411b19

Currently, the dh_make command adds 'Multi-Arch: foreign' automatically to
several packages. This implies that Multiarch will honor all items present
here[2] in all new packages sent to Debian and made by people that don't
know Multiarch (including some sponsors).

[2] https://wiki.debian.org/DependencyHell#Multi-Arch:_foreign

The natural consequence will be once such a package enters the archive, the
Multiarch:hinter will suggest more 'Multi-Arch: foreign' based on this promise
and before too long we have an archive polluted with false promises, rendering
Multiarch useless.

Regards,

Eriberto

Bug#1071973: qt6-networkauth: CVE-2024-36048

[Salvatore Bonaccorso]

Source: qt6-networkauth
Version: 6.4.2-5
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: clone -1 -2
Control: reassign -2 src:qtnetworkauth-everywhere-src 5.15.13-2
Control: retitle -2 qtnetworkauth-everywhere-src: CVE-2024-36048

Hi,

The following vulnerability was published for QAbstractOAuth.

CVE-2024-36048[0]:
| QAbstractOAuth in Qt Network Authorization in Qt before 5.15.17, 6.x
| before 6.2.13, 6.3.x through 6.5.x before 6.5.6, and 6.6.x through
| 6.7.x before 6.7.1 uses only the time to seed the PRNG, which may
| result in guessable values.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-36048
https://www.cve.org/CVERecord?id=CVE-2024-36048
[1] https://codereview.qt-project.org/c/qt/qtnetworkauth/+/560317
[2] https://codereview.qt-project.org/c/qt/qtnetworkauth/+/560368

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#966570: RFP: libamf -- Advanced Media Framework (AMF) SDK

[Braiam]

I would be willing, as long as the issues I noted in my last mail
could be addressed.


-- 
Braiam

Bug#1071972: openssl: CVE-2024-4603

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for openssl.

In avoidance of doupt, no DSA is needed, filling the bug for BTS
tracking and it can simply be fixed in the next round of rebasing
openssl (IMHO).

CVE-2024-4603[0]:
| Issue summary: Checking excessively long DSA keys or parameters may
| be very slow.  Impact summary: Applications that use the functions
| EVP_PKEY_param_check() or EVP_PKEY_public_check() to check a DSA
| public key or DSA parameters may experience long delays. Where the
| key or parameters that are being checked have been obtained from an
| untrusted source this may lead to a Denial of Service.  The
| functions EVP_PKEY_param_check() or EVP_PKEY_public_check() perform
| various checks on DSA parameters. Some of those computations take a
| long time if the modulus (`p` parameter) is too large.  Trying to
| use a very large modulus is slow and OpenSSL will not allow using
| public keys with a modulus which is over 10,000 bits in length for
| signature verification. However the key and parameter check
| functions do not limit the modulus size when performing the checks.
| An application that calls EVP_PKEY_param_check() or
| EVP_PKEY_public_check() and supplies a key or parameters obtained
| from an untrusted source could be vulnerable to a Denial of Service
| attack.  These functions are not called by OpenSSL itself on
| untrusted DSA keys so only applications that directly call these
| functions may be vulnerable.  Also vulnerable are the OpenSSL pkey
| and pkeyparam command line applications when using the `-check`
| option.  The OpenSSL SSL/TLS implementation is not affected by this
| issue.  The OpenSSL 3.0 and 3.1 FIPS providers are affected by this
| issue.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-4603
https://www.cve.org/CVERecord?id=CVE-2024-4603
[1] https://www.openssl.org/news/secadv/20240516.txt

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1071971: please downgrade perl dependency to perl-base

[Michael Tokarev]

Package: lm-sensors
Version: 1:3.6.0-7.1
Severity: normal

Currently, lm-sensors package has Depends: perl:any.  However, the only
utility which uses perl - sensors-detect - is just fine with perl-base,
it does not use anything from the more complete perl package.

On many systems we have, perl is only pulled by lm-sensors, and on all
these systems, we don't even need sensors-detect.  It'd be nice to get
rid of this dependency.

Please note that perl-base is Essential: yes.  So is sed (which is also
in Depends: line), and the minimum-required version of sed (4.0.5) is
long in debian (buster has sed version 4.7 already).  So both extra
dependencies should be removed from the Depends: line.

Thanks,

/mjt

Bug#1071722: adios4dolfinx: FTBFS: failing tests

[Drew Parsons]

On 2024-05-26 12:44, Santiago Vila wrote:


To track that, what does `lscpu` report on your failing system?
(the thread,core,socket lines are probably the relevant ones)


It's an AWS machine of type m6a.large. These are the most relevant 
specs.


Thread(s) per core:   2
Core(s) per socket:   1
Socket(s):1

...
So it seems to have "one core, two threads". I can try changing the n=2 
parameter
in the ipp.Cluster invocation to n=1 and tell you if there is any 
change,

if it helps. I don't think that will make things worse in any case.



It's worth trying.  I've got no reason to think that 2 threads 1 core 
should be problem, but I can't think of anything else that would in 
principle be different on your system compared to the others that are 
not failing.


What it's worth, my own system is
Thread(s) per core:   2
Core(s) per socket:   4
Socket(s):1

Bug#1071378: linux-image-6.7.12-686-pae: Crash during early boot

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo unreproducible

Hi Jörn,

On Sat, May 18, 2024 at 09:37:03AM +0200, Jörn Heusipp wrote:
> Package: src:linux
> Version: 6.7.12-1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: osm...@problemloesungsmaschine.de
> 
> Hello Debian kernel team!
> 
> 
> Linux 6.7.12-1 (686-pae) fails to boot for me on this system.
> 
> It hangs right after:
> ===
> Loading Linux 6.7.12-686-pae ...
> Loading initial ramdisk ...
> ===
> 
> Booting with 'earlyprintk=vga', I managed to capture a stack trace on video. I
> stitched together an image showing it as a whole:
> , and also attached.
> 
> Trimmed transcription (might contain typos) of the crash (I can transcribe all
> of it if really needed, but I figured the type of crash and the trace itself
> could be sufficient):
> ===
> BUG: kernel NULL pointer dereference, address: 0010
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> Oops: 0002 [#1] PREEMPT SMP NOPTI
> [...]
> EIP: __ring_buffer_alloc+0x32/0x194
> [...]
> show_regs
> __die
> page_fault_oops
> kernelmode_fixup_or_oops.constprop
> __bad_area_nosemaphore.constprop
> bad_area_nosemaphore
> do_user_addr_fault
> prb_read_valid
> exc_page_fault
> pvclock_clocksource_read_nowd
> handle_exception
> pvclock_clocksource_read_nowd
> __ring_buffer_alloc
> pvclock_clocksource_read_nowd
> __ring_buffer_alloc
> early_trace_init
> start_kernel
> i386_start_kernel
> startup_32_smp
> [...]
> ===
> 
> The line immediately before the crash reads
> "ftrace: allocated 78 pages with 4 groups".
> 
> linux 6.8.9-1 (686-pae) from unstable shows the same behaviour; it also
> crashes.
> 
> I am still running 6.6.15-2 on this box for now, which works completely fine
> (as did all Debian Testing kernels since at least the 2.6.32 days on this
> particular box). 6.7.12-1 (amd64) also works fine on all of my amd64 boxes.

I cannot reproduce this problem. If you still can with the recent
6.8.11-1 landed in unstable, you might try to bisect the changes in
upstream kernel to determine the breaking commit?

Regards,
Salvatore

Bug#1063571: libpcre3: move libraries to /usr (DEP17)

[Helmut Grohne]

Control: clone -1 -2
Control: retitle -2 pcre3 should not be part of trixie
Control: tags -2 trixie sid
Control: severity -2 serious
Control: block -1 by -2

On Sun, May 26, 2024 at 04:18:38PM +0100, Matthew Vernon wrote:
> I really, truly, do not want to be shipping pcre3 in trixie.

Cool. I've recorded this in the bts.

> There are 33 unfixed packages[0], so I think this is reasonable (if nothing
> else, I don't believe any of the remainder are showstoppers).

The autoremover will establish the urgency of this matter to the non-key
packages. Please NMU the others such that we're done before the
transition freeze.

Helmut

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

[Helmut Grohne]

Hi Johannes,

On Sun, May 26, 2024 at 03:26:56PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Quoting Helmut Grohne (2024-05-24 14:12:38)
> > while working with debusine.debian.net, I ran into a rather crazier kind
> > of issue with the unshare backend. It seems like debusine.debian.net
> > creates a chroot.tar where resolv.conf is a symbolic link:
> > 
> > | lrwxrwxrwx 0/0   0 2024-05-20 17:15 ./etc/resolv.conf -> 
> > ../run/systemd/resolve/stub-resolv.conf
> > 
> > Notably, /run/systemd/resolve does not exist inside the tar nor does
> > sbuild run systemd-resolved nor systemd-tmpfiles for creating this
> > location. When building, the unshare backend tries to bind mount
> > /etc/resolv.conf:
> > 
> > | --: 13: cannot create /tmp/tmp.sbuild.OQ0pOU6LQg/etc/resolv.conf: 
> > Directory nonexistent
> > https://debusine.debian.net/artifact/427489/hostname_3.23+nmu2_amd64-2024-05-24T10:06:30Z.build
> > 
> > This fails, because mount attempts to dereference the symbolic link and
> > finds that an intermediate directory does not exist. As a result, this
> > fails and network generally does not work resulting in all sorts of
> > badness.
> 
> I'm not sure where you see bind-mounting /etc/resolv.conf being done in the
> $network_setup code. If network is enabled, it reads:
> 
> [ -f /etc/resolv.conf ] && cat /etc/resolv.conf > 
> "$rootdir/etc/resolv.conf" || echo "nameserver 127.0.0.53" > 
> "$rootdir/etc/resolv.conf";

Mea culpa. I hallucinated that bind mount, but the effect is the same.
The shell redirection follows the symbolic link and figures that it
cannot create "$rootdir/etc/resolv.conf". The "Directory nonexistent"
error message really comes from the dash redirection:
https://sources.debian.org/src/dash/0.5.12-8/src/error.c/?hl=225#L225

I think we should unlink /etc/resolv.conf (as it may be a dangling
symbolic link) before creating it. Also note that if you were working
with a malicious tar archive and /etc/resolv.conf were an absolute
symbolic link, you'd be following it in the initial namespace possibly
overwriting precious files. I would not classify this as a vulnerability
as we expect the chroot tar to be "sane".

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

Not at all. Once my bind mount hallucination goes away, that is the
obvious solution.

Helmut

Bug#1071969: ITP: python-proto-plus -- Beautiful Pythonic protocol buffers

[Yogeswaran Umasankar]

Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar 
X-Debbugs-Cc: debian-de...@lists.debian.org, kd8...@gmail.com

* Package name: python-proto-plus
  Version : 1.23.0
  Upstream Contact: Google LLC 
* URL : https://github.com/googleapis/proto-plus-python
* License : Apache-2.0
  Programming Lang: Python
  Description : Beautiful Pythonic protocol buffers

This is a wrapper around protocol buffers. Protocol buffers
 is a specification format for APIs, such as those inside Google.
 This library provides protocol buffer message classes and objects
 that largely behave like native Python types. Planned to maintain it
 under DPT, and need sponsorship.

Bug#1071968: ITP: ruby-cssbundling-rails -- Bundle and process CSS in Rails via Node.js

[Ananthu C V]

Package: wnpp
Severity: wishlist
Owner: Ananthu C V 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ruby-cssbundling-rails
  Version : 1.4.0
  Upstream Contact: David Heinemeier Hansson 
* URL : https://github.com/rails/cssbundling-rails
* License : Expat
  Programming Lang: ruby
  Description : Bundle and process CSS in Rails via Node.js

 This gem provides installers to get you going with the bundler of your choice
 in a new Rails application, and a convention to use app/assets/builds to hold
 your bundled output as artifacts that are not checked into source control (the
 installer adds this directory to .gitignore by default).

This package is a dependency of gitlab.

Bug#773538: systemd: journal is quite big compared to rsyslog output

[Luca Boccassi]

Control: close -1 252-1

On Fri, 19 Dec 2014 17:32:33 +0100 Martin Steigerwald
 wrote:
> Package: systemd
> Version: 218-2
> Severity: normal
> 
> Dear Maintainer,
> 
> I have this here:
> 
> merkaba:~> du -sch /var/log/* | sort -rh | head -10
> 1,3G    insgesamt
> 1,1G    /var/log/journal
> 143M    /var/log/atop
> 53M /var/log/collectl
> 13M /var/log/installer
> 6,0M    /var/log/kern.log.3.gz
> 5,9M    /var/log/debug.3.gz
> 3,9M    /var/log/atop.log.8
> 3,6M    /var/log/atop.log.10
> 3,5M    /var/log/atop.log.14
> 
> I think the journal takes quite a bit of space compared to what
rsyslog
> produces with its standard logrotate settings (especially if you
> substract the 143M atop performance data):

compact mode has been implemented, that's good enough already, for
other RFEs just open them upstream, nothing to do downstream

-- 
Kind regards,
Luca Boccassi


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

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Luca Boccassi]

Control: tags -1 -fixed-upstream
Control: tags -1 -help
Control: tags -1 wontfix
Control: close -1

On Wed, 30 Nov 2016 20:01:51 +0100 Dirk Heinrichs
 wrote:
> Package: systemd
> Version: 232-6
> Severity: important
> 
> --- Please enter the report below this line. ---
> I'm running systems with user home directories located in an OpenAFS
> network filesystem. This used to work fine for years. However, since
> some time now, some desktop environments/applications (KDE,
Evolution,
> etc.) have trouble writing their config files, while writing to the
> same file from within a shell worked fine.
> 
> I did some investigation and found out that dbus-daemon is not
started
> be the pam-authenticated user session anymore, but
> via /lib/systemd/systemd --user.

As mentioned on the upstream ticket, this really needs to be fixed in
AFS, nothing we can do downstream.

-- 
Kind regards,
Luca Boccassi


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

Bug#1056166: systemd-homed: `passwd` fails

[Luca Boccassi]

Control: tags -1 help

On Sun, 19 Nov 2023 23:48:46 +0100 Alexander Bochmann
 wrote:
> Package: systemd-homed
> Version: 254.5-1~bpo12+2
> Followup-For: Bug #1056166
> 
> Hello,
> 
> I can confirm this problem still exists in bookworm and 
> bookworm-backports:
> 
> As soon as the Debian systemd-homed PAM configuration is activated 
> by pam-auth-update, it's not possible to change passwords of 
> users that come from /etc/passwd anymore.
> 
> This seems to be due to a PAM misconfiguration. I don't understand
> enough of the Debian PAM setup to say why it doesn't work, but 
> I tried replacing the rules with alternatives that I copied from 
> an openSUSE Tumbleweed install, and using those it's possible to 
> change details on users both from /etc/passwd and systemd-homed.

This is the pam config I ship:

# cat /usr/share/pam-configs/systemd-homed
Name: Enable user management by systemd-homed
Default: yes
Priority: 257
Auth-Type: Primary
Auth:
[success=end default=ignore]pam_systemd_home.so
Account-Type: Primary
Account:
[success=end default=ignore]pam_systemd_home.so
Session-Type: Additional
Session:
optionalpam_systemd_home.so
Password-Type: Primary
Password:
[success=end default=ignore]pam_systemd_home.so


For some reason, this results in the following change being applied to
/etc/pam.d/common-password:

-password   [success=1 default=ignore]  pam_unix.so obscure yescrypt
+password   [success=2 default=ignore]  pam_systemd_home.so 
+password   [success=1 default=ignore]  pam_unix.so obscure use_authtok 
try_first_pass yescrypt

The first line is fine, but the second is the issue.
IE, use_authtok try_first_pass are added to pam_unix.so, which break
everything. Removing those manually fix things again. I have no idea
where they are coming from... PAM experts, any idea?

-- 
Kind regards,
Luca Boccassi


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

Bug#1071964: Elogind defaults to s2idle

[Mark Hindley]

Control: forwarded -1 https://github.com/elogind/elogind/issues/285
Control: tags -1 upstream

On Sun, May 26, 2024 at 05:14:55PM +0200, Juliusz Chroboczek wrote:
> Filed upstream at https://github.com/elogind/elogind/issues/285.

Thanks. I think that is the right place to discuss this further. You would need
to present a persuasive argument for Debian to deviate from the upstream
default.

FTR, the change in behaviour is documented with a workaround in debian/NEWS[1]

Mark

[1]  https://git.devuan.org/devuan/elogind/src/branch/debian/debian/NEWS

Bug#1053443: automount should not act if filesystem is already mounted

[Luca Boccassi]

On Sun, 26 May 2024 18:57:31 +0200 Marc Haber
 wrote:
> On Sun, May 26, 2024 at 05:53:01PM +0100, Luca Boccassi wrote:
> > So yeah, not going to risk this for the benefit of a non-default
> > package with 0.19% popcon, sorry. Feel free to document the
workaround
> > and link to this bug as you see fit. I'd recommend noting the FS
> > corruption issues too, but that's up to you of course.
> 
> I just suggested the automounter to not try to mount a filesystem
that
> is already there. I am not a systemd expert, but that should be a
> minimally invasive oneliner, not changing other system's behavior,
> shouldn't it?

Feel free to propose any change you want to see with a PR upstream.
This is not something that is appropriate to patch downstream, even if
it was desirable.

-- 
Kind regards,
Luca Boccassi


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

Bug#951257: udevadm: please exit nonzero with "Running in chroot, ignoring request." when /proc is not mounted

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Thu, 27 Feb 2020 12:50:40 +1100 "Trent W. Buck"
 wrote:
> Michael Biebl wrote:
> >>> [...] you'd have to convince upstream that this is a good idea
[...]
> >> Blergh, I'll have to make a github account [...]
> > Any updates here?
> 
> Sorry, no.
> This is relatively low priority for me.

No update in 4 years, and it was in the meanwhile worked around in
udisks2. It is not appropriate to patch to change return values
downstream, so closing.

-- 
Kind regards,
Luca Boccassi


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

Bug#891558: Checking in progress on ... message improvement ideas

[Luca Boccassi]

Control: close -1 256~rc3-2

On Mon, 26 Feb 2018 22:10:05 -0500 Theodore Ts'o  wrote:
> reassign 891558 systemd 237
> thanks
> 
> On Tue, Feb 27, 2018 at 08:58:25AM +0800, 積丹尼 Dan Jacobson wrote:
> > (Alas the actual "Checking in progress on ..." messages are the
kind one
> > sees during boot that are not logged anywhere(!) and thus one only
can
> > tell you from personal memory.)
> 
> It appears the message you are complaining about comes from systemd:
> 
> ./debian/patches/debian/fsckd-daemon-for-inter-fsckd-
communication.patch:+ ngettext("Checking in
progress on %d disk (%3.1f%% complete)",
> ./debian/patches/debian/fsckd-daemon-for-inter-fsckd-
communication.patch:+  "Checking in
progress on %d disks (%3.1f%% complete)", m->numdevices),
> ./src/fsckd/fsckd.c: ngettext("Checking
in progress on %d disk (%3.1f%% complete)",
> ./src/fsckd/fsckd.c:  "Checking
in progress on %d disks (%3.1f%% complete)", m->numdevices),

fsckd has now been dropped. closing.

-- 
Kind regards,
Luca Boccassi


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

Bug#1057873: systemd-boot: allow user postinstall script to be able to sign the bootloader

[Luca Boccassi]

Control: tags -1 help

On Sat, 09 Dec 2023 23:53:17 +0100 Matteo Settenvini
 wrote:
> Package: systemd-boot
> Version: 255-1
> Severity: important
> 
> Dear Maintainer,
> 
> as per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033725 and
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996202, there seems
to be no
> willingness to sign esp/EFI/systemd/systemd-bootx64.efi and
> esp/EFI/BOOT/BOOTX64.EFI with the Debian CA.
> 
>   Sidenote: (Maybe this decision should be revisited? We are a couple
of years
>   later and systemd-boot is the only proper Linux bootloader able to
do
>   measured boot).

This is in progress and should hopefully happen for Trixie.

> Instead, the solution pointed out is that the user should have their
own
> keys. I do just that, and I use sbctl accordingly for both UKI images
and
> systemd-boot. This works well, also with sbsign instead of
> sbctl (the latter being unavailable as a package in Debian).
> 
> Unfortunately, one has to manually remember to sign the bootloader
> in the EFI partition after each re-install of the systemd-boot
package. 
> 
> Would it be possible to provide a configuration / script file so that
> one can sign the bootloader before installing it?

This should be doable with dpkg triggers. I haven't used them in years,
but IIRC it might be doable without any explicit change in systemd-
boot-efi, the packages providing the signing tools should be able to
register an interest in /usr/lib/systemd/boot/efi/ and do its stuff
when it is updated.

I am not going to work on this, anybody who is interested in this
should provide MRs to the appropriate packages.

-- 
Kind regards,
Luca Boccassi


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

Bug#1064133: systemd-resolved: Using systemd-resolved as drop-in replacements breaks in conjunction with ifupdown

[Luca Boccassi]

Control: tags -1 -upstream
Control: tags -1 wontfix
Control: close -1

On Sun, 3 Mar 2024 01:14:03 +0100 Felix Jacobi 
wrote:
> In my opinion, it should be possible to use systemd-resolved along
with 
> the original resolvconf again. This could re-allow using 
> systemd-resolved in cases, where the protocol specific identifiers
are 
> relevant (in conjunction with a custom resolvconf hook).
> 
> Maybe /usr/sbin/resolvconf could be managed with update-alternatives
or 
> the symlink from /usr/sbin/resolvconf to resolvectl could be shipped
in 
> a separate package?

Sorry, but the current setup is very much intentional. There is not
going to be yet-another-package, and there is not going to be update-
alternatives, which is an unholy mess. If you want to use sd-resolved,
just don't bother with ifupdown - there is no reason to use that in
2024, for headless systems use networkd and for GUI systems use
network-manager.

-- 
Kind regards,
Luca Boccassi


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

Bug#1053443: automount should not act if filesystem is already mounted

[Marc Haber]

On Sun, May 26, 2024 at 05:53:01PM +0100, Luca Boccassi wrote:
> So yeah, not going to risk this for the benefit of a non-default
> package with 0.19% popcon, sorry. Feel free to document the workaround
> and link to this bug as you see fit. I'd recommend noting the FS
> corruption issues too, but that's up to you of course.

I just suggested the automounter to not try to mount a filesystem that
is already there. I am not a systemd expert, but that should be a
minimally invasive oneliner, not changing other system's behavior,
shouldn't it?

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1053443: automount should not act if filesystem is already mounted

[Luca Boccassi]

On Sun, 26 May 2024 at 17:37, Marc Haber
 wrote:
>
> On Sun, May 26, 2024 at 04:57:10PM +0100, Luca Boccassi wrote:
> > I am pretty sure this is working as intended, we do not want the ESP to
> > be always mounted by default. You can disable this generator in
> > multiple ways if you don't want this behaviour - via the cmdline as
> > already mentioned, or by masking it with:
> >
> > touch /etc/systemd/system-generators/systemd-gpt-auto-generator
>
> Okay, this is then going as documentation into aide's systemd rule in
> Debian with a link to this bug report.
>
> Thanks for being a friendly neighbor to other packages.

It is a well known issue that keeping the ESP persistently mounted
causes filesystem corruption which means boot failures, because FAT32
is what it is. They do it on Fedora for example, and it is a constant
source of problems:
https://bugzilla.redhat.com/show_bug.cgi?id=1077984

So yeah, not going to risk this for the benefit of a non-default
package with 0.19% popcon, sorry. Feel free to document the workaround
and link to this bug as you see fit. I'd recommend noting the FS
corruption issues too, but that's up to you of course.

Bug#1039896: systemd: Please consider enabling the BPF_FRAMEWORK config

[Luca Boccassi]

Control: close -1 256~rc1-1

On Thu, 24 Aug 2023 11:45:41 +0200 Michael Biebl 
wrote:
> On Thu, 29 Jun 2023 11:24:33 +0100 Luca Boccassi 
wrote:
> > On Thu, 29 Jun 2023 10:16:19 + undef 
wrote:
> > > Package: systemd
> > > Version: 252.6-1
> > > Severity: wishlist
> > > X-Debbugs-Cc: Undef 
> > > 
> > > Dear Maintainer,
> > > 
> > > This config, enabled by adding `-DBPF_FRAMEWORK=true` would allow
> > settings such as 
> > > `IPAddressAllow` and RestrictFileSystems` to be used to harden
> > services on Debian systems.
> > > 
> > > `CONFIG_BPF_LSM` seems to already be enabled in Debian's kernels
so
> > in theory the only 
> > > change required should be adding the above setting to the Systemd
> > build.
> > 
> > We intentionally kept it disabled as libbpf broke API and ABI
recently,
> > and we don't want to be caught in the crossfire here, we need
stable
> > interfaces.
> > Further in the trixie dev cycle we can see what the situation is,
and
> > whether compatibility was maintained or it broke again, and re-
> > evaluate.
> 
> Nod, being a bit more cautious and letting libbpf development settle
a 
> bit seems like a reasonable idea.

A year later and things seems to have settled now, and there are more
and more features needing this (like the nsresourced stuff), so it is
now enabled.

-- 
Kind regards,
Luca Boccassi


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

Bug#1071321: libdumbnet: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file

[Bastian Germann]

I am uploading a NMU to fix this. Please find the debdiff attached.diff -Nru libdumbnet-1.18.0/debian/changelog libdumbnet-1.18.0/debian/changelog
--- libdumbnet-1.18.0/debian/changelog  2024-03-10 12:11:12.0 +
+++ libdumbnet-1.18.0/debian/changelog  2024-05-26 16:35:47.0 +
@@ -1,3 +1,10 @@
+libdumbnet (1.18.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Drop strlcat/strlcpy from symbols (Closes: #1071321)
+
+ -- Bastian Germann   Sun, 26 May 2024 16:35:47 +
+
 libdumbnet (1.18.0-1) unstable; urgency=medium
 
   * [9f0ff73] New upstream version 1.18.0
diff -Nru libdumbnet-1.18.0/debian/libdumbnet1.symbols 
libdumbnet-1.18.0/debian/libdumbnet1.symbols
--- libdumbnet-1.18.0/debian/libdumbnet1.symbols2023-10-17 
15:20:59.0 +
+++ libdumbnet-1.18.0/debian/libdumbnet1.symbols2024-05-26 
16:27:29.0 +
@@ -93,8 +93,6 @@
  route_get@Base 1.8
  route_loop@Base 1.8
  route_open@Base 1.8
- strlcat@Base 1.8
- strlcpy@Base 1.8
  tun_close@Base 1.11
  tun_fileno@Base 1.11
  tun_name@Base 1.11

Bug#902942: systemd: please ship man/*.xml files

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Tue, 03 Jul 2018 13:54:56 +0200 Dominique Dumont 
wrote:
> Package: systemd
> Version: 239-3
> Severity: wishlist
> 
> Dear Maintainer,
> 
> libconfig-model-systemd-perl provides a model so that cme command can
> check or edit some systemd configuration files. [1]
> 
> This systemd model is generated [2] from the systemd documentation
provided
> in man/*.xml (man pages are not used because they are much harder to
parse)
> 
> Currently this model is generated upstream and the generated model is
> shipped in the source tarball [3] of libconfig-model-systemd-perl.
> 
> To be compliant with Debian policy, libconfig-model-systemd-perl
package
> should:
> * drop systemd model from upstream tarball
> * regenerate systemd model from systemd xml files
> 
> The latter should be done using xml files shipped as binary package,
> either in systemd package (along the man pages) or in a systemd-
source
> package.
> 
> Could you ship these xml file in a binary package ?
> 
> All the best
> 
> [1]
https://github.com/dod38fr/config-model/wiki/Managing-systemd-configuration-with-cme
> [2]
https://github.com/dod38fr/config-model-systemd/blob/master/contrib/parse-man.pl
> [3]
https://cpan.metacpan.org/authors/id/D/DD/DDUMONT/Config-Model-Systemd-0.238.2.tar.gz

The manpages sources are an internal implementation details. They are
xml fed into docbook at the moment, but this is not a stable interface,
and in fact we are likely going to change to a different format. So it
is not advisable to build functionality to rely on them. If you really
want to, you can fetch the source package using apt, but I recommend
against it.

-- 
Kind regards,
Luca Boccassi


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

Bug#1069859: atop: Fix atop for 64-bit time_t on arm

[Steve Langasek]

On Sun, May 26, 2024 at 06:12:50PM +0200, Marc Haber wrote:
> I am not too fond about the suggested patch since it breaks atop on
> systems with 32bit time_t,

It does not: promoting the time_t to a long long on all architectures before
passing it as an argument to the format string is portable to all (existing)
architectures.  Either sizeof(time_t) == sizeof(long long) and the cast is a
no-op, or sizeof(time_t) < sizeof(long long) and this is merely a signed
extension operation.

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


signature.asc
Description: PGP signature

Bug#1066575: kakasi: diff for NMU version 2.3.6-4.2

[gregor herrmann]

Control: tags 1066575 + patch
Control: tags 1066575 + pending


Dear maintainer,

I've prepared an NMU for kakasi (versioned as 2.3.6-4.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
diff -Nru kakasi-2.3.6/debian/changelog kakasi-2.3.6/debian/changelog
--- kakasi-2.3.6/debian/changelog	2021-01-03 12:25:42.0 +0100
+++ kakasi-2.3.6/debian/changelog	2024-05-26 18:34:15.0 +0200
@@ -1,3 +1,12 @@
+kakasi (2.3.6-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "FTBFS: configure: error: can not use EUC-JP or UTF-8 encoding
+on iconv": add patch kakasi-configure-c99.patch from Fedora.
+(Closes: #1066575)
+
+ -- gregor herrmann   Sun, 26 May 2024 18:34:15 +0200
+
 kakasi (2.3.6-4.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru kakasi-2.3.6/debian/patches/kakasi-configure-c99.patch kakasi-2.3.6/debian/patches/kakasi-configure-c99.patch
--- kakasi-2.3.6/debian/patches/kakasi-configure-c99.patch	1970-01-01 01:00:00.0 +0100
+++ kakasi-2.3.6/debian/patches/kakasi-configure-c99.patch	2024-05-26 18:34:08.0 +0200
@@ -0,0 +1,20 @@
+Origin: https://src.fedoraproject.org/rpms/kakasi/blob/rawhide/f/kakasi-configure-c99.patch
+Bug-Debian: https://bugs.debian.org/1066575
+
+Avoid an implicit declaration of exit and build failures with future
+compilers which do not support implicit function declarations by
+default.
+
+diff --git a/configure.in b/configure.in
+index e865b04ffd027f3c..4a15beffd0e252a4 100644
+--- a/configure.in
 b/configure.in
+@@ -85,7 +85,7 @@ AS_VAR_IF(utf8, "yes",[
+ LIBS="$LIBICONV $LIBS"
+ AC_DEFINE(KAKASI_SUPPORT_UTF8, 1, [KAKASI_SUPPORT_UTF8])
+ AC_RUN_IFELSE([AC_LANG_PROGRAM([#include ],
+-		[if (iconv_open("EUC-JP", "UTF-8") == -1) exit(1);])],
++		[if (iconv_open("EUC-JP", "UTF-8") == -1) return 1;])],
+ 	[],
+ 	[AC_MSG_ERROR([can not use EUC-JP or UTF-8 encoding on iconv])])
+ ])
diff -Nru kakasi-2.3.6/debian/patches/series kakasi-2.3.6/debian/patches/series
--- kakasi-2.3.6/debian/patches/series	2018-12-02 10:10:55.0 +0100
+++ kakasi-2.3.6/debian/patches/series	2024-05-26 18:30:47.0 +0200
@@ -1,2 +1,3 @@
 0003-prefix.patch
 0004-multiarch.patch
+kakasi-configure-c99.patch


signature.asc
Description: Digital Signature

Bug#1053443: automount should not act if filesystem is already mounted

[Marc Haber]

On Sun, May 26, 2024 at 04:57:10PM +0100, Luca Boccassi wrote:
> I am pretty sure this is working as intended, we do not want the ESP to
> be always mounted by default. You can disable this generator in
> multiple ways if you don't want this behaviour - via the cmdline as
> already mentioned, or by masking it with:
> 
> touch /etc/systemd/system-generators/systemd-gpt-auto-generator

Okay, this is then going as documentation into aide's systemd rule in
Debian with a link to this bug report.

Thanks for being a friendly neighbor to other packages.


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1069859: atop: Fix atop for 64-bit time_t on arm

[Marc Haber]

Control: tags -1 confirmed
Control: forwarded -1 https://github.com/Atoptool/atop/issues/306
thanks

thanks for spotting and debugging this.

On Thu, Apr 25, 2024 at 02:16:33PM -0700, Steve Langasek wrote:
> Although atop currently builds successfully on armhf and armel, it is broken
> at runtime because it tries to use a time_t in a format string which now no
> longer uses the correct size for the data.  This was found in Ubuntu via
> autopkgtests (unfortunately, Debian does not run autopkgtests for binNMUs):

At least this superficial test did its job to uncover this issue. I'm
quite happy about that.

I can reproduce the issue and disagree with the classification as an RC
bug. THe normal atop usage doesn't seem affected, only the -P option is
broken. This doesnt make the package unustable for everbody.

My apologies for letting this lay for a month, I was busy elsewhere in
my life.

I am not too fond about the suggested patch since it breaks atop on
systems with 32bit time_t, which is not nice to backporters. I have
asked Upstream whether they would be up for a less invasive fix. I
intend to let this rest until the middle of the next week.

Greetings
Marc

Bug#1071964: Elogind defaults to s2idle

[Juliusz Chroboczek]

Filed upstream at https://github.com/elogind/elogind/issues/285.

Bug#1071967: libdata-fake-perl: Test failures on 32bit architectures

[gregor herrmann]

Source: libdata-fake-perl
Version: 0.006-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source
Forwarded: https://github.com/dagolden/Data-Fake/issues/15

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

t/dates.t fails on i386, looks like time_t 32 bit issues (via
Time::Piece's strptime).

https://ci.debian.net/packages/libd/libdata-fake-perl/testing/i386/46574760/#S6


Cf. https://github.com/dagolden/Data-Fake/issues/15

This (autopkgtest) failure blocks migration to testing, and also
appears during build in an i386 chroot.


Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmZTXwRfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbqUQ//alYyFmLcn9TQX4DJghlWRA07qlL7FkHwlYz7MTKzZwDGwNVkKV2vMDys
X+bI0nT57TNX/QTsxBQZ5CbAeOIRkefd/J7unE5+LSvdnXJN0P80gxcL0Oja0T7Q
dvieqShF7xll2h0y/D2swB+6GCTQZngfo6wx8ty6OG3pFAu2zaXL0sNiUvkjEMA1
vwi8/jEy2f5tz+PFJULS0SQfkcsf3dSzTBWJe8xjANOTithBzyPqbe3NI5A2Dk+F
icAw90oOKotgciTHm2qufpp+AtCDr+QJQOaa085KiGleVwk0HSIoInZsriH6Hoxj
E2buKvrMQSZ3EqfziS5u7EILnikV+ihGU27ZLbDTNPnIqsUmETRa5WNlRfC0PSu3
n0o6nCWp8lSpXsV4VafXDHwaQQyzjkzHH69UrQWUYLVC2CvG3hG5TW2of+UGa0aq
zpmgI/GVjVmbD6Lpga6t5Ni+4RcPSTSXfIIf4dJCYCQZmEhmqJrvMxbuSIehaH1r
BfggsEjrk8QBoDpcCGGcUJQCFBMEX7pbBJVnTg6mQowKZvc8Qj6ELvPZREvEpm4N
jcbD/aD6m1VsTtP1aSoEDrkD8qdJzmrV0bsAy90zyR1TNl1HLyzl6eKvBWG08C8m
4I3gIY+ADEWTNYhr+yjn5LaXDEuWNHnONeN/32Bzmxlqjyn5MMw=
=nwHw
-END PGP SIGNATURE-

Bug#1050256: AppArmor breaks locking non-fs Unix sockets

[Luca Boccassi]

On Sun, 26 May 2024 13:39:07 +0200 Salvatore Bonaccorso
 wrote:
> Hi,
> 
> For those watching this bug: John has prepared backports in his tree,
> with both approaches:
> 
>
https://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor.git/log/?h=debian-two-patch-1780227
> 
> and
> 
>
https://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor.git/log/?h=debian-backport-1780227
> 
> (but with the open question which one will be submitted for stable.
> From upstream stable point of view probably the two patch backport
> approach would be the preferred one).

Very nice, thank you!

In the meanwhile, I found a way to reliably detecting this and
gracefully skipping it in systemd, so debci is now fixed. However, it
still results in PrivateNetwork= being quietly disabled, so the
backport is still very much needed, as it is a useful security feature.

-- 
Kind regards,
Luca Boccassi


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

Bug#1068591: systemd-container: doesn't list a default package for default-dbus-system-bus dependency

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Mon, 8 Apr 2024 09:21:32 +0200 =?UTF-8?Q?Rapha=C3=ABl_Halimi?=
 wrote:
> Le 07/04/2024 à 19:34, Michael Biebl a écrit :
> > As you correctly noticed, this is a bug/fault in debootstrap.
> > I don't think individual packages should work around that, so I'm 
> > included to close this as wontfix (or reassign/merge to
debootstrap).
> 
> Fair enough, I understand. Do you want me to reassign it ?
> 
> > Fwiw, you might use an alternative debootstrap tool like mmdebstrap
> > which works properly in that regard.
> 
> I didn't know about this tool. Thanks for the tip :)

Yes this is a known debootstrap issue, and we don't want to workaround
it here. Also, I am not sure the systemd-container package is actually
needed _inside_ the container, as it provides tools and services to run
containers _on the host_.

-- 
Kind regards,
Luca Boccassi


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

Bug#1053443: automount should not act if filesystem is already mounted

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Wed, 4 Oct 2023 20:51:57 +0200 Marc Haber
 wrote:
> On Wed, Oct 04, 2023 at 08:41:10PM +0200, Michael Biebl wrote:
> > Do you both /efi *and* /boot/efi
> > 
> > The automount unit is for efi.automount
> 
> No, just /boot/efi, but the aide run triggers the automount, which
> affects for some strange reason /boot/efi and makes the inode numbers
> change.

I am pretty sure this is working as intended, we do not want the ESP to
be always mounted by default. You can disable this generator in
multiple ways if you don't want this behaviour - via the cmdline as
already mentioned, or by masking it with:

touch /etc/systemd/system-generators/systemd-gpt-auto-generator

-- 
Kind regards,
Luca Boccassi


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

Bug#779207: patch submission for improving code pages support in unzip

[Ivan Sorokin]

Dear colleagues,
 
I am writing to bring to your attention an issue with the current upstream 
version of unzip that has not been updated for many years. In the modern 
environment, where the vast majority of systems use UTF-8, unzip exhibits 
several problems that need addressing:
 
1) unzip is unable to correctly extract files containing the bit 11 in the 
General Purpose flag. This bit indicates that the file names are encoded in 
UTF-8. However, unzip attempts to re-encode them as if they are in OEM 
codepage, leading to incorrect file names.
2) By default, unzip does not display UTF-8 encoding correctly on Unix systems.
3) It is necessary to determine the OEM codepage correctly based on the system 
locale, rather than using a single codepage for all archives.
4) The assumption that archives for which the legacy codepage cannot be 
determined are encoded in ISO 8859-1 is incorrect. In reality, most archivers 
used the user's system codepage, which could be any codepage. It is reasonable 
not to alter the encoding in this case, ensuring that the archive can be opened 
at least on the same system where it was created. Additionally, options -O and 
-I have been added to specify the encoding manually.
 
I have prepared a patch (based on a similar patch from Ubuntu, with significant 
enhancements) that addresses these issues. A significant difference from the 
Ubuntu patch is that my code is capable of selecting the OEM codepage based on 
the system locale, instead of assuming the Russian/Cyrillic CP866 codepage for 
all archives when the system is set to UTF-8.
 
I hope you will find this patch useful.
 
Best regards,
Ivan Sorokin
 
 From: Giovanni Scafora 
Subject: unzip files encoded with non-latin, non-unicode file names
Last-Update: 2024-02-22

* Updated 2015-02-11 by Marc Deslauriers 
  to fix buffer overflow in charset_to_intern()
* Updated 2023-06-15 by Dominik Viererbe 
  to add documentation for `-I` and `-O` options (LP: #138307) and fixed
  garbled output when `zipinfo` or `unzip -Z` is called without arguments
  (LP: #1429939)
* Updated 2024-05-26 by Ivan Sorokin 
  to fix several problems in codepages support:
  1) Fixed bit 11 of General purpose flag support on systems with UTF-8
  system charset
  2) Fixed OEM code page being always assumed Russian/Cyrillic CP866
  on any UTF-8 system
  3) Added proper OEM code page detection based on system locale setting
  4) Removed translation from ISO 8859-1 to local charset;
  assumption that any non-unicode archive uses it is for sure wrong
  as it can be any charset used on archive creator's local system;
  also do not treat PKZIP for UNIX 2.51 archives
  as having ISO 8859-1 charset for the same reasons
  5) Enabled UTF-8 output by default on Unix systems

--- a/INSTALL
+++ b/INSTALL
@@ -480,7 +480,7 @@ To compile UnZip, UnZipSFX and/or fUnZip (detailed instructions):
   NO_WORKING_ISPRINT
 The symbol HAVE_WORKING_ISPRINT enables enhanced non-printable chars
 filtering for filenames in the fnfilter() function.  On some systems
-(Unix, VMS, some Win32 compilers), this setting is enabled by default.
+(VMS, some Win32 compilers), this setting is enabled by default.
 In cases where isprint() flags printable extended characters as
 unprintable, defining NO_WORKING_ISPRINT allows to disable the enhanced
 filtering capability in fnfilter().  (The ASCII control codes 0x01 to
--- a/fileio.c
+++ b/fileio.c
@@ -2144,9 +2144,15 @@ int do_string(__G__ length, option)   /* return PK-type error code */
 /* translate the text coded in the entry's host-dependent
"extended ASCII" charset into the compiler's (system's)
internal text code page */
-Ext_ASCII_TO_Native((char *)G.outbuf, G.pInfo->hostnum,
-G.pInfo->hostver, G.pInfo->HasUxAtt,
-FALSE);
+#if (defined(UNICODE_SUPPORT) && defined(UTF8_MAYBE_NATIVE))
+if (!G.pInfo->GPFIsUTF8 || !G.native_is_utf8) {
+#endif
+Ext_ASCII_TO_Native((char *)G.outbuf, G.pInfo->hostnum,
+G.pInfo->hostver, G.pInfo->HasUxAtt,
+FALSE);
+#if (defined(UNICODE_SUPPORT) && defined(UTF8_MAYBE_NATIVE))
+}
+#endif
 #ifdef WINDLL
 /* translate to ANSI (RTL internal codepage may be OEM) */
 INTERN_TO_ISO((char *)G.outbuf, (char *)G.outbuf);
@@ -2258,8 +2264,14 @@ int do_string(__G__ length, option)   /* return PK-type error code */
 
 /* translate the Zip entry filename coded in host-dependent "extended
ASCII" into the compiler's (system's) internal text code page */
-Ext_ASCII_TO_Native(G.filename, G.pInfo->hostnum, G.pInfo->hostver,
-G.pInfo->HasUxAtt, (option == DS_FN_L));
+#if (defined(UNICODE_SUPPORT) && 

Bug#913061: systemd: stop shipping /bin/systemd

[Luca Boccassi]

Control: tags -1 pending
Control: unblock -1 by 940051 940050

On Sat, 9 Nov 2019 02:36:20 +0100 Michael Biebl 
wrote:
> Hi Ansgar
> 
> On Thu, 12 Sep 2019 09:00:12 +0200 Ansgar  wrote:
> > Ben Hutchings writes:
> > > On Wed, 2019-09-11 at 19:20 +0200, Ansgar wrote:
> > >> would it be possible to add a fallback to try
/lib/systemd/systemd if
> > >> the user provided init=/bin/systemd and the file no longer
exists?
> > >> 
> > >> I would like systemd to stop shipping the /bin/systemd symlink
as this
> > >> should not be run by users, however it was suggested to use
> > >> init=/bin/systemd for testing purposes in the past (see below). 
So just
> > >> removing the symlink might make some systems unbootable.
> > >
> > > I don't think it's appropriate for the initramfs to do this sort
of
> > > magic.  Even if they did, this wouldn't cover systems using a
custom
> > > kernel that doesn't need an initramfs.
> > >
> > > I think that a better way to handle this would be for systemd
itself to
> > > warn on upgrade if /proc/cmdline contains init=/bin/systemd.
> > 
> > The problem is that many people don't read warning or don't react
on
> > them right away.  So I would prefer if we had an additional safety
net.
> > If this wouldn't result in unbootable systems, I agree that a
warning
> > would be sufficient.
> 
> Since Ben was against adding such a fallback to initramfs-tools, we
> either need a different solution or continue to ship the symlink.
> 
> I wonder whether aborting in preinst is acceptable or not. A warning
> message probably won't cut it.

This compat symlink has been around for many years, and documentation
has long since been updated. Given the initrd tools are not going to
add checks, I will just drop it now. Any user still setting manually
init=/bin/systemd will just have to fix their local configuration after
they notice the breakage. The systemd binary should most definitely not
be in the default PATH, and that is more important than supporting
hypothetical broken and unsupported local-only changes.

-- 
Kind regards,
Luca Boccassi


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

Bug#1005815: bootup.7 says initramfs is created by dracut

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Tue, 15 Feb 2022 21:27:58 +0100 Michael Biebl 
wrote:
> Hi Marc
> 
> Am 15.02.22 um 16:36 schrieb Marc Haber:
> > the manpage bootup(7) says that the initramfs is often created by
> > dracut(8). This might be true in the Red Hat world, but not on
Debian.
> > This wording should be patched in the Debian package.
> 
> We had this in the past, like e.g. in [1]. But I'm still not
convinced 
> that we should be starting to patch the man pages. I want less Debian
> specific patches not more and this would be one which we'd never get
rid 
> off again. A maintenance nightmare in the long run.
> 
> Strictly speaking, in this specific instance, the man pages aren't
even 
> incorrect, they just don't go into Debian specific details.
> I don't think it's worth patching that.

Yeah we should not patch manpages like this. You can use dracut in
Debian, a few people do, so it is technically correct.

-- 
Kind regards,
Luca Boccassi


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

Bug#1071966: python-ironic-inspector-client: please remove extraneous dependency on python3-mock

[Alexandre Detiste]

Source: python-ironic-inspector-client
Version: 5.1.0-3
Severity: normal

Dear Maintainer,

This package has switched to unittest.mock.

Greetings

tchet@quieter:/tmp/python-ironic-inspector-client$ grep mock -r | grep -e 
import -e debian
debian/control: python3-mock,
debian/control: python3-requests-mock,
ironic_inspector_client/tests/functional.py:from unittest import mock
ironic_inspector_client/tests/unit/test_common_http.py:from unittest import mock
ironic_inspector_client/tests/unit/test_shell.py:from unittest import mock
ironic_inspector_client/tests/unit/test_v1.py:from unittest import mock
tchet@quieter:/tmp/python-ironic-inspector-client$

Bug#1063571: libpcre3: move libraries to /usr (DEP17)

[Matthew Vernon]

Hi,

On 25/05/2024 21:43, Chris Hofstaedtler wrote:

On Fri, Feb 09, 2024 at 04:23:27PM +0100, Helmut Grohne wrote:

Package: libpcre3

[..]

we want to finalize the /usr-merge transition by moving all aliased
files from / to /usr via DEP17 to avoid any negative effects arising
from aliasing. libpcre3 is involved, because installs a shared library
below /lib.

[..]

Are you going to remove libpcre3 from trixie? If not, do you want an
NMU for this or are you going to upload it soon?


I really, truly, do not want to be shipping pcre3 in trixie.

There are 33 unfixed packages[0], so I think this is reasonable (if 
nothing else, I don't believe any of the remainder are showstoppers).


Regards,

Matthew

[0] 
https://docs.google.com/document/d/19IHP-WSOuEuSwgYkeww2VPuiGE0Q25X7/edit?usp=sharing=114425588045217704299=true=true

Bug#1060018: systemd: broken kernel log messages on virtual console

[Luca Boccassi]

Control: close -1

On Sat, 20 Jan 2024 20:45:15 +0100 Michael Biebl 
wrote:
> Control: tags -1 + moreinfo unreproducible
> 
> On Thu, 04 Jan 2024 22:32:42 +0200 dweller 
wrote:
> > I am including images that show the corruption (related to numbers
in brackets).
> > What other information can I provide to help you in identifying the
problem?
> 
> Ideally you can provide a minimal reproducer.
> Say start from minimal Debian stable installation (in a VM) and then 
> provide the necessary steps how we can trigger this issue.
> 
> My guess is, that this is an issue specific to your local
configuration 
> (fonts, locale, keyboard etc).
> 
> I've never seen an issue like this and haven't found anything in the
bug 
> stream bug tracker at https://github.com/systemd/systemd/issues that 
> looks related.
> 
> What you can also try is to install the systemd v254 version from 
> bookworm-backports.
> https://backports.debian.org/Instructions/

No follow-up in half a year, unreproducible, closing.

-- 
Kind regards,
Luca Boccassi


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

Bug#1059899: systemd-resolved: systemd-resolved takes up all memory on certain PTR queries and is then oom-killed

[Luca Boccassi]

Control: close -1

On Sat, 20 Jan 2024 20:52:20 +0100 Michael Biebl 
wrote:
> Hi Corin
> 
> 
> On Wed, 03 Jan 2024 12:50:13 +0100 Luca Boccassi 
wrote:
> > Control: severity -1 normal
> > Control: tags -1 moreinfo
> > 
> > On Wed, 03 Jan 2024 12:02:40 +0100 Corin Langosch 
> > wrote:
> > > Package: systemd
> > > Version: 247.3-7+deb11u4
> > > Severity: critical
> > > File: systemd-resolved
> > > Justification: breaks the whole system
> > 
> > Your logs show that it restarts just fine after the oom kill, so it
is
> > most definitely not "grave". Also, you did not attach your local
> > resolved.conf.
> > 
> > Also, oldstable is old. Try with backports or with upgrading to
stable.
> 
> Any updates here? Did you have the chance to reproduce this with at 
> least stable, i.e. v252. Even better would be, if you can try with
v254 
> from bookworm-backports.
> 
> So far I failed to reproduce the issue with the given information.
> 
> $ host 54.49.125.74.in-addr.arpa
> Host 54.49.125.74.in-addr.arpa not found: 3(NXDOMAIN)
> 
> That is all I get.

No follow-up in half a year, closing.

-- 
Kind regards,
Luca Boccassi


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

Bug#1055830: systemd in a container fails to set up mount namespacing

[Luca Boccassi]

Control: close -1 255.4-1

On Sat, 2 Mar 2024 13:51:48 +0100 Christian Horn 
wrote:
> Hello,
> 
> thank you for commenting.
> 
> On Wed, Feb 28, 2024 at 07:02:10PM +0100, Michael Biebl wrote:
> > 
> > On Sun, 12 Nov 2023 11:15:45 +0100 Christian Horn

> > wrote:
> > > Package: systemd
> > > Version: 252.17-1~deb12u1
> > > Severity: important
> > > [..]
> > 
> > From the provided information it is not obvious that this is
actually a
> > systemd issue. It could be the kernel or any of the dependencies
systemd
> > relies on or even redis itself.
> > 
> > In any case, if you think this is a systemd issue, we would need
further
> > information how to fix this.
> 
> The issue still exists with the latest bookworm packages in the
container.
> Updating then 'redis' in the container to the trixie version does not
> change the issue, update of package systemd pulls in these packages:
>   libsystemd-shared libsystemd0 libudev1 
>   libzstd1 systemd systemd-timesyncd
> ..and afterwards redis can be started.
> 
> Just in case it helps someone else, reproducer details:
> ```
> # On a Fedora 39 host with podman installed, as user:
> mkdir build-bookworm/
> cat >build-bookworm/Containerfile< FROM docker.io/library/debian:bookworm
> ENV DEBIAN_FRONTEND noninteractive
> RUN apt update && apt upgrade -y && apt install -y sudo systemd
procps redis
> CMD [ "/lib/systemd/systemd" ]
> EOT
> podman build -t repro build-bookworm/
> podman run --name repro -d \
>   --security-opt seccomp=unconfined --hostname repro \
>   localhost/repro /lib/systemd/systemd
> podman exec -it repro bash
> # Now in the container
> systemctl start redis
> > Job for redis-server.service failed because the [..]
> > See "systemctl status redis-server.service" and [..]
> ```
> 
> There were no further comments from others on this bug, I guess
> it's not widely hit.  I work around it now and do not plan to look
> deeper, in Trixie it also does not exist.

There are no patches downstream that could affect that behaviour as far
as I am aware, and given it's fixed in testing I'll close this now.

-- 
Kind regards,
Luca Boccassi


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

Bug#973287: systemd autopkgtest-virt-lxc failure on arm64

[Luca Boccassi]

Control: close -1

On Fri, 27 Nov 2020 10:07:42 +0100 Michael Biebl 
wrote:
> Am Freitag, den 27.11.2020, 17:40 +0900 schrieb Ryutaroh Matsumoto:
> > 
> > I have little idea which package is missing/required in this
context.
> > What I see is that, when only "Priority: required" packages are
> > installed
> > to autopkg VM, at some point systemd test scripts start failing to
> > look up hostnames,
> > and http://deb.debian.org becomes unable to be found.
> > /etc/resolv.conf seems destroyed...
> > This symptom does not appear when "Priority: important" packages
are
> > installed.
> > This is also observed on amd64 QEMU testbed, and not specific to
> > arm64.
> 
> That sounds like your autopkgtest images do not have network/internet
> access (probably due to missing ifupdown).
> Which test specifically is failing?
> 
> See also section "Network access" in
> /usr/share/doc/autopkgtest/README.package-tests.rst.gz
> 
> I'm not entirely sure if we actually need unrestricted internet
access
> or if you are simply missing access to an apt proxy.
> If simply apt fails, I wouldn't consider this a bug in the test but
> rather in how your test image/environment is setup.

arm64 autopkgtest runs work as expected on debci (lxc) and on ubuntu ci
(qemu) these days, hence closing as unreproducible.

-- 
Kind regards,
Luca Boccassi


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

Bug#707624: winbind: winbind does not recover from DC reboot etc.

[Michael Tokarev]

Version: 2:4.8.1+dfsg-1

This issue has been fixed in 4.8.1 but the bug report is still open.
Let's close it finally.

/mjt
--
GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 
ECDF 2C8E
Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 
8044 65C5
Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt

Bug#1053741: systemd-journal-remote: systemd-joural-uploading killed by watchdog every 3 minutes

[Luca Boccassi]

Control: close -1

On Sat, 18 Nov 2023 22:06:47 +0100 Michael Biebl 
wrote:
> Control: tags -1 moreinfo
> On Tue, 31 Oct 2023 10:36:36 +0100 Michael Biebl 
wrote:
> > Am 10.10.23 um 04:22 schrieb Tom Cameron:
> > 
> > > I have also looked at the systemd issue tracker on github, and
while
> > > there has historically be several issues with journal-upload,
none of
> > > them seem to have been reported recently.
> > 
> > Could you please raise this upstream and report back with the issue
number?
> 
> 
> Any updates here?
> Without further information, this issue is not really actionable.

No follow-up in half a year, closing.

-- 
Kind regards,
Luca Boccassi


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

Bug#859092: systemd-resolved : does not return fully qualified host name for local host name

[Luca Boccassi]

Control: close -1

On Tue, 5 Jul 2022 20:24:43 +0200 Michael Biebl 
wrote:
> Control: tags -1 + moreinfo upstream
> 
> On Thu, 30 Mar 2017 10:38:45 +0200 Laurent Bonnaud 
>  wrote:
> > Package: systemd
> > Version: 233-5
> > 
> > 
> > Dear maintainer,
> > 
> > here are 2 DNS queries that illustrate the problem:
> > 
> >  - when I query a "real" DNS server (bind) I get the expected
answer "irancy.iut2.upmf-grenoble.fr"
> > 
> >  - when I query systemd-resolved I get the short answer "irancy"
> > 
> > root@irancy:~# host 192.168.141.13 193.55.51.34
> > Using domain server:
> > Name: 193.55.51.34
> > Address: 193.55.51.34#53
> > Aliases:
> > 
> > 13.141.168.192.in-addr.arpa domain name pointer irancy.iut2.upmf-
grenoble.fr.
> > 
> > root@irancy:~# host 192.168.141.13 127.0.0.53
> > Using domain server:
> > Name: 127.0.0.53
> > Address: 127.0.0.53#53
> > Aliases:
> > 
> > 13.141.168.192.in-addr.arpa domain name pointer irancy.
> > 
> > 
> > This a problem for apache who complains about its ServerName.
> > 
> 
> 
> In case you can still reproduce the issue with an up-to-date version
of 
> systemd (i.e. v250 or v251), please report this upstream at
> https://github.com/systemd/systemd/issues

No follow-up in 7 years, closing.

-- 
Kind regards,
Luca Boccassi


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

Bug#1071965: gnocchi: please remove extraneous python3-mock build dependency

[Alexandre Detiste]

Source: gnocchi
Version: 4.5.0-5
Severity: normal

Dear Maintainers,

python3-mock is not used anymore.

Greetings


tchet@quieter:/tmp/gnocchi$ grep mock -r | grep -e import -e debian
debian/control: python3-mock,
gnocchi/tests/indexer/sqlalchemy/test_migrations.py:from unittest import mock
gnocchi/tests/test_aggregates.py:from unittest import mock
gnocchi/tests/test_amqp1d.py:from unittest import mock
gnocchi/tests/test_indexer.py:from unittest import mock
gnocchi/tests/test_measures_grouper.py:from unittest import mock
gnocchi/tests/test_rest.py:from unittest import mock
gnocchi/tests/test_statsd.py:from unittest import mock
gnocchi/tests/test_storage.py:from unittest import mock
gnocchi/tests/test_utils.py:from unittest import mock
tchet@quieter:/tmp/gnocchi$ 

Bug#1071964: Elogind defaults to s2idle

[Juliusz Chroboczek]

Package: elogind
Version: 255.5-1debian1

Hi,

At some point, elogind changed the behaviour of the suspend key to use
s2idle in preference to deep sleep.  On my laptop (Latitude 7390), the
time in suspend on a full battery dropped from a few days to just over one
day.

The fix was to add the following to /etc/elogind/sleep.conf:

SuspendMode=deep s2idle

Please change the default to deep sleep on systems on which it is
available, as s2idle brings no benefits to the user but has bad power
consumption on many older systems.

Thanks.

Bug#1071963: RM: oci-seccomp-bpf-hook [ppc64el] -- RoQA; FTBFS on ppc64el

[Domenico Andreoli]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: team+pkg...@tracker.debian.org

As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070768,
bpfcc/0.29.1+ds-1.1 recently dropped support for ppc64el.

I uploaded a new version of oci-seccomp-bpf-hook too soon and it was
built also for ppc64el. Now this is preventing the migration to testing.

Please remove the oci-seccomp-bpf-hook ppc64el.

Thanks,
Domenico

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05


signature.asc
Description: PGP signature

Bug#969714: systemd-localed creates /etc/vconsole.conf file when modifying keyboard layouts

[Luca Boccassi]

Control: tags -1 -patch
Control: close -1 253-1

On Mon, 07 Sep 2020 09:58:42 +0200 Roderich Schupp
 wrote:
> Package: systemd
> Version: 246.4-1
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: roderich.sch...@gmail.com
> 
> I added some keyboard layouts with gnome-control-center (tab "Region
&
> Language",
> "Input sources") and then found a file /etc/vconsole.conf, though
Debian
> disables the vconf stuff in systemd. The file seems to persist after
removing
> it and rebooting, but otherwise appears to be harmless.
> 
> The file is actually generated by systemd-localed (invoked by
> dbus from gnome-control-center), so you could probably achieve the
same
> effect by running localectl.

We have made writing console layouts via localectl a no-op some time
ago, so closing.

-- 
Kind regards,
Luca Boccassi


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

Bug#800388: PathChanged triggers too early, not just when file is closed

[Luca Boccassi]

Control: unblock 799782 by -1
Control: tags -1 upstream
Control: close -1

On Mon, 28 Sep 2015 20:27:17 +0200 Joachim Breitner
 wrote:
> Package: systemd
> Version: 226-3
> Severity: normal
> Control: block 799782 by -1
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi,
> 
> local-apt-repository ships with the following file:
> 
> $ cat /lib/systemd/system/local-apt-repository.path
> [Path]
> PathChanged=/srv/local-apt-repository
> 
> [Install]
> WantedBy=paths.target
> 
> If a process opens a not-yet-existing file in /srv/local-apt-
repository,
> starts writing and eventually closes it that systemd would activate
the
> corresponding service only after the close – at least that is my
reading
> of systemd.path(5).
> 
> This can be reproduced by installing local-apt-repository, and
running
> 
> $ pv -L 100 < .../some.deb > /srv/local-apt-repository/some.deb
> 
> and observing in the journal that dpkg-deb complains about an invalid
> file.
> 
> Is the documentation misleading me here, or is there a bug?
> 
> If it is not a bug: Would it be possible to provide the behaviour
that
> was hoping for here?
> 
> Thanks,
> Joachim

It looks like this was worked around a long time ago, and no updates
since. We do not patch nor reconfigure path units behaviour downstream,
so any issue with them needs to be tested in unstable on the latest
version and then reported upstream.

-- 
Kind regards,
Luca Boccassi


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

Bug#1071962: wput: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: wput
Version: 0.6.2+git20130413-12
Severity: normal
Tags: patch

wput build-depends on libgcrypt20-dev but afaict does not use
libgcrypt.

(sid)ametzler@argenau:/dev/shm/GCRY/wput-0.6.2+git20130413$ grep -rli gcryp
debian/changelog
debian/control
debian/patches/13-configure.in--gcrypt-link.patch
debian/patches/series
debian/autoreconf.before
debian/autoreconf.after
.pc/applied-patches
.pc/13-configure.in--gcrypt-link.patch/configure.in
configure~

cu Andreas

Bug#1069994: systemd-resolved: resolvectl dnssec failed for unsigned domains

[Luca Boccassi]

Control: close -1 256~rc2-1

On Fri, 3 May 2024 14:16:10 +0200 =?utf-8?Q?C=C3=A9dric?= Hannotier
 wrote:
> Dear Luca Boccassi, Dear Maintainers,
> 
> On Sun, 28 Apr 2024 11:42:11 +0100 Luca Boccassi 
wrote:
> > On Sun, 28 Apr 2024 11:53:17 +0200 Adrien CLERC
> >  wrote:
> > > Package: systemd-resolved
> > > Version: 255.5-1
> > > Severity: important
> > > 
> > > Dear Maintainer,
> > > 
> > > Since 255.5-1, resolvectl produces the following:
> > > 
> > > ❯ resolvectl query --validate=yes www.youtube.com
> > > www.youtube.com: resolve call failed: DNSSEC validation failed:
no-
> > signature
> > > 
> > > The domain is unsigned. It worked in 255.4-1+b1, but I'm unable
to
> > rollback,
> > > since it depends on libsystemd which makes a lot of package
unhappy
> > with
> > > dependencies.
> > > 
> > > Did I miss something?
> > > In the meantime, I'll use "DNSSEC=no", but that's not a
definitive
> > answer.
> > > 
> > > Have a nice day,
> > > Adrien
> > > 
> > 
> > There are no resolved patches downstream, report this upstream
> 
> It has been resolved upstream [1] but need backporting for now.
> I think commits to backports from upstream are:
> d840783db5208219c78d73b9b46ef5daae9fea0a
> 5237ffdf2b63a5afea77c3470d9981a2c29643cc
> 414a9b8e5e1e772261b0ffaedc853f5c0aba5719

These are all in unstable and about to migrate to testing, closing

-- 
Kind regards,
Luca Boccassi


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

Bug#1071961: mailcap: run-mailcap doesn't properly identifies magic types

[Yair Yarom]

Package: mailcap
Version: 3.70+nmu1.huji
Severity: normal
Tags: patch

Dear Maintainer,

The function MagicMimetype always fails because the `command -v file` isn't
executed inside a shell (rather, perl searches for the "command" binary, and
fails to find it).

Attached is a patch that fixes this. Somehow I think that `which` was
simpler... :-)

Regards,
Yair.

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

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

Versions of packages mailcap depends on:
ii  media-types  10.0.0
ii  perl 5.36.0-7+deb12u1

Versions of packages mailcap recommends:
ii  bzip2 1.0.8-5+b1
ii  file  1:5.44-3
ii  xz-utils  5.4.1-0.2

mailcap suggests no packages.

-- Configuration Files:
/etc/mailcap.order changed [not included]

-- no debconf information
--- a/run-mailcap
+++ b/run-mailcap
@@ -298,7 +298,7 @@
 my($file) = @_;
 my($typ);
 
-if (`command -v file`) {
+if (`command -v 'file'`) {
 open(READER, "-|", "file", "-b", "--mime-type", "-e", "tokens", "-L", 
"-z", $file);
 $typ = ;
 chomp $typ;

Bug#1071960: weechat: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: weechat
Version: 4.1.1-1
Severity: important
Tags: ftbfs
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

weechat uses libgcrypt-config to locate libgcrypt. This breaks
against libgcrypt 1.11 which does not ship libgcrypt-config anymore.
Please use pkg-config/pkgconf instead.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas