[00:19] <slangasek> ubuntu alternates are available for smoketesting (oversized, though)
[00:47]  * stgraber rsyncs
[00:47] <slangasek> desktop also posted, also oversized...
[00:48] <stgraber> nice, getting a steady 80Mb/s from cdimage.u.c :)
[00:48] <cjwatson> oh, which reminds me, I was going to try for a backport of the lintian change that switches to using libdpkg-perl
[00:49] <cjwatson> I haven't done the sums, but that might well get us either back within limits or very close
[00:56] <slangasek> cjwatson: something to include in tomorrow's images, maybe?
[00:58] <cjwatson> yeah, I'm build-testing and will see if it looks reasonable
[00:59] <cjwatson> the lintian tests don't half take forever to run
[00:59] <slangasek> :)
[01:00] <slangasek> server up
[01:00] <slangasek> ScottK: haven't queued anything for kubuntu yet, per your earlier comment; please let me know when I should
[02:07] <charlie-tca> I see Xubuntu images are new; are they really ready to smoke test?
[04:40] <micahg> skaet: ping, it seems like we have an issue with the firefox homepage, bug 790469
[04:40] <ubot4`> Launchpad bug 790469 in firefox (Ubuntu Oneiric) (and 1 other project) "invalid security certificate 11.10 (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/790469
[04:40] <micahg> I milestoned it for alpha1 since it seems bad, feel free to move if you think it's not worth respins
[04:51] <micahg> skaet: there's also bug 790617, I'll see if I can find someone to look at that
[04:51] <ubot4`> Launchpad bug 790617 in firefox (Ubuntu) (and 1 other project) "about:startpage returns 404 Not Found (affects: 2) (dups: 1) (heat: 16)" [Undecided,Invalid] https://launchpad.net/bugs/790617
[04:53] <micahg> skaet: re start page, I pinged newz2000 about it, but he probably won't see it until morning US
[05:04] <slangasek> micahg: there will be respins before alpha1 regardless, and if you have a fix that you can upload now it's probably worth doing - but the threshold for alpha1 is "boots, installs, golden" so if you don't have the fix we aren't going to sweat it
[05:05] <ScottK> slangasek: I just accepted kdebase-workspace, so once that publishes I think it's worth a shot.
[05:05] <slangasek> ok
[05:06] <micahg> slangasek: I have no idea what the fix could be at this point aside from disabling the extension, chrisccoulson should be up in a few hours and I'll ask him to take a look
[05:07] <ScottK> micahg: For an Alpha 1, I think that's not a real concern.  Fixing is good, but don't kill anyone.  This is a marathon, not a sprint and we're just getting started.
[05:08] <micahg> ScottK: ok
[05:20] <stgraber> is there a planned rebuild of edubuntu ? current daily is 20110530 and at least in my case, doesn't boot. I'd like to see if that got fixed somehow (as I doubt it's Edubuntu-specific)
[05:27] <slangasek> stgraber: yes - was provisionally waiting for smoketesting of the images already built before spinning edubuntu, but I can kick it off now
[05:29] <stgraber> would be great. I was hoping for 20110531 to improve the situation in our case but it failed because of an issue with archive.u.c ...
[05:41] <pitti> cjwatson: I already dropped the lintian dependency yesterday, it removed 7 MB from the dailies
[05:41] <pitti> cjwatson: I quickly discussed with Michael, we said it'd be better to install lintian on demand once the user actually enables a third-party repo
[07:52] <pitti> oh, kvm -vga std actually makes unity-2d work nicely
[10:23] <cjwatson> pitti: OK, it'll still be good for it not to pull in build-essential
[10:24] <cjwatson> pitti: I've been working on that with the Debian maintainers on and off since UDS
[10:24] <pitti> yes, absolutely
[10:24] <pitti> and once it's small, we might even bring it back
[10:25] <cjwatson> but if it's not on the images, I won't worry about it today
[10:25] <cjwatson> well, it'll inevitably have a perl dependency
[10:25] <pitti> even now we are still some 15 MB oversized
[10:25] <cjwatson> (-modules)
[10:25] <cjwatson> if we're ever shooting for losing perl-modules, we can't have lintian on the images
[10:25] <pitti> we can get back 5 from gnome-icon-theme surgery
[10:25] <cjwatson> we'll get 5 more in alpha 2 from live-build
[10:25] <pitti> and I think you mentioned some 5 MB due to better squashfs from live-helper
[10:26] <cjwatson> any chance of losing gnome-system-tools this cycle?
[10:26] <pitti> Johan said that the AppArmor parts which need perl are only the administration bits
[10:26] <pitti> which we actually could not instlal by default
[10:26] <pitti> cjwatson: already happened
[10:26] <pitti> it's not on the alphas any more, or at least shouldn't be
[10:26]  * pitti checks
[10:27] <cjwatson> ok
[10:27] <pitti> yep
[10:27] <pitti> then the only thing which will still bind a lot of perl is debconf-gtk
[10:27] <pitti> that and AppArmor were the two main things which hold a lot of perl modules
[10:28] <cjwatson> there are a few other things
[10:28] <pitti> yes, indeed
[10:28] <pitti> but these two are the hardest to get rid of
[10:28] <cjwatson> I don't see debconf's gnome frontend ever not depending on perl-modules; I suppose we might eventually be able to switch to cdebconf, although that's a long road
[10:28] <pitti> the rest is just some busy work with making stuff work with perl-base only
[10:29] <pitti> but no point in doing more of that as long as we have AA/debconf-gtk
[10:29] <pitti> right, unless we make a stronger decision to just use the text frontend in a vte widget
[10:30] <pitti> at some point this stuff needs to be ported to GTK 3 anyway
[10:30] <pitti> and I don't think a gtk3-perl exists right now
[10:31] <pitti> https://live.gnome.org/GTK2-Perl/Introspection sounds promising, though
[10:32] <pitti> ah, and gnome classic session also dropped from CDs now
[10:48] <cjwatson> pitti: yeah, looks like Glib::Object::Introspection et al just need to be packaged
[11:22] <jibel> bug 791139, looks like something with udev
[11:22] <ubot4`> Launchpad bug 791139 in ubiquity (Ubuntu) "When booting from an ISO, a shell is displayed for 2 min before the graphics environment starts (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/791139
[14:39] <ScottK> It looks like uninstallables for Kubuntu are fixed.
[14:40] <ScottK> cjwatson: AFAICT the Kubuntu images didn't get respun yesterday (which is fine, it would have failed), but I think from a Kubuntu perpsective nowish is a good time.
[14:57] <pitti> ScottK: cjwatson is on holiday today; let me trigger new Kubuntu images
[14:58] <ScottK> pitti: Thanks.
[14:58] <pitti> ScottK: running desktop + alternate; do you want the armels as well?
[14:59] <ScottK> pitti: No point in armel or powerpc.
[14:59] <pitti> *nod*
[15:05] <jibel> skaet, ping
[15:06] <skaet> jibel, Slangasek,  waiting for Pete.
[15:08] <jibel> skaet, ok, I thought you enjoyed the great tune on the phone
[15:08]  * slangasek jams along with the music
[15:16] <skaet> jibel,  lets just go through things here.
[15:17] <jibel> skaet, k
[15:17] <skaet> jibel,  how do things look from the smoke tests over last 12 hours?
[15:18] <slangasek> pitti: you mentioned lintian had already been uploaded; so these oversized images *already* have the benefit of that change?
[15:18] <pitti> slangasek: not lintian itself, just aptdaemon
[15:18] <pitti> yes
[15:18] <pitti> dropped some 7 MB
[15:18] <slangasek> oh
[15:19] <jibel> skaet, no failures with the installer (d-i and ubiquity)
[15:19] <jibel> major issues are crashes mainly with unity-2d
[15:19] <pitti> my test runs on i386 (real iron) and amd64 (kvm) also look good
[15:19] <jibel> e.g bug 791213 , bug 791127
[15:19] <ubot4`> Launchpad bug 791213 in unity-2d (Ubuntu) (and 1 other project) "unity-2d-places crashed with SIGSEGV in QMetaObject::metacall() (affects: 3) (dups: 1) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/791213
[15:19] <ubot4`> Launchpad bug 791127 in unity-2d (Ubuntu) (and 1 other project) "unity-2d-places crashed with SIGSEGV in QTJSC::Structure::materializePropertyMap() (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/791127
[15:19] <pitti> jibel: FYI, I installed some debug symbols for that and reported it as bug 791127
[15:20] <pitti> heh
[15:20] <jibel> 2 other very common crashes: bug 788714 , bug 788710
[15:20] <ubot4`> Launchpad bug 788714 in gnome-user-share (Ubuntu) "gnome-user-share crashed with SIGABRT in g_option_context_parse() (affects: 9) (dups: 7) (heat: 76)" [Medium,Confirmed] https://launchpad.net/bugs/788714
[15:20] <ubot4`> Launchpad bug 788710 in gnome-settings-daemon (Ubuntu) "gnome-settings-daemon crashed with SIGSEGV in exit() (affects: 5) (dups: 1) (heat: 36)" [Medium,Confirmed] https://launchpad.net/bugs/788710
[15:21] <jibel> and still 1 report about the udev failure we had yesterday but no confirmation from other testers
[15:21] <jibel> bug 791121
[15:21] <ubot4`> Launchpad bug 791121 in udev (Ubuntu) (and 1 other project) "user dropped into busybox shell after installation (affects: 1) (heat: 8)" [High,Incomplete] https://launchpad.net/bugs/791121
[15:21] <jdstrand> pitti, cjwatson: regarding apparmor/perl: we are in the process of fixing that. mdeslaur is working on it-- he rewrote a tool in python and we need to get it uploaded and iirc, adjust a seed. bottom line, it will be fixed
[15:22] <jibel> coverage is low (61.76%) but we started to test really late
[15:22] <jibel> no coverage at all of ppc and amd64+mac images
[15:22] <pitti> jibel: yay!
[15:22] <jdstrand> pitti, cjwatson: not sure about the status for alpha-1 though (ask mdeslaur)
[15:22] <pitti> jdstrand: I don't think we particularly care about a1 oversizedness
[15:22] <skaet> jibel,  are the unity-2d issues on kvm?  can't tell from a quick glance at the bug.
[15:23] <jdstrand> cool
[15:23] <jibel> upgrades are ok for all flavors (auto-upgrade-testers reports failures, => needs investigation)
[15:23] <skaet> jdstrand, pitti,  - yes, oversize is not blocker on alphas.
[15:23] <pitti> skaet: if you use kvm -vga std or -vga vmware, it works; it's only for the default emulated card (cirrus)
[15:23] <jibel> skaet, yes
[15:23] <pitti> well, FSVO "works"
[15:23] <skaet> pitti,  so there is a workaround then - cool.
[15:23] <pitti> unity-2d crashes if you look at it the wrong way
[15:23] <pitti> but install works
[15:24] <slangasek> pitti: do we think we have a clear path to right-sized images for alpha2?
[15:24] <pitti> slangasek: not there yet :/ we'll get about 5 MB from icons, and 5 MB from switching to live-builder
[15:24] <mdeslaur> pitti, jdstrand: the package is ready now if you want it for alpha-1
[15:24] <jibel> and talking about udev, there's a strange behavior of i386 images on vbox: bug 791139, need someone to confirm.
[15:24] <ubot4`> Launchpad bug 791139 in ubiquity (Ubuntu) "When booting from an ISO, a shell is displayed for 2 min before the graphics environment starts (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/791139
[15:25] <pitti> slangasek: the rest is lots of work in little pieces, like downsizing kernel, etc.
[15:25] <pitti> we have WIs for it, but haven't seen much action on this yet
[15:25] <pitti> slangasek: I'm already happy that we reduced it by 15 MB already
[15:25] <slangasek> we still have an extra python on there that we want to get rid of, but then we also want to add python3, so that's no use to you :)
[15:25] <pitti> right, that should come out as near zero sum, hopefully
[15:26] <slangasek> s/an extra python/python extensions built for a python we don't want/
[15:26] <skaet> jibel, has anyone else been able to reporduce 791121?
[15:27] <jibel> skaet, no, I think that's a pebkac
[15:27] <skaet> jibel,  not worrying about ppc and amd64+mac images for this alpha1 - we'll see if we can get that lined up for alpha 2.
[15:27] <skaet> pebkac??
[15:27] <jibel> http://en.wikipedia.org/wiki/User_error
[15:28] <skaet> jibel,  heh.  :)
[15:28] <skaet> ok,  so sounds like standard ugliness for this point in the cycle, but no real blockers at the moment?
[15:29] <jibel> about other flavors, it will be tested by tomorrow, and waiting for kubuntu.
[15:30] <jibel> no blocker.
[15:30] <jibel> ..
[15:30] <skaet> pitti, jibel, slangasek - net seems to be we're ok with these images,  waiting for kubuntu to land.
[15:30] <skaet> pitti, slangasek - anything we feel *must* get added?
[15:30] <slangasek> pitti: kubuntu alternates seem to be built, shall I post them to the tracker?
[15:31] <pitti> please do
[15:31] <pitti> desktops are building
[15:31] <slangasek> skaet: nothing in there that sounds like an alpha blocker to me, yeah
[15:33] <ScottK> I'm looking for testers now.
[15:33] <skaet> ScottK,  thanks.
[15:33] <jibel> btw list of bugs reported by iso testers: http://reports.qa.ubuntu.com/reports/isotesting/oneiric/opened.html
[15:34] <skaet> slangasek,  jibel, pitti - ok,  sounds like we'll go ahead with the images we've got unless something critical comes up later today.
[15:34] <skaet> https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview
[15:34] <jibel> what about dvds ?
[15:35] <ScottK> Don't worry about dvds for Alpha 1.
[15:35] <jibel> ok
[15:35] <skaet> ScottK,  is that a Kubuntu or general statement?
[15:36] <ScottK> skaet: We don't generally bother with them this early
[15:36] <ScottK> The Kubuntu one I know won't build, but I'd suggest generally not worrying about it.
[15:36] <skaet> ScottK,  ok.
[15:38] <skaet> Ok,  seems like plan forward is:
[15:38] <skaet> 1) continue testing current images
[15:38] <skaet> 2) add Kubuntu as they emerge and test them
[15:38] <skaet> 3) document in the TechOverview the workarounds for the worrisome bugs
[15:39] <skaet> 4) check where we are later today re: bugs, and decide if respin makes sense.
[15:39] <skaet> s/makes sense/essential/ ...   ;)
[15:40] <skaet> slangasek, pitti, ScottK, jibel - anything forgotten?
[15:40] <ScottK> Seems reasonable.
[15:40] <pitti> sounds good to me
[15:40] <pitti> not that we'd actually have a solution for any of the unity-2d or udev problems right now
[15:41]  * skaet nods
[15:41] <ScottK> Also it's pretty normal to have oversize issues in this milestone.  I wouldn't worry much about that.
[15:41] <ScottK> skaet: I need to correct something I said in the last release meeting.  I said we'd have KDE 4.7 beta 1 packaged before Alpha 2.  I need to take that back.  Upstream is waffling about tarball layout for the 4.7 series so we've stepped back a bit to wait and see how it works out.
[15:42] <skaet> ScottK,  understood.
[15:43] <skaet> jibel,  give me a ping towards the end of your day,  and we'll do a quick assessment.
[15:43] <slangasek> skaet: nothing else from me
[15:43] <skaet> If there is anything critical,  we'll regather here to discuss.
[15:43] <jibel> skaet, will do
[15:43] <skaet> slangasek,  pitt, ScottK, jibel   - thanks!!
[15:45] <didrocks> jibel: on bug #791213, it's the merge with debian which brought the regression (seems it was uploaded yesterday). I'm trying to make a dicho an cherry-picked debian patches right now (but qt takes 5 hours and half here to build)
[15:45] <ubot4`> Launchpad bug 791213 in unity-2d (Ubuntu) (and 1 other project) "unity-2d-places crashed with SIGSEGV in QMetaObject::metacall() (affects: 3) (dups: 1) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/791213
[15:45]  * skaet ... heads back to finishing of EOL dapper,  then on to tech overview prep...
[15:47] <jibel> didrocks, good to know that you already found the cause. Thanks!
[15:48] <didrocks> jibel: well, the dicho will take some times (large choice between 15 guilty patches, just trying to pick the right one, but will take time)
[15:54]  * ScottK says +1 on Dapper EOL.
[15:58] <pitti> http://cdimage.ubuntu.com/kubuntu/daily-live/20110601/
[15:58] <pitti> ScottK, slangasek ^
[15:59] <ScottK> Cool.  Thanks.
[16:03] <ScottK> pitti: Once Alpha 1 is done, we made need some help on CD size for Kubuntu.  Debian qt-kde switched from cdbs to dh7 rules so we may have lost some of your shrinking magic.
[16:05] <pitti> ScottK: -> #u-devel?
[16:08] <stgraber> pushed a seed change for edubuntu to include gnome-session-fallback and a new edubuntu-artwork to update our gdm tricks to set it as default
[16:08] <stgraber> in my tests, it's not pretty but it "works" (as in, I can start ubiquity)
[16:09] <pitti> pretty is for post-a1, I'm afraid :/
[16:09] <stgraber> so we'll need a rebuild once the seed change and the new edubuntu-artwork are in the archive
[16:10] <stgraber> highvoltage: ^ just so you know we'll ship with gnome-session-fallback for alpha-1 :)
[16:11] <highvoltage> what's that? gnome 3 fallback mode or a gnome 2 session?
[16:11] <stgraber> gnome 3 fallback
[16:11] <slangasek> pitti: yep, just posted it to the tracker :)
[16:11] <highvoltage> ok
[16:12] <stgraber> highvoltage: in my tests, gnome-classic (our current default) gives you only a blue wallpaper, unity-2d is impossible to use in kvm, unity-3d won't start because of compiz. So that was gnome-session-fallback or using xterm :)
[16:18] <highvoltage> heh, so we were quite close to just completing our kde session eh?
[16:21] <stgraber> actually, it probably would have pulled less packages on the DVD to go with a KDE session :)
[16:21] <highvoltage> yeah I wondered about that :)
[16:22] <highvoltage> but if we did that OMG!ubuntu would probably post something like "OMG Edubuntu switches to KDE by default!"
[16:25] <micahg> skaet: I apologize for being frantic crazy about alpha1, I'm usually not in here until the end of the cycle
[16:27] <skaet> micahg, no worries.  :)   glad to have you around and getting the issues raise up (and dealt with) nice and early in the cycle.
[17:01] <chrisccoulson> micahg, so, bug 790469 will be fixed shortly. not sure if we need to track that in oneiric now though
[17:01] <ubot4`> Launchpad bug 790469 in firefox (Ubuntu Oneiric) (and 2 other projects) "invalid security certificate 11.10 (affects: 4) (dups: 2) (heat: 24)" [High,Triaged] https://launchpad.net/bugs/790469
[17:01] <chrisccoulson> it doesn't require any more action from me :)
[17:08] <smoser> skaet, can you populate tracker with oneiric images: http://uec-images.ubuntu.com/server/oneiric/20110601/
[17:08] <skaet> slangasek, ^^  ?
[17:09]  * skaet dealing with Dapper EOL at the moment...
[17:09]  * slangasek has a look
[17:12] <slangasek> posted
[18:05] <micahg> chrisccoulson: cool, I'll see if I can untrack it
[18:05]  * micahg guesses that's not possible, so moves the milestone forward
[18:08] <slangasek> micahg: "untrack" is marking the release task as 'wontfix' IIRC, which leaves a default non-release-targeted task open in its place; but I think it's fine to have it targeted to the release given that we certainly want it fixed for 11.10...
[18:11] <micahg> slangasek: can you add a transition for me to the transition tracker?
[18:11] <slangasek> micahg: I don't know the answer to that question :-)
[18:12] <slangasek> I haven't seen that I've been added as a member of the committer team; maybe it happened silently
[18:12] <micahg> slangasek: ubuntu-release owns it :)
[18:12] <slangasek> does it own the branch, or just the publishing?
[18:13] <micahg> the team, you commit files to the branch and it's auto published at :55 after
[18:14] <slangasek> ok - what do you need tracked?
[18:14] <micahg> libnotify, I have a .ben file, http://bazaar.launchpad.net/~micahg/+junk/transition-tracker-libnotify-oneiric/view/head:/ubuntu/monitor/libnotify.ben
[18:15] <micahg> the title should probably be libnotify1 -> libnotify4
[18:16] <seb128> micahg, what's the interest to track those there rather than watching NBS?
[18:17] <seb128> I've been pondering asking for the libnotify things to be tracker but since NBS has an updated list I didn't see the point to do it
[18:17] <seb128> tracked
[18:17] <slangasek> seb128: the transition tracker helps figure out build ordering, for one thing
[18:18] <seb128> well there is no order in this case
[18:18] <micahg> seb128: hmm, I figured since it's a transition it should go in the transition tracker, I guess it's true that NBS has the info
[18:18] <slangasek> micahg: committed
[18:18] <micahg> slangasek: thanks
[18:18] <seb128> micahg, well the question is me trying to figure what the transition tracker provide
[18:18] <seb128> should every soname change go there?
[18:18] <seb128> if it does can we automate that?
[18:19] <seb128> it doesn't seem to make sense to have to track sonames update manually to add them
[18:19] <micahg> well, anything that requires a bit of coordination IMHO should go in the transition tracker, I saw about 30+ rdepends for libnotify and figured it was a good candidate
[18:19] <micahg> but I'm just a happy contributor
[18:20] <slangasek> for the moment, I'm happy to have the tracker track those things that developers want tracked
[18:21] <slangasek> automatically tracking every soname change would be too much, at least until we have an index page...
[18:21] <seb128> ok, I think I just don't see the point for libnotify
[18:21] <seb128> but if it's useful to other people
[18:21] <seb128> I've been using the NBS list for it and it does the job
[18:24] <micahg> seb128: ah, the advantage is that it shows build-depends issues as well, not just binary
[18:24] <micahg> so, libnotify4-dev > libnotify-dev
[18:26] <seb128> ok
[18:32] <skaet> micahg,  slangasek -   FYI.  there will be some info on the transition tracker and how to add to it in the release notes tomorrow courtesy of Laney.  :)    I agree if we could get index into place (completed, active? transitions) it would help.
[18:34] <Laney> micahg: could you have come up with an is_good line there? :-) .depends ~ /libnotify4/ or similar?
[18:35] <micahg> Laney: maybe, I didn't check to see if that always happens
[18:37] <Laney> I'd prefer we have them in general as an extra check (I know I'm guilty of missing it out for boost though)
[18:37] <micahg> Laney: boost was my model :)
[18:37] <micahg> Laney: does it just show unknown if it doesn't match the good string?
[18:38] <Laney> yeah, unknown is "affected and neither good or bad"
[18:38] <micahg> Laney: k, I can prepare another merge then
[18:38] <Laney> cool
[18:42] <micahg> Laney: BTW, if there was an actual project, we could propose actual merges :)
[18:42] <Laney> I didn't know you couldn't propose merges against normal branches
[18:43] <micahg> Laney: maybe it's an LP bug, here's my new branch BTW, https://code.launchpad.net/~micahg/%2Bjunk/transition-tracker/
[18:43] <Laney> ty
[18:44] <Laney> can always tweak it later if that turns out to be insufficient
[18:53] <ScottK> The tracker helps for stuff that's not yet NBS.  See for an example.
[18:53] <ScottK> sdee http://people.canonical.com/~ubuntu-archive/transitions/boost1.46.html
[18:53] <ScottK> sdee/see
[18:53]  * ScottK should just eat lunch and quit trying to eat and IRC.
[19:27] <micahg> Laney: can you pull in another revision please? https://code.launchpad.net/~micahg/%2Bjunk/transition-tracker/ (affected was too broad)
[19:35] <ScottK> skaet, slangasek, whoever: bug 791487 may be a bit of a showstopper for Kubuntu (investigating).  If we can get a fix, can we have a Ubiquity upload?
[19:35] <ubot4`> Launchpad bug 791487 in ubiquity (Ubuntu) "Kubuntu crashed during installation from Live Desktop (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/791487
[19:35] <slangasek> no objection here; skaet ?
[19:36] <elmo> skaet: we're going to get and/or have an RT about dapper, right?
[19:36] <elmo> skaet: specifically moving it off archive/ports/security/releases
[19:37] <Laney> micahg: done
[19:37] <micahg> Laney: thanks
[19:37] <skaet> elmo,  can send an RT if you want it done that way.
[19:38] <elmo> skaet: well - someone needs to send one for it to happen ;-)  if you don't want to for some reason, I can
[19:38] <skaet> elmo,  thanks.   Will update the process to make it explicit in future.
[19:39] <skaet> ScottK,  just respin the Kubuntu ones?   or will all the images need respinning?
[19:39] <slangasek> skaet: if there's time to test, it would be better to respin all desktop images
[19:39] <ScottK> Depends on if you care about Ubiquity being out of date on the Ubuntu and related images
[19:39] <slangasek> so we get assurance that the fix doesn't regress !kubuntu
[19:40] <skaet> jibel, ^^  do you have time to do a full retest, if they can get a fix in?
[19:40] <slangasek> I don't think we should care about out-of-dateness per se, though, so if the code change is isolated to the kubuntu ubiquity frontend, we could forgo it
[19:40] <ScottK> maco is looking to see if she can fix it, but I don't have an ETA.
[19:40] <ScottK> I don't think it is.
[19:40] <ScottK> The bug is caused by Ubiquity trying to speak gtk to Qt.
[19:40] <maco> its in ubi-prepare.py
[19:41] <skaet> ScottK,  ok,   will stay with what we have until we know a fix is ready,  then decide.
[19:42] <ScottK> Apparently it's easy to reproduce (as in can't avoid it).
[19:43] <skaet> :(
[19:49] <GrueMaster> Speaking of respins, I may need a respin of preinstalled netbook for omap.  Headless as well, but less critical.  It appears that usb is completely broken.  No keyboard/mouse or ethernet.
[19:50] <GrueMaster> I'm booting headless now to see if I can see what is wrong.  If it is a kernel config option, easy fix.  Otherwise I will have to fail the netbook image.
[19:50]  * slangasek nods
[19:58] <jibel> skaet, when would the new images be available ?
[19:59] <stgraber> slangasek, skaet: Apparently Edubuntu is ready for a rebuild (edubuntu-live just got published)
[19:59] <skaet> jibel,  not known right now,   see comments from ScottK ^^
[20:00] <jibel> I need ~3 to 4 hours to replay all tests on all desktop images
[20:00] <slangasek> stgraber: ok, scheduled
[20:00] <stgraber> thanks
[20:00] <skaet> thanks slangasek
[20:01] <slangasek> skaet: fallback option could be to release the existing !kubuntu desktop images with the previous ubiquity, but still go through the QA process on the images that include the ubiquity revved for kubuntu so that we get our regression-test and don't have any time pressure
[20:01] <maco> either charlie or john the taco is testing a patch now, i think
[20:02] <skaet> slangasek,  seems reasonable.
[20:05] <ScottK> slangasek: The live Kubuntu images really aren't releasable I don't think.
[20:05] <ScottK> As long as we test the patch in a gtk session, I think the regression risk is low.
[20:05] <slangasek> ScottK: I'm assuming they will be after a ubiquity fix is available
[20:05] <maco> assuming charlie doesnt find more bugs :)
[20:06] <ScottK> We have a draft patch.  The real question is as maco says.  Now that we peel this layer of the onion, how many are left.
[20:07] <charlie-tca> I might have typed wrong. ubi-console-setup crashed
[20:08] <charlie-tca> exit code 141
[20:08] <charlie-tca> going check my patch
[20:13] <jibel> maco, dinner is over, I'm available for testing, where can I get the patch ?
[20:14] <maco> jibel: http://paste.ubuntu.com/616043/ apply to /usr/lib/ubiquity/plugins/ubi-prepare.py
[20:14] <jibel> maco, thanks
[20:18] <maco> jibel: john the taco says the patch worked for that part, but he hit the same farther-along bug charlie-tca did
[20:19] <jibel> yup running with -d
[20:22] <jibel> maco, http://paste.ubuntu.com/616060/
[20:22] <maco> jibel: i think they only tested in kubuntu though. so do have to be sure it doesnt break ubuntu
[20:22] <jibel> pb with keyboard layout
[20:23] <jibel> testing ubuntu in parallel
[20:24] <maco> thanks jibel
[20:24]  * ScottK wonders how sharp slangasek's debconf foo is.
[20:24] <ScottK> slangasek: Any thoughts on jibel's pastebin?
[20:25] <slangasek> hum, looking
[20:27] <maco> oh wow, PageGtk and PageKde handle getting the list of countries for the kbd WAY differently
[20:27] <GrueMaster> Hmmm.  Need to figure out how to file a bug on the omap3 kernel usb failure with no keyboard and no apport in the headless image.
[20:29] <stgraber> GrueMaster: just a thought, can't you: 1) mount the sdcard on a laptop 2) install apport on it 3) boot it 4) remove the sdcard again 5) grab /var/crash/* ?
[20:30] <GrueMaster> Would be nice if it was the same arch.
[20:30] <GrueMaster> I'm working it through my babbage3.
[20:30] <ScottK> No ssh?
[20:30] <stgraber> yeah, you'd need to copy /usr/bin/qemu-arm-static to the sdcard too before doing a chroot if you do it from x86
[20:30] <stgraber> ScottK: my guess is that the NIC is usb too :)
[20:31] <ScottK> That would complicate things.
[20:31] <slangasek> ScottK: aside from the EPERM on /var/cache/debconf/passwords.dat, which doesn't make sense to me unless debconf is running as the wrong user, I don't see anything amiss with the actual debconf output
[20:31] <ScottK> maco: ^^^
[20:31] <ScottK> slangasek: Thanks.
[20:32] <maco> the stacktrace from jibel shows that its not finding France in the keyboard_names thing
[20:32] <maco> at least, thats what i think it shows ;)
[20:33] <maco> hmm it shows in line 833 of his pastebin
[20:33] <slangasek> GrueMaster: qemu
[20:33] <slangasek> GrueMaster: qemu-arm-static is surely a better option than /usr/lib/apt/methods/zmodem
[20:34] <GrueMaster> I'm using chroot on babbage3.
[20:35] <GrueMaster> Works better than qemu.
[20:35] <slangasek> maco: so the actual backtrace is because keyboard_names.lang[l]['layouts'] doesn't contain the key u'France', AFAICS
[20:35] <maco> right thats what i thought
[20:36] <slangasek> so where does keyboard_names etc. come from?
[20:36] <jibel> maco, your patch breaks ubiquity in ubuntu
[20:37] <jibel> it skips partman step
[20:37] <maco> jibel: crap. can you add "print type(self.prepare_download_updates)"  right before the first if to findo ut what *should* go in the quotes?
[20:37] <maco> (or whatever that variable name is in case im retyping it wrong)
[20:38] <maco> hm i guess youd have to comment the if's out too
[20:38] <maco> to get it to run that print
[20:39] <slangasek> fwiw, I would think the right way to fix the ubi-prepare bit would be to have prepare_download_updates subclass GtkCheckButton / QCheckBox as needed and provide a common method
[20:40] <slangasek> I think this is already being done in ubiquity/gtkwidgets.py, ubiquity/qtwidgets.py for classes such as StateBox
[20:41] <maco> that would probably be less hacky, yeah
[20:44] <maco> im confused
[20:45] <slangasek> where at?
[20:45] <maco> oh nvm. keyboard_names comes from d-i/source/console-setup/Keyboard/MyKeyboardNames.pl apparently. keyboard_names.py is built from it
[20:47] <slangasek> is language set to C in this context?
[20:47] <slangasek> ah, here we go; it's France vs. French
[20:48] <slangasek> is this an API change in d-i?
[20:50] <maco> so should i just subclass QCheckBox and give it set_sensitive() and set_active() just like gtk has?
[20:50] <maco> (and then of course set the .ui file to use my new subclass instead)
[20:50] <slangasek> in a nutshell, yes
[20:50] <slangasek> is set_sensitive needed for QCheckBox?
[20:51] <slangasek> er
[20:51] <slangasek> set_active, I mean
[20:51] <maco> Gtk has those 2 and QCheckBox doesn't. both are used in ubi-prepare.py
[20:51] <slangasek> oh, of course it is, those are the two exact methods being called
[20:51] <slangasek> yeah, ignore me, I'm losing track of method names
[20:53] <maco> get_active is also used, so will do that one too
[20:56] <maco> http://paste.ubuntu.com/616084/
[20:56] <slangasek> looks good to me
[20:56] <slangasek> also happens to mean we're not touching the common code, so Ubuntu should be fine :)
[20:57] <maco> yep
[20:57] <slangasek> the same applies to the prepare_nonfree_software QCheckBox, FWIW
[20:58] <slangasek> for that we have set_active(), set_property() being called
[20:58] <slangasek> + get_active()
[20:58] <slangasek> oh, that may be in a Gtk-specific class though
[20:58] <slangasek> yeah, that's all done in PageGtk
[20:59] <maco> ok
[21:00] <slangasek> so, hmm, maybe I've steered you wrong to suggest subclassing QCheckBox; it looks like the more conventional approach here is to override check_returncode() in PageKDE
[21:00] <slangasek> set_download_updates() and get_download_updates() are already done that way
[21:01] <slangasek> well, honestly though, check_returncode() is an awful lot of non-ui-specific code to duplicate
[21:02] <maco> set_download_updates is def'd after check_returncode, not inside it
[21:02] <slangasek> yep, that's not actually a problem
[21:03] <maco> i dont really know what check_returncode is doing
[21:03] <slangasek> the method definition exists by the time check_returncode() is called, so it would be fine for it to refer to set_download_updates() despite being defined later
[21:04] <slangasek> so I think what we want is for check_returncode to call set_download_updates() instead of set_active(), and maybe we need a new method defined to abstract self.prepare_download_updates.set_sensitive
[21:04] <maco> oh. i was looking at teh *other* check_returncode definition. there are two in that file.
[21:05]  * slangasek facepalms
[21:05] <maco> this code reminds me a bit of italian food
[21:06] <slangasek> so PageKde.check_returncode() calls the PreparePageBase.check_returncode(), then does some extra kde-specific handling
[21:06] <slangasek> the problem being that PreparePageBase.check_returncode() is not UI-independent
[21:07] <maco> i think the subclassing of QCheckBox seems somewhat less like spaghetti than adding more overrides scattered throughout this file
[21:08] <slangasek> I'm inclined to agree, but it does defy the existing convention in the code so I'd be reluctant to upload that change without signoff from the ubiquity maintainers
[21:08] <jibel> maco, http://paste.ubuntu.com/616092/ with patch http://paste.ubuntu.com/616084/ applied
[21:09] <maco> jibel: it has to berebuilt for changes to the .ui file to have an effect
[21:09] <maco> qt doesnt use .ui files straight. it has a ui->py compiler
[21:10] <slangasek> maco: well, QCheckBox also needs to be added to the import line at the top of ubiquity/qtwidgets.py
[21:10] <slangasek> jibel: ^^
[21:10] <jibel> maco, ok, how do I recompile a ui file ?
[21:10] <maco> slangasek: oh so it does
[21:13] <maco> using pykdeuic4 or pyuic4....grepping for how the ubiquity build process calls it
[21:13] <jibel> slangasek, thanks, much better with an import.
[21:15] <maco> oh, did that work without redoing the ui->py thing?
[21:16] <maco> oh, kde_ui.py import uic, so maybe it could do it
[21:18] <jibel> maco, there's no more prepare step
[21:19] <maco> with what applied?
[21:19] <stgraber> slangasek: hmm, from what I see from the logs the Edubuntu rebuilt is 20110601.1 but so is our current build :) It apparently ended up overwritting the previous build logs, not sure what will happen on cdimage.u.c
[21:19] <jibel> http://paste.ubuntu.com/616084/ + import QCheckBox
[21:19] <slangasek> stgraber: it's not done building yet
[21:20] <slangasek> stgraber: are you saying that the livefs build logs were overwritten?
[21:20] <slangasek> oh wait
[21:20] <slangasek> no
[21:20] <slangasek> so the 20110601.1 ISO build includes the 20110601 livefs build
[21:20] <slangasek> the 20110601.1 livefs build will go into 20110601.2 ISO... or if there's a mirror sync problem again, 20110601.3
[21:21] <slangasek> (the 2011601.1 was an ISO-only respin because antimony's mirror was out of sync again)
[21:21] <stgraber> ah, ok, so we'll get 20110601.2 with the 20110601.1 livefs :) not confusing at all ;)
[21:21] <maco> jibel: and without the previous patch that had the if type() stuff
[21:21] <maco> ?
[21:22] <stgraber> anyway, good to know everything works as expected. /me goes back to waiting for 20110601.2 to show up on cdimage.u.c
[21:23] <jibel> maco, yes, and then another exit 141 when entering the keyboard step
[21:23] <maco> jibel: slangasek is working on the 141 thing i think.
[21:23] <maco> slangasek: is there anything like "perl -c" for python?
[21:24] <slangasek> I've never heard of -c, what's that?
[21:24] <maco> jibel: or at least he figured out it was France v. French...and it sounds like it's in d-i itself, not ubiquity
[21:24] <maco> slangasek: syntax check
[21:24] <maco> ot
[21:24] <maco> baj
[21:24] <maco> technically its for "compile" but...eh...
[21:25] <slangasek> ah; no idea
[21:26] <ScottK> Don't think there is.
[21:28] <slangasek> console-setup itself hasn't changed since natty
[21:34] <maco> the thing where it skips over broken pages instead of letting you debug them is annoying
[21:34] <maco> jibel: any debug info anywhere? /var/log/installer maybe?
[21:52] <slangasek> jibel: was the keyboard layout crash only reproducible with kubuntu?
[21:55] <jibel> slangasek, yes.
[21:55] <jibel> maco, http://people.canonical.com/~j-lallement/junk/installer.tgz
[21:56] <jibel> cjwatson, fixed a similar issue during natty
[21:56] <maco> slangasek: the gtk version doesnt, afaict, use keyboard_names at all
[21:57] <slangasek> well, doh
[22:02] <maco> jibel: on pubi-prepare.py line 198, says
[22:02] <maco> from ubiquity.qtwidgets import StateBox
[22:02] <maco> make that   StateBox, CheckBox
[22:04] <maco> *ubi-prepare.py
[22:04] <maco> new wrist/hand braces, feels like relearning to type a bit
[22:09] <slangasek> so the generated keyboard_names.py is completely different between natty and oneiric, despite console-setup being at the same version
[22:13] <slangasek> ah, but xkb-data is not at the same version
[22:14] <slangasek> yep, deliberate upstream change in xkb-data, sigh
[22:15] <slangasek> -            <_description>France - Breton</_description>
[22:15] <slangasek> +            <_description>French (Breton)</_description>
[22:15] <slangasek> -            <_description>France - Occitan</_description>
[22:15] <slangasek> +            <_description>French (Occitan)</_description>
[22:16] <slangasek> this under the justification "description fixes that make the layout configuration correspond more closely to language and script instead of national boundaries." :P
[23:39] <slangasek> maco, ScottK: I can offer no quick fix for the keyboard problem; I think the xkb-data upstream changes are probably wrong, but also not easy to revert; and I don't particularly understand the gtk code so don't imagine I can translate that for KDE
[23:51] <ScottK> OK.
[23:51]  * ScottK hopes maco will have it solved soon then.
[23:51] <ScottK> I guess if we have to we can release note "Use live if you want to play with it, use alternate if you want to install".