=== mark is now known as mark|coffee === mark|coffee is now known as mark [09:41] usb-creator: evand * r341 usb-creator/usbcreator/backends/udisks/backend.py: Slight fix to previous commit. [10:51] ubiquity: evand * r4510 trunk/ (debian/changelog ubiquity/plugins/ubi-usersetup.py): Install oem-config-slideshow-ubuntu alongside oem-config-gtk. [13:22] ev, what's this I hear about using a shared library for the ubiquity map and the system's datetime map? I'm helping klattimer out and wanted more information about it [13:24] mterry_: will reply shortly; lunch [13:24] ev, k [13:49] mterry_: the timezone map from ubiquity has been ported to gnome-control-center (in git), so the plan is to start using that C library, or to import the source. [13:50] ev, is it in a library in g-c-c? or would we have to split it out regardless? [13:51] (because obviously using the same codebase would be ideal) [13:52] oh i see, it's written as a new-fangled g-c-c panel [13:53] indeed [13:54] so we need a separate library. I wonder if GNOME folks would be willing to use such a library in their panel so we can all share code [13:56] I hope so [14:04] seeing quite odd behavior when wedging compiz into ubiquity-dm. Compiz seemingly paints over the root window, and X ultimately crashes as the Intel driver hits an OOM condition, I think. [14:04] The wallpaper setting code is clearly missing something that nautlius is doing. [14:06] ev, so you guys need python access to the new C library? Is PyGI good? [14:08] mterry_: ah, we can't mix both sets of bindings. Rubbish [14:09] we should move ubiquity over to pygi in time anyway [14:10] ev, right, I forgot that the library would be exposing gtk objects [14:10] ev, what is 'in time'? you don't mean for natty? [14:11] I thought we wanted this in time for natty [14:11] well no, I don't think we can move ubiquity to pygi in a week, but presumably it will take time to generate bindings of any kind [14:11] But I'm surprised to hear ubiquity would move to PyGI, since I thought that also required porting to GTK+ 3.0 [14:12] mterry_: it would be nice to have for natty, but I don't think the world implode if we don't get it, given that the timezone map is already functional in natty [14:12] (my understanding is that there's GTK 2.0 pygi bindings as well) [14:13] which I believe we're using already in jockey, apport and the like [14:13] ev, I think there's a desire for the timezone map library at least existing in C form for natty, since we'd like to use it for a modified datetime preferences [14:13] as we weren't ready for the new theme engine in gtk3 [14:13] ev, I thought those got backed out [14:13] indeed, pitti has been working hard on making PyGI work with gtk+2.0 [14:13] gir1.2-gtk-2.0 [14:13] cjwatson, OK, my mistake. I thought the plan of record was to back out the port rather than fix PyGI, but that's good too [14:14] I think that was the plan at UDS [14:14] and was revised later [14:14] my information is from a few weeks ago. I'll ping pitti [14:16] OK, pitti says 2.0 mostly works. At least it does for the stuff we've ported, thanks to him [14:23] ev, cjwatson: does ubiquity require CA? [14:23] copyright assignment that is [14:23] * ev coughs [14:25] I see you're also living in the ancient GPL-2+ past :) [14:26] ev, i've actually been seeing X crash just with metacity on intel too [14:27] mterry_: so ubiquity is in the list (http://www.canonical.com/contributors), but the last time I tried to round up the contributors and get them to sign (well over a year ago, if memory serves), it failed miserably [14:27] superm1: interesting [14:28] been like that for a few weeks. bryce tracked down a few missing null pointer checks in the X server, but it's looking lower level [14:28] I'm still missing something obvious about the way compiz is handling the root window though, as even xsetroot fails to affect the display. I'm going to dig deeper into the code. [14:28] ev, I see, so it wants to be CA, but isn't quite there yet [14:28] ev, or at least, maybe CA for new peeps [14:29] someone wants it to be CA, but that person is not me [14:29] just to be able to get the code figured out you might consider just trying to apply it for a maverick build to rule out these X crashes as you wedge the code in [14:29] ev, OK, just trying to figure out what would be up with a new timezone library that involves the non-Canonical port to C. I emailed Amanda to ask [14:30] mterry_: I never check for CA, and haven't gotten called out on it, but I probably shouldn't give that as advice [14:30] ah, okay [14:30] superm1: hadn't considered that. Thanks, will do. [14:37] mterry_: "ancient GPL-2+ past"!? [14:37] highvoltage, GPL-3 is pretty old now, thought someone would upgrade the license at some point :) [14:38] mterry_: well, in ubiquity's case I guess it's probably best to choose the most free'st license that makes sense. and gplv2+ is way more free than gplv3, and probably way more appropriate for an installer [14:39] highvoltage, heh, I didn't want to start a license flamewar here [14:39] it's not a flamewar, just a cold lifeless fact :) [14:42] and I think requireing copyright assignment for ubiquity is also kind of dumb. what if ubituity gets into debian and gets widely used for some of the live images, will someone who want to merge patches and improvements from ubiquity have to go to all the contributors and keep asking them to sign ca contracts, or worse keep real big patches in the debian version because upstream doesn't want to accept non-CA patches? or just let u [14:42] * highvoltage shuts up before getting a comment about "oh where's this long stream of ubiquity contributors then!?" :) [14:50] preaching to the choir, I think [14:52] :) [15:02] hi [15:02] anyone there? [16:35] ev: ref the install/slideshow issue in natty is it out of our hands to fix it? I'm assuming so but thought I check to be sure [16:48] ev: would you mind having another look at bug 650703? apparently it may be showing up in 10.04.2 as well [16:48] Launchpad bug 650703 in ubiquity "oem-config-prepare works, but oem-config fails to start after reboot" [Critical,Confirmed] https://launchpad.net/bugs/650703 [16:50] cjwatson: absolutely. [16:51] seems to be a race with gdm's upstart job, but I'll figure out exactly what's preventing us from blocking it [16:52] davmor2: it's a bug in webkitgtk that upstream is aware of and actively trying to solve [16:53] ev: Ah okay cool I figured it would be but thought it worth checking :) [16:53] sure thing [17:16] ev: 16:49 thanks. they're still working on reproducing in u-testing, if he wants to hang out there. But it looks likely. [17:16] joined, thanks [17:40] awesome, I *had* a vbox image where I could reproduce the issue that seems to no longer like its snapshot [17:41] some things I've noticed that may or may not be related to the bug: [17:42] 1) gdm no longer emits starting-dm, it instead goes for desktop-session-start [17:42] 2) is rc RUNLEVEL=[...] really correct? Shouldn't it be runlevel [...]? [17:51] actually, do we even need the starting-dm bit anymore? Nothing seems to use it. [17:52] might want to bzr blame to find out why it was introduced [17:52] IIRC it was to avoid a race with the plymouth/gdm startup [17:52] which seems to have been resolved in lucid: https://launchpad.net/ubuntu/+source/gdm/2.29.1-0ubuntu4 [17:53] bzr blame blames me, but I credit you without an explanation of why I made the change. Fail [17:56] and we seem to handle shutting down plymouth in much the same was as the patch credited in the aforementioned gdm version does. [17:56] way* [17:57] gotta run. I'll poke more tomorrow. [20:15] ev, how do you get location names nowadays? Like, how might I map Europe/London to "London"?