Bug#1073176: gramps: Error with loss of data: TypeError: '<' not supported between instances of 'str' and 'NoneType'
On 14/06/24 19:02, IOhannes m zmölnig (Debian/GNU) wrote: On 14/06/2024 05:59, Mark Robinson wrote: Package: gramps Version: 5.2.2+dfsg-0.1 Severity: grave Justification: causes non-serious data loss bummer. New version of gramps in Trixie upgrade. Insisted on upgrading database advising to create backup without means. the latter would be an upstream bug. Most likely, but a Debian upgrade which takes the system into a state which requires a database upgrade while removing the ability to make a backup may justify a Debian News entry so users can back out of the software upgrade and perform the backup. Upgraded and loaded database. Spat error, lost new record. could you get into detail with the last bit? - when was the new record created? - how was it lost? On completing the database migration I created a new person, added birth and death information including a new death location and notes, and clicked OK. This resulted in the python error referred to in the headline which left the new person with the OK button greyed out and no way to save it. The record was lost. This information appears to have been lost in submitting the report: User Information: === Just after version upgrade and DB conversion. Being unable to backup a database after upgrading Gramps and before converting the database is highly problematic. Error Details: === 11723: WARNING: upgrade.py: line 2218: If upgrade and loading the Family Tree works, you can delete the zip file at /home/mark/.gramps/ROBINSON__Mark_Gregory_2024-06-14_12-07-04.zip 15060: WARNING: upgrade.py: line 2218: If upgrade and loading the Family Tree works, you can delete the zip file at /home/mark/.gramps/ROBINSON__Mark_Gregory_2024-06-14_12-07-08.zip 15068: WARNING: updatecallback.py: line 94: UpdateCallback with total == 0 created 3905173: ERROR: grampsapp.py: line 188: Unhandled exception Traceback (most recent call last): File "/usr/lib/python3/dist-packages/gramps/gui/editors/editperson.py", line 984, in save self.db.commit_person(self.obj, trans) File "/usr/lib/python3/dist-packages/gramps/gen/db/generic.py", line 1911, in commit_person self.add_to_surname_list(person, trans.batch) File "/usr/lib/python3/dist-packages/gramps/gen/db/generic.py", line 2450, in add_to_surname_list i = bisect.bisect(self.surname_list, name) ^^ TypeError: '<' not supported between instances of 'str' and 'NoneType' System Information: === Gramps version: 5.2.2 Python version: 3.11.9 BSDDB version: 6.2.9 (5, 3, 28) sqlite version: 3.46.0 (2.6.0) LANG: en_GB.UTF-8 OS: Linux Distribution: 6.7.12-amd64 GTK version: 3.24.42 gobject version: 3.48.2 cairo version : (1, 26, 0) Ta, Mark
Bug#1073176: gramps: Error with loss of data: TypeError: '<' not supported between instances of 'str' and 'NoneType'
Package: gramps Version: 5.2.2+dfsg-0.1 Severity: grave Justification: causes non-serious data loss Dear Maintainer, New version of gramps in Trixie upgrade. Insisted on upgrading database advising to create backup without means. Upgraded and loaded database. Spat error, lost new record. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gramps depends on: ii gir1.2-gtk-3.03.24.42-1 ii librsvg2-22.58.0+dfsg-1 ii python3 3.11.8-1 ii python3-bsddb36.2.9-2+b6 ii python3-gi3.48.2-1 ii python3-gi-cairo 3.48.2-1 ii xdg-utils 1.1.3-4.1 Versions of packages gramps recommends: ii gir1.2-geocodeglib-2.0 3.26.3-6+b2 ii gir1.2-gexiv2-0.10 0.14.2-2+b2 ii gir1.2-osmgpsmap-1.01.2.0-2+b2 ii graphviz2.42.2-9+b1 ii python3-icu 2.13.1-1 Versions of packages gramps suggests: ii fonts-freefont-ttf20211204+svn4273-2 pn gir1.2-goocanvas-2.0 pn gir1.2-gtkspell3-3.0 ii python3-numpy 1:1.26.4+ds-10 ii python3-pil 10.3.0-2 pn rcs -- no debconf information
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
Control: severity -1 normal On Fri, May 17, 2024 at 08:58:34AM +0100, Mark Hindley wrote: > On Wed, May 08, 2024 at 01:09:59PM +0100, Mark Hindley wrote: > > Michael and Steve, > > > > I would appreciate some help here. > > Bump to reset autoremove timer. Still no response. Downgrading severity to avoid the autoremove dance again. Mark
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
On Wed, May 08, 2024 at 01:09:59PM +0100, Mark Hindley wrote: > Michael and Steve, > > I would appreciate some help here. Bump to reset autoremove timer. Mark
Bug#1070854: clc-intercal FTBFS: dpkg-genbuildinfo: error: binary build with no binary artifacts found
On Fri, May 10, 2024 at 05:25:35PM +0300, Adrian Bunk wrote: > chmod +x `pwd`/debian/clc-intercal/usr/bin/* > dpkg-genbuildinfo --build=any > -O../clc-intercal_1.00-1_ppc64el-buildd.buildinfo > dpkg-genbuildinfo: error: binary build with no binary artifacts found; > .buildinfo is meaningless > dpkg-buildpackage: error: dpkg-genbuildinfo --build=any > -O../clc-intercal_1.00-1_ppc64el-buildd.buildinfo subprocess returned exit > status 25 I can't reproduce this, and nothing about the build I'm seeing in the log looks meaningfully different to what I get when I build locally. AFAICT there are .so files being installed among the various perl things and dpkg-genbuildinfo runs happily. signature.asc Description: PGP signature
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
Control: tags -1 moreinfo Michael and Steve, I would appreciate some help here. On Tue, Mar 05, 2024 at 07:33:40AM +, Mark Hindley wrote: > Control: severity -1 normal > > On Tue, Feb 06, 2024 at 05:43:41PM +0000, Mark Hindley wrote: > > Whilst I am not an expert on this transition or the abi-compliance-checker, > > a > > quick look at the logs[1] suggests this is a tool configuration issue and > > src:consolekit2 may not require t64 migration. > > > > Can you clarify? I am still not convinced that consolekit2 requires this. As identified above, it looks to me that the abi-compliance-checker tool failed and that failure flagged consolekit2 as requiring t64 migration. I may be looking for the wrong thing (in which case, please tell me the correct thing to look for), but there are no references to time_t in either library and the output from: $ git -C /home/mark/src/devuan/consolekit2/ grep time_t libconsolekit/ libck-connector/ is empty. The only references to time_t are in src/ck-tty-idle-monitor.c (used in /usr/sbin/console-kit-daemon) and tools/ck-history.c (/usr/bin/ck-history). $ git -C /home/mark/src/devuan/consolekit2/ grep time_t src/ck-tty-idle-monitor.c:time_t now; src/ck-tty-idle-monitor.c:time_t idletime; src/ck-tty-idle-monitor.c:time_t last_access; tools/ck-history.c:time_t secs; tools/ck-history.c:time_t added_t, removed_t; tools/ck-history.c:time_t oldest_e; tools/ck-history.c:time_t oldest_e; I am reluctant to implement this change unnecessarily. I would appreciate you expertise and guidance. Many thanks Mark
Bug#1070295: cgroupfs-mount: Fails to upgrade or remove if elogind is running: "umount: /sys/fs/cgroup/elogind: target is busy."
Lorenzo, Thanks for the reminder. On Fri, May 03, 2024 at 03:10:57PM +0200, Lorenzo wrote: > Is this is a duplicate of #950986? > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950986 > I bet the patch there would fix this bug too Embarrassingly, that is my patch which I clearly have no recollection of! :-| Now I look, we have been shipping a variation on it in Devuan since 2020[1]. Mark [1] https://git.devuan.org/devuan/cgroupfs-mount/commit/ff91abfaf3a5c5633744ea552084125ec6c68ce5
Bug#1070295: cgroupfs-mount: Fails to upgrade or remove if elogind is running: "umount: /sys/fs/cgroup/elogind: target is busy."
Axel, On Fri, May 03, 2024 at 01:05:15PM +0200, Axel Beckert wrote: > P.S.: Given that Christian's NMU doesn't even touch the maintainer > scripts, I suspect that this issue is also present in version 1.4. I > though didn't notice it before then, so it might be related to recent > elogind changes, hence Cc'ing the Debian Init System Diversity Team, > too. Since this is the first cgroupfs-mount update since 2017 (which predates elogind's arrival in Debian) I suspect it has always been there, just uncovered by the cgroupfs-mount NMU. My gut reaction is that cgroupfs-mount shouldn't be unmounting and remounting cgroups on upgrade and it needs some dh_installinit magic in d/rules. Mark
Bug#1068653: close
close #1068653 Restarting laptop after upgrading to unstable (from stable) worked.
Bug#1068653: evolution: Can't use google accounts
Package: evolution Version: 3.50.3-1+b1 Severity: grave I have two accounts (personal and work) and both of them are returning “Timeout was reached”. I have tried removing the accounts and re-adding them without success. personal account is @gmail.com work account is @EMPLOYER'S-DOMAIN -- System Information Debian Release: 12.5 Kernel Version: Linux gabriel 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux -- http://hexmode.com/ Don't ask me who's influenced me. A lion is made up of the lambs he's digested, and I've been reading all my life. -- Giorgos Seferis
Bug#1061493: consolekit: install PAM module and udev files into /usr
Control: notfound -1 1.2.6-3 On Wed, Mar 13, 2024 at 10:40:40PM +0100, Andreas Beckmann wrote: > Followup-For: Bug #1061493 > Control: found -1 1.2.6-3.1~exp1 > Control: severity -1 serious > Control: tag -1 ftbfs > > This change causes consolekit2 to to FTBFS in experimental: Indeed. As it was an NMU, I think the etiquette is for the NMUer to fix. In sid consolekit2 still builds cleanly. Therefore, marking notfound there. Michael, perhaps you would fix your NMU, or provide a better patch? Thanks Mark
Bug#1063099: openrc: NMU diff for 64-bit time_t transition
Control: severity -1 normal Preventing autoremoval due to uninstallable dpkg-dev version in testing. Mark
Bug#1066531: policykit-1: FTBFS: ../subprojects/mocklibc-1.0/src/netgroup-debug.c:25:3: error: implicit declaration of function ‘print_indent’ [-Werror=implicit-function-declaration]
Control: tags -1 patch
I also bumped into this whilst rebuilding src:policykit-1 yesterday.
There is an upstream patch[1], but it doesn't fix the build for me; I think it
is patching the wrong files.The problem appears to be multiple copies of
mocklibc. AFAICS ./test/mocklibc is not used in favour of a meson subproject.
The pkla-compat tarball also has mocklibc, but that is also patched already.
Getting the multiple layers of quilt and meson patches to work was
unpleasant. So the attached patch may save you some time.
HTH
Mark
[1]
https://github.com/polkit-org/polkit/commit/0d78d1e4bf5ab3ce11678005b220aac0cfc5bee5
>From f50131bcb98802a66dcc1ee4cc952ca1cc9f8ff4 Mon Sep 17 00:00:00 2001
From: Mark Hindley
Date: Wed, 13 Mar 2024 09:13:27 +
Subject: [PATCH] Import upstream patch to fix embedded mocklibc subproject
FTBFS with gcc 14.
---
...e-print_indent-function-to-the-file-.patch | 91 +++
debian/patches/series | 1 +
2 files changed, 92 insertions(+)
create mode 100644 debian/patches/06-embedded-mocklibc-move-the-print_indent-function-to-the-file-.patch
diff --git a/debian/patches/06-embedded-mocklibc-move-the-print_indent-function-to-the-file-.patch b/debian/patches/06-embedded-mocklibc-move-the-print_indent-function-to-the-file-.patch
new file mode 100644
index ..184161b7
--- /dev/null
+++ b/debian/patches/06-embedded-mocklibc-move-the-print_indent-function-to-the-file-.patch
@@ -0,0 +1,91 @@
+--- a/subprojects/mocklibc.wrap
b/subprojects/mocklibc.wrap
+@@ -8,3 +8,5 @@
+ patch_url = https://wrapdb.mesonbuild.com/v1/projects/mocklibc/1.0/2/get_zip
+ patch_filename = mocklibc-1.0-2-wrap.zip
+ patch_hash = 0280f96a2eeb3c023e5acf4e00cef03d362868218d4a85347ea45137c0ef6c56
++diff_files = mocklibc-move-the-print_indent-function-to-the-file.patch
++
+--- /dev/null
b/subprojects/packagefiles/mocklibc-move-the-print_indent-function-to-the-file.patch
+@@ -0,0 +1,69 @@
++From 0d78d1e4bf5ab3ce11678005b220aac0cfc5bee5 Mon Sep 17 00:00:00 2001
++From: Vincent Mihalkovic
++Date: Fri, 8 Mar 2024 14:04:33 +0100
++Subject: [PATCH] mocklibc: move the print_indent function to the file where it
++ is used
++MIME-Version: 1.0
++Content-Type: text/plain; charset=UTF-8
++Content-Transfer-Encoding: 8bit
++
++This fixes build error with GCC >= 14 and clang >= 17,
++failing on:
++```
++../subprojects/mocklibc-1.0/src/netgroup-debug.c:25:3: error: implicit declaration of function ‘print_indent’ [-Wimplicit-function-declaration]
++ 25 | print_indent(stream, indent);
++ | ^~~~
++```
++
++Closes: #6
++---
++ src/netgroup-debug.c | 11 +++
++ src/netgroup.c | 11 ---
++ 2 files changed, 11 insertions(+), 11 deletions(-)
++
++diff --git a/src/netgroup-debug.c b/src/netgroup-debug.c
++index 81d6e728..46e5b25f 100644
++--- a/src/netgroup-debug.c
+ b/src/netgroup-debug.c
++@@ -21,6 +21,17 @@
++ #include
++ #include
++
+++/**
+++ * Print a varaible indentation to the stream.
+++ * @param stream Stream to print to
+++ * @param indent Number of indents to use
+++ */
+++static void print_indent(FILE *stream, unsigned int indent) {
+++ int i;
+++ for (i = 0; i < indent; i++)
+++fprintf(stream, " ");
+++}
+++
++ void netgroup_debug_print_entry(struct entry *entry, FILE *stream, unsigned int indent) {
++ print_indent(stream, indent);
++
++diff --git a/src/netgroup.c b/src/netgroup.c
++index 06a8a894..e16e4519 100644
++--- a/src/netgroup.c
+ b/src/netgroup.c
++@@ -71,17 +71,6 @@ static char *parser_copy_word(char **cur) {
++ return result;
++ }
++
++-/**
++- * Print a varaible indentation to the stream.
++- * @param stream Stream to print to
++- * @param indent Number of indents to use
++- */
++-void print_indent(FILE *stream, unsigned int indent) {
++- int i;
++- for (i = 0; i < indent; i++)
++-fprintf(stream, " ");
++-}
++-
++ /**
++ * Connect entries with 'child' type to their child entries.
++ * @param headentry Head of list of entries that need to be connected
++--
++2.39.2
+--- a/meson.build
b/meson.build
+@@ -7,7 +7,7 @@
+ 'prefix=/usr',
+ 'cpp_std=c++17',
+ ],
+- meson_version: '>= 0.50.0',
++ meson_version: '>= 0.63.0',
+ )
+
+ pk_version = meson.project_version()
diff --git a/debian/patches/series b/debian/patches/series
index ddbec3c1..24156d33 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
+06-embedded-mocklibc-move-the-print_indent-function-to-the-file-.patch
04-fix-pkexec-fails-with-GDBus.Error-org.freedesktop.Po.patch
01_devuan-pkexec-pass-gtk-vars.patch
02_gettext.patch
--
2.39.2
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
Control: severity -1 normal On Tue, Feb 06, 2024 at 05:43:41PM +, Mark Hindley wrote: > Whilst I am not an expert on this transition or the abi-compliance-checker, a > quick look at the logs[1] suggests this is a tool configuration issue and > src:consolekit2 may not require t64 migration. > > Can you clarify? I would appreciate some help here. Your patch FTBFS and I need to be convinced it is actually required before spending time on it. In the meantime, downgrading severity to prevent autoremoval. Thanks Mark
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
Whilst I am not an expert on this transition or the abi-compliance-checker, a quick look at the logs[1] suggests this is a tool configuration issue and src:consolekit2 may not require t64 migration. Can you clarify? Thanks Mark [1] https://adrien.dcln.fr/misc/armhf-time_t/2024-02-03T09:18:00/logs/libconsolekit-dev/time_t/log.txt
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
Michael, On Tue, Jan 30, 2024 at 01:24:19AM +, mwhud...@debian.org wrote: > Source: consolekit2 > Version: 1.2.6-3 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t This patch appears to be broken and all the experimental builds FTBFS[1]. In addition, the bug severity is triggering autoremoval[2] That seems a sub-optimal combination. I am minded to reduce the bug severity. But I will wait for your response if you have a better suggestion. Thanks Mark [1] https://buildd.debian.org/status/package.php?p=consolekit2=experimental [2] https://udd.debian.org/cgi-bin/autoremovals.cgi
Bug#1060768: pdudaemon: Missing dependency on python3-aiohttp
Package: pdudaemon
Version: 0.0.8.58.g597052b-1
Severity: serious
Attempting to use pdudaemon without python3-aiohttp installed results in
a traceback:
# pdudaemon
Traceback (most recent call last):
File "/usr/sbin/pdudaemon", line 33, in
sys.exit(load_entry_point('pdudaemon==0.1', 'console_scripts',
'pdudaemon')())
^^
File "/usr/sbin/pdudaemon", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1206, in _gcd_import
File "", line 1178, in _find_and_load
File "", line 1149, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/pdudaemon/__init__.py", line 32, in
from pdudaemon.httplistener import HTTPListener
File "/usr/lib/python3/dist-packages/pdudaemon/httplistener.py", line 24, in
from aiohttp import web
ModuleNotFoundError: No module named 'aiohttp'
but there is no dependency declared in the package. Installing the
python3-aiohttp resolves this issue.
-- System Information:
Debian Release: 12.1
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64
Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pdudaemon depends on:
ii python3 3.11.2-1+b1
pn python3-hid
pn python3-paramiko
ii python3-pexpect 4.8.0-4
ii python3-pyasn10.4.8-3
ii python3-pysnmp4 4.4.12-2
ii python3-requests 2.28.1+dfsg-1
ii python3-serial3.5-1.1
pn python3-systemd
pn python3-usb
Versions of packages pdudaemon recommends:
ii inetutils-telnet [telnet] 2:2.4-2
ii openssh-client 1:9.2p1-2
pdudaemon suggests no packages.
Bug#1059165: [Pkg-javascript-devel] Bug#1059165: src:zlib: fails to migrate to testing for too long: triggers autopkgtest issues
On Wed, Dec 20, 2023 at 10:14:44PM +0100, Jérémy Lal wrote: > BURP wrong zlib version check in the failing test - this could be NMUed > DOLFIN has a single test failure, that is odd and unrelated as well - this > could be NMUed For non-technical reasons I can't do these NMUs myself if they're warranted/needed. signature.asc Description: PGP signature
Bug#1059165: src:zlib: fails to migrate to testing for too long: triggers autopkgtest issues
clone 1059165 -1 reassign -1 nodejs retitle -1 autopkgtest failures on i386 found -1 18.19.0+dfsg-6 block 1059165 by -1 kthxbye On Wed, Dec 20, 2023 at 08:15:31PM +0100, Paul Gevers wrote: > The Release Team considers packages that are out-of-sync between testing and > unstable for more than 30 days as having a Release Critical bug in testing > [1]. Your package src:zlib has been trying to migrate for 32 days [2]. > Hence, I am filing this bug. The version in unstable triggers autopkgtest > failures in multiple packages (although I suspect that the current dolfin > issues are due to it being flaky). The failure for burp has already a bug > report against that package, which leaves nodejs on i386. ... > This bug will trigger auto-removal when appropriate. As with all new bugs, > there will be at least 30 days before the package is auto-removed. Not sure that's likely in the case of zlib? > If you believe your package is unable to migrate to testing due to issues > beyond your control, don't hesitate to contact the Release Team. There are non-technical issues with me doing active work on nodejs package but from a quick glance the log does not seem particularly plausibly related to zlib, and I note that the failures are not ok 498 parallel/test-debugger-heap-profiler not ok 962 parallel/test-fs-utimes-y2K38 # TODO : Fix flaky test the second of which especially doesn't inspire confidence that this is due to zlib rather than general updates to unstable setting off an already flaky test (eg, the kernel changed timing?). Full log is: https://ci.debian.net/packages/n/nodejs/testing/i386/41176091/ and looking at: https://ci.debian.net/packages/n/nodejs/testing/i386/ there seem to be a number of packages triggering what from spot checks look to be the same or similar issues in nodejs in testing. I frankly don't really know what I'm supposed to do with this, the test results look like noise as far as zlib is concerned so I don't see anything to fix or investigate in the package itself. AFAICT bugs don't get filed for autopkgtest failures like they do for build failures so perhaps this was just missed up until now? signature.asc Description: PGP signature
Bug#1057122: initscripts has an undeclared file conflict on /usr/lib/udev/hwclock-set
Helmut,
Thanks for this
On Tue, Nov 28, 2023 at 10:27:41AM +0100, Helmut Grohne wrote:
> Package: initscripts
> Version: 3.08-3~bpo12+1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: fileconflict
> Control: affects -1 + util-linux
> Tags: bookworm
>
> initscripts has an undeclared file conflict. This may result in an
> unpack error from dpkg.
>
> The file /usr/lib/udev/hwclock-set is contained in the packages
> * initscripts/3.08-3~bpo12+1 as present in bookworm-backports
> * util-linux/2.36.1-8+deb11u1 as present in bullseye|bullseye-security
Are the suites and versions reported here really the problematic ones?
I agree there is a conflict, but I think it is between
initscripts/3.08-3~bpo12+1 in bookworm-backports and util-linux-extra/2.38.1-5
in bookworm.
My proposed fix is attached. It reverts the transition of the hwclock machinery
to initscripts, since this is still present in bookworm src:util-linux.
Or, have I misunderstood?
Best wishes,
Mark
diff --git a/debian/control b/debian/control
index 551b7abc..02bfe1b5 100644
--- a/debian/control
+++ b/debian/control
@@ -99,15 +99,12 @@ Multi-Arch: foreign
Depends:
sysvinit-utils (>= 3.05-1),
sysv-rc | file-rc | openrc,
- util-linux-extra,
${misc:Depends},
Recommends:
e2fsprogs,
psmisc,
Breaks: udev (<< 254.3-1),
- util-linux-extra (<< 2.39.2-2.1~)
Replaces: udev (<< 254.3-1),
- util-linux-extra (<< 2.39.2-2.1~)
Description: scripts for initializing and shutting down the system
The scripts in this package initialize a standard Debian
system at boot time and shut it down at halt or reboot time.
diff --git a/debian/initscripts.postinst b/debian/initscripts.postinst
index 0074f2a3..eb126710 100755
--- a/debian/initscripts.postinst
+++ b/debian/initscripts.postinst
@@ -42,7 +42,7 @@ INITSCRIPTS="mountkernfs.sh mount-configfs brightness
hostname.sh mountdevsubfs.
checkroot-bootclean.sh checkfs.sh mountall.sh mountall-bootclean.sh \
mountnfs.sh mountnfs-bootclean.sh bootmisc.sh urandom halt reboot \
udev umountroot umountfs umountnfs.sh sendsigs killprocs single motd \
- bootlogs rc.local rmnologin hwclock.sh"
+ bootlogs rc.local rmnologin"
for F in $INITSCRIPTS; do
if [ -x /etc/init.d/$F ]; then
diff --git a/debian/initscripts.postrm b/debian/initscripts.postrm
index 25bbb932..e53672dc 100755
--- a/debian/initscripts.postrm
+++ b/debian/initscripts.postrm
@@ -9,7 +9,7 @@ INITSCRIPTS="mountkernfs.sh mount-configfs brightness
hostname.sh mountdevsubfs.
checkroot-bootclean.sh checkfs.sh mountall.sh mountall-bootclean.sh \
mountnfs.sh mountnfs-bootclean.sh bootmisc.sh urandom halt reboot \
udev umountroot umountfs umountnfs.sh sendsigs killprocs single motd \
- bootlogs rc.local rmnologin hwclock.sh"
+ bootlogs rc.local rmnologin"
case "$1" in
purge)
diff --git a/debian/src/initscripts/Makefile b/debian/src/initscripts/Makefile
index 5da80089..b13eafa3 100644
--- a/debian/src/initscripts/Makefile
+++ b/debian/src/initscripts/Makefile
@@ -34,9 +34,6 @@ install:
$(INSTALL) -d $(DESTDIR)$(sbindir)/.
$(INSTALL) sbin/fsck.nfs $(DESTDIR)$(sbindir)/fsck.nfs
- $(INSTALL_DATA) -Dt $(DESTDIR)/usr/lib/udev/rules.d
usr/lib/udev/rules.d/hwclock.rules
- $(INSTALL) usr/lib/udev/hwclock-set $(DESTDIR)/usr/lib/udev/hwclock-set
-
$(INSTALL) -d $(DESTDIR)/usr/share/man/man8
$(INSTALL_DATA) man/fsck.nfs.8 \
$(DESTDIR)/usr/share/man/man8/fsck.nfs.8
diff --git a/debian/src/initscripts/etc/default/hwclock
b/debian/src/initscripts/etc/default/hwclock
deleted file mode 100644
index 44b04312..
--- a/debian/src/initscripts/etc/default/hwclock
+++ /dev/null
@@ -1,2 +0,0 @@
-# Settings for the hwclock init script.
-# See hwclock(5) for supported settings.
diff --git a/debian/src/initscripts/etc/init.d/hwclock.sh
b/debian/src/initscripts/etc/init.d/hwclock.sh
deleted file mode 100644
index a9872b64..
--- a/debian/src/initscripts/etc/init.d/hwclock.sh
+++ /dev/null
@@ -1,57 +0,0 @@
-#!/bin/sh
-
-### BEGIN INIT INFO
-# Provides: hwclock
-# Required-Start:
-# Required-Stop: mountdevsubfs
-# Should-Stop: umountfs
-# Default-Start: S
-# Default-Stop: 0 6
-# Short-Description: Save system clock to hardware on shutdown.
-### END INIT INFO
-
-# Note: this init script and related code is only useful if you
-# run a sysvinit system, without NTP synchronization.
-
-if [ -e /run/systemd/system ] ; then
-exit 0
-fi
-
-unset TZ
-
-hwclocksh()
-{
-HCTOSYS_DEVICE=rtc0
-[ ! -x /sbin/hwclock ] && return 0
-[ ! -r /etc/default/rcS ] || . /etc/default/rcS
-[ ! -r /etc/default/hwclock ] || . /etc/default/hwclock
-
-. /lib/lsb/init-functions
-verbose_log_action_msg() { [ "$VERBOSE" = no ] || log_a
Bug#1055484: libpam-elogind-compat has ineffective replaces for libpam-systemd due to /usr-merge
Control: block -1 1055562 Helmut, On Tue, Nov 07, 2023 at 08:39:23AM +, Mark Hindley wrote: > I think all suitable dependencies now use default-logind | logind. I will > check that is correct. If it is, libpam-elogind-compat could just be > removed. It was never available outside experimental. AFAICS, all supported cases now use Depends: default-logind | logind or have demoted the Depends to Recommends. I have filed a RM request[1]. Mark [1] https://bugs.debian.org/1055562
Bug#1055484: libpam-elogind-compat has ineffective replaces for libpam-systemd due to /usr-merge
Helmut, Thanks for this. libpam-elogind-compat was used when elogind was first introduced as a hack to circumvent missing dependencies and allow testing. I think all suitable dependencies now use default-logind | logind. I will check that is correct. If it is, libpam-elogind-compat could just be removed. It was never available outside experimental. Mark
Bug#1052942: insserv: FTBFS: insserv: Could not read script nolsbheader: No such file or directory
Control: tags -1 upstream Control: retitle -1 Upstream testsuite fails to produce deterministic results Santiago, On Sun, Oct 29, 2023 at 02:39:44PM +0100, Santiago Vila wrote: > However, I can create a machine for you to reproduce the problem. Thanks. I have reproduced on your provided machine, but still not locally and I can't identify the underlying difference between the builds. In the failure case the problem is in the upstream testsuite, specifically the test for #491391 in tests/run-testsuite which produces init.d: bootchart four one rmnologin three two insserv: override rc0.d: rc1.d: rc2.d: S01one S01three S01two S02four S98rmnologin S99bootchart rc3.d: S01one S01three S01two S02four S98rmnologin S99bootchart rc4.d: S01one S01three S01two S02four S98rmnologin S99bootchart rc5.d: S01one S01three S01two S02four S98rmnologin S99bootchart rc6.d: rcS.d: error: incorrect 5 sequence bootchart not before rmnologin The same failure mode appears to be responsible for armel and armhf autopkgtest failures logged on ci.debian.net[1] As Ian pointed out[2], there are significant and surprising changes in looping order and behaviour between the successful and failing testsuites. The diff is attached. Having said that, I still can't reproduce locally or determine a good fix. Hopefully Jesse will have a useful contribution Mark [1] https://ci.debian.net/data/autopkgtest/unstable/armel/i/insserv/38435862/log.gz [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052942#15 diff -u --label /sshx\:atlas\:/tmp/build.log --label /home/mark/src/debian/insserv/build.log /tmp/tramp.mDUEXG.log /home/mark/src/debian/insserv/build.log --- /sshx:atlas:/tmp/build.log +++ /home/mark/src/debian/insserv/build.log @@ -4,8 +4,15 @@ dpkg-buildpackage: info: source changed by Mark Hindley dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 - fakeroot debian/rules clean -echo -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection +dpkg-source: info: using patch list from debian/patches/series +dpkg-source: info: applying install-binaries-ignore-PREFIX.patch +dpkg-source: info: applying 11_debian_conf.patch +dpkg-source: info: applying 110_portmap.patch +dpkg-source: info: applying warn_in_ignore_mode.patch +dpkg-source: info: applying 0004-Fix-spurious-warnings-about-unknown-virtual-dependen.patch +dpkg-source: info: applying 0005-Fix-spelling-error-in-manpage.patch + debian/rules clean +echo -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection dh clean --with=bash-completion dh_auto_clean @@ -18,7 +25,7 @@ make[1]: Leaving directory '/home/mark/insserv-1.24.0' dh_clean debian/rules build -echo -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection +echo -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection dh build --with=bash-completion dh_update_autotools_config @@ -31,14 +31,14 @@ cc -W -Wall -Wunreachable-code -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DINITDIR=\"/etc/init.d\" -DINSCONF=\"/etc/insserv.conf\" -pipe -c map.c cc -W -Wall -Wunreachable-code -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DINITDIR=\"/etc/init.d\" -DINSCONF=\"/etc/insserv.conf\" -pipe -c listing.c cc -W -Wall -Wunreachable-code -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DINITDIR=\"/etc/init.d\" -DINSCONF=\"/etc/insserv.conf\" -pipe insserv.c -c -insserv.c: In function ‘main’: -insserv.c:2923:20: warning: ignoring return value of ‘asprintf’ declared with attribute ‘warn_unused_result’ [-Wunused-result] +insserv.c: In function 'main': +insserv.c:2923:20: warning: ignoring return value of 'asprintf' declared with attribute 'warn_unused_result' [-Wunused-res
Bug#1052942: insserv: FTBFS: insserv: Could not read script nolsbheader: No such file or directory
Lucas, I am afraid I still cannot reproduce this. I attach my successful .buildinfo. What are the differences to yours? Thanks Mark Format: 1.0 Source: insserv Binary: insserv insserv-dbgsym Architecture: amd64 Version: 1.24.0-1 Checksums-Md5: 3c928ff0990c2942950fa368b3978086 79480 insserv-dbgsym_1.24.0-1_amd64.deb 9bffd1e3395d57a5979030bc472dc80c 50572 insserv_1.24.0-1_amd64.deb Checksums-Sha1: aa26018adc027c1af58704991d3339c1a43dccf2 79480 insserv-dbgsym_1.24.0-1_amd64.deb 1d1a7b8f6e5b5ea864a7661f34e767b9a93e4b77 50572 insserv_1.24.0-1_amd64.deb Checksums-Sha256: 39912ad2e18538a91ae397467a6cd96519dd948fee2ed90b39c40b4477352bc1 79480 insserv-dbgsym_1.24.0-1_amd64.deb e4e58a1a6a3cb6a68e205341606b1702ef10dd5bd6d43af03e123b536b4cc8f8 50572 insserv_1.24.0-1_amd64.deb Build-Origin: Debian Build-Architecture: amd64 Build-Date: Sun, 29 Oct 2023 13:16:40 + Build-Path: /build/insserv-1.24.0 Build-Tainted-By: merged-usr-via-aliased-dirs Installed-Build-Depends: autoconf (= 2.71-3), automake (= 1:1.16.5-1.3), autopoint (= 0.21-12), autotools-dev (= 20220109.1), base-files (= 13), base-passwd (= 3.6.1), bash (= 5.2.15-2+b2), bash-completion (= 1:2.11-8), binutils (= 2.40.50.20230625-1), binutils-common (= 2.40.50.20230625-1), binutils-x86-64-linux-gnu (= 2.40.50.20230625-1), bsdextrautils (= 2.38.1-5+b1), bsdutils (= 1:2.38.1-5+b1), build-essential (= 12.10), bzip2 (= 1.0.8-5+b1), coreutils (= 9.1-1), cpp (= 4:12.3.0-1), cpp-10 (= 10.4.0-9), cpp-11 (= 11.4.0-1), cpp-12 (= 12.3.0-5), cpp-6 (= 6.5.0-2), cpp-8 (= 8.4.0-4), cpp-9 (= 9.5.0-3), dash (= 0.5.12-6), debconf (= 1.5.82), debhelper (= 13.11.4), debianutils (= 5.7-0.4), dh-autoreconf (= 20), dh-strip-nondeterminism (= 1.13.1-1), diffutils (= 1:3.8-4), dpkg (= 1.21.22), dpkg-dev (= 1.21.22), dwz (= 0.15-1), file (= 1:5.44-3), findutils (= 4.9.0-4), g++ (= 4:12.3.0-1), g++-12 (= 12.3.0-5), gcc (= 4:12.3.0-1), gcc-10 (= 10.4.0-9), gcc-10-base (= 10.4.0-9), gcc-11 (= 11.4.0-1), gcc-11-base (= 11.4.0-1), gcc-12 (= 12.3.0-5), gcc-12-base (= 12.3.0-5), gcc-13-base (= 13.1.0-7), gcc-6 (= 6.5.0-2), gcc-6-base (= 6.5.0-2), gcc-7-base (= 7.4.0-14), gcc-8 (= 8.4.0-4), gcc-8-base (= 8.4.0-4), gcc-9 (= 9.5.0-3), gcc-9-base (= 9.5.0-3), gettext (= 0.21-12), gettext-base (= 0.21-12), grep (= 3.8-5), groff-base (= 1.22.4-10), gzip (= 1.12-1), hostname (= 3.23+nmu1), init-system-helpers (= 1.65.2), intltool-debian (= 0.35.0+20060710.6), libacl1 (= 2.3.1-3), libarchive-zip-perl (= 1.68-1), libasan3 (= 6.5.0-2), libasan5 (= 9.5.0-3), libasan6 (= 11.4.0-1), libasan8 (= 13.1.0-7), libatomic1 (= 13.1.0-7), libattr1 (= 1:2.5.1-4), libaudit-common (= 1:3.0.9-1), libaudit1 (= 1:3.0.9-1), libbinutils (= 2.40.50.20230625-1), libblkid1 (= 2.38.1-5+b1), libbz2-1.0 (= 1.0.8-5+b1), libc-bin (= 2.36-9), libc-dev-bin (= 2.36-9), libc6 (= 2.36-9), libc6-dev (= 2.36-9), libcap-ng0 (= 0.8.3-1+b3), libcap2 (= 1:2.66-4), libcc1-0 (= 13.1.0-7), libcilkrts5 (= 7.4.0-14), libcom-err2 (= 1.47.0-2), libcrypt-dev (= 1:4.4.35-1), libcrypt1 (= 1:4.4.35-1), libctf-nobfd0 (= 2.40.50.20230625-1), libctf0 (= 2.40.50.20230625-1), libdb5.3 (= 5.3.28+dfsg2-1), libdebconfclient0 (= 0.270), libdebhelper-perl (= 13.11.4), libdpkg-perl (= 1.21.22), libelf1 (= 0.188-2.1), libfile-find-rule-perl (= 0.34-3), libfile-stripnondeterminism-perl (= 1.13.1-1), libgcc-10-dev (= 10.4.0-9), libgcc-11-dev (= 11.4.0-1), libgcc-12-dev (= 12.3.0-5), libgcc-6-dev (= 6.5.0-2), libgcc-8-dev (= 8.4.0-4), libgcc-9-dev (= 9.5.0-3), libgcc-s1 (= 13.1.0-7), libgcrypt20 (= 1.10.2-2), libgdbm-compat4 (= 1.23-3), libgdbm6 (= 1.23-3), libgmp10 (= 2:6.2.1+dfsg1-1.1), libgomp1 (= 13.1.0-7), libgpg-error0 (= 1.46-1), libgprofng0 (= 2.40.50.20230625-1), libgssapi-krb5-2 (= 1.20.1-2), libicu72 (= 72.1-3), libisl19 (= 0.20-2), libisl22 (= 0.22.1-1), libisl23 (= 0.26-3), libitm1 (= 13.1.0-7), libjansson4 (= 2.14-2), libk5crypto3 (= 1.20.1-2), libkeyutils1 (= 1.6.3-2), libkrb5-3 (= 1.20.1-2), libkrb5support0 (= 1.20.1-2), liblsan0 (= 13.1.0-7), liblz4-1 (= 1.9.4-1), liblzma5 (= 5.4.1-0.2), libmagic-mgc (= 1:5.44-3), libmagic1 (= 1:5.44-3), libmd0 (= 1.1.0-1), libmount1 (= 2.38.1-5+b1), libmpc3 (= 1.3.1-1), libmpfr6 (= 4.2.0-1), libmpx2 (= 8.4.0-4), libnsl-dev (= 1.3.0-2), libnsl2 (= 1.3.0-2), libnumber-compare-perl (= 0.03-3), libpam-modules (= 1.5.2-6), libpam-modules-bin (= 1.5.2-6), libpam-runtime (= 1.5.2-6), libpam0g (= 1.5.2-6), libpcre2-8-0 (= 10.42-1), libperl5.36 (= 5.36.0-7), libpipeline1 (= 1.5.7-1), libquadmath0 (= 13.1.0-7), libseccomp2 (= 2.5.4-1+b3), libselinux1 (= 3.4-1+b6), libsmartcols1 (= 2.38.1-5+b1), libssl3 (= 3.0.9-1), libstdc++-12-dev (= 12.3.0-5), libstdc++6 (= 13.1.0-7), libsub-override-perl (= 0.09-4), libsystemd0 (= 253-4), libtext-glob-perl (= 0.11-3), libtinfo6 (= 6.4-4), libtirpc-common (= 1.3.3+ds-1), libtirpc-dev (= 1.3.3+ds-1), libtirpc3 (= 1.3.3+ds-1
Bug#1052942: insserv: FTBFS: insserv: Could not read script nolsbheader: No such file or directory
Control: tags -1 moreinfo
Ian
On Wed, Sep 27, 2023 at 10:33:32PM +0100, Ian Jackson wrote:
> Mark Hindley writes ("Bug#1052942: insserv: FTBFS: insserv: Could not read
> script nolsbheader: No such file or directory"):
> > Thanks for this. However, I am currently unable to repoduce this
> > failure in my customary pbuilder setup. And it doesn't appear at
> > reproducible builds either[1]
>
> I just tried this myself with my usual sbuild setup and it succeeded
> there too[1].
Thanks for your confirmation.
> Lucas, I think something from your rebuild environment
> (a chroot of some kind I presume) must be triggering this failure. Is
> there some way we can reproduce it more precisely (eg, a buildinfo
> file?)
Yes, I agree a buildinfo file might give a hint.
> I looked at the build log
> http://qa-logs.debian.net/2023/09/25/insserv_1.24.0-1_unstable.log
> and compared it to the one from my sbuild, using diff. There are a
> lot of changes to the "furniture" but also there are noise changes to
> the output of the insserv test suite, including ordring changes of
> passing tests. This seemed surprising to me.
>
> Mark, is the insserv test suite supposed to produce deterministic
> output ?
I have never had the need to look at the testsuite since I started looking after
the package. A quick look now doesn't immediately reveal something that would
obviously change the order of the tests.
I tried again locally with make -j8 and still could not reproduce any failure.
Mark
Bug#1052942: insserv: FTBFS: insserv: Could not read script nolsbheader: No such file or directory
Control: tags -1 unreproducible
Lucas,
Thanks for this. However, I am currently unable to repoduce this failure in my
customary pbuilder setup. And it doesn't appear at reproducible builds either[1]
On Tue, Sep 26, 2023 at 03:45:26PM +0200, Lucas Nussbaum wrote:
> If you fail to reproduce this, please provide a build log and diff it with
> mine
> so that we can identify if something relevant changed in the meantime.
My successful pbuilder log is attached.
Mark
[1]
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/insserv.html
dpkg-checkbuilddeps: error: Unmet build dependencies: debhelper-compat (= 13)
po-debconf
W: Unmet build-dependency in source
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying install-binaries-ignore-PREFIX.patch
dpkg-source: info: applying 11_debian_conf.patch
dpkg-source: info: applying 110_portmap.patch
dpkg-source: info: applying warn_in_ignore_mode.patch
dpkg-source: info: applying
0004-Fix-spurious-warnings-about-unknown-virtual-dependen.patch
dpkg-source: info: applying 0005-Fix-spelling-error-in-manpage.patch
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building insserv using existing ./insserv_1.24.0.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building insserv in insserv_1.24.0-1.debian.tar.xz
dpkg-source: info: building insserv in insserv_1.24.0-1.dsc
I: Generated dsc will be overwritten by build result; not generating changes
file
dpkg-source: info: unapplying 0005-Fix-spelling-error-in-manpage.patch
dpkg-source: info: unapplying
0004-Fix-spurious-warnings-about-unknown-virtual-dependen.patch
dpkg-source: info: unapplying warn_in_ignore_mode.patch
dpkg-source: info: unapplying 110_portmap.patch
dpkg-source: info: unapplying 11_debian_conf.patch
dpkg-source: info: unapplying install-binaries-ignore-PREFIX.patch
I: Copying COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.20068
I: forking: cp -al /var/cache/pbuilder/base-sid.cow
/var/cache/pbuilder/build/cow.20068
I: removed stale ilistfile /var/cache/pbuilder/build/cow.20068/.ilist
I: forking: chroot /var/cache/pbuilder/build/cow.20068 cowdancer-ilistcreate
/.ilist 'find . -xdev -path ./home -prune -o \( \( -type l -o -type f \) -a
-links +1 -print0 \) | xargs -0 stat --format '%d %i ''
I: Invoking pbuilder
I: forking: pbuilder build --debbuildopts --debbuildopts ' '--no-pre-clean''
--buildplace /var/cache/pbuilder/build/cow.20068 --buildresult
/home/mark/src/debian/build --mirror http://deb.debian.org/debian
--distribution sid --no-targz --internal-chrootexec 'chroot
/var/cache/pbuilder/build/cow.20068 cow-shell'
/home/mark/src/debian/build/insserv_1.24.0-1.dsc
I: Running in no-targz mode
I: pbuilder: network access will be disabled during build
I: Current time: Tue Sep 26 17:05:48 BST 2023
I: pbuilder-time-stamp: 1695744348
I: copying local configuration
W: --override-config is not set; not updating apt.conf Read the manpage for
details.
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: redirecting /dev/ptmx to /dev/pts/ptmx
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [/home/mark/src/debian/build/insserv_1.24.0-1.dsc]
I: copying [/home/mark/src/debian/build/insserv_1.24.0.orig.tar.gz]
I: copying [/home/mark/src/debian/build/insserv_1.24.0-1.debian.tar.xz]
I: Extracting source
dpkg-source: warning: extracting unsigned source package (insserv_1.24.0-1.dsc)
dpkg-source: info: extracting insserv in insserv-1.24.0
dpkg-source: info: unpacking insserv_1.24.0.orig.tar.gz
dpkg-source: info: unpacking insserv_1.24.0-1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying install-binaries-ignore-PREFIX.patch
dpkg-source: info: applying 11_debian_conf.patch
dpkg-source: info: applying 110_portmap.patch
dpkg-source: info: applying warn_in_ignore_mode.patch
dpkg-source: info: applying
0004-Fix-spurious-warnings-about-unknown-virtual-dependen.patch
dpkg-source: info: applying 0005-Fix-spelling-error-in-manpage.patch
I: using fakeroot in build.
I: Installing the build-deps
I: user script /var/cache/pbuilder/build/cow.20068/tmp/hooks/D04add-backports
starting
I: user script /var/cache/pbuilder/build/cow.20068/tmp/hooks/D04add-backports
finished
I: user script /var/cache/pbuilder/build/cow.20068/tmp/hooks/D05apt-update
starting
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
Get:1 http://deb.debian.org/debian unstable InRelease [195 kB]
Get:2 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index
[63.6 kB]
Ign:2 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index
Get:3 http://deb.debian.org/debian unstable/main Translation-en.diff/Index
[63.6 kB]
Ign:3 http://deb.debian.org/debian unstable/main Translatio
Bug#1050375: Invalid command name "pg_connect"
Control: reassign -1 libpgtcl Control: retitle -1 libpgtcl not installed in default Tcl search path. On Wed, Aug 23, 2023 at 08:09:48PM +0200, Christoph Berg wrote: > Package: pfm > Version: 2.0.8-3 > Severity: grave > > pfm doesn't do anything useful here, it just produces a message popup > saying > > Connection to database foo has failed: > > invalid command name "pg_connect" Thanks. I believe this needs fixing in libpgtcl. Reassigning. Mark
Bug#1052316: udev postinst uses update-rc.d -f remove which breaks /etc.init.d/udev transition and non-systemd boot
Package: udev Version: 254.3-1 Severity: serious Justification: Breaks unrelated software, causes boot failure on some systems Dear systemd Maintainers, As reported in the follow-up to #1052116[1], udev's postinst uses update-rc.d's -f option which breaks the transition of /etc/init.d/udev to bin:initscripts and causes non-systemd systems to fail to boot. Michael, as discussed yesterday on #debian-systemd, I am very grateful for your quick commit of a fix[2]. This bug is to prevent unintended migration of the broken udev to trixie. With thanks and best wishes Mark [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052116#17 [2] https://salsa.debian.org/systemd-team/systemd/-/commit/12e2c67612f958148f0a4ca165cfb9ca1ed9d3c3 -- System Information: Debian Release: 12.0 merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#1028664: colord: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 meson test --timeout-multiplier 3 returned exit code 1
Control: reassign -1 liblcms2-2 2.14-1 Control: affects -1 colord I hit this FTBFS today. The gdb backtrace of the failing test is Thread 1 "colord-test-pri" received signal SIGSEGV, Segmentation fault. 0x77bd359a in cmsMLUtranslationsCodes () from /usr/lib/x86_64-linux-gnu/liblcms2.so.2 (gdb) bt #0 0x77bd359a in cmsMLUtranslationsCodes () at /usr/lib/x86_64-linux-gnu/liblcms2.so.2 #1 0x77f9c598 in cd_icc_to_string (icc=icc@entry=0x5559e2c0) at ../lib/colord/cd-icc.c:435 #2 0x55566c4e in colord_icc_func () at ../lib/colord/cd-test-private.c:1529 #3 0x77c8764e in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x77c873b5 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x77c87b52 in g_test_run_suite () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #6 0x77c87bbd in g_test_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #7 0xb428 in main (argc=, argv=) at ../lib/colord/cd-test-private.c:2400 (gdb) I suppose this has been caused by the upload of version 2.14-1 of liblcms2-2, but I don't immediately see the change there that has caused it. Reassigning. Mark
Bug#1025869: marked as pending in tigervnc
Hi Joachim, Thank you! I installed the patched .pm files and retested. *One error is fixed:* Can't locate object method "cleanup" via package "File::Temp::Dir" at /usr/share/perl5/TigerVNC/Wrapper.pm line 1347, line 100.) *The other error still remains:* $ x0vncserver -display :0 -SecurityTypes None *result:* [usage is printed] then x0vncserver: /usr/bin/X0tigervnc exited with status 1, please look into '/home/mark/.vnc/[redacted]:5900.log' to determine the reason! -2 /home/mark/.vnc/[redacted]:5900.log contains only the same information as above under result: *Note that the following does not return an error.* * * *X0tigervnc* -display :0 -SecurityTypes None I hope that helps. Thank you! Mark On Sat, Dec 17, 2022, at 11:15 AM, Joachim Falk wrote: > Control: tag -1 pending > > Hello, > > Bug #1025869 in tigervnc reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/debian-remote-team/tigervnc/-/commit/b0e4724c81f7dc9198c4685839ff38b35e5a1543 > > > Fixed some undef warnings and a tempdir cleanup error (closes: #1025869) > > > (this message was generated automatically) > -- > Greetings > > https://bugs.debian.org/1025869 >
Bug#1025869: Acknowledgement (tigervnc-scraping-server: Under bookworm server fails to start. Gives error in Wrapper.pm)
Additional info: TigerVNC says that this is an issue with Debian script, not an upstream issue with them. https://github.com/TigerVNC/tigervnc/issues/1560#issuecomment-1351443752
Bug#1025869: tigervnc-scraping-server: Under bookworm server fails to start. Gives error in Wrapper.pm
Package: tigervnc-scraping-server Version: 1.12.0+dfsg-5 Severity: grave Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** TigerVNC Server version 1.12.0, built 2022-07-09 14:10 Debian Testing (Bookworm) Try to start server: $x0vncserver -display:0 -SecurityTypes None Result: 0vncserver: /usr/bin/X0tigervnc exited with status 1, please look into '/home/mark/.vnc/[machine-name-redacted]:5900.log' to determine the reason! -2 Can't locate object method "cleanup" via package "File::Temp::Dir" at /usr/share/perl5/TigerVNC/Wrapper.pm line 1347, line 100. Looking at the referenced log file, there are no details. It just contains the usage. I am not a developer. I can test software if provided with a binary but find compiling challenging. Thank you! -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tigervnc-scraping-server depends on: ii libc6 2.36-4 ii libfile-readbackwards-perl 1.06-2 ii libgcc-s1 12.2.0-9 ii libgnutls30 3.7.8-4 ii libjpeg62-turbo 1:2.1.2-1+b1 ii libpam0g1.5.2-5 ii libpixman-1-0 0.40.0-1.1 ii libstdc++6 12.2.0-9 ii libx11-62:1.8.1-2 ii libxdamage1 1:1.1.5-2 ii libxext62:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxrandr2 2:1.5.2-2+b1 ii libxtst62:1.2.3-1.1 ii perl5.34.0-5 ii tigervnc-common 1.12.0+dfsg-5 ii zlib1g 1:1.2.11.dfsg-4.1 Versions of packages tigervnc-scraping-server recommends: ii tigervnc-tools 1.12.0+dfsg-5 Versions of packages tigervnc-scraping-server suggests: ii openssl 3.0.7-1 -- no debconf information
Bug#1019661: Breaks monin and maybe other packages
Klaus, On Tue, Sep 13, 2022 at 12:16:33PM +0100, Klaus Ethgen wrote: > Package: lsb-base > Version: 11.3 > Severity: critical > > The new package breaks monin as it does not provide > /lib/lsb/init-functions anymore. This file has been moved to sysvinit-utils. Which version of that do you have installed? Mark
Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations
Andreas, On Tue Aug 30 23:05:59 2022 Andreas Beckmann wrote: > Followup-For: Bug #1009915 > Control: found -1 3.05-1 > > Hi, > > there seems to be one manpage (in bootlogd) missing conflict handling: > > /usr/share/man/fr/man8/bootlogd.8.gz Thanks. I was under the impression that manpages-i10n had changed to systemd versions (which doesn't have bootlogd.8) but apparently not. I think we should continue to use the manpages-i10n version and not have any more dpkg diversions than are absolutely necessary. I am away for a week, but will resolve this once I am back. Mark
Bug#1012674: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)
On Wed, Jul 27, 2022 at 09:00:09PM +0200, vollan...@gmail.com wrote: > There is no licence on this code, it is juste free!! If that's the goal they should have a clear statement that they're in the public domain, without an explicit license grant of some kind the default is that things are copyrighted and all rights reserved. signature.asc Description: PGP signature
Bug#915850: rsnapshot: reproducible build (usrmerge): embeds path of tool found via PATH
Control: tags -1 pending Simon, Thanks for this. On Sun, Jul 17, 2022 at 01:15:42PM +0100, Simon McVittie wrote: > Control: reopen -1 > Control: severity -1 serious > > On Fri, 24 Jun 2022 at 13:12:07 +, Debian Bug Tracking System forwarded: > > * d/rules: specify PATH for build so unmerged usr paths are discovered > > first (Closes: #915850). > > Sorry, this does not solve the problem. More precisely, it solves the > problem as originally reported (for cp, rm, lvcreate, etc.), but also > causes the opposite problem for tools that are canonically in /usr/bin > (rsync, ssh, logger, du, perl). Yes, I had realised this and have already queued the patch that was originally suggested. Mark
Bug#1013916: missing dependency
Control: tags -1 patch
Georges,
I have bumped into this issue as well.
A patch to fix is below.
Thanks,
Mark
>From 88e5b316d6ad0587226e17b010d7c43e75d4815d Mon Sep 17 00:00:00 2001
From: Mark Hindley
Date: Thu, 14 Jul 2022 12:50:18 +0100
Subject: [PATCH] d/control: move adduser dependency to cron-daemon-common
(Closes: #1013916).
d/cron-daemon-common.postinst uses addgroup. When the -common package was
created, moving the adduser dependency was overlooked.
---
debian/control | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/debian/control b/debian/control
index 8f00824..a7f2bab 100644
--- a/debian/control
+++ b/debian/control
@@ -24,7 +24,6 @@ Depends:
${shlibs:Depends},
${misc:Depends},
sensible-utils,
-adduser,
lsb-base,
libpam-runtime
Recommends:
@@ -58,7 +57,8 @@ Description: process scheduling daemon
Package: cron-daemon-common
Architecture: all
-Depends: ${misc:Depends}
+Depends: ${misc:Depends},
+adduser,
Conflicts:
cron (<< 3.0pl1-140),
cronie (<< 1.6.1-4),
--
2.35.1
Bug#1014730: liburi-perl: Breaks apt-cacher with "Can't locate Regexp/IPv6.pm" error
Hi,
On Tue, Jul 12, 2022 at 07:31:48AM +0100, Mark Hindley wrote:
> > Corresponding untested patch against apt-cacher attached.
>
> The problem with this approach is that errors from apt-cacher's own evals will
> be skipped as well.
I think the patch below might be a better approach. It preserves the logging
output which is an important function of die_handler().
Robert, are you able to test this?
Thanks.
Mark
>From ae98977a1747350ee6659408bc8b08c366a7116d Mon Sep 17 00:00:00 2001
From: Mark Hindley
Date: Tue, 12 Jul 2022 13:25:37 +0100
Subject: [PATCH] Don't exit in die_handler() if called from eval.
$SIG{__DIE__} hook is called from evals.
Closes: #1014730
---
apt-cacher | 1 +
1 file changed, 1 insertion(+)
diff --git a/apt-cacher b/apt-cacher
index a8c00cb..56eccf8 100755
--- a/apt-cacher
+++ b/apt-cacher
@@ -1255,6 +1255,7 @@ sub write_error_log {
sub die_handler {
my ($msg) = @_;
write_error_log("error [$$]: $msg");
+return if $^S; # In eval block
sendrsp(HTTP::Response->new(502, 'apt-cacher internal error (died)',
['Connection' => 'close'])) if $con;
exit 1;
}
--
2.35.1
Bug#1014730: liburi-perl: Breaks apt-cacher with "Can't locate Regexp/IPv6.pm" error
Niko,
On Mon, Jul 11, 2022 at 09:26:12PM +0300, Niko Tyni wrote:
> [apt-cacher maintainers: the context here is that URI.pm introduced an
> optional dependency on Regexp::IPv6 by requiring it in an eval block,
> but the apt-cacher __DIE__ handler exits when the require fails.]
Thanks for including me.
> On Mon, Jul 11, 2022 at 05:35:17PM +0200, gregor herrmann wrote:
>
> > So we have:
> > - do nothing
> > - patch URI to restart the default signal handler in the eval
> > - (reassign? and) do something in apt-cacher
>
> I'm not really sure if there's a consensus on best practices around
> $SIG{__DIE__}.
I agree, although perlvar suggests it should be avoided completely:
Having to even think about the $^S variable in your exception handlers
is simply wrong. $SIG{__DIE__} as currently implemented invites
grievous and difficult to track down errors. Avoid it and use an
"END{}" or CORE::GLOBAL::die override instead.
I don't know when that was added. I don't remember reading it before.
> IMO apt-cacher is the one that should be fixed, rather
> than demanding that all the modules it uses need to reset and restore
> $SIG{__DIE__} before catching exceptions.
>
> >From 'perldoc -f die' :
>
> You can arrange for a callback to be run just before the "die"
> does its deed, by setting the $SIG{__DIE__} hook. The associated
> handler is called with the exception as an argument, and can
> change the exception, if it sees fit, by calling "die" again.
> See "%SIG" in perlvar for details on setting %SIG entries, and
> "eval" for some examples. Although this feature was to be run only
> right before your program was to exit, this is not currently so:
> the $SIG{__DIE__} hook is currently called even inside "eval"ed
> blocks/strings! If one wants the hook to do nothing in such
> situations, put
>
> die @_ if $^S;
>
> as the first line of the handler (see "$^S" in perlvar). Because
> this promotes strange action at a distance, this counterintuitive
> behavior may be fixed in a future release.
>
> Corresponding untested patch against apt-cacher attached.
The problem with this approach is that errors from apt-cacher's own evals will
be skipped as well.
Mark
Bug#1012674: NMU: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)
On Mon, Jul 11, 2022 at 06:54:13PM +0200, Bastian Germann wrote: > Am 11.07.22 um 18:40 schrieb Mark Brown: > > On Mon, Jul 11, 2022 at 06:16:31PM +0200, Bastian Germann wrote: > > > I have uploaded zlib 1.2.12.dfsg-0.1 with the changes attached to > > > DELAYED/3. > > Why? Please drop this. > Okay. When are you going to address this bug then? > It has been a month not reacting to the RC bug. > I think this is not acceptable for a key package such as zlib. I'm not sure what there is to react to here other than doing an upload; it's a packaging thing more than something causing active breakage for users and we're nowhere near to doing a release yet so there didn't seem a huge sense of urgency here so I'd been going to roll it into packaging the new upstream release. The bug gives the air of being from an audit and in those cases you do have to balance keeping people up to date with creating noise for submitters and there's been no followup requests for status or anything. I have been hoping that we're going to get another upstream release which rolls in some of the fixes for the string of problems that people have been having with the security fix release that was recently done though that is looking depressingly unlikely and so I need to figure out what needs backporting. Given the release schedule startng to kick off at the beginning of next year it'll be some time this year, I'd guess some time this quarter. In any case this upload isn't a targetted fix for the individual issue, it's got a whole bunch of other unrelated changes including a new upstream release which are clearly out of scope. Like I say I have substantial concerns about the new upstream release so that having been rolled in is especially worrying. signature.asc Description: PGP signature
Bug#1012674: NMU: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)
On Mon, Jul 11, 2022 at 06:16:31PM +0200, Bastian Germann wrote: > I have uploaded zlib 1.2.12.dfsg-0.1 with the changes attached to DELAYED/3. Why? Please drop this. signature.asc Description: PGP signature
Bug#1013248: libseat-dev: Missing libseat-dev dependency on libsystemd-dev via pkg-config
Control: tags -1 pending
Control: retitle -1 libseat-dev: libseat.pc contains unnecessary
Requires.private: libsystemd
Braiam,
Thanks for this.
On Sun, Jun 19, 2022 at 08:32:22PM -0400, Braiam Peguero wrote:
> pkgconfig/libseat.pc includes dependency on libsystemd:
>
> $ cat /usr/lib/x86_64-linux-gnu/pkgconfig/libseat.pc
> prefix=/usr
> includedir=${prefix}/include
> libdir=${prefix}/lib/x86_64-linux-gnu
>
> have_seatd=true
> have_logind=true
> have_builtin=true
>
> Name: libseat
> Description: Seat management library
> Version: 0.7.0
> Requires.private: libsystemd
I think this is unecessary. I have been investigating where it comes from and
why it is there.
In short, src:seatd upstream also build libseat as a static library. If you were
to link against that you would also require libsystemd as the logind backend in
built-in in our configuration.
However, the Debian package does not include the static library and my
perception is that static libraries are, at best, optional and generally
discouraged in Debian.
The pkg-config syntax appears inadequate to cover the case where a static
version of a library has a dependency additional to the shared. There is a long
and unresolved discussion about this[1].
Meson generates libseat.pc and there is another, also unresolved, meson
discussion[2] that Requires.private should be omitted when building shared
libraries. This also contains the suggestion that is my chosen fix[2]: namely to
patch meson.build to use shared_library() rather than library().
Mark
[1] https://bugs.freedesktop.org/105572.
[2] https://github.com/mesonbuild/meson/issues/3970
[3] https://github.com/mesonbuild/meson/issues/3970#issuecomment-410224556
Bug#1008889: FTBFS: Build-depends libltdl3-dev which is no longer available
Package: cluster-glue Version: 1.0.12-20 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear Maintainer, src:cluster-glue FTBFS in unstable as the build dependency on libltdl3-dev is no longer available. Thanks. Mark -- System Information: Debian Release: bookworm/sid Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-4-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages cluster-glue depends on: ii adduser 3.121 ii bzip21.0.8-5 ii init-system-helpers 1.62devuan1 ii libbz2-1.0 1.0.8-5 ii libc62.33-7 ii libcurl4 7.82.0-2 ii libglib2.0-0 2.72.0-1 pn liblrm2 pn libopenhpi3 pn libopenipmi0 pn libpils2 pn libplumb2 pn libplumbgpl2 ii libsnmp405.9.1+dfsg-1+b1 pn libstonith1 ii libtimedate-perl 2.3300-2 ii libxml2 2.9.13+dfsg-1 ii lsb-base 11.1.0 ii perl 5.34.0-3 ii python3 3.9.8-1 ii python3.93.9.12-1 ii zlib1g 1:1.2.11.dfsg-4 cluster-glue recommends no packages. Versions of packages cluster-glue suggests: pn ipmitool
Bug#1008265: CVE-2018-25032: zlib memory corruption on deflate
On Fri, Mar 25, 2022 at 10:50:51PM +0100, Salvatore Bonaccorso wrote: > Here is a preliminary debdiff to address this. Thanks, that's roughly what I uploaded - it looks like your mail raced with my own update. signature.asc Description: PGP signature
Bug#1006308: closed by Debian FTP Masters (reply to Mark Hindley ) (Bug#1006308: fixed in seatd 0.6.4-1)
Salvatore, On Wed, Feb 23, 2022 at 10:14:59AM +0100, Salvatore Bonaccorso wrote: > Thanks for the quick fix! > > Note there is a typo in the CVE, should have been CVE-2022-25643. Evidently too quick! Thanks for pointing it out. Would you prefer a new upload to fix it now or wait for the next routine one? Mark
Bug#999155: ping
On Mon, Jan 24, 2022 at 05:51:43PM +0100, Thorsten Alteholz wrote: > In order have some activity on this bug and to avoid autoremoval of > dependencies, this is a reminder of outstanding things to do ... Please don't send content free pings, they just add noise and make it likely that it's going to take longer (since I remember that I did something but forget that it was just handling the ping). signature.asc Description: PGP signature
Bug#999155: RC bug in mm and zlib
On Wed, Jan 05, 2022 at 12:57:47PM +0100, Thorsten Alteholz wrote: > are you already working on an update of mm and zlib? Or do you need some > help? They're utterly trivial, I'll get round to them at some point when I do a batch run through all my packages. It'd be more effort to integrate something. signature.asc Description: PGP signature
Bug#996764: FTBFS: test misc/swaplabel failure
Chris,
On Mon, Oct 18, 2021 at 03:17:14PM +0200, Chris Hofstaedtler wrote:
> Could you add your Signed-off-by: to the patch, so I can forward it
> upstream? (Or you could send it to util-li...@vger.kernel.org
> directly, too.)
Yes, of course. Attached. I'll leave you to send it upstream, so everything is
in one place. Hope that is OK.
Best wishes
Mark
>From b2e6485bbb9e9ce1929d8ba4a3aa0965a52cd52f Mon Sep 17 00:00:00 2001
From: Mark Hindley
Date: Sun, 17 Oct 2021 20:25:47 +0100
Subject: [PATCH] Fix test/misc/swaplabel failure due to change in mkswap
behaviour.
mkswap now warns if the image file has holes. If fallocate is used to create the
file, use POSIX semantics to ensure the file has no holes.
This fixes the test failure
misc: swaplabel ... FAILED (misc/swaplabel)
= script: /build/util-linux-2.37.2/tests/ts/misc/swaplabel =
= OUTPUT =
1 Setting up swapspace version 1, size = 9 pages (9xPGSZ bytes)
2 LABEL=1234567890abcde, UUID=12345678-abcd-abcd-abcd-1234567890ab
3 LABEL: 1234567890abcde
4 UUID: 12345678-abcd-abcd-abcd-1234567890ab
= EXPECTED ===
1 Setting up swapspace version 1, size = 9 pages (9xPGSZ bytes)
2 LABEL=1234567890abcde, UUID=12345678-abcd-abcd-abcd-1234567890ab
3 LABEL: 1234567890abcde
4 UUID: 12345678-abcd-abcd-abcd-1234567890ab
= O/E diff ===
==
The additional error appears in swaplabel.err:
mkswap: contains holes or other unsupported extents.
This swap file can be rejected by kernel on swap activation!
Use --verbose for more details.
Signed-off-by: Mark Hindley
---
tests/ts/misc/swaplabel | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/ts/misc/swaplabel b/tests/ts/misc/swaplabel
index 0801cb213..8b1abb5c3 100755
--- a/tests/ts/misc/swaplabel
+++ b/tests/ts/misc/swaplabel
@@ -25,7 +25,7 @@ ts_check_test_command "$TS_HELPER_SYSINFO"
# fallocate does not work on most file systems
function fallocate_or_skip()
{
- $TS_CMD_FALLOCATE -l $1 $2 2>/dev/null || \
+ $TS_CMD_FALLOCATE -x -l $1 $2 2>/dev/null || \
truncate -s $1 $2 || \
ts_skip "no way to create test image"
}
--
2.20.1
Bug#996764: FTBFS: test misc/swaplabel failure
Package: util-linux
Version: 2.37.2-3
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
Chris,
Whilst building a local version of util-linux 2.37.2-3, the misc/swaplabel test
failed.
I believe this is caused by the change in behaviour of mkswap, which now
complains on stderr if the provided image contains holes. My build environment
is pbuilder/cowbuilder chroot with /var/cache/pbuilder mounted as
ext3. Apparently the call to fallocate() in tests/ts/misc/swaplabel allocates a
file with holes that mkswap then complains about. The additional, unexpected
text in /build/util-linux-2.37.2/tests/output/misc/swaplabel.err is:
mkswap: contains holes or other unsupported extents.
This swap file can be rejected by kernel on swap activation!
Use --verbose for more details.
which directly causes the failure.
I have worked around it with the attached patch which invokes fallocate() with
the -x flag. Although, I suppose fallocate could be dispensed with and truncate
always used instead.
Best wishes
Mark
-- System Information:
Debian Release: 10.0
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-17-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages util-linux depends on:
ii fdisk 2.33.1-0.1+devuan1~beowulf2
ii libaudit1 1:2.8.4-3
ii libblkid1 2.33.1-0.1+devuan1~beowulf2
ii libc6 2.28-10
ii libcap-ng0 0.7.9-2
ii libeudev1 3.2.9-9~beowulf1
ii libmount1 2.33.1-0.1+devuan1~beowulf2
ii libpam0g 1.3.1-5
ii libselinux12.8-1+b1
ii libsmartcols1 2.33.1-0.1+devuan1~beowulf2
ii libtinfo6 6.1+20181013-2+deb10u2
ii libuuid1 2.33.1-0.1+devuan1~beowulf2
ii login 1:4.5-1.1
ii zlib1g 1:1.2.11.dfsg-1
util-linux recommends no packages.
Versions of packages util-linux suggests:
ii dosfstools 4.1-2
ii kbd 2.0.4-4
ii util-linux-locales 2.33.1-0.1+devuan1~beowulf2
-- no debconf information
>From 03a585290d86b74d4861e11569c426362c8b853c Mon Sep 17 00:00:00 2001
From: Mark Hindley
Date: Sun, 17 Oct 2021 20:25:47 +0100
Subject: [PATCH 1/1] Fix test/misc/swaplabel failure due to change in mkswap
behaviour.
mkswap now warns if the image file has holes. If fallocate is used to create the
file, use POSIX semantics to ensure the file has no holes.
This fixes the test failure
misc: swaplabel ... FAILED (misc/swaplabel)
= script: /build/util-linux-2.37.2/tests/ts/misc/swaplabel
=
= OUTPUT =
1 Setting up swapspace version 1, size = 9 pages (9xPGSZ bytes)
2 LABEL=1234567890abcde, UUID=12345678-abcd-abcd-abcd-1234567890ab
3 LABEL: 1234567890abcde
4 UUID: 12345678-abcd-abcd-abcd-1234567890ab
= EXPECTED ===
1 Setting up swapspace version 1, size = 9 pages (9xPGSZ bytes)
2 LABEL=1234567890abcde, UUID=12345678-abcd-abcd-abcd-1234567890ab
3 LABEL: 1234567890abcde
4 UUID: 12345678-abcd-abcd-abcd-1234567890ab
= O/E diff ===
==
The additional error appears in swaplabel.err:
mkswap: contains holes or other unsupported extents.
This swap file can be rejected by kernel on swap activation!
Use --verbose for more details.
diff --git a/tests/ts/misc/swaplabel b/tests/ts/misc/swaplabel
index 0801cb213..8b1abb5c3 100755
--- a/tests/ts/misc/swaplabel
+++ b/tests/ts/misc/swaplabel
@@ -25,7 +25,7 @@ ts_check_test_command "$TS_HELPER_SYSINFO"
# fallocate does not work on most file systems
function fallocate_or_skip()
{
- $TS_CMD_FALLOCATE -l $1 $2 2>/dev/null || \
+ $TS_CMD_FALLOCATE -x -l $1 $2 2>/dev/null || \
truncate -s $1 $2 || \
ts_skip "no way to create test image"
}
--
2.20.1
Bug#992089: xemacs21-packages: contains a file with a non-free "disparaging to Sun" license
On Wed, Aug 11, 2021 at 02:38:48PM +0200, Pierre Gruet wrote: > Source: xemacs21-packages > Version: 2009.02.17.dfsg.2-4 > Severity: serious > Tags: stretch buster bullseye sid ... > The file > xemacs-packages/jde/java/src/jde/debugger/expr/LValue.java > incorporates a non-free license, stating This bug has been present for several decades now, it is *extremely* late for the buster release at this point and fixing this will require an upload of a new source version to pull out the file. I therefore propose that we ignore this bug for the upcoming release to avoid the minor but still present risk of disruption at this point in the cycle. signature.asc Description: PGP signature
Bug#985509: openrc: diff for NMU version 0.42-2.1
Control: tags 985509 + patch Control: tags 985509 + pending Dear openrc maintainers, I've prepared an NMU for openrc (versioned as 0.42-2.1) to address #985509 and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. Mark diff -Nru openrc-0.42/debian/changelog openrc-0.42/debian/changelog --- openrc-0.42/debian/changelog2020-11-27 08:48:35.0 + +++ openrc-0.42/debian/changelog2021-04-02 11:16:00.0 +0100 @@ -1,3 +1,11 @@ +openrc (0.42-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Make -dev package symlinks in /usr/lib target shared libraries in +/lib. (Closes: #985509). + + -- Mark Hindley Fri, 02 Apr 2021 11:16:00 +0100 + openrc (0.42-2) unstable; urgency=medium * Team upload. diff -Nru openrc-0.42/debian/libeinfo-dev.links.in openrc-0.42/debian/libeinfo-dev.links.in --- openrc-0.42/debian/libeinfo-dev.links.in1970-01-01 01:00:00.0 +0100 +++ openrc-0.42/debian/libeinfo-dev.links.in2021-04-02 11:16:00.0 +0100 @@ -0,0 +1 @@ +@SHLIBDIR@/libeinfo.so.1 @LIBDIR@/libeinfo.so diff -Nru openrc-0.42/debian/librc-dev.install.in openrc-0.42/debian/librc-dev.install.in --- openrc-0.42/debian/librc-dev.install.in 2020-11-27 08:48:35.0 + +++ openrc-0.42/debian/librc-dev.install.in 2021-04-02 11:16:00.0 +0100 @@ -1,4 +1,3 @@ -debian/tmp@SHLIBDIR@/librc.so /usr@SHLIBDIR@ debian/tmp/usr/include/rc.h /usr/include debian/tmp@LIBDIR@/pkgconfig/openrc.pc @LIBDIR@/pkgconfig debian/tmp/usr/share/man/man3/r*/usr/share/man/man3 diff -Nru openrc-0.42/debian/librc-dev.links.in openrc-0.42/debian/librc-dev.links.in --- openrc-0.42/debian/librc-dev.links.in 1970-01-01 01:00:00.0 +0100 +++ openrc-0.42/debian/librc-dev.links.in 2021-04-02 11:16:00.0 +0100 @@ -0,0 +1 @@ +@SHLIBDIR@/librc.so.1 @LIBDIR@/librc.so diff -Nru openrc-0.42/debian/rules openrc-0.42/debian/rules --- openrc-0.42/debian/rules2020-11-27 08:48:35.0 + +++ openrc-0.42/debian/rules2021-04-02 11:16:00.0 +0100 @@ -15,7 +15,7 @@ DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) -DH_INSTALL_FILES = $(basename $(wildcard debian/*.install.in)) +DH_INSTALL_FILES = $(basename $(wildcard debian/*.install.in) $(wildcard debian/*.links.in)) export LIBDIR = /usr/lib/$(DEB_HOST_MULTIARCH) export SHLIBDIR = /lib/$(DEB_HOST_MULTIARCH) @@ -35,6 +35,9 @@ %.install: %.install.in sed -e 's;@SHLIBDIR@;$(SHLIBDIR);g' -e 's;@LIBDIR@;$(LIBDIR);g' <$< >$@ +%.links: %.links.in + sed -e 's;@SHLIBDIR@;$(SHLIBDIR);g' -e 's;@LIBDIR@;$(LIBDIR);g' <$< >$@ + override_dh_auto_clean: dh_auto_clean rm -f $(DH_INSTALL_FILES)
Bug#980634: [Debichem-devel] Bug#980634: gromacs: FTBFS: Errors while running CTest
Sounds plausible. There's no recent gromacs changes to how we use CTest or MPI! On Thu, 21 Jan 2021 at 17:21, Nicholas Breen wrote: > This is *probably* a side effect of the ongoing, messy mpich/pmix/ucx > transition in unstable, but that has so many moving parts that it'll > take a bit to figure out which version of which package is responsible. > >
Bug#969839: Bug#973298: [Pkg-rust-maintainers] Bug#969839: rust-failure: Should rust-failure be removed from unstable?
On Sat, 05, Dec, 2020 at 12:26:27PM +0100, Sylvestre Ledru spoke thus.. > > So you are right, thanks for spotting my mistake, which is because I > > indeed only check if dak rm would cause any issues. I agree that we > > thus likely cannot remove it for now from unstable. > > It has been removed despite this comment. This causes a bunch of breakage. > Could you please bring it back? At the request of the release-team, we re-injected the packages which were still in testing back into unstable. Should be back at the next dinstall. Mark -- Mark Hymers
Bug#974089: Acknowledgement (colord: FTBFS i386: colord-test-private ABRT)
Control: reassign -1 src:colord 1.4.5-1 Of course this would be better assigned to the source package. Mark
Bug#974089: colord: FTBFS i386: colord-test-private ABRT
Package: colord Version: 1.4.5-1 Severity: serious Justification: FTBFS Dear Maintainer, colord 1.4.5-1 fails to build from source on (at least) i386. Summary of Failures: 1/4 colord-test-private FAIL 2.94s (killed by signal 6 SIGABRT) Thanks. Mark
Bug#973639: libgromacs6: missing Breaks+Replaces: libgromacs5
Hi Andreas, Thanks for the report, and sorry for the omission. This was already fixed upstream by bumping to soversion 0.2.0 and will be in 2021~beta2 Mark On Mon, 2 Nov 2020 at 19:00, Andreas Beckmann wrote: > Package: libgromacs6 > Version: 2021~beta1-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'sid' to 'experimental'. > It installed fine in 'sid', then the upgrade to 'experimental' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. > > See policy 7.6 at > > https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces > > From the attached log (scroll to the bottom...): > > Preparing to unpack .../libgromacs6_2021~beta1-1_amd64.deb ... > Unpacking libgromacs6:amd64 (2021~beta1-1) ... > dpkg: error processing archive > /var/cache/apt/archives/libgromacs6_2021~beta1-1_amd64.deb (--unpack): >trying to overwrite '/usr/lib/x86_64-linux-gnu/libgmxapi.so.0.1.0', > which is also in package libgromacs5:amd64 2020.4-2 > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) > Errors were encountered while processing: >/var/cache/apt/archives/libgromacs6_2021~beta1-1_amd64.deb > > Shared libraries with independent soversions shouldn't be bundled in the > same > binary package. > > > cheers, > > Andreas >
Bug#973354: src:apt-cacher: fails to migrate to testing for too long: maintainer built arch:all binaries
Paul, Many thanks for this. On Thu, Oct 29, 2020 at 11:51:18AM +0100, Paul Gevers wrote: > Your package is only blocked because the arch:all binary package(s) > aren't built on a buildd. Unfortunately the Debian infrastructure > doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will > shortly do a no-changes source-only upload to DELAYED/15, closing this > bug. Please let me know if I should delay or cancel that upload. I had been trying to get this resolved through my usual sponsor/uploader, but have been unable to get a response from him. So you action is very welcome. Thanks. I am happy for there to be no delay, should you wish. Thanks. Mark
Bug#968335: kernel crash: WARNING: CPU: 0 PID: 0 at lib/percpu-refcount.c:155 percpu_ref_switch_to_atomic_rcu+0xf8/0x120
Hi, just wanted to report that after using kernel 4.19.0-11-amd64 my system is stable again (uptime now more than 1 week) and the message is no more seen in the logs. So problem is solved at least on my system. Bye,wahlm
Bug#971644: elogind: accidentally hitting Fn-F12 crashes the system (dirty filesystem)
Control: forwarded -1 https://github.com/elogind/elogind/issues/177 Thorsten, Many thanks for this. On Sun, Oct 04, 2020 at 01:30:53AM +0200, Thorsten Glaser wrote: > Package: elogind > Version: 243.7-1+debian1 > Severity: critical > Justification: causes serious data loss > X-Debbugs-Cc: t...@mirbsd.de [..] > Oct 4 01:09:22 tglase-nb vmunix: [1043273.743227] elogind-daemon[1640]: > Hibernate key pressed. > Oct 4 01:09:22 tglase-nb vmunix: [1043273.747348] elogind-daemon[1640]: > Hibernating... > Oct 4 01:09:22 tglase-nb vmunix: [1043273.749104] PM: Image not found (code > -22) > > This is clear evidence that elogind *actively* captured that keypress > and did something not normal (i.e. not present on a standard pre-systemd > system without elogind). Whatever it did apparently failed, but it STILL > proceeded to crash the whole system (with the screen flickering a number > of times and then the system suddenly powering off). I fully agree that this should be handled better. Forwarded upstream. [...] > I’ve also just looked at the elogind.conf file I was told to change in > one of the two other bugreports I mentioned above. There is some config > regarding hibernation, so I guess, now that I know about the problem, > I could just turn off as a WORKAROUND *ONLY* (I *assume* changing > #HandleHibernateKey=hibernate > toHandleHibernateKey=ignore > might do the trick) Yes, I would expect that to be a good workaround in your case. > but then I wonder why this is not ignored by default, If there is a consensus that the default should be different, then I am happy to change it. Best wishes Mark
Bug#968335: kernel crash: WARNING: CPU: 0 PID: 0 at lib/percpu-refcount.c:155 percpu_ref_switch_to_atomic_rcu+0xf8/0x120
Hello, my gigabyte brix system (Celeron J3160) worked rock solid 24/7 up to now (stretch install, upgrade to buster) as a small server with zabbix/mariadb, some kvm virtual machines and docker containers. Mass storage is at 2 usb3 2T disks. After updating the kernel to 4.19.0-10-amd64 (Debian 4.19.132-1) the system froze after around 2-3 days. I rebooted and tried again with the same result. I did a fallback to 4.19.0-9-amd64 (4.19.118-2+deb10u1) and the system again runs stable for a month now. Unfortunately no information about the reason for the freeze could be found in the logs. But around one day after boot I found a similar warning in the log like it is reported in this report. Here is the message of the first try: Aug 9 00:00:02 brix kernel: [273566.195095] [ cut here ] Aug 9 00:00:02 brix kernel: [273566.195107] percpu ref (css_release) <= 0 (-399677) after switching to atomic Aug 9 00:00:02 brix kernel: [273566.195127] WARNING: CPU: 1 PID: 0 at lib/percpu-refcount.c:155 percpu_ref_switch_to_atomic_rcu+0xf8/0x120 Aug 9 00:00:02 brix kernel: [273566.195128] Modules linked in: fuse btrfs zstd_compress zstd_decompress xxhash xor raid6_pq ufs qnx4 hfsplus hfs minix vfat msdos fat jfs xfs dm_mod vhost_net vhost tap tun devlink ipt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo nft_counter nft_chain_nat_ipv4 nf_nat_ipv4 xt_addrtype nft_compat nf_tables nfnetlink xt_conntrack nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c br_netfilter nls_utf8 overlay isofs loop bridge stp llc snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic btusb intel_rapl intel_powerclamp coretemp arc4 kvm_intel snd_hda_intel i915 snd_hda_codec iwlmvm kvm hci_uart mac80211 snd_hda_core btqca evdev snd_hwdep btrtl irqbypass snd_pcm btbcm drm_kms_helper crct10dif_pclmul btintel crc32_pclmul iwlwifi rtsx_pci_ms ghash_clmulni_intel snd_timer intel_cstate Aug 9 00:00:02 brix kernel: [273566.195176] bluetooth memstick cfg80211 iTCO_wdt pcspkr iTCO_vendor_support drm snd soundcore i2c_algo_bit drbg ansi_cprng ecdh_generic pcc_cpufreq video rfkill pwm_lpss_platform pwm_lpss acpi_pad intel_int0002_vgpio sg button ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp nfsd libiscsi_tcp libiscsi scsi_transport_iscsi auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb uas usb_storage hid_generic usbhid sd_mod crc32c_intel rtsx_pci_sdmmc ahci libahci aesni_intel xhci_pci xhci_hcd libata i2c_i801 r8169 sdhci_pci aes_x86_64 crypto_simd cryptd glue_helper cqhci sdhci usbcore lpc_ich realtek scsi_mod libphy rtsx_pci mmc_core mfd_core usb_common thermal fan i2c_hid hid Aug 9 00:00:02 brix kernel: [273566.195225] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.0-10-amd64 #1 Debian 4.19.132-1 Aug 9 00:00:02 brix kernel: [273566.195227] Hardware name: GIGABYTE GB-BACE-3160/MZBSWMP-00, BIOS F6 06/13/2018 Aug 9 00:00:02 brix kernel: [273566.195230] RIP: 0010:percpu_ref_switch_to_atomic_rcu+0xf8/0x120 Aug 9 00:00:02 brix kernel: [273566.195232] Code: 78 ff ff ff 80 3d 2b 71 d2 00 00 75 8c 49 8b 54 24 d8 49 8b 74 24 e8 48 c7 c7 68 98 29 a4 c6 05 11 71 d2 00 01 e8 f2 ae ca ff <0f> 0b e9 68 ff ff ff f0 49 83 6c 24 d8 01 75 9c 49 8b 44 24 e8 48 Aug 9 00:00:02 brix kernel: [273566.195234] RSP: 0018:9b017bc83ee0 EFLAGS: 00010282 Aug 9 00:00:02 brix kernel: [273566.195236] RAX: RBX: 7ff9e6c3 RCX: Aug 9 00:00:02 brix kernel: [273566.195238] RDX: 0041 RSI: a49f7b21 RDI: 0246 Aug 9 00:00:02 brix kernel: [273566.195239] RBP: 42a50401ac08 R08: R09: 00021980 Aug 9 00:00:02 brix kernel: [273566.195241] R10: 00018e1d3146539c R11: a49f7b06 R12: 9b0176c3e838 Aug 9 00:00:02 brix kernel: [273566.195242] R13: a452dce0 R14: 7fff R15: 0202 Aug 9 00:00:02 brix kernel: [273566.195244] FS: () GS:9b017bc8() knlGS: Aug 9 00:00:02 brix kernel: [273566.195245] CS: 0010 DS: ES: CR0: 80050033 Aug 9 00:00:02 brix kernel: [273566.195247] CR2: 7fce0683e9a0 CR3: 00015a20a000 CR4: 001026e0 Aug 9 00:00:02 brix kernel: [273566.195248] Call Trace: Aug 9 00:00:02 brix kernel: [273566.195252] Aug 9 00:00:02 brix kernel: [273566.195259] rcu_process_callbacks+0x218/0x4b0 Aug 9 00:00:02 brix kernel: [273566.195264] ? rebalance_domains+0x274/0x2c0 Aug 9 00:00:02 brix kernel: [273566.195268] __do_softirq+0xde/0x2d8 Aug 9 00:00:02 brix kernel: [273566.195273] irq_exit+0xba/0xc0 Aug 9 00:00:02 brix kernel: [273566.195276] smp_apic_timer_interrupt+0x74/0x140 Aug 9 00:00:02 brix kernel: [273566.195279] apic_timer_interrupt+0xf/0x20 Aug 9 00:00:02 brix kernel: [273566.195281] Aug 9 00:00:02 brix kernel: [273566.195284] RIP: 0010:cpuidle_enter_state+0xb9/0x320 Aug 9
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Control: reassign -1 apt-cudf Dear apt-cudf maintainers, On Tue, Jun 30, 2020 at 07:43:52PM +0200, Ansgar wrote: > On Tue, 2020-06-30 at 17:45 +0100, Mark Hindley wrote: > > I am struggling to understand how libelogind0 came to be installed in the > > build > > in the first place. Can you help me understand that? > > No idea; apt's resolver is sometimes creative. Other examples include > [1], [2], [3]. > > [1]: > https://buildd.debian.org/status/logs.php?pkg=hplip=3.20.6%2Bdfsg0-1=amd64 > [2]: > https://buildd.debian.org/status/logs.php?pkg=gnome-applets=3.37.2-1=amd64 > [3]: > https://buildd.debian.org/status/logs.php?pkg=kopete=4%3A20.04.1-1=amd64 The common feature in all of these experimental buildd failures is that apt-cudf fails to find the correct solution leaving a libsystemd-dev <=> libelogind0 conflict. Reassiging. Thanks. Mark
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Control: tags -1 moreinfo On Thu, Jul 02, 2020 at 04:33:36PM +0200, Thorsten Glaser wrote: > On Thu, 2 Jul 2020, Ansgar wrote: > > > package), so the problem might also be the `Provides: logind` in > > libpam-elogind. > > Shouldn’t the package dependencies on default-logind | logind > handle this? Absolutely. Ansgar, Nothing you have shown so far demonstrates anything wrong with the src:elogind dependencies. In fact you have suggested several times that this is an issue with apt or whatever dependency resolver the experimental buildd uses. Can you provide information from the resolver to show how it is coming to its incorrect decision? Thanks Mark
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Control: tags -1 moreinfo On Wed, Jul 01, 2020 at 12:35:18PM +0200, Axel Beckert wrote: > Is it still the case that the buildds use aptitude for resolving > dependencies on experimental builds? Because aptitude might be even > more "creative" than apt in that regards. Thanks. That is one for Angar. It seems possible that the presence of libpam-elogind-compat in experimental makes aptitude and/or apt try an invalid solution. Ansgar, are you able to confirm that? If so I will reassign. libpam-elogind-compat can be removed completely once packages update dependencies from libpam-systemd to default-logind | logind. The outstanding bugs that I am aware of are #925338, #925339, #932047 #921021, #923387 (the last 2 of which I see have been closed unanswered). Mark
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Ansgar, On Tue, Jun 30, 2020 at 07:43:52PM +0200, Ansgar wrote: > On Tue, 2020-06-30 at 17:45 +0100, Mark Hindley wrote: > > I am struggling to understand how libelogind0 came to be installed in the > > build > > in the first place. Can you help me understand that? > > No idea; apt's resolver is sometimes creative. Other examples include > [1], [2], [3]. > > [1]: > https://buildd.debian.org/status/logs.php?pkg=hplip=3.20.6%2Bdfsg0-1=amd64 > [2]: > https://buildd.debian.org/status/logs.php?pkg=gnome-applets=3.37.2-1=amd64 > [3]: > https://buildd.debian.org/status/logs.php?pkg=kopete=4%3A20.04.1-1=amd64 Thanks. I have looked through these and, again, I can see no other regerences to either elogind or systemd that might explain this. However, all 4 examples you have given relate to builds for experimental. Is that always the case? If so, I wonder if this is related to the presence in experimental of libpam-elogind-compat? Mark
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Ansgar, Thanks for this. On Tue, Jun 30, 2020 at 06:27:20PM +0200, Ansgar wrote: > Package: libelogind0 > Version: 243.7-1+debian1 > Severity: serious > > libelogind0's `Provides: libsystemd0` causes unrelated packages to > fail to build due to unmet dependencies. See [1] for an example. > > The relevant log part is: > > +--- > | The following packages have unmet dependencies: > | libelogind0 : Conflicts: libsystemd0 > | E: Broken packages > | apt-get failed. > +--- I am struggling to understand how libelogind0 came to be installed in the build in the first place. Can you help me understand that? Presumably there is a build dependency on libsystemd-dev, but I don't see it in the log. Thanks Mark
Bug#959783: util-linux: 2.35.1-1 FTBFS in pbuilder chroot: testsuite fails in misc/fallocate and misc/mountpoint
Source: util-linux
Version: 2.35.1-1
Severity: serious
Justification: FTBFS
Tags: patch
Dear Maintainer,
Thanks for packaging the new version of util-linux.
Unfortunately the testsuite fails when building in a pbuilder/cowbuilder
chroot. In particular misc/fallocate and misc/mountpoint.
The issues appear to be:
misc/fallocate: the expected failure case has not been migrated to the new test
framework with clear separation of stdout and stderr.
misc/mountpoint: This assumes / is a mountpoint which is not the case in a
chroot.
Patches addressing both of these failures are below. However, I am aware that
using /proc as the test mountpoint is a linux only solution, so you may well
prefer another approach.
Thanks.
Mark
--- a/tests/ts/misc/fallocate
+++ b/tests/ts/misc/fallocate
@@ -30,7 +30,7 @@
# fs type of $TS_OUTDIR, could be used to skip this test early
fs_type=$(${TS_CMD_FINDMNT} -n -o FSTYPE -T ${TS_OUTDIR})
- grep -qi "fallocate: fallocate failed:.*not supported" $TS_OUTPUT \
+ grep -qi "fallocate: fallocate failed:.*not supported" $TS_ERRLOG \
&& ts_skip "'${fs_type}' not supported"
fi
--- a/tests/ts/misc/mountpoint
+++ b/tests/ts/misc/mountpoint
@@ -8,15 +8,16 @@
ts_check_test_command "$TS_CMD_MOUNTPOINT"
-ln -s / ./symlink-to-root
+# Use /proc: / is not a mountpoint in a build chroot.
+ln -s /proc ./symlink-to-proc
ts_init_subtest "default"
-$TS_CMD_MOUNTPOINT ./symlink-to-root >> $TS_OUTPUT 2>> $TS_ERRLOG
+$TS_CMD_MOUNTPOINT ./symlink-to-proc >> $TS_OUTPUT 2>> $TS_ERRLOG
echo $? >> $TS_OUTPUT 2>> $TS_ERRLOG
ts_finalize_subtest
ts_init_subtest "nofollow"
-$TS_CMD_MOUNTPOINT --nofollow ./symlink-to-root >> $TS_OUTPUT 2>> $TS_ERRLOG
+$TS_CMD_MOUNTPOINT --nofollow ./symlink-to-proc >> $TS_OUTPUT 2>> $TS_ERRLOG
echo $? >> $TS_OUTPUT 2>> $TS_ERRLOG
ts_finalize_subtest
@@ -25,5 +26,5 @@
echo $? >> $TS_OUTPUT 2>> $TS_ERRLOG
ts_finalize_subtest
-rm -f ./symlink-to-root
+rm -f ./symlink-to-proc
ts_finalize
--- a/tests/expected/misc/mountpoint-default
+++ b/tests/expected/misc/mountpoint-default
@@ -1,2 +1,2 @@
-./symlink-to-root is a mountpoint
+./symlink-to-proc is a mountpoint
0
--- a/tests/expected/misc/mountpoint-nofollow
+++ b/tests/expected/misc/mountpoint-nofollow
@@ -1,2 +1,2 @@
-./symlink-to-root is not a mountpoint
+./symlink-to-proc is not a mountpoint
1
Bug#958499: eclipse: fails to launch
Package: eclipse Version: 3.8.1-11 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? 1. `sudo apt install eclipse` 2. Launch Eclipse from the menu or from commandline. 3. I get 'An error has occurred.' There is a log generated: !SESSION Wed Apr 22 16:16:35 PDT 2020 -- !ENTRY org.eclipse.equinox.launcher 4 0 2020-04-22 16:16:35.306 !MESSAGE Exception launching the Eclipse Platform: !STACK java.lang.ClassNotFoundException: org.eclipse.core.runtime.adaptor.EclipseStarter at java.net.URLClassLoader.findClass(URLClassLoader.java:382) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:626) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438) at org.eclipse.equinox.launcher.Main.main(Main.java:1414) * What exactly did you do (or not do) that was effective (or ineffective)? After Googling this error, it was suggested to explictly specify Java8 in eclipse.ini. * What was the outcome of this action? The problem is still the same. Additional Googling suggests this package is 1) very outdated, and 2) hopelessly broken. Eclipse Founation itself does not provide this for the armv7l architecture. * What outcome did you expect instead? A package provided in repos should work. It should probably be removed from the repos to save other users the frustration. -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 10 (buster) Release:10 Codename: buster Architecture: armv7l Kernel: Linux 4.19.97-v7+ (SMP w/4 CPU cores) 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 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages eclipse depends on: ii eclipse-jdt 3.8.1-11 ii eclipse-pde 3.8.1-11 eclipse recommends no packages. eclipse suggests no packages. Versions of packages eclipse-platform depends on: ii ant 1.10.5-2 ii ant-optional 1.10.5-2 ii default-jre [java6-runtime] 2:1.11-71+b1 ii eclipse-platform-data3.8.1-11 ii eclipse-rcp 3.8.1-11 ii gconf-service3.2.6-5 ii java-common 0.71 ii libc62.28-10+rpi1 ii libcommons-codec-java1.11-1 ii libcommons-httpclient-java 3.1-15 ii libcommons-logging-java 1.2-2 ii libgconf-2-4 3.2.6-5 ii libglib2.0-0 2.58.3-2+deb10u2 ii libjetty9-java 9.4.15-1 ii libjsch-java 0.1.55-1 ii liblucene2-java 2.9.4+ds1-6 ii libservlet3.1-java [libservlet3.1-java] 1:4.0.1-2 ii openjdk-11-jre [java6-runtime] 11.0.6+10-1~deb10u1 ii openjdk-8-jre [java6-runtime]8u212-b01-1+rpi1 ii sat4j2.3.5-0.3 Versions of packages eclipse-platform recommends: ii eclipse-pde 3.8.1-11 Versions of packages eclipse-platform suggests: ii eclipse-jdt 3.8.1-11 Versions of packages eclipse-pde depends on: ii default-jre [java6-runtime] 2:1.11-71+b1 ii eclipse-jdt 3.8.1-11 ii eclipse-platform3.8.1-11 ii libasm3-java3.3.2-3 ii openjdk-11-jre [java6-runtime] 11.0.6+10-1~deb10u1 ii openjdk-8-jre [java6-runtime] 8u212-b01-1+rpi1 eclipse-pde suggests no packages. Versions of packages eclipse-jdt depends on: ii default-jre [java6-runtime] 2:1.11-71+b1 ii eclipse-platform3.8.1-11 ii junit 3.8.2-9 ii junit4 4.12-8 ii libhamcrest-java1.3-9 ii openjdk-11-jre [java6-runtime] 11.0.6+10-1~deb10u1 ii openjdk-8-jre [java6-runtime] 8u212-b01-1+rpi1 Versions of packages eclipse-jdt recommends: ii default-jdk 2:1.11-71+b1 eclipse-jdt suggests no packages. -- no debconf information
Bug#952257: xemacs21-packages: FTBFS: Malformed UTF-8 character (fatal) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.
On Sun, Feb 23, 2020 at 02:22:15PM +0100, Lucas Nussbaum wrote: > Relevant part (hopefully): > > make[3]: Entering directory '/<>/xemacs-packages/edit-utils' Not sure how these are generated but there's over 1000 lines of log here, most of it irrelevant. This makes it hard to both find the actual problem and reply to this mail. The only relevant part of the log is: > > cd . && makeinfo -o edit-utils.info edit-utils.texi > > cd . && makeinfo -o tempo.info tempo.texi > > utf8 "\xE5" does not map to Unicode at > > /usr/share/texinfo/Texinfo/ParserNonXS.pm line 1796, line 22. > > Malformed UTF-8 character: \xe5\x67\x65 (unexpected non-continuation byte > > 0x67, immediately after start byte 0xe5; need 3 bytes, got 1) in pattern > > match (m//) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364. > > Malformed UTF-8 character (fatal) at > > /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364. > > make[3]: *** [../../XEmacs.rules:310: tempo.info] Error 25 signature.asc Description: PGP signature
Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout
Control: severity -1 important Thorsten, On Thu, Jan 23, 2020 at 10:10:03PM +0100, Thorsten Glaser wrote: > > This behaviour is configurable via RemoveIPC in /etc/elogind/logind.conf. > > See > > > Perhaps you could confirm that this configuration change provides the > > behaviour > > you want? > > thanks, yes, this provides the behaviour necessary for proper system > operation. Please make it the default. Good! Downgrading severity to important. I will explore the implications of changing the default. Thanks. Mark
Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout
On Thu, Jan 23, 2020 at 08:32:46PM +0100, Thorsten Glaser wrote: > Package: elogind > Version: 241.3-1+debian2 > Severity: critical > Justification: breaks unrelated software > > I’m using a scheme in which I store ssh-agent and gpg-agent information > across all logins (local X session or ssh or xrdp) under /dev/shm/ since > I needed space that an unprivileged user can use and that doesn’t persist > across reboots. > > Since installing elogind, logging out from SSH sessions then on again > both breaks gpg-agent as well as makes ssh-agent instances multiply and, > thus, lose their loaded keys to the user. Thorsten, Thanks for this. This behaviour is configurable via RemoveIPC in /etc/elogind/logind.conf. See man logind.conf(5). I accept that the documentation for the behaviour is difficult to find (I had to search quite hard) and it may be that the default ought to be different. Perhaps you could confirm that this configuration change provides the behaviour you want? Many thanks. Mark
Bug#945303: calendar-google-provider: Please package version corresponding to thunderbird version
Thank you for the explanation! For my part I hadn't yet seen the NEWS item because apt-get was holding back fetching the package, blocked by that dependency issue. Now all sorted since I switched to the non-packaged add-on. Cheers, Mark The University of Dundee is a registered Scottish Charity, No: SC015096
Bug#942503: libpoppler46: New jessie-security version causes xpdf segfault
On Fri, Oct 18, 2019 at 04:37:00PM +1100, Brian May wrote: > Mark Hindley writes: > > > Since this upload was an LTS NMU, I should have copied you in. > > Thanks for the report. It looks like the fix for CVE-2019-10871 might be > broken, and I might have to revert this change. Thanks. Confirm fixed with +deb8u13. Mark
Bug#942503: libpoppler46: New jessie-security version causes xpdf segfault
Package: libpoppler46 Version: 0.26.5-2+deb8u12 Severity: grave Justification: renders package unusable Dear Maintainer, I have just upgraded to libpoppler46 version 0.26.5-2+deb8u12 (from +deb8u11) which has just appeared in jessie-security. The new version causes xpdf to segfault. Starting program: /usr/bin/xpdf.real [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x555695e3 in ?? () (gdb) bt #0 0x555695e3 in ?? () #1 0x55565912 in ?? () #2 0x55565a2f in ?? () #3 0x55561da0 in ?? () #4 0x7757cfd3 in Gfx::go(bool) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.46 #5 0x7757d1b8 in Gfx::display(Object*, bool) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.46 #6 0x775c5605 in Page::displaySlice(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, bool (*)(void*), void*, bool (*)(Annot*, void*), void*, bool) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.46 #7 0x555642bc in ?? () #8 0x55567b80 in ?? () #9 0x5556d011 in ?? () #10 0x55562175 in ?? () #11 0x555718e2 in ?? () #12 0x779b3ac3 in ?? () from /usr/lib/x86_64-linux-gnu/libXm.so.4 #13 0x779ebac1 in ?? () from /usr/lib/x86_64-linux-gnu/libXm.so.4 #14 0x779ec1e5 in ?? () from /usr/lib/x86_64-linux-gnu/libXm.so.4 #15 0x779bd15b in _XmDispatchGadgetInput () from /usr/lib/x86_64-linux-gnu/libXm.so.4 #16 0x77a6cdb2 in _XmGadgetActivate () from /usr/lib/x86_64-linux-gnu/libXm.so.4 #17 0x7724d855 in ?? () from /usr/lib/x86_64-linux-gnu/libXt.so.6 #18 0x7724e7e2 in _XtTranslateEvent () from /usr/lib/x86_64-linux-gnu/libXt.so.6 #19 0x772271bb in XtDispatchEventToWidget () from /usr/lib/x86_64-linux-gnu/libXt.so.6 #20 0x7722787d in ?? () from /usr/lib/x86_64-linux-gnu/libXt.so.6 #21 0x77227959 in XtDispatchEvent () from /usr/lib/x86_64-linux-gnu/libXt.so.6 #22 0x77233527 in XtAppProcessEvent () from /usr/lib/x86_64-linux-gnu/libXt.so.6 #23 0x77227d3d in XtAppMainLoop () from /usr/lib/x86_64-linux-gnu/libXt.so.6 #24 0x5556169d in ?? () #25 0x760f9b45 in __libc_start_main (main=0x555613c0, argc=1, argv=0x7fffdb98, init=, fini=, rtld_fini=, stack_end=0x7fffdb88) at libc-start.c:287 #26 0x55561bec in ?? () Downgrading to version 0.26.5-2+deb8u4 fixes the segfault. Mark -- System Information: Debian Release: 8.11 Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-10-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libpoppler46 depends on: ii libc6 2.19-18+deb8u10 ii libfontconfig1 2.11.0-6.3+deb8u1 ii libfreetype6 2.5.2-3+deb8u4 ii libjpeg62-turbo1:1.3.1-12+deb8u2 ii liblcms2-2 2.6-3+deb8u2 ii libopenjpeg5 1:1.5.2-3 ii libpng12-0 1.2.50-2+deb8u3 ii libstdc++6 4.9.2-10+deb8u2 ii libtiff5 4.0.3-12.3+deb8u9 ii multiarch-support 2.19-18+deb8u10 Versions of packages libpoppler46 recommends: ii poppler-data 0.4.7-1 libpoppler46 suggests no packages. -- no debconf information
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
Simon, On Tue, Aug 27, 2019 at 05:46:32PM +0100, Mark Hindley wrote: > Simon, > > I think I have finally got to the bottom of this. As you suspected it is apt's > invocation of dpkg. See #935910. This is now resolved in apt version 1.8.4 which is in both sid and bullseye. I can no longer reproduce the breakage that you reported. Are you satisfied that this bug can be closed? Thanks. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Cristian, On Sat, Sep 28, 2019 at 11:41:56AM +0200, Thorsten Glaser wrote: > On Sat, 28 Sep 2019, Cristian Ionescu-Idbohrn wrote: > > > 1. install sysvinit-core; that removes systemd-sysv but nothing else > >systemd related > > > Souldn't that work? > > It would, if but for libpam-systemd having a (somewhat questionable > but understandable) dependency on systemd-sysv. This is basically > what spawned this thread. > > So we’ll not be going there. Thorsten is quite right. There is already a separate bug concerning the libpam-systemd systemd-sysv dependency. See https://bugs.debian.org/935304. That would be a more appropriate place for you to add any comments you may have regarding this aspect of the behaviour you have observed. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Fri, Sep 27, 2019 at 03:39:43PM +0200, Julien Cristau wrote: > On Fri, Sep 27, 2019 at 09:19:10AM -0400, Sam Hartman wrote: > So one thing I think we should ensure is we don't end up uninstalling > systemd without an explicit user choice. Julien, I appreciate that you are suggesting some additional protection is required against this. However, it appears that the way APT handles the current dependencies already require explicit user choice to be made. Testing on a basic sid desktop install with systemd as pid 1 I get the following behaviour: - apt install libelogind0 Generates the apt "You are about to do something potentially harmful. To continue type in the phrase 'Yes, do as I say!'" warning. - apt install elogind - apt install libpam-elogind For both of these APT fails to find a solution. The only way make it find an solution is to explicitly request installation of sysvinit-core such as 'apt install libpam-elogind sysvinit-core' So I am not sure any changes are required in order to enforce explicit instruction before attempting removal of systemd. Is this sufficient? Mark test@DebianUnstable: ~test@DebianUnstable:~$ dpkg -l systemd* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=---=== ii systemd 242-7amd64system and service manager un systemd-container (no description available) un systemd-shim(no description available) ii systemd-sysv 242-7amd64system and service manager - SysV links test@DebianUnstable: ~test@DebianUnstable:~$ sudo apt-get install libelogind0 Reading package lists... Done Building dependency tree... Reading state information... Done The following packages were automatically installed and are no longer required: acl avahi-daemon colord-data gir1.2-matemenu-2.0 gnome-accessibility-themes gnome-themes-extra gnome-themes-extra-data gtk2-engines-pixbuf libargon2-1 libavahi-core7 libayatana-appindicator3-1 libayatana-ido3-0.4-0 libayatana-indicator3-7 libcolorhug2 libcryptsetup12 libdaemon0 libdbusmenu-glib4 libdbusmenu-gtk3-4 libgd3 libgphoto2-6 libgphoto2-l10n libgphoto2-port12 libgusb2 libieee1284-3 libindicator3-7 liblightdm-gobject-1-0 libmate-menu2 libmate-panel-applet-4-1 libmateweather-common libmateweather1 libnss-mdns libplymouth4 librda-common librda0 libsane libsane-common libsnmp-base libsnmp30 lightdm-gtk-greeter mate-menus mate-panel-common mate-polkit-common menu menu-xdg sane-utils update-inetd Use 'sudo apt autoremove' to remove them. The following packages will be REMOVED: colord init libnss-systemd libpam-systemd libsystemd0 lightdm mate-panel mate-polkit plymouth plymouth-label policykit-1 policykit-1-gnome systemd systemd-sysv xiccd The following NEW packages will be installed: libelogind0 WARNING: The following essential packages will be removed. This should NOT be done unless you know exactly what you are doing! init systemd-sysv (due to init) 0 upgraded, 1 newly installed, 15 to remove and 0 not upgraded. Need to get 224 kB of archives. After this operation, 20.1 MB disk space will be freed. You are about to do something potentially harmful. To continue type in the phrase 'Yes, do as I say!' ?] n Abort. test@DebianUnstable: ~test@DebianUnstable:~$ sudo apt-get install elogind Reading package lists... Done Building dependency tree... Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: elogind : Depends: libelogind0 (= 241.3-1+debian1) but it is not going to be installed E: Unable to correct problems, you have held broken packages.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Julien, On Fri, Sep 27, 2019 at 03:39:43PM +0200, Julien Cristau wrote: > So one thing I think we should ensure is we don't end up uninstalling > systemd without an explicit user choice. > > The "init" package has the "Important: yes" control field which as I > understand it tells apt to behave like "Essential: yes", except for not > trying to install the package if it is not installed. > > That's not quite enough for our purposes, because apt would still be > allowed to replace systemd-sysv with sysvinit-core, but maybe > systemd-sysv could get that flag as well? > > Julian didn't seem to find the idea crazy when we brought that up on > irc. Thanks. The aim of preventing accidental removal of systemd is very reasonable. However, using this approach the hurdle you create even to a user who really wants to uninstall is pretty high. Few people will continue having seen the 'You are about to do something potentially harmful' warning. I think the effect we are after is rather closer to that of apt-mark hold systemd or dpkg --set-selections systemd hold. Once held, uninstalling the package requires a specific request to apt. But I realise this approach will also prevent upgrades. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Sam, On Fri, Sep 27, 2019 at 09:19:10AM -0400, Sam Hartman wrote: > >>>>> "Mark" == Mark Hindley writes: > > Mark> Sam, Since I cannot get a working and robust dpkg-divert > Mark> solution, I feel the need to revisit the validity of these > Mark> concerns. > > I'd like to push back on the phrasing here. > What i'm hearing is that after spending a couple of weeks exploring ways > to meet these concerns, you'd now like to push back on whether they are > a good idea in the first place. > That seems dismissive both of Julien's concerns and the engineering > effort you and others have spent exploring what the valid options are. > I agree with you that it's time to go back and revisit whether these > concerns are requirements that we can meet. I wasn't intending to be dismissive at all. And I apologise if sloppy or careless use of language on my part gave that impression. [snip] > I think it is fair to ask Julien as the bug submitter to engage here > either by coming up with new options that none of us have explored or by > coming up with specific problems. Alternatively it would be reasonable > for him to ask someone else who has more time to dedicate to this issue > to step in. > > In general, we expect maintainers to respond to RC bugs within two > weeks. > I think that in a situation like this it would be reasonable to expect > Julien to respond within two weeks as well. > However, for your information, DSA is having some significant hardware > challenges and I think he is very involved in that. > I'd recommend being very receptive to a specific request for more time. > > Assuming no response, I think it would be reasonable for you to close > the bug after the timeout arguing that you have considered the issues > he brought up, considered alternative designs, and articulated why this > is the best option. I am happy with that. Thank you for your help, advice and facilitation. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Thu, Sep 26, 2019 at 12:52:27PM +0200, Thorsten Glaser wrote: > On Thu, 26 Sep 2019, Mark Hindley wrote: > > > It is possible to get APT to attempt a solution by specifically requesting > > 'apt > > install libelogind0 sysvinit-core'. This removes systemd-sysv and then > > fails > > Does it also request a “Yes, do as I say!” then? No it doesn't. > If not (or perhaps anyway) libsystemd0 should get Important: yes, as > I wrote earlier, which will force that. Yes it could. Thanks Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Sam, Since I cannot get a working and robust dpkg-divert solution, I feel the need to revisit the validity of these concerns. On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote: > >>>>> "Mark" == Mark Hindley writes: > >> If we are going to use c/r/p libsystemd0, is there some way we > >> can limit the potential damage to people who have positively > >> indicated that they want to run a non-default init system? One > >> of the concerns is what happens if apt decides somehow that it > >> wants to install libelogind0 when you don't expect it. > > Mark> I have to admit I don't understand this fear. libsystemd0 is > Mark> just a way of talking to a running systemd process. If systemd > Mark> is not running and PID 1 libsystemd0 APIs generally return non > Mark> fatal errors. So by running a non-default init, libsystemd0 is > Mark> only there to satisfy dynamically loaded symbols at > Mark> runtime. Otherwise it is basically non functional. libelogind0 > Mark> is the same if elogind isn't running. > > Foo-package depends on the latest libsystemd0. I'm running unstable or > testing. The latest libsystemd0 isn't building on my arch yet. But > elogind is simpler and has build fine on my arch. I install foo-package > and suddenly end up with libelogind0 instead of libsystemd0 > > This is probably a problem. > Libsystemd0 and libelogind0 probably behave differently and you probably > do care which one you have. Yes, it would be a problem if that was what happened, but if this system had systemd installed, the current dependencies do not allow it. If systemd wasn't installed it might happen. However, I don't think that would cause any change in function. There appears to be some mystique as to what libsystemd0 and libelogind0 do. Their only function is to provide library API access to a running systemd or elogind process. In the absence of that, they do nothing beyond satisfying the runtime linker. > The specific problems depend on what init system I have, on whether I > have elogind running or systemd-logind, etc. > But it's probably not a good situation. Yes, so problems and loss of functionality are caused only if you end up with the combination systemd/libelogind0 or elogind/libsystemd0. Current dependencies make the first of these impossible and second one is what we are trying to provide a solution to. To be sure, I have just tried to install libelogind0 on a sid VM booted with systemd. APT will not let you do it requiring you to type the 'Yes, do as I say!' phrase after its serious warning which is surely enough to dissuade most people from proceeding. The dependency stack is init (Priority: important) PreDepends systemd-sysv systemd-sysv (Priority: important) PreDepends systemd libelogind0 conflicts systemd Given that, I can see no way libelogind0 could accidentally be installed on a system with systemd. It is possible to get APT to attempt a solution by specifically requesting 'apt install libelogind0 sysvinit-core'. This removes systemd-sysv and then fails gracefully when the systemd prerm fails. 'apt -f install' successfully cleans up by configuring sysvinit-core. This would only be specified by a user wanting to switch to an non-default init and is not going to happen by accident. Importantly in this scenario, libelogind0 is still not installed and the system including systemd as init still functions. If you realise you have made a mistake you can even return to systemd-sysv just by reinstalling it. I hope you don't feel I am going over old ground here, but I fail to see a case that is not covered. What am I missing? Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Thu, Sep 26, 2019 at 12:11:47AM +0200, Thorsten Glaser wrote: > On Wed, 25 Sep 2019, Mark Hindley wrote: > > > Thanks. Triggers may be an answer to the libsystemd soversion issue. > > Mind that anything that runs between unpacking the new libsystemd0 > and running the trigger will use libsystemd0 instead of libelogind0. Ah, of course! Sam, I don't see a way of implementing a robust dpkg-divert solution. Sorry. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Wed, Sep 25, 2019 at 10:09:15PM +0200, Thorsten Glaser wrote: > On Wed, 25 Sep 2019, Mark Hindley wrote: > > > libelogind0 can be coninstalled with libsystemd0. However, it is fragile > > because > > the file that needs to be diverted out of the way is libsystemd.so.0.26.0 > > (the > > actual library file, not a symlink) otherwise ldconfig will still find it > > and > > create symlinks. However, AFAICS dpkg-divert doesn't accept wildcards and > > so if > > the minor soversion is bumped and a new version of libsystemd0 is > > installed, the > > new file is installed without a divert and ldconfig redirects the symlink. > > Yes, this is not a good idea. > > You could do with a trigger on /usr/lib/ and a wildcard-expanding > shell loop in postinst, which is also a tad fragile. Thanks. Triggers may be an answer to the libsystemd soversion issue. > dpkg-divert also has a small period in which neither is available. > I don’t like this approach. In this usage case, I believe I have avoided this being a problem. The flow to switch to libelogind.so goes 1) symlink libelogind.so.0 to a temporary file. 2) rename temporary file to libsystemd.so.0 (I believe this is atomic). 3) dpkg-divert libsystemd.so.0.26.0 out of the way so ldconfig can't find it. 4) Whenever ldconfig runs the manual symlink libsystemd.so.0 -> libelogind.so.0 is preserved. I believe using a temporary file and then renaming means there is no point at which there is a valid libsystemd.so.0 symlink. But I could be wrong. This isn't the same as the 'standard' dpkg-divert when a file is moved out of the way so another can be installed in it's place Is this still flawed? Thanks Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Mon, Sep 23, 2019 at 04:16:05PM -0400, Sam Hartman wrote: > Mark> Anyway, I am happy to try to work up a dpkg-divert solution if > Mark> that is likely to be more acceptable. > > I don't know if it will be. > I'm trying to be a facilitator here and make sure all sides understand > each other. > > So, the advantage of the dpkg-divert approach seems to me to be that if > you never turn it on, it can't hurt you. > So, for example, if you do more than install a package to trigger it, it > could be very safe for the systemd user. > > Even if you trigger from the elogind postinst, that's probably OK so > long as very little hard depends on elogind. > > The disadvantages are: > > 1) Making sure you never get into a situation where you try to boot > systemd with libelogind0. Assuming you can dpkg-divert a symlink, you > can presumably manage the /sbin/init link, but you cannot stop someone > from init=/bin/systemd with libelogind0 as libsystemd0. Although > systemd doesn't actually link to libsystemd0, so perhaps that's not > quite as bad as I thought, although I'm sure it isn't good.. (You may > not need to stop this: it's a disadvantage, and sometimes the chosen > solution has disadvantages). > > 2) There was FUD about dpkg-divert being inappropriate for critical > system functions. I don't know whether this is still true or how big of > a deal it is. But for example if things are in an inconsistent state on > upgrade between unpack phase and configure phase, that might be a > disadvantage. Basically, I think it's probably fine if the initial > diversion has some fragility (where if your system crashes at that one > point, recovery is hard). I think it's less amazing if every time you > upgrade systemd, elogind or similar, there is fragility. I have got a PoC dpkg-divert solution working. The divert created in elogind.postinst and removed in elogind.prerm. The libsystemd.so compatibility symlink is also handled there. It works as far as it goes and it means that libelogind0 can be coninstalled with libsystemd0. However, it is fragile because the file that needs to be diverted out of the way is libsystemd.so.0.26.0 (the actual library file, not a symlink) otherwise ldconfig will still find it and create symlinks. However, AFAICS dpkg-divert doesn't accept wildcards and so if the minor soversion is bumped and a new version of libsystemd0 is installed, the new file is installed without a divert and ldconfig redirects the symlink. I can't work out a way around this at the moment, but any suggestions are welcome. Thanks Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Ian, Thanks for this. On Tue, Sep 24, 2019 at 07:28:29AM +0800, Ian Campbell wrote: > On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote: > Would it be any help at all of the "dbus client-ish" bits and the > "direct API-ish" bits of the two libraries were split up into two > separate libraries? i.e. would that allow the c/r/p replacement of one > of the two libraries (AIUI the API one is the more problematic) to be > pushed further up the dependency stack? I think that is what we already have (if I have understood you correctly). The dbus components are in systemd/elogind and the sd-*(3) APIs are in libsystemd0/libelogind0. Or have I misunderstood? > Has anyone investigated late dynamic binding using a stub library which > merely determines which init is running and then dlopens the > appropriate libsystemd0 of libelogind0 library and forwards the calls > to it? > I don't know if the dynamic linker could be coerced into doing the > selection automagically, in a way similar to how the hwcap stuff can be > used to pickup versions of libraries optimised for different classes of > processor. hwcap is provided by the kernel so I think can't be used > directly, but maybe there is a parallel mechanism somewhere? I think Adam Borowski suggested somthing similar a while ago as an option, but I am not aware of anything more than an idea. I also experimented with LD_PRELOAD a while ago. But it felt very hackish. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Mon, Sep 23, 2019 at 03:34:50PM -0400, Sam Hartman wrote: > Hi. > I've looked a bit at the systemd code as compared to the elogind code. > > One of the major reasons that libsystemd0 cannot be used as a > replacement for libelogind0 is that elogind does not have compatible > cgroup naming. > The systemd (and elogind) libraries do some operations over dbus. > But other operations are done directly. For example to look and see > what session a pid is in, the library will look at the cgroups of the > pid. > Similarly to see whether a particular pid belongs to a uid, it looks at > the cgroup naming. > > If you take a look at src/basic/cgroup-util.c in the elogind sources and > take a look at what is #if 0'd you can see the naming differences. Yes. systemd uses user units and scopes. elogind can not support either and uses internal hash containers. So if a system is running elogind and polkit asks libsystemd0 for a session id to a pid, it will search for a session-.scope and find nothing. See the two implementations of cg_path_get_session(): https://github.com/elogind/elogind/blob/d4a3f29/src/basic/cgroup-util.c#L1713 Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote: > Foo-package depends on the latest libsystemd0. I'm running unstable or > testing. The latest libsystemd0 isn't building on my arch yet. But > elogind is simpler and has build fine on my arch. I install foo-package > and suddenly end up with libelogind0 instead of libsystemd0 > > This is probably a problem. > Libsystemd0 and libelogind0 probably behave differently and you probably > do care which one you have. > The specific problems depend on what init system I have, on whether I > have elogind running or systemd-logind, etc. > But it's probably not a good situation. I believe we have guarded against exactly this already because libelogind0 conflicts with systemd, so you couldn't change from libsystemd0 to libelogind0 on a systemd install without removing the running systemd (which won't happen). > The concern is there might be other cases where the dependency resolver > gives you an answer that is inappropriate for your environment. We're > not sure we have confidence we can enumerate and think about all these > situations. I agree we can't envisage all cases, but that is what testing is for. Anyway, I am happy to try to work up a dpkg-divert solution if that is likely to be more acceptable. Thanks. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Sam, Many thanks for this. On Mon, Sep 23, 2019 at 11:58:18AM -0400, Sam Hartman wrote: Mark> I have tried the approach suggested by Laurent of using Mark> elogind with libsystemd0 and I could not get the sd-*(3) APIs Mark> to function correctly. > What trouble did you run into? That sd-login(3) APIs failed to match pids to the current session and so policykit authorisation failed. > So, I think I understand Julian's issues better after trying to write my > bits from the DPL mail. You have explained Julian's position and concerns far more clearly than has ever been the case directly to me. > You haven't really tried to address them at all. Hmmm. I think I have in line with the clarity with which they have been expressed. But let's move on. > His issue is that we have a long history of trouble with apt and c/r/p > being used this deep in the dependency chain. > So, he's arguing that you have a high bar (possibly infinitely high) for > using that approach. > > Ultimately he wants you to produce a solution where multiple init > systems can be coinstalled and where you don't need a conflicts. OK. But elogind is not an init. sysvinit-core and systemd are coinstallable, but not sysvinit-core and systemd-sysv. Do you mean he wants elogind and systemd to be coninstallable? > I think you've explored some of that design space and have a feel for > why some of that is unattractive. > As an example, if you have systemd installed, it might be running. The > combination of systemd running and libelogind0 being the systemd library > is unfortunate. Trying to boot systemd in that configuration (using > libelogind0) would presumably be quite fatal. Yes and this is currently prevented because both elogind and libelogind0 conflict with systemd. > So, the next question is why libelogind0 needs to exist. That is why > can't you just use libsystemd0 with elogind? > What I've heard so far is "It doesn't work." This was asked of elogind upstream this question almost a year ago: https://github.com/elogind/elogind/issues/97 In particular Yamakazure replied "What I can guarantee is, that if you link something against libsystemd, and then use elogind, that "something" will not work, as the inner workings of libsystemd are quite different. So keeping libsystemd around is no option. But if libsystemd is gone and simply replaced by libelogind, it might work." And we have since demonstrated that once the libelogind0 exposes the same ABI as libsystemd0 so it can be used as a direct replacement, it does work. A couple of days ago I built elogind without libelogind0 and installed it on a system with sysvinit-core and libsystemd0. Applications using the sd-login(3) API, most notably policykit-1 failed to associate pids and sessions and so all policykit-based authentication failed. > Why doesn't it work? How hard would it be to make it work? I am not completely sure. But I think it is because elogind and systemd-login store information in /sys/fs/cgroup/ differently because elogind does not have or need many of the features of systemd. Currently you need a matched pair, either systemd/libsystemd0 or elogind/libelogind0 for successful operation. elogind is never going to have all the features of systemd. That would be pointless. If you want or require all of those features, just use systemd. > Would that be better for Debian than using c/r/p? > And the answer to some of these might be "we don't know and we don't > have anyone who can find out." > That is a fine answer to give, although it might also be fine for the > release team to say that they want that analysis before committing to > something dangerous like c/r/p libsystemd0. > > But even if we understand why libelogind0 is needed, then why do we need > c/r/p libsystemd0? > Could we do something with dpkg-divert? Would that be better? It might possibly work. I will try it out. But, playing devil's advocate, I don't really see the difference: you will still be replacing libsystemd.so with libelogind.so. The only difference is where it happens -- in the package or via dpkg-divert. > If we are going to use c/r/p libsystemd0, is there some way we can limit > the potential damage to people who have positively indicated that they > want to run a non-default init system? > One of the concerns is what happens if apt decides somehow that it wants > to install libelogind0 when you don't expect it. I have to admit I don't understand this fear. libsystemd0 is just a way of talking to a running systemd process. If systemd is not running and PID 1 libsystemd0 APIs generally return non fatal errors. So by running a non-default init, libsystemd0 is only there to satisfy dynamically loaded symbols at runtime. Otherwise it is basically non functional. libelogind0 is the same if elogind isn't running.
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Sat, Sep 21, 2019 at 06:51:16PM +0200, Cristian Ionescu-Idbohrn wrote: > > Would you, please, start a new bug for this unless you really think > > it is the same issue (apt being broken by continuing to uninstall > > libsystemd0 after systemd prerm fails) and I will be happy to help. > > I really don't know what to think, but I do really feel this is not > related to the systemd installed version. Any current systemd version > should be removed without affecting the state. Am I wrong? I have to admit I am not clear exactly what you see is the problem. Is it that removing systemd is taking lots of other packages with it? Looking at the list of removals I think it is libpolkit-qt-1 that is taking everything else out becuase it has not been patched to support the new logind virtual packages. See #925344. But I still don't think it is the same as Simon's original bug here. HTH. Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
Cristian, On Sat, Sep 21, 2019 at 04:35:39PM +0200, Cristian Ionescu-Idbohrn wrote: > I'm interested in this, but my systems (unstable and testing) are in a > slightly different state. Let's take unstable, for example: Thanks for this. However, I really don't see it as relating to Simon's original report. Would you, please, start a new bug for this unless you really think it is the same issue (apt being broken by continuing to uninstall libsystemd0 after systemd prerm fails) and I will be happy to help. Thanks. Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
Control: tags -1 - pending On Fri, Sep 20, 2019 at 04:30:00PM +0200, Thorsten Glaser wrote: > On Thu, 19 Sep 2019, Mark Hindley wrote: > > > On irc he also said there was little point in adding the Breaks: as apt > > doesn't > > rexec itself. > > Yes, even a Pre-Depends would not achieve anything TTBOMK. OK. Thanks. Removing the pending tag as I don't think there is anything for elogind to do to fix this. Simon, Are you happy for me to close this as resolved? Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Julian, On Wed, Sep 11, 2019 at 02:28:55PM +0100, Mark Hindley wrote: > > I don't think it's reasonable to ship this package with C/R/P > > libsystemd0. > > I understand that you don't like it. However, for libelogind0 to export the > same > symbols as libsystemd0 so that it could C/R/P libsystemd0 was the agreed > solution to bug #923244. > > Do you have another suggestion as to how we could have resolved that? Other > solutions were discounted at the time. > > > I think it opens you (and, more importantly, users) up to issues like > > #934491. Even if #935910 were to be fixed in the package manager in > > > > > bullseye, it would still mean libelogind0 couldn't ship with the C/R/P > > until bullseye+1. > > I think it seems likely from discussions on #debian-dpkg that #935910 will be > fixed in APT and #934491 can be addressed by adding Breaks: << fixed APT. #935910 is now fixed in apt 1.8.4 in unstable and with that installed I can no longer reproduce #934491. The APT maintainers have said that adding a Breaks for the fixed version of apt is not useful. I have tried the approach suggested by Laurent of using elogind with libsystemd0 and I could not get the sd-*(3) APIs to function correctly. Are there any outstanding issues that you would like me to address to resolve this bug? Thanks. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Laurent, On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote: > Hello, > > When I looked I elogind a while back I was able to build a package without > having a public libelogind0, I basically had that in my debian/rules file: > > # We only build the libelogind0 and libelogind-dev if we are building for > # Devuan or its derivatives > ifneq ($(shell dpkg-vendor --derives-from Devuan && yes), yes) > export DH_OPTIONS=--no-package=libelogind0 --no-package=libelogind-dev > endif I have just tested this approach. The build and install seems OK. However, applications using the sd-*(3) APIs through libsystemd.so (most notably src:polickit-1) fail to match pids to sessions despite the session being registered correctly with elogind. Normal functionality is restored by installing libelogind0 and restarting polkitd. Sorry. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Laurent, On Fri, Sep 20, 2019 at 01:29:43PM +0200, Laurent Bigonville wrote: > Can't this be stubbed or mocked on the elogind side? I presume you mean slices here? (I am not sure that slices are the only difference in implementation, but let's ignore that for now). To be honest, I am not sure. Possibly, but I have my doubts that upstream would be interested in doing it: elogind has no use for them. Although they have already been very accommodating by stubbing out all the APIs in libelogind0 to be binary compatible with libsystemd0. As I see it, if you want slices and all of the other features that systemd provides, use systemd. If you want a slimmed down implementation of DBus login1 and sd-login(3) to use when systemd is not PID1, then elogind might be useful. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote: > Hello, > > When I looked I elogind a while back I was able to build a package without > having a public libelogind0, I basically had that in my debian/rules file: > > # We only build the libelogind0 and libelogind-dev if we are building for > # Devuan or its derivatives > ifneq ($(shell dpkg-vendor --derives-from Devuan && yes), yes) > export DH_OPTIONS=--no-package=libelogind0 --no-package=libelogind-dev > endif > > libelogind library is only needed for applications that want to interact > with the daemon, in the ITP (#905388) bug I also noted that. > > If I'm not mistaken, libsystemd (and libelogind) are using D-Bus to > communicate with the daemon part, was it checked that the API used is > compatible? Is there documentation of the differences, if any? Yes, the APIs are the same (deliberately so). > Bottom line, is libelogind even needed in the archive to achieve your goal > of having an implementation of the login1 D-Bus API not requiring systemd as > PID1? Thanks. I think you are correct that the login1 DBus API doesn't require libsystemd0 or libelogind0. However some packages, notably policykit use the sd-login(3) API which is part of libsystemd0 or libelogind0. Whilst the APIs, and symbol ABIs are the same between the two libraries (with the caveats noted in the libelogind0 package description) the implementations differ. I have been tolkd int he past by elogind upstream that it is not possible for elogind to use libsystemd0. For example libsystemd0 requires the concept of slices which elogind doesn't have. The only way I have got all of these components to work together on an elogind systemd is to ensure everything uses libelogind0. Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Thu, Sep 19, 2019 at 08:36:53PM +0100, Mark Hindley wrote: > Control: tags -1 pending > > Simon, > > On Tue, Aug 27, 2019 at 05:46:32PM +0100, Mark Hindley wrote: > > I think I have finally got to the bottom of this. As you suspected it is > > apt's > > invocation of dpkg. See #935910. > > This has now been fixed in apt 1.9.4 (experimental). > > I propose to add > > Breaks: apt (<< 1.9.4) > > to the libelogind0 stanza in d/control. > > In my testing with apt v1.9.4 system breakage is avoided. After the systemd > prerm fails, dpkg returns immediately and apt is still available to fix the > system. Actually, Julian has just uploaded apt 1.8.4 with the same fix to unstable. On irc he also said there was little point in adding the Breaks: as apt doesn't rexec itself. I suppose the only thing it might achieve is to ensure apt had been updated to the latest version already. Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
Control: tags -1 pending Simon, On Tue, Aug 27, 2019 at 05:46:32PM +0100, Mark Hindley wrote: > I think I have finally got to the bottom of this. As you suspected it is apt's > invocation of dpkg. See #935910. This has now been fixed in apt 1.9.4 (experimental). I propose to add Breaks: apt (<< 1.9.4) to the libelogind0 stanza in d/control. In my testing with apt v1.9.4 system breakage is avoided. After the systemd prerm fails, dpkg returns immediately and apt is still available to fix the system. Are you happy with this? Mark
Bug#940565: PySide2 segfaults with Python3. Message: "SystemError: could not initialize part 1" (shiboken)
Package: pyside2 Version: 5.11.2-3 Severity: grave The file test.py contains a single line (without the "> " quotation): > import PySide2.QtCore as core Running > python3 test.py results in a segfault with output: > SystemError: could not initialize part 1 FWIW, I could trace that message to sources/shiboken2/libshiboken/signature.cpp in the pyside2 orig.tar Running the script with python instead of python3 gives no error. The same behaviour occurs with other Pyside2 modules instead of QtCore. > uname -a > Linux debian 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28) x86_64 > GNU/Linux > ls -l /lib/*/libc.so.6 > lrwxrwxrwx 1 root root 12 Mai 1 19:24 /lib/x86_64-linux-gnu/libc.so.6 -> > libc-2.28.so The machine in question runs in a VirtualBox VM. Best regards, Mark Weyer
Bug#940034: elogind and the release team block
Julien, On Wed, Sep 11, 2019 at 03:07:51PM +0100, Mark Hindley wrote: > I would hope we can all accept those. If so, there is no requirement for a > manual block: at the moment there are RC bugs which prevent migration. If or > when they are resolved migration can occur based on the release teams policy > in > effect at that time. I see you have removed the block whilst I was writing this. Thank you. Mark
Bug#940034: elogind and the release team block
Sam, Thanks On Wed, Sep 11, 2019 at 09:15:58AM -0400, Sam Hartman wrote: > I reached out to jcristau to talk about his block hint. > Based on our IRC discussion, it sounds like he was having trouble > bringing himself to remove the hint presumably because he doesn't think > the broader issue was being dealt with. Thanks for helping to clarify that. [snip] > Actually, they would prefer that you create an elogind that mirrors > enough of the interfaces that you can just use libpam-systemd. You said > that would not work, explaining that elogind for example doesn't have a > concept of slices. You never clearly articulated why it couldn't > emulate slices enough to pacify libpam-systemd. I don't know if it is > just that work hasn't been done or if it would be a bad idea for some > reason. This was from my discussions with elogind upstream, mainly in the context of #923244. We considered the possibility of linking elogind against libsystemd0. However, it was felt that the implementations were sufficiently different to make that unfeasible. My understanding is that elogind doesn't have a concept of slice simply because it doesn't require them. It just maps pids, sessions and users. But I am happy to go back to them and ask again. > Now you've got someone arguing that the providing libpam-systemd and > conflicting with libpam-systemd is problematic. Do you mean libsystemd0 here? > And I'll admit that it is definitely a problematic approach. > I realize that you talked it over with the systemd maintainers and while > they didn't quite agree, my reading of their message was fairly > sympathetic. > > So now you've got conflicting requirements coming from multiple > directions. > > I really don't see a way forward besides getting enough of the right > parties involved to understand the issues and come up with a solution > that balances the trade offs across multiple packages. > > I'm sorry that you've been placed in this position. No worries. Thanks for your help. My suggestion is based on the following premises:- - We are currently early in the bullseye cycle. There seems to me to be no better time to allow a wider audience to test elogind and report problems. I can certainly understand reluctance to test this later in the cycle. - The existing RC bug handling is sufficient on its own to control whether elogind should be in testing. - If problems are found with elogind either directly or indirectly, please submit bugs, RC status if it is warranted, and I will be happy to deal with them. I want elogind to be as good as it can be both for its users and for people who choose not to use it. I would hope we can all accept those. If so, there is no requirement for a manual block: at the moment there are RC bugs which prevent migration. If or when they are resolved migration can occur based on the release teams policy in effect at that time. Does that seem reasonable? Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Julien, Thank you. On Wed, Sep 11, 2019 at 02:48:19PM +0200, Julien Cristau wrote: > -UID: 41176 > > Package: libelogind0 > Version: 241.3-1+debian1 > Severity: serious > > I wrote this in #934132 but that is being ignored so I'll repeat here. I don't think it was being ignored, rather I had already answered it there. > I don't think it's reasonable to ship this package with C/R/P > libsystemd0. I understand that you don't like it. However, for libelogind0 to export the same symbols as libsystemd0 so that it could C/R/P libsystemd0 was the agreed solution to bug #923244. Do you have another suggestion as to how we could have resolved that? Other solutions were discounted at the time. > I think it opens you (and, more importantly, users) up to issues like > #934491. Even if #935910 were to be fixed in the package manager in > > > bullseye, it would still mean libelogind0 couldn't ship with the C/R/P > until bullseye+1. I think it seems likely from discussions on #debian-dpkg that #935910 will be fixed in APT and #934491 can be addressed by adding Breaks: << fixed APT. > But beyond that particular issue, I'm sorry to say I think fundamentally > attempting to provide a drop-in replacement for libsystemd0 while > conflicting with systemd is doomed. The replacement of sysvinit with > systemd was careful to keep both init systems co-installable, and I > think that's something to preserve to avoid providing users with a > loaded footgun with alternative init systems. I think this is where we will just have to disagree. I think choice in software is important. That choice is precious and can be exercised in many ways. Most importantly, you are free to choose not to use something that you don't like or don't want. Best wishes Mark
