[00:01] <slangasek> so... someone's throwing back armel build failures until they stick?
[00:01] <ScottK> slangasek: lamont threw back the entire stack last night.
[00:01] <Laney> lamont did a mass give-back las... yeah
[00:01] <slangasek> it's been more than once
[00:01] <slangasek> I've gotten two mails each for all my failed uploads in the past two days
[00:02] <ScottK> Hmmm.  I don't think so.
[00:02] <ScottK> I only got one.
[00:02] <slangasek> ah; then maybe a subset
[00:03] <ScottK> One for the original failure and another for the give back or two extras?
[00:03] <slangasek> the original failure was months ago - I got two build attempts of, e.g., 'imview' in the past two days
[00:03] <ScottK> slangasek: Would you please source accept ibid from New.  The LP U/I is being unhelpful.
[00:03] <slangasek> looking
[00:04] <slangasek> is it unhappy because 'ibid' is a substring of 'python-pyfribidi'?
[00:04] <ScottK> I don't think so.
[00:04] <slangasek> accepted
[00:04] <ScottK> I get a "you are not allowed here" error.
[00:04] <slangasek> doh
[00:04] <ScottK> It happens every now and then, usually for reasons that aren't clear.
[00:05] <ScottK> One known cause is if a package I try to accept fixes a private bug I don't have access too, but that's not he case ehre.
[00:05] <ScottK> here even
[00:06] <slangasek> heh, wacky
[00:12] <doko_> slangasek: now uploaded all packages which are statically linked according to the package name/description
[00:13] <slangasek> ah
[00:18] <ScottK> slangasek: A couple more syncs when you have a moment: http://paste.debian.net/69637/  We also want the new ipplan (0.92a), but I think it's still in incoming (see 565781)
[00:18] <slangasek> we'll see how many of those we get to; I'll definitely be leaving some space in the build queue for emergency blocker builds
[00:18] <slangasek> ScottK: ok, will look
[00:28] <cjwatson> slangasek: yes, both gfxboot-theme-ubuntu and d-i I think
[00:29]  * cjwatson goes for a late-night poke at those
[00:29] <slangasek> ta
[00:29] <cjwatson> "There are 142 file requests on the export queue".  Hmm
[00:30] <cjwatson> tomorrow morning would be inconvenient, right?
[00:31] <slangasek> yeah. can you give me instructions I could follow to do it myself tonight?
[00:33] <cjwatson> nah, I'll just stay up a bit
[00:33] <cjwatson> not quite sleepy yet anyway
[00:33] <cjwatson> my scripts are a bit finicky ...
[00:34] <slangasek> ok
[00:35] <cjwatson> have been up late looking over the rather ... unusual state of UK politics at the moment :)
[00:38] <slangasek> xserver-xorg-video-geode reviewed, follow-up question sent to Q-FUNK
[00:38] <slangasek> oh?  what's the unusual part?
[00:38] <cjwatson> third party (the one I happen to support) surging by something like 15% in at least some polls
[00:39] <slangasek> oh, huh
[00:39] <cjwatson> less in others but it appears to be statistically significant across the board
[00:39] <cjwatson> interesting times ahead given that we have an election right before UDS :)
[00:39] <slangasek> hurray for free TV exposure
[00:39] <cjwatson> which I'll have to proxy-vote in, boo
[00:40] <cjwatson> ah, here come the translation tarball mails
[00:40] <cjwatson> haven't made any traction yet on sbeattie's worrying partitioning bug, btw - I'll have to attack that tomorrow and possibly fix it post-rc :-/
[00:41] <cjwatson> I followed through all the maths in the code and couldn't find an error
[00:41]  * slangasek nods
[00:41] <cjwatson> oh, meep, and I promised Mark I'd change the CD boot splash branding
[00:42] <cjwatson> so I mentioned in the release meeting that the design team had asked to blank the splash screen, as they were upset about the distortion evident on some systems (gfxboot doesn't know about widescreen etc.)
[00:42] <cjwatson> I was alarmed about getting rid of the bottom icons (the rebus for "press a key") and clarified with Mark on Friday evening
[00:43] <slangasek> "blank the splash screen" - urk, hadn't understood that from the meeting
[00:43] <cjwatson> he wants the logo gone from the CD boot splash (i.e. gfxboot - plymouth stays as it is) but is fine with the icons remaining
[00:43] <slangasek> ok
[00:44] <cjwatson> I'll mail ubuntu-doc, they're bound to have screenshotted it but it should be very easy to redo
[00:44] <slangasek> yes, with gimp and the rectangle tool ;)
[00:44] <cjwatson> not really happy about this being announced two weweks out, but at least it is easy to deal with
[00:45] <cjwatson> ooh, cute transliteration of Xubuntu in Bulgarian
[00:45] <cjwatson> -msgstr "^Инсталиране на Xubuntu"
[00:45] <cjwatson> +msgstr "^Инсталиране на Ксубунту"
[00:45] <slangasek> Ksubuntu!
[00:45] <cjwatson> nice digraph
[00:46] <slangasek> they could've just gone with Chubuntu... :)
[00:46] <ScottK> You could ask Mark to review the time zone map again if you're short on last minute crises.
[00:46] <ScottK> ;-)
[00:46] <cjwatson> argh
[00:47]  * cjwatson remembers he needs to update the d-i translations first, *then* regenerate gfxboot-theme-ubuntu's font
[00:47] <cjwatson> ordering ...
[00:47] <cjwatson> one of these days I'll document all this
[00:49]  * cjwatson wonders if he should remove the Kubuntu splash too
[00:49] <cjwatson> I'm thinking just the one that was explicitly requested, i.e. Ubuntu
[00:50] <cjwatson> but that requires a g-t-u code change
[00:51] <ScottK> There's an open bug about updating it for Kubuntu to match the new branding, so going away would solve that.
[00:59] <cjwatson> Riddell already dealt with that bug though
[01:01] <ScottK> Oh, OK.
[01:05] <Riddell> cjwatson: the Kubuntu splash is different though because we still have the menu items showing
[01:06] <cjwatson> oh that's right, you aren't using the hidden-timeout mode
[01:06] <cjwatson> Mythbuntu is though
[01:07] <cjwatson> I can probably come up with a plan
[01:08] <Riddell> consulting on hidden-timeout with seele is still on my todo, guess it'll roll over to UDS
[01:10] <cjwatson> no rush from my end
[01:22] <cjwatson> ok, that worked fine
[01:29] <cjwatson> Riddell: to some extent, making it not a crazy hack for maverick is on hold until I decide whether to throw the whole lot away and move to grub
[01:43] <cjwatson> slangasek: I've uploaded all the translation changes etc.; I've also committed and deployed the debian-cd changes for the CD splash thing on the basis that they're a no-op without gfxboot-theme-ubuntu 0.9.9
[01:44] <cjwatson> slangasek: I'm going to go to bed shortly, so if you need to back anything out or fix anything or whatever, everything's in bzr
[01:45]  * cjwatson looks at his mirror job and wonders idly if mrpt-doc is really useful enough to justify its enormous size
[01:46] <cjwatson> sort of looks like a "Debian maintainer has too much bandwidth" case
[01:49] <cjwatson> anyone know what happened to language-pack-gv{,-base}, and why the gnome language packs for gv exist without them?
[01:49] <cjwatson> not in NEW ...
[01:50] <slangasek> nope - just pinged ArneGoetje and pitti on -devel about it
[02:21] <slangasek> cjwatson: what do these build/Makefile changes have to do with amd64/netboot-xen?  looks like a miscommit to me...
[02:22] <slangasek> cjwatson: n/m, found
[02:27] <stgraber> slangasek: Edubuntu is failing to build due to issues with the -gv langpacks. Poked ArneGoetje about it and it seems like the language pack itself was removed from the archive but not the -gnome and -support with both still depending on the langpack and so making our build to fail.
[02:28] <stgraber> (as we install all -gnome, -kde, -base and -support in the live environment)
[02:28] <slangasek> stgraber: already sorted on #ubuntu-devel; next builds will succeed
[02:28] <stgraber> ok ;) I guess my laptop isn't up to date then as it still shows -support and -gnome in the archive :)
[02:29] <stgraber> slangasek: can you trigger a rebuild once the archive is clean, either later tonight or tomorrow as our 20100419 build already failed ?
[02:30] <slangasek> -gnome was removed 20 minutes ago, so the change won't be published for another hour; -support only suggests: the language pack, not depends
[02:30] <slangasek> "later tonight", yes - I'll be starting the RC mastering tonight
[02:30] <stgraber> great
[02:32] <stgraber> I guess langpacks really were the biggest source of build failure for Edubuntu this cycle (though shortly followed by my LTSP live environment ;)). Seems like it's hard to have all the langpacks installed at the same time ...
[02:35] <ScottK> slangasek: Next layer of perl MIR bugs is done.  Would you please pre-promote libexception-class-perl libb-keywords-per perltidy libreadonly-perl libreadonly-xs-perl libpod-spell-perl libfile-which-perl libstring-format-perl libfile-homedir-perl
[02:36] <slangasek> ScottK: done
[02:36] <ScottK> Thanks.
[02:37] <ScottK> We'll know in ~70 minutes if that was it.
[02:37] <ScottK> Every single one of that batch had an existing MIR that just had to be resurrected.
[02:38] <slangasek> convenient
[02:38] <ScottK> Yep
[04:30] <ScottK> slangasek: Two more under that stuck.  MIRs resurrected for libclass-data-inheritable-perl libdevel-stacktrace-perl - would you please pre-promote those too?
[04:30] <slangasek> done
[04:30] <ScottK> Thanks.  With that, I think I'm off to bed.
[04:31] <slangasek> ok, 'night
[04:56] <slangasek> doko__: are syncs to the partner repo actually possible?
[07:13] <pitti> ScottK: ugh, so many new perl MIRs? the fun thing is, you submitted a ton of MIRs which aren't necessary according to http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, but c-m has two perl modules which don't have MIRs..
[07:14] <ara> morning all
[07:17] <pitti> hey ara, how are you?
[07:17] <ara> hey pitti, a bit sleepy, but doing fine :-)
[07:17] <ara> pitti, yourself?
[07:18] <pitti> ara: I'm great, thanks; had a really nice weekend
[07:18] <ara> pitti, nice :)
[07:18] <pitti> go-kart race and big party on Saturday, and enjoying the nice sun yesterday
[07:19] <ara> pitti, wow, it sounds like a really nice weekend
[07:21] <slangasek> pitti: they're all necessary, component-mismatches just doesn't show them because I've been pre-promoting in order to get builds done
[07:21] <pitti> slangasek: ah, thanks
[07:21] <slangasek> and it looks like we're *still* missing two more, for libperl-critic-perl build-deps, sigh
[07:22] <pitti> slangasek: I just added tasks for them
[07:22] <slangasek> cheers
[07:22] <pitti> I'll review them together with the other bunch
[07:25] <slangasek> ScottK: did you find out what we're meant to do with kde-l10n-sv?
[07:26] <slangasek> FWIW, ISO mastering will be ready to start after the next publishing cycle (had to fix a d-i FTBFS on i386, I had demoted -generic-pae udebs because of component-mismatches, oops)
[07:28] <pitti> slangasek: the -gv langpacks are sorted out now?
[07:28] <slangasek> yep, seems they were empty - removed at ArneGoetje's request
[07:30] <slangasek> we really ought to have a mountall upload for bug #553290 before RC, but a) we need to back out the change for bug #559761 from bzr unless Keybuk has come up with a fix for the bug in my plymouth patch that this tickles, b) I don't know if he's gotten any other feedback on his ppa test except for mine, or if he's expecting any
[07:42] <slangasek> pitti: what's your gut feeling on taking ttf-takao-pgothic in for RC?  I can have it uploaded within the hour, if you're willing to push it through NEW
[07:43] <pitti> slangasek: I thought that would also require a package split in ttf-vlgothic?
[07:43] <pitti> slangasek: I'm fine for a quick NEWing if you still want to push it through
[07:44] <slangasek> pitti: ttf-vlgothic is a different font; takao-gothic is the new one that ArneGoetje says we should be using in its place
[07:44] <pitti> ah, right
[07:45] <pitti> slangasek: that'd be great, this would complete this bug/spec
[07:55] <slangasek> pitti: ttf-takao uploaded
[07:58] <pitti> slangasek: ok, should hit the queue in 2 mins, will review then
[08:06] <slangasek> if we do take the ttf-takao switch, that means another round of metapackage uploads, which "buys" us another publishing cycle before ISO mastering begins
[08:06] <slangasek> so I'm going to look at getting mountall fixed in that window
[08:08] <slangasek> pitti: and the vlgothic -> takao-pgothic switch saves us 600k packed, 1.5M unpacked; which appears to be enough to let us seed ttf-khmeros-core (220k), and fully complete the spec.  Is that ok with you?
[08:13]  * ogra wonders why his ubiquity changes dont show up in the changelog for 2.2.18
[08:15] <ogra> ugh, they dont even show up in http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/changes
[08:15]  * ogra wonders why ... i'm sure i pushed
[08:17] <ogra> argh ... /me glares at https://code.edge.launchpad.net/~ogra/ubiquity/trunk and curses
[08:17] <ogra> oh noes ... i pushed to an old branch
[08:18] <ogra> slangasek, i'm ashamed to ask, but is there any chance to get http://bazaar.launchpad.net/~ogra/ubiquity/trunk/revision/4081 merged before release ?
[08:18] <pitti> slangasek: absolutely, yes
[08:18]  * ogra feels really dumb now
[08:19] <pitti> slangasek: ttf-takao source-NEWed
[08:19] <slangasek> ogra: ehm, so current ubiquity can't actually install omap?
[08:19]  * pitti will watch builds and binary-NEW
[08:19] <ogra> slangasek, yes, d-i should be able to though since the last rebuild
[08:19] <ogra> (havent tested yet)
[08:19] <slangasek> ogra: ok; please commit that change to the right branch, and upload it now
[08:20] <ogra> slangasek, thanks a lot ... thats really embarassing
[08:20] <slangasek> "now" meaning "within the next 20 minutes"
[08:20] <ogra> yes, ding it now
[08:20] <ogra> *doing
[08:22] <ogra> sigh, if LP would stop timing out on me that would help
[08:23] <slangasek> pitti: thanks for the source NEW - I've also uploaded mountall, the changes are Keybuk's and I've already reviewed and tested them myself, but I would prefer another set of eyeballs if you don't mind
[08:23] <ogra> slangasek, meh, i know why my branch setup was wrong, i apparently cant upload to ubiquity trunk (though i'm in the installer team for d-i casper etc)
[08:24] <slangasek> ah
[08:24]  * ogra wonders ifg cjwatson is awake to approve him for the right team
[08:24] <slangasek> in the meantime, please upload
[08:24] <slangasek> and push a merge request in parallel
[08:25] <ogra> ok, i need to fiddles with the changelog first, one sec.
[08:25] <ogra> -s
[08:28] <ogra> crap ... there is an additional change from ev in the trunk branch
[08:28] <ogra> for bug #563309 apparently
[08:29] <ogra> i guess i need to talk to ev first :/
[08:29] <ogra> looks safe but i dont want to upload without his approval
[08:30] <slangasek> please just upload your fix, then
[08:30] <pitti> slangasek: takao binNEWed (to main)
[08:30] <slangasek> we can sort out the paperwork afterwards
[08:30] <slangasek> pitti: thanks
[08:30] <ogra> ok
[08:36] <pitti> slangasek: heh, you beat me to committing the seed change by a couple of secs :)
[08:37] <slangasek> whoo I won \o/
[08:39] <slangasek> ok, afk for a bit
[08:45] <ogra> slangasek, uploaded
[08:58] <slangasek> pitti: do you think you can review mountall?
[08:58] <slangasek> I have the publisher on manual so we can grab the rest of these fixes in a single publisher run
[09:16] <pitti> slangasek: I don't quite understand the "Don't run fsck while there's an uncleared error on the filesystem" part
[09:16] <pitti> are those uncleared errors only set by fsck itself? (i. e. it runs the first time, but then avoids a loop)
[09:17] <pitti> i. e. would an unclean shutdown not count as an "uncleared error"?
[09:17] <slangasek> https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/501801/comments/8 is the explanation, I believe
[09:17] <ev> pitti, slangasek: I've uploaded a fix for bug 563309 as ubiquity 2.2.19 in case we have enough time to squeeze it in.
[09:18] <slangasek> ev: midair collision - ogra already uploaded a 2.2.19 containing the changes to support armel+omap, but he didn't have commit rights on the branch and wasn't sure enough of your change to upload it himself
[09:18] <slangasek> ev: can you merge and reupload as .20?
[09:18] <ev> slangasek: will do
[09:19] <slangasek> blah, metapackage updates take too long
[09:21] <wgrant> slangasek: Why? because the task changes take two cycles to propogate?
[09:21] <pitti> slangasek: so if you are sure about the fsck thing, it looks fine to me otherwise
[09:22] <slangasek> wgrant: because downloading package files from the canonical<heehee> source takes too long
[09:22] <slangasek> pitti: I haven't personally vetted that code, but Keybuk is confident in it, and user feedback indicates that it fixes the worst problems...
[09:22] <pitti> ok, thanks
[09:23] <pitti> slangasek: I can take a -meta update/upload if you want me to?
[09:23] <pitti> slangasek: which one are you currently building?
[09:24] <slangasek> pitti: I have all but one of them done now
[09:24] <slangasek> (also, I'm hand-hacking a bit since ttf-takao-pgothic binaries aren't really in the archive yet)
[09:24]  * pitti thought ttf-takao would need to get published first
[09:24] <pitti> ah, heh :)
[09:25] <ev> slangasek: done
[09:26] <pitti> slangasek: for the "disable file a bug menu entry", "disable apport" and "disable kerneloops" changes, should we do them after RC? or for RC? (in the past we did them right after)
[09:28] <slangasek> pitti: I seem to always be eager to change apport before you, both disabling and enabling. :)  I'm ok with doing it after RC if you think that's best
[09:30] <pitti> slangasek: oh, I'm fine with doing the uploads now
[09:30] <pitti> we have enough crash reports now, anyway :)
[09:30] <pitti> in fact I'd prefer disabling it in the RC as well
[09:31] <pitti> slangasek: launchpad-integration change is uploaded now; having that in the RC would be nice
[09:31] <slangasek> ok
[09:32] <slangasek> I'll review that and ubiquity, you can review *-meta :)
[09:32] <pitti> since that's the first time that we do that change
[09:32] <pitti> ack
[09:32]  * pitti prepares apport and kerneloops uploads
[09:36] <pitti> slangasek: apport and kerneloops uploaded
[09:37] <slangasek> pitti: you say this lpi change isn't one we've made previously at release?  Do we have to worry about this invalidating documentations?
[09:37] <slangasek> -s
[09:37]  * pitti checks with mdke
[09:37] <ev> thanks!
[09:38] <slangasek> netbook-meta is the last
[09:38] <pitti> I'm at it
[09:39] <james_w> I'm on a-a duty today, what is it worth me looking at?
[09:40] <pitti> oh, NBS already looks quite good
[09:40] <pitti> james_w: if you have some minutes, getting that to 0 would be awesome
[09:40] <slangasek> james_w: there are some sourceful new packages that I guess need to be decided
[09:40] <james_w> pitti: doko says he is watching the java one, and I can't get a sensible answer on how to handle sugar
[09:41] <slangasek> james_w: and components-mismatches still has some stuff that needs hunted down & beaten with the MIR-stick
[09:41] <james_w> do we want any syncs today?
[09:41] <pitti> james_w: it looks like sugar is at 0.88 now?
[09:42] <james_w> pitti: yeah, but due to something to do with xpcom they couldn't upload the 0.88 browser, so that's stuck at 0.86
[09:43] <cjwatson> so what's the current vs. desired state of ubiquity?
[09:43]  * cjwatson has read scrollback
[09:43] <slangasek> equal
[09:43] <slangasek> at least AFAIK :)
[09:43] <cjwatson> ah, I missed the bit where ev uploaded
[09:43] <cjwatson> good
[09:44] <cjwatson> ev: except bzr doesn't reflect this yet ... missing debcommit -r push?
[09:44] <ev> cjwatson: fixed
[09:46] <pitti> slangasek: so, after the ubiquity/meta/apport/etc. bits are in, we'll build images for testing; after that, should we review/accept further safe and small fixes for tomorrow's dailies, or do you plan that today's images are the RC ones? (barring critical installer fixes, etc.)
[09:46] <slangasek> hmm, seems that ubuntu-docs normally takes >2h to build, boo
[09:47] <slangasek> in that case, we should do a publisher run as soon as the -meta builds are up, then another when ubuntu-docs is up
[09:47] <pitti> let's hope that the current security build isn't OO.o :)
[09:47] <slangasek> pitti: I prefer that today's be the RC ones, barring critical fixes
[09:47] <pitti> slangasek: ack; so should we discourage people from uploading stuff now?
[09:47] <pitti> there's still a bunch of fixes; some of them  might go in right after RC, of course
[09:48]  * pitti refers to the recent dbusmenu/indicator uploads, and similar
[09:48] <slangasek> cf. my last message on #-devel
[09:48] <pitti> ah
[09:48] <slangasek> I certainly prefer that anything we *know* is going in be done before RC
[09:49] <slangasek> and we have time for these, they'll still get done building before ubuntu-docs AFAICS
[09:49] <slangasek> I'm reviewing indicator-messages, if you or cjwatson wants to take libdbusmenu
[09:49] <mvo> what are the chances for getting software-center 2.0.2 in ? a small change, but helps performance a lot
[09:49] <mvo> ups
[09:49] <slangasek> mvo: 100% ;)
[09:49] <mvo> mail old, nevermind, its in already
[09:49] <mvo> lalala
[09:49] <pitti> slangasek: taking libdbusmenu
[09:49]  * mvo takes a cup of tea 
[09:50] <james_w> http://paste.ubuntu.com/418478/ are todays syncs. the only one to main is the first, which apparently brings a ftbfs fix, ok to sync? (they all have ffe approval)
[09:52] <pitti> james_w: hm, libgda4 is 4.0.4 -> 4.0.8
[09:53] <pitti> libgda4 isn't on the CD images, but certainly on the DVD
[09:53] <james_w> and apparently builds a gir package now
[09:53] <pitti> james_w: was that the "would be nice to get back in sync" category, or does it fix critical bugs?
[09:54] <james_w> bug 537379
[09:54] <james_w> claims that it is important
[09:55] <james_w> oh, I've just seen the instruction to wait :-/
[09:57] <james_w> and pychecker was actually in main before it was removed
[10:06] <pitti> ^ jockey was a trivial and obvious patch, accepted
[10:07] <slangasek> hmm, think I beat you to that one :)
[10:07] <pitti> slangasek: ah, seems you did :)
[10:07] <ogra> ev, cjwatson sorry for the mess, i wasnt aware i had no commit rights to ubiquity/trunk and didnt check where my bzr push went last week
[10:08] <ev> ogra: no worries at all
[10:08] <ogra> i was under the assumption that being allowed to push to d-i would also allow me to push to ubiquity ... but that seem to be different teams
[10:08] <ogra> (and i forgot that i had set up the ubiquity branch differently last year)
[10:09] <ev> yeah, d-i is maintained by core-dev
[10:09] <ogra> right
[10:09] <ev> at any rate, you're in ~ubuntu-installer now :)
[10:09] <ogra> i'll do better next time, now that i know that :)
[10:09] <ogra> yeah, thaks a lot :)
[10:09] <ogra> *thanks too
[10:09] <ev> sure thing
[10:09] <slangasek> might be useful if someone could bump build scores on xubuntu-meta
[10:09] <pitti> doing
[10:17] <slangasek> well, that took a bit longer than intended, but metapackages should all be accepted in ~10 min (for amd64/armel/i386), then I'll fire off the publisher
[10:26] <slangasek> publisher running
[10:42] <doko__> slangasek: yes, cjwatson did sync it last time
[10:43] <slangasek> doko__: I thought that when he synced it, he broke the archive... :)
[10:43] <slangasek> cjwatson: ^^ does syncing to partner work now?
[10:46] <cjwatson> err, I had to file several bugs as a result and it was generally a right mess
[10:46] <cjwatson> we sort of got it working eventually
[10:46] <cjwatson> I think at least some of the bugs have been fixed
[10:46] <cjwatson> but I would not recommend trying it outside of a relaxed environment, i.e. not 1.5 weeks before release :)
[10:46] <cjwatson> best just upload the same source package
[10:50] <doko__> ok, I'll upload it manually
[10:56] <ogra> slangasek, bug 563618 has properly tested code now that actually sets the rtc/system clock on boot to work around the infinite reboots with no rtc battery
[10:57] <slangasek> ogra: ok; I'll take a look later today
[10:57] <ogra> sweet, thanks
[10:58] <ogra> indeed you can only set the clock to rubbish anyway, but with that script we set it to at least usable rubbish :)
[10:59] <ogra> ted tso agreed to fix fsck for us to completely ignore timestamps if teh e2fsck.conf override is set but that will surely take until maverick or maverick+1
[11:16] <slangasek> *-meta published.  Waiting for synaptic to build before publishing the tasks and starting the ISOs
[11:17] <slangasek> as well as ubiquity/armel, it seems
[11:17] <ogra> sweet !
[11:17]  * ogra is just testing netinst d-i ... bein very excited 
[11:17] <ogra> *being
[11:37] <slangasek> aah!  why did the OOo/armel build just restart?
[11:38] <slangasek> lamont: is OOo killing armel buildds?
[11:38] <pitti> the buildd?
[11:38] <slangasek> now on satinash; but I thought that's where it was before, too
[11:38] <lamont> slangasek: crabapple was not the build
[11:39] <lamont> hubbard is another question
[11:41]  * ogra sees a lot of 404's for security.ubuntu.com in his installation test log, isnt it time we enable that ? 
[11:42] <pitti> ogra: they should have existed for months
[11:42] <pitti> and in fact they did
[11:42] <pitti> (with empty Packages.gz, of course)
[11:42] <ogra> weird, probably not for armel
[11:43] <pitti> right, just i386/amd64
[11:43] <ogra> ah
[11:43] <pitti> http://security.ubuntu.com/ubuntu/dists/lucid-security/main/
[11:43] <pitti> ogra: seems they are on http://ports.ubuntu.com/dists/lucid-security/main/
[11:43] <pitti> for armel
[11:44] <ogra> ouch
[11:44] <ogra> then our sources.lists are wrong
[11:45] <ogra> probably on all arches, i havent done any non-omap tests for about four weeks now
[11:45] <lamont> slangasek: hubbard was last seen building wordnet 1:3.0-22
[11:47] <slangasek> pitti: ehm, that seems pretty critical to have fixed for RC
[11:47] <cjwatson> pretty sure that apt-setup selects ports.ubuntu.com on non-x86 architectures
[11:47] <cjwatson> for security
[11:48] <cjwatson> if it doesn't, I need an installation log with DEBCONF_DEBUG=developer
[11:48] <cjwatson> ogra: ^-
[11:49] <ogra> cjwatson, will do  one after i fifnshed this install test (and actually check what ends up in the installed system)
[11:49] <ogra> *finished
[11:58] <hyperair> slangasek: got a minute? Bug #564506
[11:59] <hyperair> it's got a binary rename, but it's pretty low-impact, considering the only rdep of the renamed binary currently FTBFS, and is waiting for the new name.
[12:00] <hyperair> not to mention that the current version of the said binary package in the archive is broken pretty spectacularly.
[12:03] <slangasek> hyperair: why do the -cil and -cil-dev packages not have consistent names?
[12:07] <doko__> any reason not to accept llvm-gcc-4.2? only builds on i386/amd64, 20min build time
[12:09] <slangasek> hyperair: and why was the banshee-community-extensions package uploaded to build-depend on packages that haven't been accepted yet for lucid and might yet not be...?
[12:09] <slangasek> doko__: no specific reason, just haven't looked yet
[12:09] <hyperair> slangasek: because the previous version didn't build either.
[12:10] <hyperair> slangasek: and because the previous version of indicator-application was broken pretty spectacularly
[12:10] <hyperair> slangasek: as for the naming, the -cil version contains the ABI version, the -cil-dev contains the API version
[12:11] <hyperair> slangasek: it's standard across all the CLI libraries in the archive.
[12:11] <slangasek> well, blah
[12:11] <slangasek> it's also not, AFAICS, relevant to the problem that's supposed to be getting solved in that bug
[12:11] <hyperair> slangasek: er. the bug wasn't complete -- there were more problems than i realized.
[12:12] <hyperair> slangasek: one of the duplicates complains about the library not getting into the GAC, for example.
[12:12] <slangasek> the package may have problems, but I don't see how the package renames have anything to do with fixing the critical issues
[12:13] <hyperair> slangasek: well it was a CLI policy violation.
[12:13] <hyperair> slangasek: directhex decided to fix everything altogether in the patch.
[12:14] <directhex> moo?
[12:14] <hyperair> yay directhex
[12:17] <slangasek> hyperair, directhex: I'd like to see an indicator-application upload with just the minimal changes necessary to make the package functional; at this stage I could care less about whether it conforms with policies on package names
[12:17] <slangasek> that will mean another upload of banshee-community-extensions to fix the build-deps back
[12:17]  * hyperair sighs
[12:17] <hyperair> fine
[12:18] <hyperair> slangasek: but is there a reason to be this resistant about a binary rename of a package that has no other rdeps?
[12:19] <slangasek> hyperair: because packages from this source are on the CDs, and the window for changes to those packages is much smaller than for universe
[12:20] <hyperair> ah right. the CDs. i forgot.
[12:21] <ogra> ogra@beagle:~$ cat /etc/apt/sources.list|grep security|grep main
[12:21] <ogra> deb http://security.ubuntu.com/ubuntu lucid-security main restricted
[12:21] <ogra> deb-src http://security.ubuntu.com/ubuntu lucid-security main restricted
[12:21] <ogra> hmm
[12:22]  * ogra does an install with DEBCONF_DEBUG=developer
[12:22] <directhex> there are 4 major bugs in the package, ignoring the policy problems - everything in debian/rules , and the pcfile patch
[12:22] <directhex> obviously the values in the patch i sent would need to be reverted back to incorrect locations, if the package naming is ruled out
[12:24] <slangasek> directhex: do you think the risk is greater if making those location reverts?
[12:25] <directhex> slangasek, i think the tying together of API, ABI, install location and package names, within policy, was as a direct result of pain elsewhere when dealing with partial changes, and leading to big long painful Conflicts: and Replaces: dances
[12:26] <directhex> slangasek, my personal stance with canonical's bindings has been to go for unstable api/abi packaging, which is simpler & unversioned throughout, and a "safer" option for libs in flux. but i was overruled with libu1, and i simply play the hand i'm dealt
[12:27] <directhex> slangasek, the only changes which really have any potential to impact the packages on the CD are the changes to debian/rules, and those need to happen ANYWAY
[12:28] <directhex> (hint: as i understand CDBS, the one bit which *does* change the CD contents is the DEB_DH_MAKESHLIBS_ARGS_libappindicator0 which should really be there anyway)
[12:28] <slangasek> directhex: OTOH, your patch *adds* the Conflicts/Replaces, which should be a one-time thing and shouldn't be any easier or harder if we do it now, or in maverick
[12:29] <directhex> true. question is whether it's ever likely to need backporting
[12:29] <directhex> since backporting from valid to invalid policy will add burden
[12:31] <slangasek> the shlibdeps change may fix a bug, I don't know; if so, it's not a particularly serious bug, but I'll allow that change either way because the impact of getting it wrong is also roughly 0
[12:34] <hyperair> makeshlibs, not shlibdeps
[12:35] <slangasek> yes
[12:38] <ogra> wohoo ... flash-kernel works in d-i
[12:40] <directhex> hyperair, do you have time to strip out the renames from my debdiff? i need to pop to the bank
[12:41] <slangasek> directhex, hyperair: alternatively, if you've extensively tested this out-of-archive and can assure me that there will be *zero* need for further uploads of indicator-application for lucid, I can see my way to taking the rename
[12:44] <hyperair> i'm not sure about *zero* need for further uploads.. we'd have to ask tedg about whether he has any further issues.
[12:46] <directhex> i tested the lib installed and could be built against as expected, i didn't rebuild b-c-e but can do that now
[12:56] <directhex> hm...  Depends: banshee (>= 1.6.0), banshee-extensions-common (= 1.6.0-1ubuntu4), libappindicator0.0-cil (>= 0.0.19), libglib2.0-cil (>= 2.12.9), libgtk2.0-cil (>= 2.12.9), libmono-addins0.2-cil (>= 0.4), libmono-corlib2.0-cil (>= 1.2.2.1), libnotify0.4-cil (>= 0.4.0~r2998)
[12:56] <directhex> there we go, picking up the dependencies properly now, that's a good thing
[12:57] <directhex> yep, appindicator in banshee, working fine. just how nature intended
[12:58] <slangasek> directhex, hyperair: so you're happy that if I accept this, any new issues that turn up are ones we'll be able to live with for release?
[12:58] <hyperair> slangasek: yes.
[13:00] <slangasek> if so, please get it uploaded and I'll accept it after RC
[13:02] <hyperair> seb128: ^^
[13:02] <directhex> hang on, i just want to double-check apt's handling of the conflicts
[13:04] <directhex> yep, looks fine
[13:07] <slangasek> cjwatson, pitti: so my rune for triggering ISO builds contingent on a package publishing has been properly scriptified now - cdimage/bin/wait-for-package
[13:08] <slangasek> (could use better documentation, still...)
[13:08] <pitti> ah, wait-for-package <package>_<version>
[13:08] <pitti> sweet, thanks
[13:11] <slangasek> yeah, it really just passes that to zgrep
[13:13] <stgraber> slangasek: did you trigger that new edubuntu build ?
[13:14] <cjwatson> slangasek: neat
[13:15] <slangasek> stgraber: I'm doing the big batch of ISO builds now; it'll be a few hours yet before it reaches edubuntu in the queue
[13:17] <cjwatson> slangasek: could do with mirroring build-image-set's semaphore handling around anonftpsync though - as it is it looks unsafe against parallel builds
[13:18] <cjwatson> maybe even just bail out if it ever notices that another build is running
[13:18] <slangasek> hmm
[13:18] <slangasek> isn't that a problem in anonftpsync itself, then?
[13:19] <cjwatson> depends where you think the locking ought to live :)
[13:19] <slangasek> right :)
[13:19] <cjwatson> at the moment, the practice is to do it outside anonftpsync
[13:19] <slangasek> ok
[13:19] <cjwatson> I don't object to moving it if that makes more sense; I think I did it outside because I picked up anonftpsync from elsewhere
[13:20] <cjwatson> so I think I was regarding it as basically a contributed tool
[13:20] <slangasek> build-image-set's semaphore still has the bug where a universe sync and a main sync in parallel can leave an inconsistent universe tree, right?
[13:21] <cjwatson> there's only one lock - I think it's more complicated than that but I forget the details
[13:21] <cjwatson> sorry :(
[13:22] <slangasek> I think it's: main sync grabs the lock; universe build sees the lock so assumes it doesn't need to sync anything; lock clears, main is up-to-date but the Releases file isn't
[13:23] <cjwatson> that does sound plausible
[13:50] <slangasek> xserver-xorg-input-vmmouse> reviewed, if we have to respin RC for any reason, please accept this
[13:56] <slangasek> james_w: do you have any more information about this sugar xpcom issue?  if the new version has an unsupportable xulrunner dep, then I guess the thing to do is to just drop the old package
[13:56] <james_w> slangasek: I don't. lfaroane and ChrisCoulson know what's going on I think
[13:56] <slangasek> ok
[14:27] <ogra> cjwatson, bug 566639
[14:27] <slangasek> lamont: what's the state of the acorn?
[14:28] <slangasek> ogra: is it only reproducible with omap?
[14:28] <lamont> slangasek: theoretically, it's full of love for livecd builds
[14:28] <ogra> slangasek, i'll ask one of my team members to try to reproduce under imx51/dove
[14:29] <slangasek> lamont: so should I point some of these RC builds over there?
[14:29] <lamont> slangasek: is there something I should look at on it?
[14:29] <lamont> slangasek: feel free
[14:29] <lamont> it's all yours now
[14:29] <lamont> well, I do plan to abuse it a little bit for a bootstrap of yet another universe package, but...
[14:29] <lamont> shouldn't be any real impact to livecd builds
[14:37] <jdstrand> I'm wondering if bug #521298 should really remain unmilestoned with no Importance set. so far 62 people have said they are affected by the bug...
[14:38] <ogra> slangasek, not reproducable on imx51 apparently
[14:38] <slangasek> ogra: were both install tests done with the same kind of media?
[14:38] <ogra> you mean imx vs omap ?
[14:39] <ogra> i dont think so though it shows up for me in both omap installs (to SD as well as to USB) while imx can only install to USB
[14:40] <slangasek> I mean the /install /media
[14:40] <ogra> ah, i dont hink the guys actually test d-i based installs
[14:40] <ogra> plars, ^^^ ?
[14:41] <ogra> and even more rarely netinst images
[14:42] <plars> ogra: the netinst images usually get tested at each milestone, but not the d-i (currently server) images
[14:42] <ogra> ah
[14:42] <slangasek> yes, these are variables to be eliminated before drawing conclusions about it not being reproducible on imx51
[14:42] <ogra> (netinst is d-i too :) )
[14:42] <slangasek> plars: tested, but does this bug manifest w/ netinst?
[14:43] <plars> ogra: the install I'm looking at where I don't see the bug is netbook install, not netinst
[14:43] <ogra> slangasek, well, i'll test -server now and once omap netbook is respun i'll test that one too and comment on the bug
[14:44] <ogra> so i'll at least know if the install media has any influence ... but i rather suspect that apt-setup is missing some kind of subarch thing
[14:48] <ogra> oh, heh
[14:49] <ogra> # Awful Ubuntu-specific hack. *-security suites for ports architectures
[14:49] <ogra> # aren't available on security.ubuntu.com, only on ports.ubuntu.com
[14:49] <ogra> ....
[14:49] <ogra>         db_get mirror/$protocol/hostname
[14:49] <ogra>         if [ "$RET" = ports.ubuntu.com ]; then
[14:49] <ogra> ...
[14:49] <ogra> i was using my local mirror for the netinst
[14:49] <ogra> so thats just a weakness in the matching
[14:50]  * ogra comments in the bug
[14:51] <slangasek> ah
[14:53] <ogra> i guess that code should better use archdetect but i'm not sure what drawbacks that would imply
[14:58] <jdstrand> 08:37 < jdstrand> I'm wondering if bug #521298 should really remain unmilestoned with no Importance set. so far 62 people have said they are affected by the bug...
[14:58] <jdstrand> slangasek: this was recently moved back to plymouth ^
[15:00] <slangasek> jdstrand: I'm afraid I have no clue about that bug; Keybuk marked it 'triaged', but hasn't explained what the bug is, so there's only value in milestoning it if he's going to have time to work on it
[15:00]  * ogra just saw the too on his beagle install 
[15:01] <jdstrand> slangasek: perhaps, but I can tell you from first hand experience that it makes the boot experience look very unprofessional
[15:01]  * ogra clocks the me too link
[15:01] <ogra> *clicks even
[15:01] <ogra> jdstrand, ++
[15:02] <ogra> i thought it was armel specific since i hadnt seen it before
[15:02] <jdstrand> ogra: I think it is anything that uses the plymouth text theme
[15:02] <ogra> yeah
[15:02] <jdstrand> I've seen it on at least 2 i386 boxes
[15:03] <ogra> i dont run x86 boxes with text theme anywhere that would indeed explain it
[15:03] <jdstrand> I'm blessed with old hardware :)
[15:03] <ogra> heh, i'm cursed with new but powerless ARM hardware :)
[15:03] <jdstrand> heheh
[15:06] <slangasek> jdstrand: oh; can you put that in the bug description/title that it's easily reproducible with the text theme?  If I can reproduce it, maybe we can get some traction on it for release, yes
[15:06] <jdstrand> slangasek: ok
[15:12] <cjwatson> slangasek: I can reproduce it in a VM any time, but I have not been able to get any traction on stracing it
[15:13] <cjwatson> slangasek: i.e. when I tried to strace plymouthd to find out if that was what was causing it, boot hung
[15:13] <cjwatson> slangasek: if you'd like somebody with some basic familiarity with plymouth to be teleoperated, I can oblige
[15:13] <slangasek> heh, ok
[15:13] <cjwatson> slangasek: but FWIW all I did was a server install in kvm
[15:14] <cjwatson> it doesn't quite reproduce every time, but often enough (at least one in two for me)
[15:32] <jdstrand> interesting, latest plymouth on my T42 (ie, one of the machines that I've seen the bug on), recently started using plymouth-logo, with less than desirable results: number of colors seems to have defaulted to something far too low-- the 'fade in' of the logo is all wrong (bright greens, etc). shutdown has a similar but different look...
[15:35] <slangasek> jdstrand: do you have the wrong version of the plymouth-theme-ubuntu-logo package installed?
[15:35] <jdstrand> slangasek: I just dist-upgraded, let me get the version
[15:35] <jdstrand> 0.8.2-2
[15:35] <slangasek> hmm
[15:36] <jdstrand> slangasek: ^ that is true for all packages seen with 'dpkg -l|grep plymouth'
[15:36] <jdstrand> slangasek: http://paste.ubuntu.com/418633/
[15:37] <slangasek> jdstrand: what's cat /proc/fb?
[15:37] <jdstrand> should be radeonfb... let me check
[15:37] <jdstrand> $ cat /proc/fb
[15:37] <jdstrand> 0 radeondrmfb
[15:38] <jdstrand> slangasek: you may recall that this was the system that has 32MB of ram on a radeon 7500, and the text theme was the default for a while
[15:38] <slangasek> jdstrand: that'll be a kernel bug, then
[15:38] <slangasek> er
[15:38] <slangasek> and indeed, it'll be a new kernel bug, then
[15:38] <jdstrand> it now switched over to logo
[15:39] <jdstrand> for a second before gdm comes up (X starting I guess), it looks pretty
[15:39] <slangasek> bug #564471
[15:39]  * ogra wonders if during initramfs it possibly overrides with vga16fb
[15:40] <jdstrand> slangasek: that is it exactly-- and that is true on boot and shutdown (unsurprisingly)
[15:40] <slangasek> jdstrand: confirm it, pester the kernel team? :)
[15:41] <jdstrand> slangasek: though, I need KMS on this laptop (as you may also recall ;)
[15:46] <jdstrand> apw: fyi ^ (bug #564471)
[15:49] <apw> slangasek, a new kernel bug ... we didn't enable kms on anything recently that i know of?
[15:49] <slangasek> apw: new relative to Apr 2, I believe
[15:50] <apw> the bug says it was the removal of 915.modeset=1 was the reason
[15:50] <slangasek> apw: not bug #564471
[15:50] <jdstrand> that would be odd-- 915 is intel-- these are radeon
[15:50] <apw> from the /etc/modprobe.d/radeon-kms.conf ...
[15:51] <apw> sorry radeon.modeset=1
[15:51] <apw> right file, wrong option name
[15:51] <apw> but in theory all we did was went from 'enabled' to 'enabled' ...
[15:52] <apw> given its reported enabled
[15:52] <jdstrand> (please keep it enabled for my radeon 7500 ;)
[15:53] <slangasek> apw: oh; ignore that bit of the bug description (or edit away, if you like) - I don't think the regression that user saw has anything at all to do with radeon-kms.conf, they probably also rebooted to a new kernel at the same time and didn't notice
[15:53] <jdstrand> slangasek: I can say that a couple (few?) weeks ago we saw in bug #554143 that it was plymouth's detection that downgraded the 7500 to the text theme
[15:53] <apw> if anything the bug comments imply we now enable kms where we did not before, or plymouth did not use it
[15:53] <slangasek> yeah
[15:54] <slangasek> jdstrand: plymouth hasn't gained any support for 16-bit framebuffers in the meantime
[15:54] <apw> hrm, does that mean that plymouth is miss useing the framebuffer
[15:55] <jdstrand> slangasek: yeah, which is why I was surprised to see a presumably 24/32 bit image shoved into the 16 bit color scheme
[15:55] <slangasek> so if it's now showing up with the graphical splash, either the kernel is now exporting a truecolor fb, or it's writing to a vgafb; and cat /proc/fb kinda rules out the latter
[15:55] <slangasek> apw: no, it means the framebuffer is wrong ;)
[15:56] <apw> jdstrand, so i need you to boot back to a previous kernel and prove its a kernel change which triggered it, and let me know which one :)
[15:56] <jdstrand> apw: k
[15:56]  * jdstrand wonders why he seems to hit all these boot issues...
[15:57] <jdstrand> slangasek: does this look right: http://paste.ubuntu.com/418644/
[15:57] <apw> you have a heap of junk for a laptop ?  :)
[15:57] <jdstrand> apw: dude... uncool
[15:57] <slangasek> jdstrand: yep
[15:57] <jdstrand> :)
[15:58] <jdstrand> hey-- the T42 was quite a nice laptop back in the day
[15:58] <apw> heh i had one of those, and it was never a nice laptop
[15:58] <jdstrand> really? it always work well for me-- I rarely if ever had to do anything to get it to work with Ubuntu
[15:59] <jdstrand> of course, I chose the radeon 7500 specifically cause I didn't want a proprietary driver...
[15:59] <apw> jdstrand, mine exploded in the end
[15:59] <jdstrand> my wife still has one and it is going strong
[15:59] <apw> jdstrand, i can't tell from this bug if the thing is fine once plymouth is done or not
[16:00] <jdstrand> I don't use mine as much, but it still works great (barring the recently fixed radeon/KMS bug and this plymouth thingie)
[16:00] <jdstrand> apw: it is only the boot splash before X kicks in that is affected. everything else seems ok. but let me double check that
[16:01] <apw> ok then i'd be interestied in knowing what your previous kernel was
[16:01] <jdstrand> 18 uses the text logo
[16:02] <jdstrand> (for boot-- shutdown uses logo)
[16:02] <apw> do you have -19 ?
[16:02] <jdstrand> booting into it now
[16:02] <jdstrand> err-- 18 and 19 use the text theme on boot, logo on shutdown
[16:04] <apw> jdstrand, ok that makes little sense then, for -21 to differ there
[16:04] <slangasek> jdstrand: please make sure to use an up-to-date initramfs for these comparisons
[16:04] <apw> yeah if you rebuild the -18 initramfs i suspect it may break
[16:04] <slangasek> i.e., if you have cryptsetup installed, plymouth is in the initramfs, and you'll have an old version in the initramfs for the old kernel
[16:04] <ScottK> The quassel upload is not needed until after RC.  It just converts patches we have into a nice release number.
[16:05]  * jdstrand reboots again
[16:09] <jdstrand> apw, slangasek: ok, after booting into 19, doing update-initramfs -u -k 2.6.32-19-generic and rebooting into it: degraded logo theme on boot and shutdown
[16:10] <jdstrand> I'm afraid of 18 based on apw's comment
[16:11] <apw> no i meant i suspected you would transfer the issue into it
[16:11] <slangasek> jdstrand: you get the strange colormap with -19?
[16:12] <jdstrand> slangasek: yes (what I meant by 'degraded')
[16:12] <slangasek> hmm; and -19 was the one present at the time we last discussed this
[16:12] <slangasek> let me double-check the upstream plymouth changes - I don't remember anything about this
[16:13] <apw> jdstrand, is plymouth actually in your initramfs?
[16:13] <jdstrand> slangasek: yes -- bug #554143 shows me as having 2.6.32-19-generic
[16:13] <jdstrand> apw: well, I would assume so-- I am using splash and get the degraded logo. what do you want me to check specifically?
[16:13] <slangasek> oh, I know what the difference is
[16:13] <ScottK> pitti: re all those perl module MIRs - I don't have an opinion on if the entire mess needs to be in Main or not.  I was just trying to get it what was in main was buidable/installable.
[16:14] <apw> jdstrand, i didn't think plymouth was in there
[16:14] <slangasek> jdstrand: plymouth 0.8.2 switched us to using the drm renderer unconditionally on radeon, where before we used drm only for multi-head displays
[16:14] <jdstrand> ah
[16:14] <apw> hrm
[16:14] <slangasek> so this is a plymouth/libdrm/kernel issue
[16:15] <jdstrand> well, while I sould prefer the logo theme over the text, it is less than optimal atm :)
[16:15] <apw> so either plymout doesn't grob the frambuffer, or the framebuffer is not right in the kernel
[16:15] <jdstrand> s/sould/would/
[16:15] <apw> jdstrand, what does VT1 look like once X starts?
[16:15] <jdstrand> apw: normal-- login prompt
[16:15] <apw> jdstrand, you are just being limited in your interpretation of pretty
[16:16] <jdstrand> heh
[16:16] <jdstrand> tbh-- a black screen until gdm comes up with no text would be beautiful at this point
[16:17] <apw> you just need more drugs to fully apprecaite the green
[16:17] <jdstrand> ie, if 'quiet' was really quiet, and lose splash
[16:17] <jdstrand> hah
[16:18] <apw> slangasek, so whats our next step
[16:18] <jdstrand> slangasek: how do I force text logo in .21? update-alternatives --config default.plymouth didn't do it for me (or maybe there is more I need to do)
[16:18] <slangasek> apw: assign the bug back to plymouth; the drm renderer isn't checking bpp
[16:18] <jdstrand> I keep saying 'text logo'...
[16:18] <jdstrand> text *theme*
[16:18] <slangasek> (just verified the code)
[16:18] <slangasek> jdstrand: boot with plymouth:splash=text
[16:18] <jdstrand> slangasek: k, thanks
[16:19] <apw> slangasek, will do
[16:20] <apw> slangasek, done
[16:20] <jdstrand> slangasek: that didn't do it-- related to the drm issue?
[16:20] <slangasek> jdstrand: hmm, sec
[16:20] <pitti> ScottK: sure, no problem; I didn't want to shoot the messenger, thanks for sorting this ot
[16:21] <pitti> out
[16:21] <ScottK> Understood.
[16:22] <slangasek> jdstrand: really should've worked - is the text theme in your initrd?
[16:27] <jdstrand> slangasek: looks like it: http://paste.ubuntu.com/418660/
[16:28]  * jdstrand tries again
[16:28] <slangasek> jdstrand: oh - plymouth:splash=ubuntu-text
[16:28] <slangasek> sorry
[16:28] <slangasek> 'text' doesn't work because it's looking for text/text.plymouth
[16:28] <jdstrand> that didn't work either. let me super double check I didn't mistype it
[16:29] <jdstrand> slangasek: should I lose 'splash'?
[16:29] <slangasek> jdstrand: no
[16:30] <jdstrand> slangasek: sorry, no. that didn't work
[16:30] <jdstrand> I even said it out loud to myself 'plymouth' 'colon' 'splash' 'equals' 'ubuntu-text'
[16:31] <jdstrand> eek
[16:31] <jdstrand> my screen just faded to white
[16:31] <jdstrand> and didn't get to the gdm screen
[16:31] <slangasek> jdstrand: what was the filter on that pastebin?
[16:32] <jdstrand> find . -name "*plymouth*"
[16:32] <slangasek> ok
[16:32] <slangasek> is /lib/plymouth/ubuntu-text.so also in the initrd?
[16:35] <jdstrand> slangasek: yes
[16:35] <jdstrand> (I had to reboot to get to a usable system)
[16:36] <slangasek> hmm
[16:40] <jdstrand> slangasek: do you want my initrd?
[16:41] <slangasek> jdstrand: don't think it'll help; I'm missing something, but I have no clue what ATM
[16:42] <jdstrand> slangasek: ok. well I wanted to test/comment more on the Broken pipe bug, but it'll have to wait until I can boot using the text theme (obviously)
[16:43] <slangasek> heh, right
[16:56] <ScottK> slangasek: FTBFS fix ^^^
[16:56] <NCommander> slangasek: on the arm FTBFS of libgphoto2, is it acceptable if we drop doxygen from the build-deps so configure disables generating documentation? The package builds probably, it just appears that our buildds suck
[16:57] <slangasek> NCommander: is the doxygen documentation currently shipped somewhere?
[16:57] <slangasek> there's no arch: all -doc package
[16:57] <NCommander> slangasek: its shipped in the -dev part of the package if memory serves.
[16:58] <slangasek> please only drop the build-dep on armel, then
[16:58] <NCommander> slangasek: that was my plan. I rather fix it so we have an arch all docs package, but the root canal needed to libgphoto2's configure scripts probably would be a bit excessive for an upload this late
[16:59] <slangasek> ScottK: accepted, thanks!
[16:59] <ogra> NCommander, err
[16:59] <ogra> NCommander, i thought there was a request that the arch all stuff shuldnt be built on armel for gphoto, didnt you work on that ?
[16:59] <slangasek> NCommander: why would any root canal be needed?  Making an arch: all -doc package would only require splitting it up in the debian/rules install or binary target
[17:00] <slangasek> NCommander: though, in this case I think just dropping the docs for armel is best
[17:00] <slangasek> due to the time
[17:10] <ScottK> What's the deal with OOo on armel?  I see it got restarted again.
[17:10] <slangasek> don't know
[17:11] <jdstrand> slangasek: do you need a bug for the text theme issue?
[17:11] <slangasek> lamont: did you find out anything about that OOo restart?
[17:11] <slangasek> jdstrand: might as well - btw, if you want to switch to text semi-permanently, just remove plymouth-theme-ubuntu-logo...
[17:12] <jdstrand> slangasek: I was afraid of doing that, since I got that weird white fade-out, but I'll try
[17:18] <ScottK> I'd appreciate it if someone could throw http://paste.debian.net/69754/ at mass-sync.py.
[17:25] <slangasek> jdstrand: har; weird bug in the commandline parsing, 'plymouth:splash=ubuntu-text' doesn't work when it's the last option on the boot line
[17:29] <jdstrand> slangasek: oh heh
[17:29] <jdstrand> slangasek: let me reinstall plymouth-theme-ubuntu-logo and try again
[17:30] <jdstrand> slangasek: btw, that is bug #566762
[17:39] <doko__> slangasek: please accept the sun-java6 package, the previous one does contain undistributable stuff
[17:39] <slangasek> cjwatson: are you still able to reproduce bug #521298?  jdstrand and I appear to have both been trying, I haven't been able to and AIUI jdstrand hasn't either
[17:40] <slangasek> doko__: done
[17:41] <jdstrand> slangasek: I saw a very brief flash of text once, but after 7 reboots the Broken pipe seems gone. shutdown is another story (see comment #44 in bug #521298
[17:42]  * slangasek nods
[17:42] <cjwatson> slangasek: I'll give it another go shortly
[17:42] <slangasek> the general problem of text being shown over the text-mode splash screen isn't likely to get fixed before final
[17:42] <jdstrand> ogra: you might be interested in ^
[17:43] <slangasek> shutdown messages, etc.
[17:43] <jdstrand> slangasek: would it be possible to add a newline after the dots?
[17:43] <slangasek> probably
[17:43] <jdstrand> slangasek: I think it would look more acceptable with it
[17:44] <jdstrand> I wonder if I am not seeing it now cause ureadahead is up to date...
[17:44] <jdstrand> (the Broken byte issue)
[17:45] <cjwatson> do you see it if you switch to tty7 after booting?
[17:45] <slangasek> I'm guessing that was an effect of one of the mountall / plymouth bugs that were recently fixed
[17:45] <cjwatson> because when I was seeing it I was doing oem-config stuff, which tends to land on tty7 in between things
[17:45] <jdstrand> cjwatson: when should I go to tty7? gdm is there at present...
[17:45] <cjwatson> oh, server installs I'm talking about
[17:46] <cjwatson> easier to see there
[17:46] <jdstrand> cjwatson: right, I was seeing it on desktop until recently
[17:46] <cjwatson> yeah, but why not use the easy reproduction case :)
[17:46] <cjwatson> I saw it in desktop OEM installs
[17:46]  * jdstrand nods
[17:46] <cjwatson> which flick to tty7 between ubiquity-dm and gdm
[17:46] <jdstrand> it only ever bothered my on my laptop :P
[17:46] <cjwatson> but that's hopeless for actual debugging
[17:47] <jdstrand> I can crank up a VM to see
[17:47] <cjwatson> I think I did see it rather less with plymouth 0.8.2
[17:47] <cjwatson> I'm doing a server install now to check
[17:50] <lamont> slangasek: the one where someone external to crabapple reset it?  yeah.  I know what happened there
[17:51] <slangasek> lamont: does knowing what happened mean we can be assured of it not happening again? :)
[17:52] <lamont> well... it would be very very beneficial to our future selves if the armel machines were actually server-class hardware, instead of naked boards with stuff plugged into them
[17:52] <slangasek> heh
[17:58] <slangasek> plars, GrueMaster: ETA 1h30 for arm netbook images
[17:59] <GrueMaster> Roger that.
[17:59] <slangasek> cjwatson, pitti: ^^ I don't expect I'll manage to be around at that time to post those, so if someone could post them to the ISO tracker when they're done, that'd be groovy
[18:00] <ogra> jdstrand, i cant confirm because i'm continually reinstalling my beagleboard :) i'll check once i have an install that will persist longer than 20min ;)
[18:00] <GrueMaster> slangasek: Why the respin?  It looks like there was an image already for today.
[18:00] <slangasek> GrueMaster: because these are the candidate images for RC
[18:01] <GrueMaster> Ok.
[18:03] <slangasek> ubuntu, kubuntu DVDs will also show up in the next few hours; I'll post them after my nap if no one beats me to it
[18:08] <ScottK> slangasek: ^^^ rebuild FTBFS fix.  Fine to wait for after RC.
[18:09]  * slangasek nods
[18:13] <ScottK> slangasek: Any chance of getting my sync's done from earlier today? http://paste.debian.net/69754/
[18:13] <slangasek> looking
[18:15] <ScottK> Thanks
[18:15] <slangasek> running
[18:15] <ScottK> Great
[18:25]  * slangasek drops off for a bit
[18:29] <pitti> slangasek: sorry, I need to leave for Taekwondo as well now, but I can have another look when I'm back in ~ 3 hours
[19:03] <vish> !outyet
[19:03] <vish> grr..
[20:26] <facundobatista> Hi all
[20:27] <facundobatista> slangasek, ping
[20:37] <GrueMaster> Have the arm images (imx51 & dove) finished building?  Would like to start downloading them so I can test this afternoon.
[20:44] <facundobatista> slangasek, ping, I have this proposal that should get into Lucid (it's from early March):
[20:45] <facundobatista> slangasek, https://code.edge.launchpad.net/~facundo/ubuntu/lucid/pyinotify/fix-path-overlap/+merge/21266
[20:45] <facundobatista> slangasek, without it, pyinotify lies about the path where some MOVE_SELFs happen, which is critical for all the software using it (Ubuntu One between them)
[20:46] <facundobatista> slangasek, kenvandine already sponsored it
[23:01] <GrueMaster> Someone please update iso.qa.ubuntu.com with the ubuntu arm images asap so I can start uploading test info.
[23:16] <cjwatson> GrueMaster: one moment
[23:18] <cjwatson> GrueMaster: done
[23:18] <cjwatson> slangasek: ^-
[23:18] <GrueMaster> Thanks.
[23:47] <cjwatson> slangasek: hm, so I indeed can't reproduce the EPIPE errors on a fresh install.  Maybe the case I was hitting got fixed