Control: close -1
Hi. I was asked to take a look at #940034 and ended up reading this
bug too. According to message #191 here, from the maintainer,
| I can no longer reproduce the breakage that you reported.
That this now works is a consequence of #935910 having been fixed by
apt in
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
On Sat, 21 Sep 2019, Mark Hindley wrote:
> 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
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
On Sat, 21 Sep 2019, Mark Hindley wrote:
> 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
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
On Sat, 21 Sep 2019, Mark Hindley wrote:
>
> Removing the pending tag as I don't think there is anything for
> elogind to do to fix this.
Hi,
I'm interested in this, but my systems (unstable and testing) are in a
slightly different state. Let's take unstable, for example:
,
| #
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
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.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn •
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.
>
>
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
Control: block -1 935910
On Thu, Aug 15, 2019 at 08:42:35PM +0100, Mark Hindley wrote:
> > > Unsure if that’s apt or dpkg. Plus, the failing prerm is in systemd,
> > > not in libsystemd0.
> >
> > I think this is probably dpkg, but it's dpkg being told what to do by
> > apt, so it could be either
On Thu, 15 Aug 2019, Mark Hindley wrote:
> I don't think so because the versions are different. systemd 241-7 Depends on
> libsystemd0 =241-7 (= ${binary:Version}). libelogind0 Provides libsystemd0
> =241.3 (= ${source:Upstream-Version}. That can never satisfy the systemd
> dependency.
The idea
On Thu, Aug 15, 2019 at 08:02:51PM +0100, Simon McVittie wrote:
> On Thu, 15 Aug 2019 at 18:33:20 +0200, Thorsten Glaser wrote:
> > On Thu, 15 Aug 2019, Mark Hindley wrote:
> > > At this point apt has failed to remove systemd/241-7 which depends on
> > > libsystemd
> > > (=241-7). Surely it
On Thu, 15 Aug 2019, Simon McVittie wrote:
> I still wonder whether apt/dpkg are being forced into this by libelogind0
> using Conflicts rather than Breaks - Conflicts is a stronger relationship
AFAICT file-level conflicts still need Provides+Conflicts+Replaces,
and these are what we have here.
On Thu, 15 Aug 2019 at 18:33:20 +0200, Thorsten Glaser wrote:
> On Thu, 15 Aug 2019, Mark Hindley wrote:
> > At this point apt has failed to remove systemd/241-7 which depends on
> > libsystemd
> > (=241-7). Surely it should not then go on to try and remove the systemd
> > dependency?
>
> Unsure
On Thu, 15 Aug 2019, Simon McVittie wrote:
> On Thu, 15 Aug 2019 at 18:34:39 +0200, Thorsten Glaser wrote:
> > On Thu, 15 Aug 2019, Mark Hindley wrote:
> > > Can you point me to any official documentation that says packages
> > > should not depend on systemd-sysv?
> >
> > No, but why should
On Thu, 15 Aug 2019 at 18:34:39 +0200, Thorsten Glaser wrote:
> On Thu, 15 Aug 2019, Mark Hindley wrote:
> > Can you point me to any official documentation that says packages
> > should not depend on systemd-sysv?
>
> No, but why should they?
For documentation value, if nothing else: it's a way
On Thu, 15 Aug 2019, Mark Hindley wrote:
> Can you point me to any official documentation that says packages
> should not depend on systemd-sysv?
No, but why should they? It’s an almost empty package, and it
can be fulfilled by just depending on systemd.
It does not guarantee that systemd is
On Thu, 15 Aug 2019, Mark Hindley wrote:
> I am now wondering if the prime responsibliity for the system breakage here is
> down to apt's behaviour.
[…]
> At this point apt has failed to remove systemd/241-7 which depends on
> libsystemd
> (=241-7). Surely it should not then go on to try and
Thanks for everybody's input with this thorny issue.
I am now wondering if the prime responsibliity for the system breakage here is
down to apt's behaviour.
On Sun, Aug 11, 2019 at 03:31:00PM +0100, Simon McVittie wrote:
> Actual result (transcript below):
>
> * systemd-sysv is removed
> *
On Tue, Aug 13, 2019 at 04:46:32PM +0200, Thorsten Glaser wrote:
> But TTBOMK it is possible to install sysvinit alongside systemd,
> then reboot and select sysvinit as “alternative” init from the
> GRUB menu, then remove everything else. Now that I see /sbin/init
> is part of sysvinit-core, I
On Wed, 14 Aug 2019 at 19:41:08 +0100, Mark Hindley wrote:
> I have managed to work around this today. It requires circumventing the
> systemd
> prerm failure. I am not recommending that as a final solution, but maybe we
> can
> have another go at asking the systemd maintainers to review it?
On Tue, Aug 13, 2019 at 07:58:09PM +0100, Mark Hindley wrote:
> Thorsten,
>
> Thanks for this.
>
> On Tue, Aug 13, 2019 at 04:46:32PM +0200, Thorsten Glaser wrote:
> > On Sun, 11 Aug 2019, Simon McVittie wrote:
> >
> > > Found while preparing a test VM to test #923240. Please raise this to
> >
On Tue, 13 Aug 2019, Adam Borowski wrote:
> > 1. Merge elogind into libpam-elogind (not the other way round),
> >as elogind without libpam-elogind is apparently (see the
> >other thread) not useful in any way.
>
> I don't think it's reasonable to have the daemon in a library package.
>
On Tue, Aug 13, 2019 at 10:43:30PM +0200, Thorsten Glaser wrote:
> On Tue, 13 Aug 2019, Adam Borowski wrote:
>
> > The prerm also makes systemd non-removable without uninstalling most
> > packages,
> > rebooting, then installing anew. Requiring such a reinstall is pretty much
> > RC in by book.
On Tue, Aug 13, 2019 at 10:36:04PM +0200, Thorsten Glaser wrote:
> > > I would also add that it surprises me that apt requires symbols from
> > > libsystemd.so.
> >
> > libapt-pkg uses sd-bus, systemd's implementation of D-Bus (the same one
> > provided by libelogind), to tell systemd-logind (or
On Tue, 13 Aug 2019, Adam Borowski wrote:
> The prerm also makes systemd non-removable without uninstalling most packages,
> rebooting, then installing anew. Requiring such a reinstall is pretty much
> RC in by book.
>
> I've reported this before as #930105 but this got insta-closed+downgraded
On Tue, 13 Aug 2019, Simon McVittie wrote:
> Ah, that's a major constraint on finding a correct solution here. systemd
> is from the same source package as libsystemd0, so I think it's
> reasonable for them to be in lockstep: systemd executables could well be
> using private symbols or relying on
On Tue, 13 Aug 2019, Mark Hindley wrote:
> I would also add that it surprises me that apt requires symbols from
> libsystemd.so. I haven't yet investigated what functionality that is. But that
> is a side issue.
Probably for “modern Poett^WLinux desktop” logging, or somesuch.
bye,
//mirabilos
On Tue, Aug 13, 2019 at 09:10:12PM +0100, Simon McVittie wrote:
> On Tue, 13 Aug 2019 at 19:58:09 +0100, Mark Hindley wrote:
> > I would also add that it surprises me that apt requires symbols from
> > libsystemd.so.
>
> libapt-pkg uses sd-bus, systemd's implementation of D-Bus (the same one
>
On Tue, Aug 13, 2019 at 07:58:09PM +0100, Mark Hindley wrote:
> On Tue, Aug 13, 2019 at 04:46:32PM +0200, Thorsten Glaser wrote:
> > On Sun, 11 Aug 2019, Simon McVittie wrote:
> > > Found while preparing a test VM to test #923240. Please raise this to
> > > RC severity if you think it is justified
On Tue, 13 Aug 2019 at 19:58:09 +0100, Mark Hindley wrote:
> systemd depends on a specific pacakged version of libsystemd0 (currently 241-7
> in sid) whilst all other packages at most depend on a particular src version
> (eg. >= 213).
Ah, that's a major constraint on finding a correct solution
Thorsten,
Thanks for this.
On Tue, Aug 13, 2019 at 04:46:32PM +0200, Thorsten Glaser wrote:
> On Sun, 11 Aug 2019, Simon McVittie wrote:
>
> > Found while preparing a test VM to test #923240. Please raise this to
> > RC severity if you think it is justified - I don't want to create the
>
> I
On Sun, 11 Aug 2019, Simon McVittie wrote:
> Found while preparing a test VM to test #923240. Please raise this to
> RC severity if you think it is justified - I don't want to create the
I don’t think it’s RC in any of the involved packages (elogind,
systemd (shock!), apt) because it’s really a
Simon,
Thanks for this.
I was aware of this in the sense that I know systemd can't be uninstalled whilst
it is PID 1. Most recently this was discussed in #930105 and tagged wontfix.
The only way I have managed to migrate systems reasonably cleanly is to boot
with init=/bin/sh, replace systemd
Package: libelogind0
Version: 241-7
Severity: important
Found while preparing a test VM to test #923240. Please raise this to
RC severity if you think it is justified - I don't want to create the
impression that I'm using RC bugs as a way to push an agenda, but I think
this might deserve critical
37 matches
Mail list logo
