reassign 679409 lightdm found 679409 1.2.2-3 thanks Hi Roger,
On Sun, Aug 12, 2012 at 09:48:02AM +0100, Roger Leigh wrote: > On Sun, Aug 12, 2012 at 03:37:52PM +1000, James Tocknell wrote: > > I've tested the patch, and it doesn't fix the issue I'm having. I'm > > using Upstart > > as my init daemon, and lightdm still fails, with no useful output in > > /var/log/boot. However, lightdm does start when I use sysvinit as the init > > daemon, with the patch. Could this be a Upstart issue? I know lightdm has > > some association with Ubuntu, and Upstart is Ubuntu's default init daemon, > > could the issue be with the very different versions of Upstart in Ubuntu and > > Debian? The problem could lie in the fix for the bug #660824, which was a > > change between the version of sysvinit-utils that works for me and don't > > work > > for me, as it's Upstart related. > I'll have to ask Steve Langasek, who was responsible for that change. > Steve, it appears that lightdm won't start using upstart with the > recent sysvinit upstart bridge stuff. I'm not sure if this is an > issue in sysvinit, startpar-upstart-inject, or upstart. None of the above. It's a bug in lightdm, for shipping an upstart job with no start condition. I have no idea why this is done; the upstart job used in Ubuntu for lightdm doesn't look anything like this. Now, there's a good chance that "fixing" the lightdm upstart job to have a correct start condition still won't work, because several of the prerequisite events are not yet available at start time with the upstart in Debian. I'm planning to fix this ASAP for wheezy, having spoken with Neil McGovern at DebConf and gotten provisional release team sign-off, but it's not absolutely certain this will go in or when. In the meantime, I believe the correct fix is for the lightdm package to drop its upstart job. > I've patched startpar to special-case lightdm as for gdm/kdm, but this > doesn't appear to have any effect here (but is probably generally a good > thing to have). The change that was committed has nothing at all to do with this bug, and to me it looks like an unnecessary divergence from startpar upstream; so I've reverted those changes from the git repo. IMHO it's not something that's worth carrying a delta from upstream over. But feel free to reinstate if you disagree. BTW, Roger, could you please run 'echo DEBCHANGE_RELEASE_HEURISTIC=changelog >> ~/.devscripts' on your development machine? This is the only sensible behavior to use with dch in a shared VCS; it's very frustrating to have to check the archive or look at git tags each time to figure out whether the changes I'm looking at on trunk are uploaded or not... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
