Bug#792206: apt-cacher: modifies conffiles (policy 10.7.3): /etc/default/apt-cacher
package apt-cacher notfound 792206 1.7.11 thanks
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#923240: policykit-1: Please support alternative logind implementations
Control: tags -1 - moreinfo Simon, Many thanks for this. On Fri, Aug 09, 2019 at 02:35:13PM +0100, Simon McVittie wrote: > Control: tags -1 + moreinfo > > On Mon, 25 Feb 2019 at 10:58:49 +0000, Mark Hindley wrote: > > For desktops to be installable on such systems, policykit-1 needs to depend > > on > > the newly approved virtual packages default-logind and logind. In the latest > > upload of src:systemd, libpam-systemd provides default-logind. > > Sorry for the delay in getting back to you on this. Non-critical changes > to important components like policykit-1 did not seem like a good idea > during the buster release freeze. Yes, I understand that. It also seems to me that now, early in the bullseye cycle, is a good time for such changes. > Does polkit work correctly on systems that use elogind, without any > further source or binary changes? It is not enough that a logind-like > service is merely installed and monitoring sessions: to keep polkit's > core functionality working, it has to be able to query logind's state > via libsystemd.so.0 APIs. Yes, it works in my testing. I have had a number of other reports of success too with a variety of desktops (xfce, mate, budgie, cinnamon and even gnome). Since #923244 was resolved in version 241.1-1+debian1, libelogind0 is ABI compatible with libsystemd0 and exposes the same symbols for runtime linking, although providing a subset of functionality. This is explained fully in the libelogind0 package description: sd-login(3), sd-bus(3) and sd-id128(3) APIs are implemented in full with most other functions returning -ENOSYS. libelogind0 also provides a libsystemd.so symlink so that applications compiled against systemd work with libelogind0 at runtime. > For example, when polkitd calls sd_pid_get_session(), if the system is > using elogind, the API call needs to return whether pid is part of an > elogind session. > > Please could you describe how this is meant to work on systems that use > elogind? Which packages are meant to be installed to make this work? > > For comparison, here is how it works on systemd systems: > > - libpam_systemd is invoked on login and logout > - libpam_systemd communicates with systemd-logind to update its knowledge > of login sessions > - polkitd is linked to libsystemd.so.0, which is provided by libsystemd0 > - libsystemd0 communicates with systemd-logind via D-Bus, or by reading > files in /run/systemd that are considered private to the combination > of systemd-logind and libsystemd0 (mainly /run/systemd/seats and > /run/systemd/sessions, I think) > > Which parts of that architecture get replaced when using elogind? In exactly the same way. libpam-elogind is invoked at login/logout and updates elogind's record of sessions. polkitd calls functions in libelogind.so via its libsystemd.so symlink to retrieve information on users, sessions and their related processes. > When a bug is reported in policykit-1 on a system that is using elogind, > does the reportbug-generated message template indicate that? Is there > someone among the elogind maintainers who can help with such bugs if > they appear to be integration issues between policykit-1 and elogind? > > (If the reportbug-generated message template with your proposed patch > doesn't currently indicate systemd-logind vs. elogind, it should be > possible to fix that by putting appropriate runes in > debian/policykit-1.bug-control.) I will be very happy to work to resolve issues related to elogind and its integration with other packages. You are correct that a reportbug template including that information would be useful. > > There is a separate issue about backend support for elogind. I will > > open a separate bug for that. > > Does that separate bug exist, or has the question of backend support > become irrelevant due to changes in the design of how elogind fits into > Debian since you opened this bug? Yes that was #923244 which has now been solved by runtime ABI compatibility rather than the original suggestion of alternative backend packages. > On Fri, 09 Aug 2019 at 14:15:17 +0200, Svante Signell wrote: > > Please explain your decision on why desktops for other > > init systems are excluded (even in sid). > > Please don't assume that the absence of action is a deliberate decision. > All of policykit-1's maintainers (both upstream and in Debian) mostly > work on other things and don't have a huge amount of time available for > policykit-1. This makes us reluctant to risk creating the possibility > of non-functional combinations of packages that will take more of our > time to debug. I understand. To help prevent that libelogind0 conflicts with systemd itself so that the non-functional situation of systemd with libelogind0 is not possible. Thanks and best wishes. 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#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#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#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#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#926591: libelogind0: does not ship SONAME link /lib//libelogind.so.0 -> libsystemd.so.0.25.0
control: tags -1 pending On Sun, Apr 07, 2019 at 02:12:54PM +0200, Andreas Beckmann wrote: > I think the symlink setup is overly complicated by using both > /lib and /usr/lib. You should either move everything to /lib > (if that is really required for compatibility with libsystemd0) > or just restrict to /usr/lib (as done in my patch). > I also think you don't need libsystemd.so.0.25.0 symlinks at all, > a libsystemd.so.0 -> libelogind.so.0 symlink should be sufficient. Thanks for this. I have queued your patch for upload. > This produces some noise in piuparts tests and therefore I'd like > to see it fixed for buster. Version 241.1-1 isn't in buster and I am not sure if it will make it in as there is no sign of movement in the unblock request (#925489). But I am happy to fix it in unstable. Thanks Mark
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#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#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#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#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#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
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
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#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#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
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#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. So the scenarios I can see are 1) systemd PID 1 with libsystemd0 2) alternative init with libsystemd0 3) alternative init with libelogind0 4) no init (contain
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
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
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 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
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 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
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: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, 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
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
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
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#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#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#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#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#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#905178: apt-cacher: prompting due to modified conffiles which were not modified by the user: /etc/default/apt-cacher
Andreas On Sat, Mar 23, 2019 at 07:00:53PM +0100, Andreas Beckmann wrote: > you probably need to take care of the config files installed by older > versions, here I could still trigger the bug on upgrades from squeeze to > wheezy to jessie to stretch to buster. Thanks for pointing this out. Just so we don't have to revisit it again in the future, how far back do you think this needs to go? lenny? earlier? Mark
Bug#905178: apt-cacher: prompting due to modified conffiles which were not modified by the user: /etc/default/apt-cacher
control: tags -1 pending
Bug#916768: libelogind-dev-doc: missing Breaks+Replaces: libelogind-dev (<< 239.1+20181115-1)
Package: libelogind-dev-doc Tags: pending On Tue, Dec 18, 2018 at 01:21:47PM +0100, Andreas Beckmann wrote: > Package: libelogind-dev-doc > Version: 239.3-3+debian1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'testing'. > It installed fine in 'testing', then the upgrade to 'sid' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. Andreas, Many thanks. I have queued a fix for this. > PS: please use a normal debian revision in the version, i.e. only number This is deliberate: Devuan is the defacto packaging upstream for these packages and therefore has the plain number only revision. We need to distinguish the versions that include the Debian specific packaging. Mark
Bug#916768: closed by Mark Hindley (Re: Bug#916768: libelogind-dev-doc: missing Breaks+Replaces: libelogind-dev (<< 239.1+20181115-1))
On Thu, Dec 20, 2018 at 08:10:09AM +0100, Helmut Grohne wrote: > Control: reopen 916750 > > Hi Mark, > > On Wed, Dec 19, 2018 at 06:39:04PM +, Debian Bug Tracking System wrote: > > Package: libelogind-dev-doc > > Version: 239.3-4+debian1 > > > > Closing manually as upload had typo in bug number. > > > > Sorry. > > If you noticed your mistake and closed the right bug now, why didn't you > reopen the bug you erroneously closed? Doing so now. Helmut, Apologies. I was going to but I have limited connectivity and wanted to make sure I did it right first: I wasn't clear if a reopen was sufficient. Sorry for messing with your report. Mark
Bug#939101: elogind: elogind 239 in bullseye FTBFS with gcc-9
Package: elogind Version: 239.3+20190131-1+debian1 Severity: serious Control: fixed -1 241.3-1+debian1 Control: block -1 by 934132 Reproducible builds of src:elogind 239.3+20190131-1+debian1 in bullseye have FTBFS for the last few days. This seems to be related to the migration of gcc-9 to bullseye. The issue appears to be the STRING_FOREACH macro and was fixed in systemd in v241: https://github.com/systemd/systemd/issues/11394 https://bugzilla.opensuse.org/show_bug.cgi?id=1121387#c0 This fix is already included in elogind 241.3-1+debian1 which is in unstable. However, migration of elogind 241.3-1+debian1 to bullseye is currently blocked (see #934132). When it is unblocked it should resolve this issue. Mark
Bug#939101: elogind: elogind 239 in bullseye FTBFS with gcc-9
On Sun, Sep 01, 2019 at 11:33:55AM +0100, Mark Hindley wrote: > The issue appears to be the STRING_FOREACH macro and was fixed in > systemd in v241: Sorry, that should be FOREACH_STRING macro. Mark
Bug#939101: Not present in sid, removing tag
Control: tags -1 - sid Andreas, On Mon, Sep 02, 2019 at 05:21:13PM +0200, Andreas Beckmann wrote: > tags 939101 + sid bullseye Actually, this isn't present in sid AFAICS. Thanks 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
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: 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#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#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#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#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#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#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#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#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#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#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#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&ver=3.20.6%2Bdfsg0-1&arch=amd64 > [2]: > https://buildd.debian.org/status/logs.php?pkg=gnome-applets&ver=3.37.2-1&arch=amd64 > [3]: > https://buildd.debian.org/status/logs.php?pkg=kopete&ver=4%3A20.04.1-1&arch=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)
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)
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: 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&ver=3.20.6%2Bdfsg0-1&arch=amd64 > [2]: > https://buildd.debian.org/status/logs.php?pkg=gnome-applets&ver=3.37.2-1&arch=amd64 > [3]: > https://buildd.debian.org/status/logs.php?pkg=kopete&ver=4%3A20.04.1-1&arch=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#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#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 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 '
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#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#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#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#1052942: insserv: FTBFS: insserv: Could not read script nolsbheader: No such file or directory
6 kB] Ign:3 http://deb.debian.org/debian unstable/main Translation-en.diff/Index Get:4 http://deb.debian.org/debian unstable/main amd64 Packages [9512 kB] Get:5 http://deb.debian.org/debian unstable/main Translation-en [7032 kB] Fetched 16.9 MB in 10s (1747 kB/s) Reading package lists... Building dependency tree... Reading state information... 176 packages can be upgraded. Run 'apt list --upgradable' to see them. I: user script /var/cache/pbuilder/build/cow.20068/tmp/hooks/D05apt-update finished I: user script /var/cache/pbuilder/build/cow.20068/tmp/hooks/D80no-man-db-rebuild starting I: Preseed man-db/auto-update to false I: user script /var/cache/pbuilder/build/cow.20068/tmp/hooks/D80no-man-db-rebuild finished I: -> Attempting to satisfy build-dependencies Note, using file '/build/insserv_1.24.0-1.dsc' to get the build dependencies Reading package lists... Building dependency tree... Reading state information... The following NEW packages will be installed: bash-completion debconf: delaying package configuration, since apt-utils is not installed 0 upgraded, 1 newly installed, 0 to remove and 176 not upgraded. Need to get 0 B/224 kB of archives. After this operation, 1489 kB of additional disk space will be used. Selecting previously unselected package bash-completion. (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 23021 files and directories currently installed.) Preparing to unpack .../bash-completion_1%3a2.11-8_all.deb ... Unpacking bash-completion (1:2.11-8) ... Setting up bash-completion (1:2.11-8) ... Processing triggers for man-db (2.11.2-2) ... Not building database; man-db/auto-update is not 'true'. Reading package lists... Building dependency tree... Reading state information... The following additional packages will be installed: libfakeroot The following packages will be upgraded: fakeroot libfakeroot debconf: delaying package configuration, since apt-utils is not installed 2 upgraded, 0 newly installed, 0 to remove and 174 not upgraded. Need to get 0 B/95.0 kB of archives. After this operation, 0 B of additional disk space will be used. (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 23787 files and directories currently installed.) Preparing to unpack .../libfakeroot_1.32.1-1_amd64.deb ... Unpacking libfakeroot:amd64 (1.32.1-1) over (1.31-1.2) ... Preparing to unpack .../fakeroot_1.32.1-1_amd64.deb ... Unpacking fakeroot (1.32.1-1) over (1.31-1.2) ... Setting up libfakeroot:amd64 (1.32.1-1) ... Setting up fakeroot (1.32.1-1) ... Processing triggers for man-db (2.11.2-2) ... Not building database; man-db/auto-update is not 'true'. Processing triggers for libc-bin (2.36-9) ... I: Copying back the cached apt archive contents I: Building the package I: Running cd /build/insserv-1.24.0/ && env PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage -us -uc '--no-pre-clean' && env PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-genchanges -S > ../insserv_1.24.0-1_source.changes dpkg-buildpackage: info: source package insserv dpkg-buildpackage: info: source version 1.24.0-1 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Mark Hindley dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 debian/rules build echo -g -O2 -ffile-prefix-map=/build/insserv-1.24.0=. -fstack-protector-strong -Wformat -Werror=format-security -g -O2 -ffile-prefix-map=/build/insserv-1.24.0=. -fstack-protector-strong -Wformat -Werror=format-security dh build --with=bash-completion dh_update_autotools_config dh_autoreconf dh_auto_configure dh_auto_build make -j2 "INSTALL=install --strip-program=true" make[1]: Entering directory '/build/insserv-1.24.0' sed -r '\!@@BEGIN_SUSE@@!,\!@@(ELSE|END)_SUSE@@!d;\!@@(NOT|END)_SUSE@@!d'
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#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#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
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#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#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#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#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#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#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#447646: apt-cacher: upstream server caught mid-sync causes indefinite false hits and constant client MD5Sum mismatch errors
Thanks for this. Could you give me a bit more info:
Are you using checksumming?
Can you send the debug output of one of the 'stuck' retrievals
On Mon, Oct 22, 2007 at 01:03:49PM -0700, Tony Godshall wrote:
> When upstream server is caught mid-sync and apt-cacher downloads only
> a partial file,
> apt-get on client identifies it as a MD5Sum mismatch error.
>
> Without apt-cacher, this is easily handled- one simply runs "apt-get
> update && apt-get install $pkgs" again.
>
> With apt-cacher, the the partial file continues to be returned,
> resulting in a "stuck" condition in the
> clients.
>
> The code at issue appears to be...
>
> if (-f $complete_file) {
> # not much to do if complete
> # Possibly checksum cached file before delivery
> $cache_status = "HIT";
> debug_message("$cache_status");
> }
I have wondered if this piece of code is adequate. 1.5.5 checks the size
of the returned file against the cached header. See line 981. But this
will only pickup on disk corruption. Checksumming should have picked
this up, if you were using it.
In addition, to force refresh of a cached file, apt-cacher now honours
Pragma: No-cache. So doing
apt-get -o Acquire::http::No-Cache=true install $pkg
should have forced a fresh file to be downloaded.
I would be grateful if you could try this and tell me if it doesn't work
> Apparently apt-cacher assumes that a file downloaded with good status
> is complete, which makes it unusable for common situations, such as...
One solution seems to be to send a head request upstream and verify that
the cached file is the size expected. There seems likely to be a
significant overhead for that. Maybe we should use checksumming all the
time?
Thanks,
Mark
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447646: apt-cacher: upstream server caught mid-sync causes indefinite false hits and constant client MD5Sum mismatch errors
severity 447646 important thanks Since there is a workaround using the No-Cache option, I propose to downgrade this to important Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485089: apt-cacher: 1.6.3: Checksum database recovery locking broken
Package: apt-cacher Version: 1.6.3 Severity: serious Tags: pending Locking of checksum database recovery is broken in 1.6.3 causing a hang. Serverity to prevent Testing migration. Fix upload is pending Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#519896: apt-cacher: upgrade failure
On Mon, Mar 16, 2009 at 12:45:35AM +0100, Marc Dequènes (Duck) wrote:
> Coin,
>
> In fact, 1.6.7 is not working any more. Seems it is related to libdb4.7
> being draggued in by other packages in the upgrade.
Could you try this patch.
Mark
commit 08c1ecae34e77d5f164fa2ac4208cc0e76024b9d
Author: Mark Hindley
Date: Mon Mar 16 09:03:59 2009 +
Possible fix for #519896.
DB logging controlled with log_set_config in libdb-4.7
diff --git a/apt-cacher-lib-cs.pl b/apt-cacher-lib-cs.pl
index bff07aa..83feed9 100755
--- a/apt-cacher-lib-cs.pl
+++ b/apt-cacher-lib-cs.pl
@@ -123,8 +123,8 @@ sub db_recover {
-Flags => DB_CREATE | DB_INIT_LOG |
DB_INIT_MPOOL | DB_INIT_TXN |
DB_RECOVER | DB_PRIVATE | DB_USE_ENVIRON,
- -SetFlags => DB_LOG_INMEMORY
or die "Unable to create recovery environment:
$BerkeleyDB::Error\n";
+$renv->log_set_config( DB_LOG_INMEMORY, 1 ) && warn "log_set_config failed
with $!";
close $logfile;
unlink "$cfg->{cache_dir}/private/dblock";
return defined $renv;
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519896: apt-cacher: upgrade failure
On Mon, Mar 16, 2009 at 10:56:11AM +0100, Marc Dequènes (Duck) wrote:
> Coin,
>
> Quoting "Mark Hindley" :
>
>> Could you try this patch.
>
> Just moved the complaint to the log_set_config() line.
Sorry, they have changed the flag as well. Is this better?
commit 9d0562b66e472e40c0dda778af58708c92b2abce
Author: Mark Hindley
Date: Mon Mar 16 10:35:39 2009 +
DB_LOG_INMEMORY changed to DB_LOG_IN_MEMORY!!
diff --git a/apt-cacher-lib-cs.pl b/apt-cacher-lib-cs.pl
index 83feed9..e0665c4 100755
--- a/apt-cacher-lib-cs.pl
+++ b/apt-cacher-lib-cs.pl
@@ -124,7 +124,7 @@ sub db_recover {
DB_INIT_MPOOL | DB_INIT_TXN |
DB_RECOVER | DB_PRIVATE | DB_USE_ENVIRON,
or die "Unable to create recovery environment:
$BerkeleyDB::Error\n";
-$renv->log_set_config( DB_LOG_INMEMORY, 1 ) && warn "log_set_config failed
with $!";
+$renv->log_set_config( DB_LOG_IN_MEMORY, 1 ) && warn "log_set_config
failed with $!";
close $logfile;
unlink "$cfg->{cache_dir}/private/dblock";
return defined $renv;
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519896: setting package to apt-cacher, tagging 540691, tagging 517761, tagging 519896, tagging 537189
# Automatically generated email from bts, devscripts version 2.10.35lenny3 # via tagpending # # apt-cacher (1.6.9) unstable; urgency=low # # * Rescan cached files after checking for diff_Index parents (closes: #537189) # * Fix handling of Keep-Alive and multiple hosts in path_map. Debugging by "Daniel Richard G." (closes: #517761) # * Fix "400 No request Received" caused by incomplete input line. Patch from "Daniel Richard G." (closes: #540691) # * Support libdb4.7 (closes: #519896) package apt-cacher tags 540691 + pending tags 517761 + pending tags 519896 + pending tags 537189 + pending -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519896: setting package to apt-cacher, tagging 540691, tagging 541378, tagging 517761, tagging 519896 ...
# Automatically generated email from bts, devscripts version 2.10.35lenny3 # via tagpending # # apt-cacher (1.6.9) unstable; urgency=low # # * Rescan cached files after checking for diff_Index parents (closes: #537189) # * Fix initscript for dependency based boot sequencing. Patch from Petter Reinholdtsen (closes: #541378) # * Fix handling of Keep-Alive and multiple hosts in path_map. Debugging by "Daniel Richard G." (closes: #517761) # * Fix "400 No request Received" caused by incomplete input line. Patch from "Daniel Richard G." (closes: #540691) # * Support libdb4.7 (closes: #519896) package apt-cacher tags 540691 + pending tags 541378 + pending tags 517761 + pending tags 519896 + pending tags 537189 + pending -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519896: setting package to apt-cacher, tagging 540691, tagging 516525, tagging 541378, tagging 517761 ...
# Automatically generated email from bts, devscripts version 2.10.35lenny3 # via tagpending # # apt-cacher (1.6.9) unstable; urgency=low # # * Rescan cached files after checking for diff_Index parents (closes: #537189) # * Fix initscript for dependency based boot sequencing. Patch from Petter Reinholdtsen (closes: #541378) # * Fix handling of Keep-Alive and multiple hosts in path_map. Debugging by "Daniel Richard G." (closes: #517761, #516525) # * Fix "400 No request Received" caused by incomplete input line. Patch from "Daniel Richard G." (closes: #540691) # * Support libdb4.7 (closes: #519896) # * Remove regular calls to libdb failchk (closes: #535093) package apt-cacher tags 540691 + pending tags 516525 + pending tags 541378 + pending tags 517761 + pending tags 519896 + pending tags 535093 + pending tags 537189 + pending -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519896: setting package to apt-cacher, tagging 540691, tagging 516525, tagging 541378, tagging 517761 ...
# Automatically generated email from bts, devscripts version 2.10.35lenny3 # via tagpending # # apt-cacher (1.6.9) unstable; urgency=low # # * Rescan cached files after checking for diff_Index parents (closes: #537189) # * Fix initscript for dependency based boot sequencing. Patch from Petter Reinholdtsen (closes: #541378) # * Fix handling of Keep-Alive and multiple hosts in path_map. Debugging by "Daniel Richard G." (closes: #517761, #516525) # * Fix "400 No request Received" caused by incomplete input line. Patch from "Daniel Richard G." (closes: #540691) # * Support libdb4.7 (closes: #519896) # * Remove regular calls to libdb failchk (closes: #535093) package apt-cacher tags 540691 + pending tags 516525 + pending tags 541378 + pending tags 517761 + pending tags 519896 + pending tags 535093 + pending tags 537189 + pending -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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&suite=experimental [2] https://udd.debian.org/cgi-bin/autoremovals.cgi
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#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_action_msg "$@"; }
-
-case "$1" in
-start)
-# start is handled by /usr/lib/udev/rules.d/85-hwclock.rules.
-
Bug#598469: apt-cacher: excessive connections launched at server
reassign 598469 apt-cacher-ng Thanks On Wed, Sep 29, 2010 at 10:14:52AM +0100, Philip Hands wrote: > Package: apt-cacher > Severity: serious > > Hi, > > I run ftp.uk.debian.org, and recently noticed that I was getting hourly > spikes of connections. On investigation, it seems that a particular IP > address is launching what ammounts to a low-grade DoS, trying to get > the same files thousands of times a day, making hundreds of attempts per > second. > > Examining the incoming packets, I see this header: > > User-Agent: Debian Apt-Cacher-NG/0.4 This is apt-cacher-ng, not apt-cacher. Reassigned Mark -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786661: apt-cacher: Does not work in inetd mode - fails to create /var/run/apt-cacher
On Sun, May 24, 2015 at 11:27:09AM +0200, Robert Luberda wrote:
> Package: apt-cacher
> Version: 1.7.10
> Severity: serious
> Justification: Policy 9.1.4
>
> In inetd mode apt-cacher is run as www-data user, who does not
> have permission to create /var/run/apt-cacher directory. This
> makes apt-cacher die() in /usr/share/apt-cacher/lib/apt-cacher.pl:429:
Thanks.
Yes, I had already noticed this. I already had a fix queued which is to fallback
to /tmp/apt-cacher if /var/run is not writable (inetd or CGI mode).
I think this might have been the underlying cause of bug #760141 as well.
Try this:
diff --git a/lib/apt-cacher.pl b/lib/apt-cacher.pl
index ff56a08..d8524cc 100755
--- a/lib/apt-cacher.pl
+++ b/lib/apt-cacher.pl
@@ -18,6 +18,7 @@ use IO::Uncompress::AnyUncompress qw($AnyUncompressError);
use Module::Load::Conditional;
use File::Spec;
use File::Path ();
+use List::Util;
use Carp::Always;
use Carp;
our $cfg;
@@ -53,7 +54,7 @@ sub read_config {
generate_reports => 1,
group => eval {my $g = $); $g =~ s/\s.*$//; $g},
http_proxy => '',
- libcurl_socket => '/var/run/apt-cacher/libcurl.socket',
+ libcurl_socket => (List::Util::first { -w || -w
(File::Spec->splitpath($_))[1] } glob('{/var/run,/tmp}/apt-cacher')) .
'/libcurl.socket',
limit => 0,
limit_global => 0,
log_dir => '/var/log/apt-cacher',
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786661: apt-cacher: Does not work in inetd mode - fails to create /var/run/apt-cacher
package apt-cacher
tag 786661 pending
thanks
On Sun, May 31, 2015 at 11:53:52AM +0200, Robert Luberda wrote:
> Mark Hindley pisze:
>
> Yes, this work, but I think this might be considered as rather insecure
> use of /tmp. You can consider changing init script instead or in
> addition to the change, for example like this:
>
>
> diff --git a/init.d/apt-cacher b/init.d/apt-cacher
> index 2c38b7f..46500f9 100755
> --- a/init.d/apt-cacher
> +++ b/init.d/apt-cacher
> @@ -15,7 +15,8 @@
>DESC="Apt-Cacher"
>NAME=apt-cacher
>DAEMON=/usr/sbin/$NAME
> -PIDFILE=/var/run/$NAME/$NAME.pid
> +PIDDIR=/var/run/$NAME
> +PIDFILE=$PIDDIR/$NAME.pid
>SCRIPTNAME=/etc/init.d/$NAME
>
># Gracefully exit if the package has been removed.
> @@ -33,7 +34,12 @@ fi
># Function that starts the daemon/service.
>#
>d_start() {
> -
> +# apt-cacher needs $PIDDIR, but is not able to create it in the
> inetd mode
> +if test ! -d "$PIDDIR"; then
> + mkdir -m 755 "$PIDDIR"
> + chown www-data:www-data "$PIDDIR"
> +fi
> +
>if test "$AUTOSTART" = 1 ; then
>start-stop-daemon --start --quiet \
> --exec $DAEMON -- -R 3 -d -p $PIDFILE $EXTRAOPT && \
Thanks.
Yes, I had thought of that approach, but I was concerned that the user
configurable variable libcurl_socket could get of sync with the RUNDIR specified
in the initscript. But I suppose if folk are going to start moving things
around, they will have to ensure the directories are sane and writable.
Mark
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786661: apt-cacher: Does not work in inetd mode - fails to create /var/run/apt-cacher
On Sun, May 31, 2015 at 11:53:52AM +0200, Robert Luberda wrote:
> diff --git a/init.d/apt-cacher b/init.d/apt-cacher
> index 2c38b7f..46500f9 100755
> --- a/init.d/apt-cacher
> +++ b/init.d/apt-cacher
> @@ -15,7 +15,8 @@
>DESC="Apt-Cacher"
>NAME=apt-cacher
>DAEMON=/usr/sbin/$NAME
> -PIDFILE=/var/run/$NAME/$NAME.pid
> +PIDDIR=/var/run/$NAME
> +PIDFILE=$PIDDIR/$NAME.pid
>SCRIPTNAME=/etc/init.d/$NAME
>
># Gracefully exit if the package has been removed.
> @@ -33,7 +34,12 @@ fi
># Function that starts the daemon/service.
>#
>d_start() {
> -
> +# apt-cacher needs $PIDDIR, but is not able to create it in the
> inetd mode
> +if test ! -d "$PIDDIR"; then
> + mkdir -m 755 "$PIDDIR"
> + chown www-data:www-data "$PIDDIR"
Sorry, the other thing I meant to add is that setting the user:group here could
break installations where admins have changed the user or group in
apt-cacher.conf.
Mark
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786661: apt-cacher: Does not work in inetd mode - fails to create /var/run/apt-cacher
Could you try/critique this initscript patch for me, please.
Thanks.
Mark
diff --git a/debian/apt-cacher.init b/debian/apt-cacher.init
index 2c38b7f..7ae1636 100644
--- a/debian/apt-cacher.init
+++ b/debian/apt-cacher.init
@@ -15,7 +15,8 @@
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="Apt-Cacher"
NAME=apt-cacher
DAEMON=/usr/sbin/$NAME
-PIDFILE=/var/run/$NAME/$NAME.pid
+RUNDIR=/var/run/$NAME
+PIDFILE=$RUNDIR/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
# Gracefully exit if the package has been removed.
@@ -40,6 +41,18 @@ d_start() {
echo "$NAME."
else
echo "Not started (AUTOSTART not enabled in /etc/default/$NAME)";
+
+# apt-cacher needs $RUNDIR, but is not able to create it in inetd or
CGI mode
+ if test ! -d "$RUNDIR"; then
+ mkdir -m 755 "$RUNDIR"
+ CONFIG_FILES="/etc/$NAME/$NAME.conf $(run-parts --list
/etc/$NAME/conf.d)"
+ RUN_AS_USER=$(sed -n 's/^ *user *= *//p' $CONFIG_FILES | tail -1)
+ RUN_AS_GROUP=$(sed -n 's/^ *group *= *//p' $CONFIG_FILES | tail -1)
+ [ "$RUN_AS_USER" ] && chown $RUN_AS_USER "$RUNDIR"
+ [ "$RUN_AS_GROUP" ] && chgrp $RUN_AS_GROUP "$RUNDIR"
+ fi
+
+
fi
}
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#657834: apt-cacher: fails to upgrade from squeeze
package apt-cacher tag 657834 pending thanks On Sun, Jan 29, 2012 at 11:08:01AM +0100, Holger Levsen wrote: > Package: apt-cacher > Version: 1.7.2 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > squeeze. It installed fine in squeeze, then the upgrade to wheezy fails. > > From the attached log (scroll to the bottom...): > > Preparing to replace apt-cacher 1.6.12 (using .../apt-cacher_1.7.2_all.deb) > ... > Running apt-cacher upgrade script > Can't locate IO/Uncompress/AnyUncompress.pm in @INC (@INC contains: > /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 > /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 > /usr/local/lib/site_perl .) at /usr/share/apt-cacher/apt-cacher-lib.pl line > 16. > BEGIN failed--compilation aborted at > /usr/share/apt-cacher/apt-cacher-lib.pl > line 16. > Compilation failed in require at /usr/share/apt-cacher/upgrade.pl line 16. > dpkg: warning: subprocess old pre-removal script returned error exit status > 2 > dpkg - trying script from the new package instead ... > Stopping libcurl backend > /var/lib/dpkg/tmp.ci/prerm: 39: /usr/share/apt-cacher/libcurl.pl: not found > dpkg: error processing /var/cache/apt/archives/apt-cacher_1.7.2_all.deb (-- > unpack): >subprocess new pre-removal script returned error exit status 127 > configured to not write apport reports > invoke-rc.d: policy-rc.d denied execution of start. > Errors were encountered while processing: >/var/cache/apt/archives/apt-cacher_1.7.2_all.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) Thanks. I think the patch below fixes it. I have queued it for the next release. Mark commit 54efcd73bc195f1917f7b4c3313d2da2de9d7f40 Author: Mark Hindley Date: Mon Jan 30 11:34:14 2012 + Check for existence of libcurl.pl in prerm. In the case of failed-upgrade the script might be missing, only try to run it if it is present (Closes #657834). diff --git a/debian/prerm b/debian/prerm index 7607b35..700dc63 100755 --- a/debian/prerm +++ b/debian/prerm @@ -34,9 +34,12 @@ case "$1" in ;; esac -# Stop any running libcurl backend -echo "Stopping libcurl backend" -/usr/share/apt-cacher/libcurl.pl EXIT +# Script might not be present in the case of failed-upgrade, so check first +if [ -x /usr/share/apt-cacher/libcurl.pl ] ; then +# Stop any running libcurl backend +echo "Stopping libcurl backend" +/usr/share/apt-cacher/libcurl.pl EXIT +fi # dh_installdeb will replace this with shell code automatically # generated by other debhelper scripts. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#662737: apt-cacher: Fails to retrieve packages
On Tue, Mar 06, 2012 at 04:13:45PM +1100, Scott Ferguson wrote:
> Package: apt-cacher
> Version: 1.7.3~rc4
> Justification: renders package unusable
> Severity: grave
>
> *** Please type your report below this line ***
> *some* clients fail to download packages. Some are pure Squeeze, others
> include Squeeze-backports. All use apt (no aptitude, synaptic etc). I've
> tried a number of repositories over the last four days. The error is the
> same and I can't work out why it only seems to affect some boxen.
Just for me to be clear, on the boxen affected, this is for all requests
on those boxes, not just some?
> Example error message on clients (edited):-
> Failed to fetch
> http://http.us.debian.org/debian/pool/main/c/cairomm/libcairomm-1.0-1_1.8.4-3_i386.deb
>
> Connection failed
>
> Site is good, and on the same machine:-
> # wget -t 0
> http://http.us.debian.org/debian/pool/main/c/cairomm/libcairomm-1.0-1_1.8.4-3_i386.deb
> --2012-03-06 14:18:10--
> http://http.us.debian.org/debian/pool/main/c/cairomm/libcairomm-1.0-1_1.8.4-3_i386.deb
> Resolving http.us.debian.org... 64.50.233.100, 64.50.236.52,
> 128.30.2.36, ...
> Connecting to http.us.debian.org|64.50.233.100|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 72176 (70K) [application/x-debian-package]
> Saving to: `libcairomm-1.0-1_1.8.4-3_i386.deb'
>
> 100%[=>] 72,176 40.8K/s
> in 1.7s
>
> 2012-03-06 14:18:16 (40.8 KB/s) - `libcairomm-1.0-1_1.8.4-3_i386.deb'
> saved [72176/72176]
>
> /var/log/apt-cacher/error.log (edited) shows:-
> Tue Mar 6 14:12:11 2012|error [16392]: Failed to open/create
> libcairomm-1.0-1_1.8.4-3_i386.deb for return: Permission denied at
> /usr/sbin/apt-cacher line 696, line 4.
>
> There is no /var/cache/apt-cacher/packages/
Really? What is in /var/cache/apt-cacher? What are the permissions in
there?
This looks like a configuration error/installation error.
Is there a directory in root '/packages'?
> ===/usr/sbin/apt-cacher lines 693-698 =
> # Open/create cached file
> for (my $cached_file = "$cfg->{cache_dir}/packages/$cache->{name}") {
> unlink $cached_file if $cache->{status} && $cache->{status} eq
> 'NOCACHE'; # Ensure new file for Cache-Control: no-cache
> sysopen($cache->{content}, $cached_file, O_RDWR|O_CREAT)
> || die "Failed to open/create $cached_file for return: $!";
> }
>
This should produce a die message which says
Failed to open/create
/var/cache/apt-cacher/packages/libcairomm-1.0-1_1.8.4-3_i386.deb for
return.
But the one you quote is missing the full path. Did you edit that path
out of the log message? If not, then cache_dir is not set, for some
reason. But there is a default (/var/cache/apt-cacher/), so I can't see
how it could not be set.
> -- Configuration Files:
> /etc/apt-cacher/apt-cacher.conf changed:
> log_dir = /var/log/apt-cacher/
> group = www-data
> user = www-data
> allowed_hosts = 192.168.0.0/24
> generate_reports = 1
Is this really all that is in the config file?
Could you check the setting of cache_dir when you point a browser to
http://localhost:3142
Thanks
Mark
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#662737: apt-cacher: Fails to retrieve packages
package apt-cacher tag 662737 pending severity 662737 normal thanks On Wed, Mar 07, 2012 at 01:35:57PM +1100, Scott Ferguson wrote: > Update - Mark Hindley pointed out that my use of rsync to add packages > from /var/cache/apt/archives on client boxen had imported *.deb packages > owned by root into /var/cache/apt-cacher/import (on the the apt-cacher > server). > Running apt-cacher-import.pl then moved those files into > /var/cache/apt-cacher/packages with the same ownership - and caused the > (my) problem. Thanks. I have queued a patch to warn of chmod failure for 1.7.4. Mark -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
