we need to either disable logind from systemd-services, or split it
out again.
I thought about this a bit more: Given that we still want to do the
transition in a month, and not do intrusive packaging and conffile
changes, I'd rather just keep logind in systemd-services, but make it
inert until
Where we are:
- current systemd v198 is in raring, with broken out systemd-services package
which provides logind, hostnamed, etc.
- libudev1 transition is mostly complete and in raring; the only remaining
reverse dep to libudev0 is chromium on armhf as it currently FTBFSes there.
(This
I'll be almost entirely offline the next three days. I'd appreciate it
if another release team member would follow up on this. No matter which
option we pick, we should do it soon.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
(Switch to systemd-services - ok, I see this is covered by bug #1153567
and bug #1153633.)
If the list of upstream packages needing fixed for sd_booted() is
substantial, I think we should split logind back out. The package split
here should be driven by Ubuntu's needs, not by the Debian systemd
I think the amount of remaining churn we're looking at here speaks
against an FFe for switching to logind in 13.04. Since this feature is
not critical path for anything else, I'm going to nack here.
I don't know if the desktop team is still planning to switch from
ubuntu-system-service to
Martin, is there a list of upstream software affected by the wrong
sd_booted() check?
Yes, it's linked from the spec: http://people.canonical.com/~pitti/tmp
/cgroup-sd_booted.txt
OK, so I'll go forward with disabling logind from the raring packages,
and keep it enabled in the PPA only. I'll
Any thoughts on whether we should go logind for raring or not? I wonder
how much energy I should put into maintaining the logind PPA, and
playing catch-up with normal raring uploads. If we postpone that to
raring+1, then this is rather pointless.
Also, if we don't do logind, but want the D-BUS
Could you recap where we are, what the next steps are and what's been done to
mitigate any associated risks with moving forward?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1153224
Title:
[FFE]
FFe approved for systemd update and the Udev transition.
Thanks. I uploaded 198 to raring-proposed now, and will upload the 39
reverse libudev0 depends for the transition. Iain blocked both systemd
and udev from migration, which should hold back all reverse dependencies
of libudev1 as well. So
libudev1 migration is complete in raring-proposed. The blocks of udev
and systemd will be kept until after beta-1 release, though.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1153224
Title:
[FFE]
Some comments:
* The libudev0 → libudev1 migration is the least risky here. I can
prepare it today in the PPA for the handful of source packages which
need (trivial) adaptions for the dropped symbols, the other 20 or so
reverse dependencies are mere rebuilds.
* In theory we can also update
Someone added a reference to http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2012-1174 . This has been fixed upstream in
http://cgit.freedesktop.org/systemd/systemd/commit/?id=5ebff53 and
backported to Debian in 44-1 in April 3. Thus this is fixed in raring as
well.
--
You received this bug
libudev1 migration: I searched for all packages which use symbols that
got dropped in libudev1. Detailled notes are in the spec, but summary is
that only one package (lvm2) needs a sourceful upload. I cherry-picked
the upstream fix for that into the PPA. For udev we only need to drop
the
OK. Since no one else jumped in
FFe approved for systemd update and the Udev transition. Then let's see
where we are. If you end up having to upload anything that's on an ISO
for a flavor participating in Beta 1, please double check that it's in
stgraber's transition block so we don't get
I've been trying to understand what might be required to do this. I
don't want to make any decision on my own, so here's my probably
incomplete outline. Most of the information was gleaned from reading the
bugs/BP and discussing a bit with pitti. Errors are no doubt mine.
- Update systemd to
Why was this not landed before feature freeze? One attribute of the
development schedule this cycle is that we move feature freeze later in
the cycle so that people could get work done before hand with the
understanding that we would not generally approve things that didn't
make it.
Has the
libsolid4 (the KDE hardware interface layer) in KDE 4.10 (the Kubuntu KDE
version for raring) does not support logind, but there are patches available
from upstream which upstream has said they will help us integrate. It would
also affect the lightdm KDE greeter. That work is not done yet.
FWIW, if the release time says this is better kept for post-raring, I'm
okay with that. I just got asked from two different directions to try
and ask for a FFE here.
BTW, the intention is to not break any existing software with this. If
any software suddenly stops working because logind is
- Update systemd to 195
+ Brings with it a udev SONAME bump
For the record, this is optional. The only applicable CVE of systemd
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1174) is fixed
in that version, and this doesn't yet ship a newer udev/libudev.
However, I figure the
While this doesn't have to be done in lockstep, I think ending up
shipping both of consolekit and logind on a single image in 13.04 is a
bad outcome; we're trying to drive our footprint down, this would have
the opposite effect. If we're not confident to have the transition done
before 13.04
It seemed to me like the discussion on IRC today went back and forth about if
the switch to logind and the udev transition needed to be tied together and if
not, which was more important to do first. Given that this we just thought up
in mid-cycle, rather than planned, I'm starting to think
On Mon, Mar 11, 2013 at 09:55:48PM -, Scott Kitterman wrote:
It seemed to me like the discussion on IRC today went back and forth about
if the switch to logind and the udev transition needed to be tied together
and if not, which was more important to do first.
This was mostly a matter of
Okay. What happens if we do step one and stop? Is it reasonable to
approve that and see how that goes before deciding on the udev stuff?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1153224
Title:
On Mon, Mar 11, 2013 at 11:46:27PM -, Scott Kitterman wrote:
Okay. What happens if we do step one and stop? Is it reasonable to
approve that and see how that goes before deciding on the udev stuff?
That doesn't seem a very sensible stopping point to me. The interface
surface of the
OK. As long as someone is on the hook to fix regressions from the
libudev1 migration, that makes sense.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1153224
Title:
[FFE] Move to logind for
Note that this also blocks on the MIR bug 1152187, but I would like to
discuss this FFE in parallel.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1153224
Title:
[FFE] Move to logind for session
** Description changed:
At the last UDS we decided to finally drop the long-abandoned ConsoleKit
and migrate to logind:
https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303
-consolekit-logind-migration
I fixed current raring's logind package (from systemd source) to
27 matches
Mail list logo
