Bug#508764: libc6: Lots of locale warnings during upgrade

[Michael Biebl]

Package: libc6
Version: 2.7-16
Severity: important

Hi,

I did a test upgrade from etch - lenny. As soon as the new libc6 has
been unpacked, I get lots of those warnings:

perl: warning: Setting locale faile
perl: warning: Please check that your locale settings:
LANGUAGE = (unset)
LC_ALL = (unset)
LANG = de_DE.UTF-8
are support and installed on your system.
perl: warning: Falling back to the standard locale (C).


The sheer amount of those warnings, makes it hard to spot any real
important messages.

Michael


-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (300, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.27.9
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libgcc1   1:4.3.2-1  GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
pn  glibc-doc none (no description available)
ii  libc6-i6862.7-16 GNU C Library: Shared libraries [i
ii  locales   2.7-16 GNU C Library: National Language (

-- debconf information excluded



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#529173: -e aa_DJ.UTF-8 UTF-8 in list of locales

[Michael Biebl]

Package: locales
Version: 2.9-12
Severity: normal

Hi,

as you can see from the attached picture, I get a strange entry in the
list of locales, when I run dpkg-reconfigure locales
The first entry is -e aa_DJ.UTF-8 UTF-8 (note the -e).

My guess is, that this is added by locales.config, as /etc/locale.gen
looks normal.

Cheers,
Michael

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (300, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.29.3
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages locales depends on:
ii  debconf [debconf-2.0] 1.5.26 Debian configuration management sy
ii  libc6 [glibc-2.9-1]   2.9-12 GNU C Library: Shared libraries

locales recommends no packages.

locales suggests no packages.

-- debconf information:
* locales/default_environment_locale: de_DE.UTF-8
* locales/locales_to_be_generated: de_DE ISO-8859-1, de_DE.UTF-8 UTF-8, 
de...@euro ISO-8859-15, en_GB ISO-8859-1, en_GB.ISO-8859-15 ISO-8859-15, 
en_GB.UTF-8 UTF-8, en_US ISO-8859-1, en_US.ISO-8859-15 ISO-8859-15, en_US.UTF-8 
UTF-8
attachment: locale.png

Bug#538916: libc6.1-dev: Conflicting definitions in linux/ptrace.h and sys/ptrace.h on ia64

[Michael Biebl]

Package: libc6.1-dev
Version: 2.9-19
Severity: important

Hi,

upstart on ia64 currently ftbfs [1]. It's the only architecture, where
this happens. The relevant build log is

In file included from /usr/include/asm/ptrace.h:58,
 from /usr/include/linux/ptrace.h:49,
 from child.h:27,
 from child.c:37:
/usr/include/asm/fpu.h:57: error: redefinition of 'struct ia64_fpreg'
In file included from /usr/include/linux/ptrace.h:49,
 from child.h:27,
 from child.c:37:
/usr/include/asm/ptrace.h:208: error: redefinition of 'struct pt_all_user_regs'

This very much looks like a toolchain issue on ia64 (conflict between 
libc6.1-dev and linux-libc-dev).
Feel free to reassign appropriately.

Cheers,
Michael

[1]
https://buildd.debian.org/fetch.cgi?pkg=upstartver=0.6.2-1arch=ia64stamp=1248677700file=log
-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (300, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.30.3
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#369402: sys/inotify.h

[Michael Biebl]

reopen 369402
thanks

There is quite a lot software out there today which uses inotify.
Each of this package has to be updated to ship a private copy of the
inotify syscall. Using linux/inotify.h is not a good option.

Please consider to patch/backport sys/inotify from current upstream
glibc.h, so this software can be compiled unaltered.

Cheers,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#369402: sys/inotify.h

[Michael Biebl]

Aurelien Jarno wrote:
 Version: 2.5-0exp6
 
 Michael Biebl a écrit :
 reopen 369402
 thanks

 There is quite a lot software out there today which uses inotify.
 Each of this package has to be updated to ship a private copy of the
 inotify syscall. Using linux/inotify.h is not a good option.

 Please consider to patch/backport sys/inotify from current upstream
 glibc.h, so this software can be compiled unaltered.

 
 Etch is frozen nothing can be added. Please use glibc 2.5 from experimental.
 
 Closing the bug with the version from experimental.

Well then, let's hope we get out etch soon and glibc 2.5 in unstable.

I wanted to start working on hal-0.5.9 which has the above problem and I
wanted to avoid having to patch hal for that. upstream has no interest
to support glibc  2.4. I already did this dance with tracker and
upstart and don't want to do it again. I guess hal will have to wait then...

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#415870: nscd -i hosts causes main nscd daemon to segfault

[Michael Biebl]

Package: nscd
Version: 2.3.6.ds1-13
Severity: important
File: /usr/sbin/nscd

Running nscd -i hosts while the main nscd daemon is running yields
# nscd -d
20662: handle_request: request received (Version = 2) from PID 20669
20662:  INVALIDATE (hosts)
Segmentation fault

nscd -i hosts is used by network-manager to invalidate the hosts cache
on DNS changes. Atm it effectively kills the running nscd instance.

Michael



-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (300, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.21-rc4
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages nscd depends on:
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries

nscd recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#415870: nscd -i hosts causes main nscd daemon to segfault

[Michael Biebl]

Pierre HABOUZIT wrote:
 On Thu, Mar 22, 2007 at 07:31:47PM +0100, Michael Biebl wrote:
 Package: nscd
 Version: 2.3.6.ds1-13
 Severity: important
 File: /usr/sbin/nscd

 Running nscd -i hosts while the main nscd daemon is running yields
 # nscd -d
 20662: handle_request: request received (Version = 2) from PID 20669
 20662:  INVALIDATE (hosts)
 Segmentation fault

 nscd -i hosts is used by network-manager to invalidate the hosts cache
 on DNS changes. Atm it effectively kills the running nscd instance.

 Michael
 
   Does it still fails with ncsd from glibc 2.5 ? if yes, would it be
 possible to provide some kind of core/backtrace ?
 

Tested it with 2.5-1, works fine now.

I think this bug report can be closed.

Cheers,
Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#753725: Please don't run telinit u under systemd

[Michael Biebl]

Package: libc6
Version: 2.19-4
Severity: important
Tags: patch

The current version of libc6.postint runs telinit u to tell init to
re-exec itself. This was added so the system can shutdown cleanly when
sysvinit is the active PID 1.

Under systemd this is not necessary since systemd uses a dedicated
systemd-shutdown [1] tool which replaces init on shutdown. This ensures all
file systems can be unmounted cleanly.

Running telinit u midway through a dist-upgrade can have unwanted side
effects as the systemd package might be in an inconsistent state.
As you can see at [2], apt decided to remove libaudit0 (which is a
dependency of systemd in wheezy) and replace it with libaudit1. The new
systemd package is not yet unpacked. Running telinit u in such a state
will then lead to kernel panic.

Therefore please consider applying the attached patch in your next
upload.

Cheers,
Michael


[1] http://www.freedesktop.org/software/systemd/man/systemd-halt.service.html
[2] http://people.debian.org/~biebl/Debian-2014-07-04T13-18-40-656412000Z.webm

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff --git a/debian/debhelper.in/libc.postinst b/debian/debhelper.in/libc.postinst
index 82ed0ba..1e8af5d 100644
--- a/debian/debhelper.in/libc.postinst
+++ b/debian/debhelper.in/libc.postinst
@@ -233,6 +233,11 @@ then
 touch /var/run/init.upgraded
 fi
 fi
+if [ -d /run/systemd/system ]; then
+# Skip if systemd is the active PID 1, since systemd doesn't
+# need a reexec for a clean shutdown
+TELINIT=no
+fi
 fi
 if [ $TELINIT = yes ]; then
 telinit u 2/dev/null || true ; sleep 1

Bug#818999: DNS no longer working for NAT networking in VMware

[Michael Biebl]

Package: libc6
Version: 2.22-3
Severity: important

Hi,

I have a couple of vmware instances that use NAT networking.
After the libc6 upgrade from 2.21 to 2.22 on the host system, the VMs
are no longer able to resolve any names.

I found https://bbs.archlinux.org/viewtopic.php?id=201946

A workaround for now is to configure the guests to not use the DNS
server provided by vmware but a public one, like 8.8.8.8.


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

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6:amd64 depends on:
ii  libgcc1  1:5.3.1-12

libc6:amd64 recommends no packages.

Versions of packages libc6:amd64 suggests:
ii  debconf [debconf-2.0]  1.5.59
pn  glibc-doc  
ii  libc-l10n  2.22-3
ii  locales2.22-3

-- debconf information excluded

Bug#832521: Please backport fix for O_TMPFILE for jessie

[Michael Biebl]

Source: glibc
Version: 2.19-18+deb8u4
Severity: normal
Tags: patch

Hi,

while working on a backport of systemd v230 for jessie, we ran into
issues. Our test-suite was failing on i386, specifically test-tmpfiles.
It turns out, the files created wit O_TMPFILE had broken permissions and
were unreadable. After further investigation, this turned out to be a
bug in glibc[2].
I've backported the commit to 2.19 and with that patch applied, our
test-suite completed successfully on i386. The patch I've attached did
compile successfully on i386 and it fixed our issue in systemd. There
where a few conflicts when cherry-picking the patch, so please
double-check, just in case I missed something.

It would be great if you could include this patch in your next stable
upload. I noticed that there is already an accepted upload
2.19-18+deb8u5 for jessie 8.6. It would be awesome if you could make a
follow-up upload 2.19-18+deb8u6 to get that fix into 8.6 (I think there
is still some time left for that). If not, please consider including it
for 8.7.
The commit itself has been in unstable/stretch for a while, so seen some
wider testing.

Regards,
Michael

[1] 
https://buildd.debian.org/status/fetch.php?pkg=systemd=i386=230-7~bpo8%2B1=1468945449
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=17523
-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From dfff01413587d937e077d94b07b2fa0b7d6f8080 Mon Sep 17 00:00:00 2001
From: Eric Rannaud 
Date: Tue, 24 Feb 2015 13:12:26 +0530
Subject: [PATCH] linux: open and openat ignore 'mode' with O_TMPFILE in flags

Both open and openat load their last argument 'mode' lazily, using
va_arg() only if O_CREAT is found in oflag. This is wrong, mode is also
necessary if O_TMPFILE is in oflag.

By chance on x86_64, the problem wasn't evident when using O_TMPFILE
with open, as the 3rd argument of open, even when not loaded with
va_arg, is left untouched in RDX, where the syscall expects it.

However, openat was not so lucky, and O_TMPFILE couldn't be used: mode
is the 4th argument, in RCX, but the syscall expects its 4th argument in
a different register than the glibc wrapper, in R10.

Introduce a macro __OPEN_NEEDS_MODE (oflag) to test if either O_CREAT or
O_TMPFILE is set in oflag.

Tested on Linux x86_64.

	[BZ #17523]
	* io/fcntl.h (__OPEN_NEEDS_MODE): New macro.
	* io/bits/fcntl2.h (open): Use it.
	(openat): Likewise.
	* io/open.c (__libc_open): Likewise.
	* io/open64.c (__libc_open64): Likewise.
	* io/open64_2.c (__open64_2): Likewise.
	* io/open_2.c (__open_2): Likewise.
	* io/openat.c (__openat): Likewise.
	* io/openat64.c (__openat64): Likewise.
	* io/openat64_2.c (__openat64_2): Likewise.
	* io/openat_2.c (__openat_2): Likewise.
	* sysdeps/mach/hurd/open.c (__libc_open): Likewise.
	* sysdeps/mach/hurd/openat.c (__openat): Likewise.
	* sysdeps/posix/open64.c (__libc_open64): Likewise.
	* sysdeps/unix/sysv/linux/dl-openat64.c (openat64): Likewise.
	* sysdeps/unix/sysv/linux/generic/open.c (__libc_open): Likewise.
	(__open_nocancel): Likewise.
	* sysdeps/unix/sysv/linux/generic/open64.c (__libc_open64): Likewise.
	* sysdeps/unix/sysv/linux/open64.c (__libc_open64): Likewise.
	* sysdeps/unix/sysv/linux/openat.c (__OPENAT): Likewise.

Conflicts:
	ChangeLog
	NEWS
	sysdeps/unix/sysv/linux/generic/open.c
	sysdeps/unix/sysv/linux/generic/open64.c

(cherry-picked from commit 65f6f938cd562a614a68e15d0581a34b177ec29d)
---
 io/bits/fcntl2.h  | 18 +-
 io/fcntl.h| 14 --
 io/open.c |  4 ++--
 io/open64.c   |  4 ++--
 io/open64_2.c |  4 ++--
 io/open_2.c   |  4 ++--
 io/openat.c   |  4 ++--
 io/openat64.c |  4 ++--
 io/openat64_2.c   |  4 ++--
 io/openat_2.c |  4 ++--
 sysdeps/mach/hurd/open.c  |  4 ++--
 sysdeps/mach/hurd/openat.c|  4 ++--
 sysdeps/posix/open64.c|  4 ++--
 sysdeps/unix/sysv/linux/dl-openat64.c |  2 +-
 sysdeps/unix/sysv/linux/open64.c  |  4 ++--
 sysdeps/unix/sysv/linux/openat.c  |  6 +++---
 16 files changed, 49 insertions(+), 39 deletions(-)

diff --git a/io/bits/fcntl2.h b/io/bits/fcntl2.h
index 4f13b10..bb8d233 100644
--- a/io/bits/fcntl2.h
+++ b/io/bits/fcntl2.h
@@ -20,7 +20,7 @@
 # error "Never include  directly; use  instead."
 #endif
 
-/* Check that calls to open and openat with O_CREAT set have an
+/* Check that calls to open and openat with O_CREAT or O_TMPFILE set have an
appropriate 

Bug#845512: FTBFS: failing tests on various architectures: FAIL: elf/tst-prelink-cmp

[Michael Biebl]

Source: glibc
Version: 2.24-6
Severity: serious

glibc FTBFS on various architectures with
FAIL: elf/tst-prelink-cmp

Full builds log at https://buildd.debian.org/status/package.php?p=glibc


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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#854141: [Piuparts-devel] tzdata: purging tzdata leaves dangling /etc/localtime symlink

[Michael Biebl]

Am 22.03.2017 um 16:56 schrieb Andreas Beckmann:

> tzdata (which is now in testing, too). But that should have happened
> inbetween, so rescheduling the tzdata test in sid (from March 13) should
> be sufficient.

Btw, can you please reschedule the affected piuparts tests, so that
evolution-data-server is no longer listed as failing and rejected from
testing migration because of that:

https://tracker.debian.org/pkg/evolution-data-server

Thanks,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#854141: [Piuparts-devel] tzdata: purging tzdata leaves dangling /etc/localtime symlink

[Michael Biebl]

Am 22.03.2017 um 16:56 schrieb Andreas Beckmann:
> Control: notfound -1 2017a-1
> 
> On 2017-03-22 16:46, Michael Biebl wrote:
> 
>> That bug seems to be still unfixed in the latest version
>>
>> https://piuparts.debian.org/sid/fail/tzdata_2017a-1.log
>>
>> 0m17.0s ERROR: FAIL: After purging files have disappeared:
>>   /etc/localtime -> /usr/share/zoneinfo/Etc/UTC   not owned
> 
> Nope, that just means the chroot needs to be regenerated with the new
> tzdata (which is now in testing, too). But that should have happened
> inbetween, so rescheduling the tzdata test in sid (from March 13) should
> be sufficient.

Well, the log says that tzdata_2017a-1 was installed and tested.
Now I'm confused. Can you explain what piuparts is doing there?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#854141: [Piuparts-devel] tzdata: purging tzdata leaves dangling /etc/localtime symlink

[Michael Biebl]

Am 22.03.2017 um 17:09 schrieb Andreas Beckmann:
> And piuparts expects the chroot after the test to be in the same state
> as before the test. But that chroot was created with the previous
> version of tzdata installed, which was purged in a further minimizing
> step, but left that dangling symlink ... and got stored to disk as the
> base chroot for further sid tests. But now this link suddenly
> disappeared after installing+purging the new version, making piuparts
> unhappy.

Thanks for the explanation.
Now the error message "FAIL: After purging files have disappeared:"
suddenly makes more sense.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#854141: tzdata: purging tzdata leaves dangling /etc/localtime symlink

[Michael Biebl]

Control: found -1 2017a-1

On Sat, 04 Feb 2017 14:07:33 +0100 Andreas Beckmann  wrote:
> Package: tzdata
> Version: 2016j-2
> Severity: important
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package left unowned files on
> the system after purge, which is a violation of policy 6.8 (or 10.8):
> 
> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails
> 
> Filing this as important as having a piuparts clean archive is a release
> goal since lenny.
> 
> >From the attached log (scroll to the bottom...):
> 
> 0m36.2s ERROR: FAIL: Package purging left files on system:
>   /etc/localtime -> /usr/share/zoneinfo/Etc/UTCnot owned

That bug seems to be still unfixed in the latest version

https://piuparts.debian.org/sid/fail/tzdata_2017a-1.log

0m17.0s ERROR: FAIL: After purging files have disappeared:
  /etc/localtime -> /usr/share/zoneinfo/Etc/UTC  not owned

0m17.0s ERROR: FAIL: Installation and purging test.

This now blocks other packages, like evolution-data-server, from
entering testing.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#993821: After upgrading libc, some services are unable to restart (including systemd-resolved)

[Michael Biebl]

Hi Aurelien

Am 07.09.21 um 12:41 schrieb Aurelien Jarno:

Hi,

On 2021-09-07 10:39, Michael Hudson-Doyle wrote:



What's happening is that systemd is running with the old glibc, forks and
then does NSS things that cause the new glibc's NSS modules to load and
they don't necessarily work, leading to failures in any unit that specifies
User=. At least for Ubuntu's builds the NSS modules seem to be ABI
compatible between 2.32 and 2.33 (I didn't try 2.31 vs 2.32) but they are
definitely not between 2.33 and 2.34.


Thanks for this feedback and the pointer to the patch used in Ubuntu. It
seems to be a good solution, and matches what is done for other init
systems.

On the other hand, the problem is supposed to only happen for major
glibc version upgrade where the NSS modules might have a different ABI.
In that regard, I would be tempted to restart it only for major versions
upgrade like it's done for other daemons. Now if the systemd maintainers
consider it's fine restarting it for each glibc upgrade, we should
probably go that way.


I guess you are in a better position to make a judgement call here. If I 
read the glibc bug report correctly, there aren't strictly any 
guarantees regarding NSS modules. What that means for glibc minor 
updates, I'm not really in a position to tell.


Fwiw, I don't have a better proposal then Michael's patch he added to 
Ubuntu. We could run with that and if it causes problems, reiterate on it.


Regards,
Michael

Re: Bug#993821: After upgrading libc, some services are unable to restart (including systemd-resolved)

[Michael Biebl]

Am 06.09.21 um 23:45 schrieb Vincent Bernat:
> Package: systemd
> Version: 247.9-1
> Severity: normal
>

Hey!

After upgrading to libc6 2.32-1, some services are unable to restart.
In my case, systemd-resolved, systemd-timesyncd and colord. Using
"systemctl daemon-reexec" fixes the issue. Unsure if there is really
something to be fixed but as I didn't find anything about that, a bug
report may help others. I suppose the problem is related to NSS.

Sep 06 23:06:43 chocobo systemd[1]: Starting Network Time Synchronization...
Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service: Failed to 
determine user credentials: No such process
Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service: Failed at 
step USER spawning /lib/systemd/systemd-timesyncd: No such process





@libc maintainers: any ideas what could be causing this? If this is 
triggered by a libc6 update, should this be reassigned to glibc?




OpenPGP_signature
Description: OpenPGP digital signature

Re: Bug#993821: After upgrading libc, some services are unable to restart (including systemd-resolved)

[Michael Biebl]

Control: reassign -1 libc6
Control: found -1 2.32-1
Control: severity -1 serious
Control: affects -1 + systemd

Hi Michael

Am 07.09.21 um 00:39 schrieb Michael Hudson-Doyle:
On Tue, 7 Sept 2021 at 10:21, Michael Biebl <mailto:bi...@debian.org>> wrote:


Am 06.09.21 um 23:45 schrieb Vincent Bernat:
  > Package: systemd
  > Version: 247.9-1
  > Severity: normal
  >
 > Hey!
 >
 > After upgrading to libc6 2.32-1, some services are unable to restart.
 > In my case, systemd-resolved, systemd-timesyncd and colord. Using
 > "systemctl daemon-reexec" fixes the issue. Unsure if there is really
 > something to be fixed but as I didn't find anything about that, a bug
 > report may help others. I suppose the problem is related to NSS.
 >
 > Sep 06 23:06:43 chocobo systemd[1]: Starting Network Time
Synchronization...
 > Sep 06 23:06:43 chocobo systemd[236983]:
systemd-timesyncd.service: Failed to determine user credentials: No
such process
 > Sep 06 23:06:43 chocobo systemd[236983]:
systemd-timesyncd.service: Failed at step USER spawning
/lib/systemd/systemd-timesyncd: No such process
 >
 >


@libc maintainers: any ideas what could be causing this? If this is
triggered by a libc6 update, should this be reassigned to glibc?


We went through this in Ubuntu recently and decided that restarting 
systemd in glibc's postinst was the safest option: 
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1942276 
<https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1942276>


What's happening is that systemd is running with the old glibc, forks 
and then does NSS things that cause the new glibc's NSS modules to load 
and they don't necessarily work, leading to failures in any unit that 
specifies User=. At least for Ubuntu's builds the NSS modules seem to be 
ABI compatible between 2.32 and 2.33 (I didn't try 2.31 vs 2.32) but 
they are definitely not between 2.33 and 2.34.


Thanks for this information. This is indeed an icky issue and I feel 
like we are between a rock and a hard place.
I'm not a huge fan of going back to re-exec systemd again directly in 
libc6.postinst, but your proposed patch to at least check that the 
systemd binary can be sucessfully executed should at least deal with the 
situation sufficiently, where a library is (temporarily) missing.
I do wonder though, if this this will mean that on dist-upgrades the 
daemon-reexec will be skipped.


Anyway, I think it's best to reassign this libc6 for now and mark it as 
RC so the package doesn't migrate to testing for now.


Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994006: libc6: NSS modules changes require a restart of systemd-logind, which is not possible

[Michael Biebl]

Hi Aurelien,

thanks for the bug report

On Thu, 9 Sep 2021 18:48:42 +0200 Aurelien Jarno  wrote:

> One way to workaround the issue would be to force systemd-logind to do a
> NSS lookup, just like it it s already the case when a user log onto the
> system.

Before the upgrade, I assume, i.e. in libc6.preinst? 
Have you already tested this? If so, what did you use?
Should we construct something based on systemd-run maybe?

Michael



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

Bug#822733: tzdata: Drop /etc/timezone

[Michael Biebl]

Am 29.01.2023 um 15:38 schrieb Luca Boccassi:
On Sun, 29 Jan 2023, 13:15 Michael Biebl, <mailto:bi...@debian.org>> wrote:


Am 28.01.2023 um 02:12 schrieb Luca Boccassi:
 > I'm looking at this again, because handling /etc/timezone is one
of the
 > last large technical debt patches that we carry in Debian for
 > src:systemd, and we want to drop it for Trixie.
 > The idea is to add a tmpfiles.d entry in the systemd package that
 > unconditionally deletes /etc/timezone if present. If someone wants to
 > keep using it, they can simply override the tmpfiles.d entry with the
 > usual mechanisms.
 >
 > So, could you please reconsider the proposal to stop creating it
if it
 > doesn't exist (but keep updating if it does) in the tzdata
postinst as
 > above for Trixie?

I'm a bit confused: If you forcefully want to delete /etc/timezone
via a
tmpfiles snippet, why let tzdata update an existing /etc/timezone?


Because it can be overridden as mentioned, so in case there are unknown 
corner cases where it's still needed, a drop-in can be added to avoid 
deleting the file and it will still get updated. In the future we can 
then consider removing this as well.




I would prefer, if all this is handled within tzdata.
- It should stop creating /etc/timezone
- It should delete /etc/timezone on upgrades as a one-time action
- If users manually create the file afterwards (say touch /etc/timezone) 
a dpkg-reconfigure tzdata would update the file.


This should all be under tzdata's control.

Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#822733: tzdata: Drop /etc/timezone

[Michael Biebl]

Am 28.01.2023 um 02:12 schrieb Luca Boccassi:

I'm looking at this again, because handling /etc/timezone is one of the
last large technical debt patches that we carry in Debian for
src:systemd, and we want to drop it for Trixie.
The idea is to add a tmpfiles.d entry in the systemd package that
unconditionally deletes /etc/timezone if present. If someone wants to
keep using it, they can simply override the tmpfiles.d entry with the
usual mechanisms.

So, could you please reconsider the proposal to stop creating it if it
doesn't exist (but keep updating if it does) in the tzdata postinst as
above for Trixie?


I'm a bit confused: If you forcefully want to delete /etc/timezone via a 
tmpfiles snippet, why let tzdata update an existing /etc/timezone?


OpenPGP_signature
Description: OpenPGP digital signature

Bug#822733: tzdata: Drop /etc/timezone

[Michael Biebl]

Hi

Am 07.02.23 um 23:01 schrieb Aurelien Jarno:


2022g-3. You probably want to change d-i to not create that file.


Where specifically does d-i (i.e. which component)  create /etc/timezone?


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1064131: libnss-nisplus: install NSS module into /usr

[Michael Biebl]

Source: libnss-nisplus
Version: 1.3-4
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. libnss-nisplus installs files into /lib; these should be moved
into the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

This should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru libnss-nisplus-1.3/debian/changelog 
libnss-nisplus-1.3/debian/changelog
--- libnss-nisplus-1.3/debian/changelog 2020-10-18 10:56:30.0 +0200
+++ libnss-nisplus-1.3/debian/changelog 2024-02-17 15:56:05.0 +0100
@@ -1,3 +1,10 @@
+libnss-nisplus (1.3-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install NSS module into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Sat, 17 Feb 2024 15:56:05 +0100
+
 libnss-nisplus (1.3-4) unstable; urgency=medium
 
   * Add a build-depends on libnsl-dev. 
diff -Nru libnss-nisplus-1.3/debian/install libnss-nisplus-1.3/debian/install
--- libnss-nisplus-1.3/debian/install   2020-08-20 19:08:28.0 +0200
+++ libnss-nisplus-1.3/debian/install   2024-02-17 15:56:04.0 +0100
@@ -1 +1 @@
-usr/lib/${DEB_HOST_MULTIARCH}/libnss_nisplus.so.2* /lib/${DEB_HOST_MULTIARCH}
+usr/lib/${DEB_HOST_MULTIARCH}/libnss_nisplus.so.2*

Bug#1064130: libnss-nis: install NSS module into /usr

[Michael Biebl]

Source: libnss-nis
Version: 3.1-4
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. libnss-nis installs files into /lib; these should be moved into
the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

This should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru libnss-nis-3.1/debian/changelog libnss-nis-3.1/debian/changelog
--- libnss-nis-3.1/debian/changelog 2020-10-18 10:48:47.0 +0200
+++ libnss-nis-3.1/debian/changelog 2024-02-17 15:51:43.0 +0100
@@ -1,3 +1,10 @@
+libnss-nis (3.1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install NSS module into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Sat, 17 Feb 2024 15:51:43 +0100
+
 libnss-nis (3.1-4) unstable; urgency=medium
 
   * Add a build-depends on libnsl-dev.
diff -Nru libnss-nis-3.1/debian/install libnss-nis-3.1/debian/install
--- libnss-nis-3.1/debian/install   2020-08-20 19:09:05.0 +0200
+++ libnss-nis-3.1/debian/install   2024-02-17 15:51:41.0 +0100
@@ -1 +1 @@
-usr/lib/${DEB_HOST_MULTIARCH}/libnss_nis.so.2* /lib/${DEB_HOST_MULTIARCH}
+usr/lib/${DEB_HOST_MULTIARCH}/libnss_nis.so.2*