[09:54] <xnox> mpt: we have a keyboard bug for every step of the installer
[09:54] <xnox> https://wiki.ubuntu.com/Ubiquity/KeyboardBug#preview
[09:54] <xnox> https://wiki.ubuntu.com/Ubiquity/KeyboardBug
[10:35] <mpt> joy
[10:39] <xnox> Yeah, it's like christmas came early =)
[10:40] <xnox> The best bit is when people need/want to switch to English after booting in e.g. russian locale at every single step.
[11:06] <mpt> xnox, do you happen to have a screenshot of the 12.10 installer with the wi-fi spinner at the bottom left?
[11:08] <xnox> mpt: no, as I failed to type my 63 character long WiFi correctly to trigger the spinner.
[11:08] <xnox> s/WiFi/WiFi password/
[11:08]  * xnox can fake a screenshot for you though.
[11:42] <xnox> mpt: https://picasaweb.google.com/105922848292507689403/February182013#5846255791327235314
[11:42] <xnox> nexus7 saves the world again
[11:45] <ogra_> xnox, erm, how did you get that working ?
[11:45] <xnox> ogra_: which part? =)
[11:46] <ogra_> the whole of it
[11:46] <ogra_> how did you work around my bug ?
[11:46] <xnox> ogra_: so my old nexus was already pre-flashed, I $ sudo apt-get install oem-config-gtk etc... & sudo touch /var/oem-config/run & reboot
[11:47] <xnox> it just works.
[11:47] <ogra_> hmpf
[11:47] <ogra_> why doesnt it on fresh images then
[11:47] <xnox> i may not be fully up to date then.
[11:47] <xnox> do you want me to dist-upgrade and see if it breaks? =)
[11:47] <ogra_> yes please :)
[11:50]  * ogra_ is a little desparate to find *any* pointer to whats wrong
[11:54] <mpt> xnox, excellent, thank you
[11:54] <mpt> discussing this layout pattern right now
[12:06] <xnox> ogra_: dist-upgrade, reboot, had plymouth splash and now just black screen with nothin on it.
[12:06] <xnox> here is the dpkg view of my dist-upgrade: http://paste.ubuntu.com/1676722/
[12:06] <ogra_> YAY !!!!
[12:06] <xnox> grep for upgrade
[12:07] <xnox> and install
[12:07] <ogra_> sigh, 164 packages
[12:07]  * xnox was spending time fixing background which now works =) and not dist-upgrading
[12:09] <xnox> ogra_: how can I boot it now?
[12:09] <ogra_> remove the lock
[12:09] <ogra_> that sometimes works
[12:10] <ogra_> i havent found a reliable way yet, it seems to be very random
[12:11] <ogra_> do you have an ssh server installed ? probably the logs on an installed system are more verbose
[12:11] <xnox> yeap ssh'ed in.
[12:11] <xnox> Fatal server error: Server is already active for display 0
[12:11] <ogra_> yeah
[12:12] <ogra_> complaining about the lock, as well, right ?
[12:12] <ogra_> thats all i can get ... i wish there was an ~.xession-errors for u-dm
[12:13] <xnox> right in syslog I see the same stuff as currently seen in the daily desktop images with "Failed to activate service 'org.freedesktop.ConsoleKit' timed out
[12:14] <xnox> and consolekit failing to acquite the bus
[12:15]  * xnox wonders if the first X is started ubiquity-dm, then ubiquity-dm fails, and respawns a new X without cleaning the lock.
[12:15] <xnox> (killing the first instance)
[12:16] <ogra_> yes, thats one of my three theories
[12:16] <ogra_> the most compelling one actually ... else it would be lightdm or upstart which is unlikely
[12:16] <ogra_> thats why i would like an .xsession-errors file
[12:17] <ogra_> since i guess one of the fired up apps u-dm uses is at fault here
[12:17] <ogra_> and oem-config-debug sadly only kicks in after oem-config is up
[12:18] <xnox> it's weird because there is console-kit-daemon running with pid 965, yet the one that failed to activate has pid 1263
[12:18] <xnox> so it failed to talk to it.
[12:18] <ogra_> hmm
[12:19] <ogra_> i see qdbus in your upgrade list
[12:20] <ogra_> nothing about consolekit or polkit
[12:21] <ogra_> theoretically there is an Xsession.d script that firse up the appropriate ck session for you
[12:21] <ogra_> (unless you use lightdm)
[12:22] <ogra_> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680264
[12:22] <ubot2> Debian bug 680264 in nodm "nodm: ConsoleKit fails to recognize the current session as local" [Normal,Open]
[12:22] <ogra_> i wondefr if thats related
[12:23] <ogra_> it has a patch to try out
[12:23] <xnox> there were some pam changes
[12:24] <ogra_> also, slangasek seems to have moved soem pam stuff around in lightdm from "auth" to "session" that tries to read /etc/default/localer ... which doesnt exist in our installer env
[12:24] <xnox> also ubiquity launches X directly does that read / launch xsessions?
[12:24] <ogra_> though you should have it on an installed system indeed
[12:24] <ogra_> i think it does, not sure
[12:24] <ogra_> hmm, it doesnt launch xinit but plain X
[12:25] <ogra_> so Xsession might ot be processed
[12:26] <ogra_> once my nx7 is charged enough i'll try your method ... it didnt strike me to test on an installled system
[12:26] <mpt> ehhhh
[12:27] <xnox> mpt: did you just read the backlog? =) or is that the comment on the font/spacing alignment of the connecting label?
[12:28] <mpt> xnox, I'm in a meeting where we're talking about bug 732634 for the umpteenth time :-]
[12:28] <mpt> as if it was ever a deliberate design choice
[12:28] <ogra_> or just a general statement to the evilness of the world ?
[12:28] <ubot2> Launchpad bug 732634 in ubiquity (Ubuntu) "Progress bar restarts from zero after copying files" [Medium,Confirmed] https://launchpad.net/bugs/732634
[12:29] <xnox> mpt: refresh the bug report, does that help?
[12:31] <mpt> \o/
[12:32] <cjwatson> That bug is darkly amusing since it has comments like "The proper solution is apparently to teach debconf that its progress value is sometimes only for a subtask of a larger task" several years after such support was introduced
[12:32] <cjwatson> It's just broken, it's not fundamentally missing
[12:33] <cjwatson> xnox: Do you know about and understand the PROGRESS REGION extension?
[12:33] <xnox> cjwatson: know about - yes, understand - sort of.
[12:34] <cjwatson> Your bug reference is incorrect - nested progress bar support was introduced long before that
[12:34] <cjwatson> Before espresso was renamed to ubiquity
[12:34] <cjwatson> r799, originally
[12:35] <ogra_> geez, installing oem-config-gtk tries to pull in nearly all of kde here
[12:35] <ogra_> even with recommends disabled
[12:35] <xnox> =)))) well, ok that it even early, for me at that time it was good enought that _it exists today_
[12:35] <xnox> ogra_: install oem-config-gtk ubiquity-frontend-gtk
[12:35] <xnox> and oem-config and ubiquity then it's a short list.
[12:35] <ogra_> yep, just did that :)
[12:36] <xnox> it is trying to pull in the kde frontend for some reason, instead of the gtk one.
[12:36] <cjwatson> xnox: The idea is that you say PROGRESS REGION <start> <end>, then PROGRESS START <start> <end> <title> ... (more progress commands) ... PROGRESS STOP, and the progress commands within the start/stop pair are scaled to the region you provided
[12:37] <cjwatson> IIRC
[12:38] <cjwatson> So have a look at the protocol stream and see what's doing it wrong
[12:39] <xnox> ok. thanks. debug mode logs again =))))
[12:39] <cjwatson> That's what they're for :)
[12:40] <xnox> cjwatson: i think we are missing some progress regions then, as if one does progress start 0 without starting a new progress region you see the jump to zero effect.
[12:40] <ogra_> 1405 ?        S      0:00 /usr/bin/python3 /usr/bin/ubiquity-dm vt7 :0 oem /usr/sbin/oem-config-wrapper --only
[12:40] <ogra_>  1431 ?        S      0:00 sleep 1
[12:40] <ogra_>  1432 ?        Z      0:00 [Xorg] <defunct>
[12:40] <cjwatson> Yep, very likely
[12:40] <ogra_> aha
[12:40] <ogra_> i wonder wheer that zombie comes from
[12:40] <cjwatson> Should be a pretty trivial fix once identified
[12:41] <xnox> ogra_: in ubiquity-dm we have a loop of trying to start X server and if it fails so many times, we try fail-safe config.
[12:41] <ogra_> yeah, i had that at some point during my tests
[12:41] <ogra_> i wish there would be any indicator in any log though ...
[12:42] <xnox> ogra_: it's python - so just type in more logging =)
[12:42]  * ogra_ digs into the dm and scatters soem prints over it
[12:50] <xnox> ogra_: anything in /var/crash/ ?
[12:50] <ogra_> wait, just rebooting
[12:54] <ogra_> http://paste.ubuntu.com/1676848/
[12:54] <ogra_> definitely CK
[12:55] <xnox> ogra_: can you grep if there are any console-kit daemons running any way?
[12:55] <xnox> in ps.
[12:55] <ogra_> i wonder if we should just switch to process Xsession
[12:55] <xnox> cjwatson: why ubiquity-dm has never been a proper Xsession?
[12:55] <ogra_> ogra@nexus7:~$ ps ax|grep console
[12:55] <ogra_>   956 ?        Sl     0:00 /usr/sbin/console-kit-daemon --no-daemon
[12:56] <xnox> so it's failing to talk to it.
[12:56]  * xnox ponders to try that debian patch or see/revert recent slangaseks pam changes.
[12:56] <ogra_> well, i think it is started in the wrong order
[12:57] <xnox> ogra_: the first thing ubiquity-dm does is ask for a console-kit session, which should dbus activate it.
[12:57] <ogra_> yes, but it doesnt take care for starting it
[12:57] <ogra_> which usually Xsession woudl do
[12:57] <xnox> so who started the one that is running?!
[12:57] <cjwatson> xnox: Too much effort to excise all the bits we wanted to avoid
[12:58] <cjwatson> There were memory constraints and the like - I explicitly didn't want to run a full session
[12:58] <cjwatson> Or a full DM
[12:58] <xnox> ok.
[12:58] <cjwatson> I mean I guess you could split ubiquity-dm into a DM part and a session part.  It just never seemed worth the effort really
[12:59] <ogra_> well, with the recent diet lightdm might serve out purpose
[12:59] <cjwatson> ubiquity-dm can't rely on lightdm
[12:59] <ogra_> hmm, indeed flavours ...
[12:59] <cjwatson> 'cos it needs to be workable in lots of different flavours, yeah
[13:00] <ogra_> oh
[13:00] <ogra_> erm
[13:01] <ogra_> seems teher is no session dbus at all running here
[13:01] <ogra_> i would assume thats needed for ck to talk to the system bus through it
[13:03] <xnox> but we are starting on lightdm, which in turn starts on dbus.
[13:04] <ogra_> system
[13:04] <ogra_> not session
[13:04] <ogra_> the session bus is started by gnome-session or alternatively by Xsession
[13:04] <xnox> upstart jobs that is.
[13:04] <xnox> ah, wait.
[13:04] <ogra_> it runs as the session user usually
[13:04] <ogra_> so after auth
[13:05]  * xnox thought ck runs on system bus, not session.
[13:05]  * ogra_ tries to mimic the Xsession behavior in the oem-config.conf exec line 
[13:05] <xnox> cause ck is opened before ubiquity-dm starts a session bus
[13:06] <ogra_> the point is that to talk to system services the session bus is used i think
[13:06] <ogra_> with ck inbetween for policy checks
[13:08]  * ogra_ reboots with the hack in place
[13:11] <ogra_> bah, patched the wrong codepath
[13:18] <ogra_> hmm, so i have it starting with a session bus but it doesnt change anything :(
[13:19] <ogra_> oh, lovely ... at least i can count how often it respawned now
[13:22]  * ogra_ moves the code around a bit
[13:34] <ogra_> GOT IT !!!
[13:34] <ogra_> bah, only partially
[13:35] <ogra_> changing the exec line in oem-config.conf to:
[13:35] <ogra_> exec /usr/bin/ck-launch-session oem-config-firstboot $debug $automatic
[13:35] <ogra_> gets me running X and a popup that the installer encountered an error on the desktop
[13:36] <ogra_> aha
[13:36] <ogra_> dbus.exceptions.DBusException: org.freedesktop.NetworkManager.Settings.NotPrivileged: Insufficient privileges.
[13:36] <ogra_> thats funny ...
[13:36] <ogra_> since i have NM in the panel
[13:37]  * xnox reverted lightdm, consolekit and it boots now
[13:37]  * xnox ponders if consolekit's memory leak wasn't actually a memory leak.
[13:39] <ogra_> oh, i created an oem user for testing ... i guess i should swithc that back to root as we use it on the image
[13:42] <ogra_> yipiie
[13:42] <xnox> you fixed it? =)
[13:42] <ogra_> ogra@nexus7:~$ grep exec /etc/init/oem-config.conf
[13:42] <ogra_>     exec /usr/bin/dbus-launch --exit-with-session /usr/bin/ck-launch-session oem-config-firstboot $debug $automatic
[13:43] <ogra_> with that it works for me
[13:43] <xnox> it also needs to go into ubiquity normal as it also fails with ~ similar symtoms.
[13:43] <xnox> and this also means we can drop dbus-launch code from ubiquity-dm
[13:43] <ogra_> well, i still think it would be better to just process Xsession.s
[13:43] <ogra_> Xsession.d
[13:46] <xnox> my boot was a fluke as it is back to booting black.
[13:48] <ogra_> hmm
[13:48] <ogra_> none of the indicators work ... i can select reboot but never get the popup for it
[13:48] <ogra_> so i would guess its not 100% yet
[13:52] <ogra_> btw, the panel doesnt expand in landscape
[13:53] <xnox> ogra_: so poking indicator-session-service it's sitting on the dbus that lightdm has, instead of ours.
[13:53] <ogra_> ah
[13:53] <ogra_> thats a mess
[13:54]  * ogra_ is so happe we found the cause and at least a workaround ... i wated my whle weekend on this (including my birthday on sat.)
[13:54] <ogra_> *happy
[13:55] <ogra_> *wasted
[14:23] <xnox> ogra_: looking at all the Xsession.d scripts some of them are definately what we do not want.
[14:24] <ogra_> hmm, yeah