[00:04] <TheLordOfTime> phillw, perhaps #launchpad
[00:04] <TheLordOfTime> since they understand the interconnectivity
[00:05] <phillw> TheLordOfTime: they suggested it in the mix, but is somewhat more involved, hence my asking Brian to 'have a think'
[00:06] <TheLordOfTime> Brian as in... bdmurray?
[00:06] <TheLordOfTime> (the BUGS GOD of Ubuntu)
[00:07] <phillw> #ubuntu-bugs ?
[00:07]  * TheLordOfTime shrugs
[00:07] <TheLordOfTime> phillw, you should see the responses, and to be honest, "Brian" could mean one of numerous LP/IRC nicks, so i'm calling you out on your lack of specificity :P
[01:42] <xnox> plars: gema: i just sent an email to ubuntu-installer & utah-devel about automatic preseeding of nexus7 ubuntu core images.
[01:42] <xnox> at this point it works to the point on unattended boot into configured desktop.
[01:43] <xnox> but WiFi settings did not managed to establish network connectivity, once that is available it will be good to go.
[01:43] <xnox> I am also will be looking tomorrow to use adbd code to reboot back into bootloader.
[03:43] <plars> xnox: hmm, I'm on utah-devel but I don't think I got it
[06:26] <pitti> Good morning
[07:34] <dholbach> good morning
[08:03] <jibel> good morning
[09:15] <xnox> plars: https://lists.ubuntu.com/archives/ubuntu-installer/2013-February/001218.html
[09:16] <xnox> and here https://lists.ubuntu.com/archives/ubuntu-utah-devel/2013-February/000080.html
[09:16] <xnox> plars: maybe it was held in moderation queue, i dunno =)
[15:25]  * smartboyhw wonders where on Earth is balloons
[16:19] <balloons> SergioMenesesAFK, I think I know what the deal was with your weird big diffs
[18:06] <balloons> xnox, are you about now?
[18:13] <xnox> balloons: hello.
[18:14] <xnox> (sorry was away from the keyboard a little bit)
[18:14] <balloons> xnox, hey :-) Excellent, so thomi and I spent some time yesterday trying to introspect ubiquity
[18:14] <xnox> I'm listening =)
[18:14] <balloons> I wanted to have a crack at writing an autopilot test for ubiquity
[18:14] <balloons> we ran into some issues tho.. it seems ubiquity won't load the autopilot gtk module
[18:15] <xnox> good. Doing it on the nexus would be like the easiest thing on earth, I'm almost done with autoprovisioning it.
[18:15] <xnox> balloons: is it a GTK_MODULE? edit /usr/bin/ubiquity-dm to make sure it does load it.
[18:15] <balloons> yes, GTK_MODULES
[18:15] <balloons> weird ok
[18:16] <balloons> ohh
[18:16] <xnox> balloons: or I can strike a deal if you can get it to work from the point of launching it using the desktop icon in the "try ubuntu session" i'll fix it up to the point where it works from automatic booting.
[18:16] <balloons> lol.. gotcha, so we do need to edit it in
[18:17] <balloons> yes, I'm going at it via try ubuntu session, load live session, then run the test
[18:17] <balloons> we'll start there
[18:17] <xnox> cause I can't learn autopilot to write them and integrate, but I can make sure the written scripts are automatically run & like watch the jobs and fix things.
[18:17] <balloons> kk, booting bm again
[18:17] <balloons> xnox, yes, I think that would be fair and helpful :-)
[18:28] <balloons> ok, so I see the overlay scrollbars being forced to load
[18:38] <balloons> xnox, ok so if  i have it into the python script for ubiquity, I get this: Gtk-Message: Failed to load module "autopilot". If I hack it into ubiquty-dm, it wants args to run.. how can I run it?
[18:38] <xnox> how does it normally run?
[18:39] <balloons> so the normal means for messing about is to use the autopilot launch tool to launch the app
[18:39] <xnox> balloons: can you send me actual debug messages via pastebin?
[18:39] <balloons> it needs a straight binary however (not a script)
[18:39] <balloons> but all it's doing is force loading the 'autopilot' gtk module
[18:40] <balloons> so I'm trying to do that manually..
[18:40] <xnox> balloons: so do that. What do you mean by "straight binary" ? Cause ubiquity is not compiled gtk, but rather written in python. So it will be a script.
[18:40] <balloons> xnox, well.. sorry a bit confusing.. Forget that part :-) The point is I can't seem to manually load the gtk module to the point that the vis tool will see it
[18:41] <balloons> and without that, I can't see the dbus session to start writing something ;-)
[18:41] <balloons> so, maybe running in debug mode or with verbose output might help? trying to straight load it fails with only that message
[18:41] <balloons> for instance, yesterday I was trying this: GTK_MODULES="autopilot:$GTK_MODULES" /usr/lib/ubiquity/bin/ubiquity
[18:42] <balloons> hmm, yea, I mean adding -d doesn't tell me anything more.. the module isn't loading
[18:42] <xnox> balloons: we start dbus session only half way between ubiquity-dm starting and ubiquity actually appearing.
[18:43] <balloons> xnox, ohh interesting
[18:43] <xnox> seriously login into - try ubuntu. that will be a better environment to develop the tests.
[18:43] <xnox> plus we will need to test in that mode as well.
[18:43] <balloons> I'm in try ubuntu
[18:43] <balloons> I'm in a vm, loaded up into a live session
[18:43] <xnox> right.
[18:44] <balloons> I've got the installer link on the desktop
[18:44] <xnox> in that case, one sec.
[18:44] <balloons> k
[18:45] <xnox> does: autopilot-auto-launch-script /usr/bin/ubiquity work?
[18:45] <balloons> no, that gives the "Only dynamically linked binaries are supported" error
[18:46] <balloons> so I was trying to get closer to the source to get it to launch.. hence my digging around in /usr/lib/ubiquity/bin/ubiquity
[18:46] <balloons> but I soon abandoned that and just tried to manually load the module..
[18:47] <xnox> balloons: heh. So is there a way to launch autopilot against gtk python apps?
[18:47] <xnox> if there isn't it will not work at all.
[18:48] <balloons> xnox, yes, the launch feature just loads the module, so.. no worries if it doesn't automagically work
[18:48] <balloons> we need to get ubiquity running with the module loaded so it will export it's dbus session
[18:48] <balloons> that's all
[18:49] <xnox> it starts a complete dbus session? or just is available on the dbus?
[18:50] <balloons> I think just available works..
[18:50]  * balloons notes your in the UK (never knew your tz)
[18:51] <balloons> I'll have to start pinging you earlier :-)
[18:51] <xnox> balloons: i'd just do "return GtkIntrospectionTestMixin" in the "def get_application_introspection_base(app_path):"
[18:51] <xnox> instead of exit(1)
[18:52] <xnox> and try again using the automatic script, as the script does more =)
[18:52] <balloons> :-)
[18:52] <balloons> alrighty.. lets give that a whrl
[18:52] <xnox> autopilot should have a command arg to specify the type of interspection. All that check does is check Qt vs Gtk vs Other.
[18:53] <balloons> it's rudimentary
[18:53] <balloons> wow
[18:53] <balloons> you know I never even glance at this
[18:56] <balloons> xnox, ok now when is the session started?
[18:57] <balloons> the other potential issue is permissions...
[18:59] <xnox> what session?
[18:59] <xnox> did ubiquity & autopilot start ?
[19:00] <balloons> yes, so it launched no errors about not being able to load the module
[19:00] <balloons> then running the vis tool however, it doesn't show ubiquity
[19:00] <balloons> we could check using dbus-monitor
[19:08] <balloons> xnox, so when I launch ubiquity, I'm not see any dbus activity.. no interface, no properties, etc, for ubiquity
[19:11] <xnox> is there any for python?
[19:12] <xnox> balloons: shutdown VM, boot the VM, at the boot screen quickly click esc. choose english
[19:13] <balloons> ok..
[19:13] <balloons> yep.. now?
[19:13] <xnox> then in F6 i think there is accessibility options choose the biggest one (blind user)
[19:13] <xnox> that will load all a11y frameworks on boot.
[19:14] <xnox> F5 -> screen reader
[19:14] <chilicuil> hi, I'm looking at the install image testcases and whenever Ubuntu should be named it's 'FAMILY' instead, i.e., <dt>Click on the Install FAMILY icon</dt>
[19:15] <chilicuil> is that the expected behaviour?
[19:15] <balloons>  chilicuil yes, we should note that somewhere.. FAMILY wll automagically convert to the proper family as needed
[19:15] <balloons> kubuntu, ubuntu, etc
[19:15] <balloons> since we share testcases
[19:15] <chilicuil> balloons: ok, thanks
[19:15] <balloons> xnox, kk
[19:15] <balloons> I used braille terminal
[19:16] <balloons> well hmm
[19:16] <xnox> balloons: no braille is too much, you want screen reader
[19:16] <balloons> high contrast, magnifier, screen reader, braille terminal, keyboard modifiers, on-screen keyboard
[19:16] <xnox> "screen reader"
[19:16] <balloons> :-)
[19:16] <balloons> done deal
[19:19] <balloons> k, installing d-feet and autopilot again
[19:19] <balloons> it's fun being read to
[19:20] <xnox> yeah, I tend to turn off speakers after a while
[19:20] <balloons> ok, what next?
[19:21] <balloons> I see the lovely a11y bus now
[19:23] <xnox> launch autopilot and it all should work (tm)
[19:23] <balloons> lol
[19:23] <xnox> well /usr/bin/ubiquity via autopilot start script
[19:26] <balloons> yes, so I modded the start script again and launched it
[19:26] <balloons> i don't see any ubiquity session in d-feet, nor does the autopilot tool see it
[19:26] <balloons> hmm
[19:26] <xnox> what do you mean by ubiquity session?
[19:26] <xnox> how does it normally work and what are you expecting to see in d-feet?
[19:27] <balloons> after you launch it with autopilot
[19:27] <balloons> I should get a dbus connection in the autopilot vis tool
[19:27] <balloons> I'm not getting that
[19:28] <balloons> now, it may be because ubiquity is running as root
[19:28] <balloons> i assume it is anyway :-) I'm assuming you escalate and run as root, or you run only certain ops as root?
[19:28] <xnox> pkexec d-feet
[19:28] <xnox> yes, it's running as root.
[19:29] <balloons> ahh.. so thomi might have to help out there in order for me to see it
[19:29] <balloons> one sec, let's see
[19:29]  * thomi waves
[19:30] <balloons> hello thomi :-) xnox and I are getting closer on ubiquity and autopilot
[19:30] <thomi> oh?
[19:30] <balloons> here's the summary.. if we ignore the warning for your lddconfig hack and just load the gtk module, it seems to load ubiquity fine
[19:31] <balloons> however, running autopilot vis shows me nothing
[19:31] <balloons> note however, ubiquity runs as root
[19:31] <balloons> so if I try running both autopilot launch and autopilot vis as root, I see no connections
[19:31] <xnox> and it also re-execs itself by the way.....
[19:31] <xnox> and it's python....
[19:31] <thomi> balloons: ok... the fact that ubiquity runs doesn't mean that it's honored the GTK_MODULES env var and actually loaded the plugin though
[19:31] <xnox> and it can use either gtk or qt toolkits.....
[19:32] <balloons> thomi, your correct.. how can we verify?
[19:32] <thomi> xnox: re-exec'ing itself shouldn't be an issue, since environment is inherited in most cases
[19:32] <thomi> alesage: any ideas?
[19:32] <thomi> alesage: does the gtk plugin log something when it loads?
[19:33] <alesage> thomi if you need to test, you can enable the logging, but no it's disabled as it ships
[19:34] <thomi> alesage: ok, do you mind if I add a single log line that prints "Gtk introspection plugin loaded" to stdout every time?
[19:34] <thomi> would that cause issue?
[19:34] <thomi> *issues?
[19:34] <thomi> also, I wonder about enabling the debug logging if a particular env var is set?
[19:34] <thomi> like: AP_GTK_LOGGING=1
[19:35] <alesage> thomi I wouldn't think it would cause problems--I'm just not sophisticated to know where to put the log :)
[19:35] <alesage> there's a bit of code in main.cpp to handle logging thomi if you want to adjust
[19:35] <thomi> alesage: I was going to log to stdout
[19:35] <thomi> that way autopilot tests will pick it up
[19:35] <alesage> thomi o I see, yes no objection
[19:35] <xnox> balloons: get the pid of the ubiquity and cat /proc/NNNN/environ and see the environment
[19:36] <xnox> that way you'll see if it enherited the module or not.
[19:36] <xnox> (well it will be python3 process...)
[19:36] <balloons> sorry got dc'd for a sec
[19:36] <balloons> reading scrollback
[19:37] <balloons> k, 'll try your idea xnox
[19:38] <balloons> yep, GTK_MODULES=:autopilot
[19:38] <balloons> good stuff
[19:38] <thomi> xnox, balloons, alesage: for your delectation: https://bugs.launchpad.net/autopilot-gtk/+bug/1130861
[19:38] <thomi> balloons: think that leading ':' might be screwing it up?
[19:38] <balloons> not sure why it's there tbh
[19:39] <thomi> balloons: you probable did:
[19:39] <thomi> GTK_MODULES=$GTK_MODULES:autopilot
[19:39] <balloons> I assume since the GTK_MODULES
[19:39] <balloons> yes
[19:39] <xnox> balloons: that's missing overlay-scrollbar modules
[19:39] <thomi> and GTK_MODULES was empty
[19:39] <balloons> exactly
[19:39] <xnox> and libcanberra?!
[19:39] <thomi> :)
[19:39]  * xnox offline to find some dinner. be back later, maybe.
[19:40] <balloons> let me check some of the other processes
[19:42] <balloons> thomi, anyways, on your theory, yes I agree with the reasoning
[19:42] <balloons> however I used launch to launch it
[19:43] <xnox> GTK_MODULES=overlay-scrollbar autopilot-script-thing /usr/bin/ubiquity =)
[19:43] <balloons> as I said, in order to launch we hacked around your ldd_output and just told it to load gtk anyway
[19:43] <xnox> try that ;-)
[19:44] <thomi> balloons: I see - perhaps you could file a bug against autopilot for that?
[19:44] <balloons> xnox also suggested we just hack in the GTK_MODULES os.environ line in the python ubiquity script
[19:44] <balloons> thomi, sure.. I think being able to force one or the other would be good.. auto by default, allow me to force
[19:44] <xnox> that will only help with "install ubuntu" not in "try ubuntu"
[19:45] <balloons> xnox, OHH.. makes sense now.. You confused me before with that
[19:45] <balloons> as I had no idea had to run the result.. heh
[19:47] <balloons> so, thomi alesage should I be running autopilot vis or autopilot launch as root? see above about ubiquity re-execing itself and running as root
[19:47] <thomi> balloons: hmmmmmm that's an interesting question
[19:48] <thomi> I wonder which session bus it connects to?
[19:48] <thomi> balloons: maybe test by running: sudo autopilot launch gedit
[19:48] <thomi> and then: autopilot vis
[19:48] <balloons> ohh right right
[19:48] <thomi> if you can see the gedit connection, then it connects to the regular user session bus
[19:48] <thomi> if not, try 'sudo autopilot vis'
[19:49] <balloons> ohh
[19:49] <balloons> weird.. running as root directly doesn't work
[19:49] <balloons> can't find the ap interface
[19:49] <balloons> on launch
[19:49] <thomi> balloons: ahhhh... you may need to launch it manually then.
[19:49] <balloons> sudo does the same thing
[19:51] <balloons> GTK_MODULES="autopilot:$GTK_MODULES" ubiquity fails to load ap module
[19:53] <thomi> balloons: I can take a look after I finish this loggign thing...
[20:13] <Letozaf_> balloons, Hi
[20:15] <balloons> I'm watching the ap tets run on the nexus7 tablet
[20:15] <balloons> they work :-)
[20:27] <balloons> ok.. so back on this ubiquity thing
[20:27] <balloons> thomi you freed up now/
[20:27] <balloons> ?
[20:28] <thomi> balloons: almost... 10 minutes?
[20:33] <SergioMeneses> hi guys!
[20:33] <SergioMeneses> balloons, \o I read your message, what is it?
[20:33] <balloons> SergioMeneses, hello
[20:33] <balloons> your all merged
[20:33] <balloons> the issue was a control character at the top
[20:33] <balloons> chilicuil fixed it for us (and found it!)
[20:34] <balloons> so I'll sync the new stuff back to the tracker soon
[20:34] <SergioMeneses> balloons, nice
[20:41] <Letozaf_> balloons, can I ask you or thomi about autopilot and shotwell, I'm stuck can't solve a thing
[20:41] <balloons> Letozaf_, please do
[20:41] <balloons> btw.. oh oh oh
[20:41] <balloons> I needed to share ths with you
[20:41] <thomi> Letozaf_: BTW, that vis bug is fixed now
[20:41] <SergioMeneses> balloons, ?
[20:42] <balloons> Letozaf_, https://github.com/martinpitt/umockdev
[20:42] <Letozaf_> balloons, thomi hurray!!!
[20:42] <balloons> Letozaf_, that is made by pitti and it can create fake hw.. like a camera :-)
[20:43] <Letozaf_> balloons, thats super !!! great!!!
[20:43] <Letozaf_> balloons, but how does it work ?
[20:43] <balloons> I've not messed with it much yet, but  think we can incoporate t
[20:43] <Letozaf_> balloons, well let me know when you find out how to work with it
[20:44] <Letozaf_> balloons, I keep on swithing on and off my camera for testing with shotwell >D
[20:44] <balloons> Letozaf_, hehe
[20:44] <balloons> well, pitti is in your timezone, but he's around in the morning and daytime
[20:44] <Letozaf_> balloons, :D
[20:45] <balloons> however, there's a basic info on the github
[20:45] <balloons> read the  Command line: Record and replay PtP/MTP USB devices
[20:46]  * Letozaf_ is reading
[20:48] <Letozaf_> balloons, sounds good, but do you think I could try this out ?
[20:49] <Letozaf_> balloons, well if I'm able to :-P
[20:49] <balloons> thomi, yay for bug fixes
[20:50] <thomi> balloons: ok, Gtk doesn't like me, so I can answer your questions now, if you like
[20:50] <balloons> Letozaf_, yes you can try if you'd like. I have no experience, but as I said, the author is on this channel :-)
[20:50] <balloons> thomi, ok, so let's summarize quickly I suppose
[20:51] <balloons> it appears like ubiquity loads with the autopilot launch hack, but it doesn't work when autopilot vis is run (as root or not)
[20:51] <balloons> if you run autopilot launch as root, it doesn't seem to work (can't find ap)
[20:51] <balloons> if you try and manually load the gtk module into ubiquity it doesn't seem to work
[20:51] <thomi> balloons: have you confirmed that ubiquity actually loads the autopilot plugin?
[20:52] <balloons> finally, I'm concerned that I can't see a session being created by ubiquity when it is run
[20:52] <balloons> meaning, if I load dbus-monitor, or d-feet, I don't see an entry for ubiquity
[20:52] <balloons> thomi, I can see the env variable is passed, and it doesn't error. that's all
[20:52] <thomi> balloons: my guess is that the AP plugin isn't being loaded. some apps don't seem to honor the GTK_MODULES env var... like gnome-terminal, for example
[20:53] <balloons> according to xnox it does honor it
[20:53] <Letozaf_> balloons, well I also have no experience but this thing sounds so good it has to be tried :D
[20:53] <thomi> do we have evidence to support that? can you see it using overlay scrollbars for example?
[20:53] <balloons> Letozaf_, lol.. that's the spirit! Don't beat your head on it too much, but yes, I think it has good potential for us
[20:54] <balloons> thomi, yes it does use overlay scrollbars
[20:54] <Letozaf_> balloons, lol
[20:54] <thomi> balloons: hmmmm, ok
[20:54]  * Letozaf_ will beat her head :-P
[20:56] <thomi> balloons: hmmm, interesting
[20:56] <thomi> balloons: when I run:
[20:56] <thomi> GTK_MODULES=autopilot ubiquity
[20:56] <thomi> I get:
[20:56] <thomi> Gtk-Message: Failed to load module "autopilot"
[20:58] <balloons> yep
[20:58] <balloons> does that straight out mean to you it's not honoring?
[20:58] <thomi> no, the opposite
[20:58] <thomi> it means it's reading that environment variable, and not loading the plugin
[20:59] <balloons> lol.. true true
[20:59] <thomi> looking into it now
[21:01] <thomi> balloons: I can load the ap plugin with a test python/Gtk3 app, so there's no problem there...
[21:01] <balloons> that's good
[21:04] <balloons> thomi, so if I run GTK_MODULES="autopilot:$GTK_MODULES" /usr/lib/ubiquity/bin/ubiquity it doesn't complain
[21:04] <balloons> however, it fails as ubiquity normally launches that as root..
[21:04] <balloons> using sudo incorporates the previous issues
[21:04] <xnox> sudo potentially strips the environment
[21:05] <balloons> hey xnox :-0
[21:05] <thomi> balloons: try hacking that file and changing LOCKFILE to be something that you have write access to
[21:05] <xnox> balloons: can you try: GTK_MODULES="autopilot:$GTK_MODULES" sudo -E /usr/bin/ubiquity ?
[21:05] <balloons> thomi, i went that route a bit, but it will ultimtaely just fail
[21:06] <balloons> it really does need root
[21:06] <balloons> xnox, running
[21:06]  * xnox there is a way to run ubiquity as a normal user........ but it's oem config mode only
[21:07] <balloons> ohh.. right
[21:07] <balloons> the user setup mode
[21:07] <balloons> xnox, thomi, so running GTK_MODULES="autopilot:$GTK_MODULES" sudo -E /usr/bin/ubiquity doesn't give any failure
[21:07] <balloons> but autopilot vis doesn't see anythng
[21:07] <balloons> i'll check env
[21:07] <xnox> ok.
[21:07] <thomi> balloons: what about with sudo -E ?
[21:08] <balloons> thomi, it doesn't say it can't load the module
[21:08] <balloons> it just runs
[21:08] <thomi> so /usr/bin/ubiquity launched the inner script with: gksudo --preserve-env, so there's no need to call the inner script directly
[21:08] <thomi> so we also don't need to mess about with sudo ourselves
[21:09] <balloons> interesting: GTK_MODULES="autopilot:$GTK_MODULES" sudo -E /usr/bin/ubiquity
[21:09] <balloons> gtk_modules=autopilot:autopilot:overlay-scrollbars
[21:11] <balloons> without sudo, it fails to load module "autopilot"
[21:11] <thomi> balloons: wtf? that makes no sense
[21:12] <balloons> you tell me mate.. everything we're seeing and you and xnox are saying points to the fact this should have just worke
[21:12] <balloons> *worked
[21:12] <thomi> balloons: ahaaaa
[21:12] <balloons> xnox, can we force ubiquity to run in non-privileged mode?
[21:13] <balloons> without going through oem-install?
[21:13] <thomi> balloons: the "Gtk-Message: Failed to load module "autopilot"" message is from gksudo
[21:13] <thomi> balloons: not from ubiquity I think
[21:13] <balloons> hmm
[21:13]  * xnox ponders if we should use pkexec and not gksudo
[21:13] <thomi> balloons: run this: UBIQUITY_WRAPPER_DEBUG=1 GTK_MODULES=autopilot ubiquity
[21:14] <thomi> balloons: and observe that that message is printed when gksudo is asking for your password
[21:14] <xnox> there is no password. so it goes straight through.
[21:15] <balloons> ['gksudo', '--preserve-env', '--', '/usr/bin/ubiquity']
[21:15] <balloons> Gtk-Message: Failed to load module "autopilot"
[21:15] <thomi> xnox: ok, well I hadn't entered my password into gksudo before, so it asked me :)
[21:16] <balloons> thomi, definitely confirmed
[21:16] <balloons> launching gksudo alone prints it as well
[21:16] <balloons> let's not use gksudo
[21:17] <thomi> balloons: I don't think that's the problem
[21:17] <balloons> thomi, why not?
[21:17] <thomi> we don't care if gksudo fails to load the ap plugin
[21:17] <balloons> oh ohh
[21:17] <thomi> it's ubiquity we care about
[21:17] <balloons> lol.. I get it
[21:17] <thomi> and we already know that it's preserving the environment OK
[21:17] <balloons> lol
[21:18]  * thomi reads more source code
[21:18] <balloons> I'm jumping on anything.. sorry
[21:19] <xnox> balloons: s/gksudo/pkexec/
[21:19] <balloons> xnox, yea, I modded ubiquity already.. but I think thomi is right
[21:20] <thomi> heh... found a bug in ubiquity
[21:20] <thomi> not one that helps us though :)
[21:26] <xnox> thomi: which is what? =)
[21:27] <thomi> xnox: some unused code in the main ubiquity script that does nothing
[21:28] <xnox> thomi: please send a patch or pastebin unused code or give line numbers =)
[21:28] <thomi> xnox: I've closed the file, but I will
[21:28] <thomi> when I get back there again :)
[21:35] <thomi> xnox: so... you know the ubiquity internals?
[21:36] <thomi> xnox: /usr/lib/ubiquity/ubiquity/gtkwidgets.py line 470 there's an error the file has:
[21:36] <thomi> super().__init__()
[21:36] <thomi> should be super(Builder, self).__init__()
[21:36] <xnox> true.
[21:37] <xnox> is it necessory?
[21:37]  * thomi can't quite work out how it works without that
[21:37] <thomi> xnox: in python2.x, yes
[21:37] <xnox> thomi: ubiquity is python3 only =)
[21:37] <xnox> http://docs.python.org/3.1/library/functions.html#super
[21:38] <xnox> since the beginning of quantal.
[21:38] <thomi> xnox: ahaaaaa!
[21:38] <thomi> xnox: lol... that explains a lot
[21:38]  * thomi stops trying to use python2
[21:38] <thomi> heh
[21:44] <balloons> lol
[21:51] <thomi> hmmm
[21:51] <thomi> so I  was trying to run the gtk frontend by itself, but it starts debconf, and that fails for some reason
[21:53] <thomi> balloons: my suggestion is to work with the ubiquity developers and figure out how the gtk main loop is being run. I see a couple of different entry points in the gtk frontend, and It's not immeadiately obvious to me which is being used
[21:53] <balloons> thomi, it depends on how it was invoked
[21:53] <thomi> balloons: however, we now know a lot more than we did a few hours ago. to summarise:
[21:53] <balloons> through the live session, or through the straight install.. or as xnox mentioned, through the oem setup and reboot
[21:54] <thomi> 1) We know that calling /usr/bin/ubiquity as the command to launch doesn't strip the GTK_MODULES env var, so we can use that for autopilot
[21:54] <thomi> 2) we know that there's no problem at all with a python app loading the autopilot plugin
[21:55] <thomi> also, running: sudo autopilot launch gedit && sudo autopilot vis" works for me - I can see the gedit window (but not Unity)
[21:57] <balloons> thomi, nice summary
[21:57] <balloons> sudo works for you?
[21:57] <balloons> wow
[21:58] <balloons> weird.. it does work on my deskto
[21:58] <balloons> but not in the live session
[21:58] <xnox> thomi: main loop eh ?! =) we have in general two main loops - debconf one and the UI one. The UI main loop can be either a gtk or Qt one.
[21:59] <xnox> we stop the mainloop between each page and process the debconf mainloop, when we figure out from debconf what to show next we draw the next page & enter the UI mainloop again.
[21:59] <xnox> due to the way pages behave they may enter additional nested mainloops.
[22:00] <xnox> indeed it's not obvious.
[22:00] <xnox> thomi: how do you know that starting debconf fails?
[22:00] <xnox> if debconf fails ubiquity can't do anything at all.
[22:05] <thomi> xnox: I get an uncaught exception :)
[22:05] <xnox> =/
[22:06] <thomi> since I can't find any code that modifies the GTK_MODULES env. var, I'm assuming that the difference has to be in the way the main loop is entered
[22:07] <thomi> perhaps calling Gtk.Main() imports the modules, but whatever ubiquity does to enter/exit the main loop doesn't work?
[22:07]  * thomi shrugs
[22:15] <Letozaf_> balloons, :( oh well.. I tried to compile umockdev but got an error: http://paste.ubuntu.com/1693598/
[22:16] <Letozaf_> balloons, I will see if tomorrow I will able to carry on
[22:16] <Letozaf_> balloons, now it's a bit late :(
[22:16] <balloons> Letozaf_, :-(
[22:16] <xnox> thomi: can you paste the error.....
[22:16] <Letozaf_> balloons, I will try again tomorrow :D  'night
[22:55] <phillw> xnox: has your fix for bug 1128597 got into the system yet?
[22:57] <xnox> not yet.
[22:58] <phillw> xnox: is there any workaround? as it is a killer bug for me to test lubuntu in either VBox or KVM...
[22:59] <xnox> phillw: oh. I thought it's only affecting booting into blind accessibility.
[22:59]  * xnox raising priority to upload that fix.
[23:00] <phillw> xnox: nope, it stalled a guy who uses VBox, and when I attempted to replicate in kvm, it killed me as well :(
[23:00] <phillw> thanks, much appreciated.