[00:02] <skaet> infinity,  can you take a close look at the ubuntu desktop images, and verify all the points in the release checklist have actually been handled?      I'll be doing some updates as well.
[00:05] <infinity> skaet: Yep, yep.
[00:06] <skaet> thanks infinity :)
[00:26] <cjwatson> slangasek: ^-
[00:26] <cjwatson> parallel-accept-safe
[00:26] <cjwatson> slangasek: If you could do debian-installer once grub2-signed has built and published, then I could go to bed :-)
[00:27] <infinity> cjwatson: It just needs a rebuild?
[00:27] <cjwatson> skaet: ^- that's the one
[00:27] <cjwatson> infinity: Yeah
[00:27] <infinity> cjwatson: I have the technology to do that. :P
[00:27] <skaet> thanks cjwatson.
[00:27] <skaet> thanks infinity
[00:27] <cjwatson> So do I, but not the technology to stay up half the night again :P
[00:27] <slangasek> cjwatson: yeah, we can take care of d-i
[00:27] <infinity> cjwatson: Yeah, I realised that I'd been working for 24h when I went to bed this morning. :/
[00:28] <infinity> (oops)
[00:28] <slangasek> infinity: how much money did you raise for charity?
[00:28] <skaet> :)
[00:28] <infinity> slangasek: Two dollars and a discarded candy wrapper.
[00:28] <slangasek> infinity: doing it wrong
[00:30] <slangasek> so, this is interesting
[00:30] <slangasek> cmp build/shim.efi.signed /usr/lib/shim/shim.efi
[00:30] <slangasek> build/shim.efi.signed /usr/lib/shim/shim.efi differ: char 217, line 3
[00:31] <slangasek> I'm quite certain that worked on the last binary
[00:31] <cjwatson> Err
[00:31] <cjwatson> Why would the signed and unsigned binaries be identical?
[00:31] <slangasek> cjwatson: because I ran sbattach --remove :)
[00:31] <cjwatson> Oh, and didn't change the filename :P
[00:31] <slangasek> yeah
[00:32] <slangasek> noted, will make that more obvious :-)
[00:34] <slangasek> well hmm
[00:34] <slangasek> downgrading sbsigntool and testing against the previous shim, the command fails in the same way
[00:35] <cjwatson> So bug in new sbsigntool?
[00:35] <cjwatson> Sucks to be Jeremy.
[00:35] <slangasek> no
[00:35] <cjwatson> Oh.  Reading comprehension.
[00:35] <slangasek> possibly pre-existing bug in sbsigntool
[00:35] <slangasek> but I swear I tested that part
[00:35] <cjwatson> Then confused.  Did it actually work before?
[00:35] <slangasek> maybe?
[00:35] <slangasek> I have no logs to prove it ;)
[00:37] <slangasek> need to look at the PE struct and see what's going on
[00:37] <slangasek> fwiw the files are *largely* identical
[00:38] <slangasek> -0000320 00 40 13 00 00 04 00 00 8d 0c 15 00 0a 00 00 00
[00:38] <slangasek> +0000320 00 40 13 00 00 04 00 00 6a 8a 15 00 0a 00 00 00
[00:38] <slangasek> -5112520 74 00
[00:38] <slangasek> -5112522
[00:38] <slangasek> +5112520 74 00 00 00 00 00 00 00
[00:38] <slangasek> +5112530
[00:39] <slangasek> aha, that's a length field, isn't it :)
[00:39] <slangasek> grr
[00:40] <cjwatson> All right, I'm off to bed.  Don't forget to accept those boot loaders. :-)  SMS me if there's a bug in my patch so that I can come back and fix it.
[00:41] <slangasek> grub2 just accepted :)
[00:41] <infinity> Was just about to click that...
[00:41] <cjwatson> Yay.
[00:41]  * infinity goes to have a spot of food instead of queue colliding.
[00:45] <slangasek> and grub2-signed accepted
[00:49] <skaet> :)
[00:49]  * skaet stands by to kick off the full set of rebuilds,  once the publisher runs.
[00:51] <ScottK> skaet: It'd be nice to get the first Kubuntu set out before you kick off another.
[00:54] <skaet> ScottK,  Kubuntu set is building now and almost out.
[00:55]  * skaet just went to check,   and yeah they are out.
[00:55] <skaet> ScottK,  ^ they are available now.
[00:55] <skaet> Kubuntu active build has started as well.
[00:56] <ScottK> Thanks.  Will test shortly.
[00:56] <skaet> :)
[01:12] <infinity> skaet: Release checklist looks good from my end, BTW.  Looks like others took care of things while I was napping this morning. :P
[01:14] <skaet> yup.   but a second set eyes (that are no longer sleep deprived) builds confidence.  ;)
[01:14] <skaet> thanks
[01:15] <cjwatson> slangasek: ^- grub2/amd64 waiting in unapproved there
[01:15] <cjwatson> (I would be in bed but my daughter was suddenly ill ... :-/)
[01:15] <slangasek> cjwatson: got it, thanks
[01:15] <slangasek> cjwatson: aw :/
[01:16] <infinity> Dearest libatomic-ops, PFO, kthx, no love, Me.
[01:17] <skaet> cjwatson,  sorry.  :(
[01:19]  * infinity is tempted to mail his magical Panda that CAN'T REPRODUCE THIS BUG to the DC to build this package...
[01:28]  * ScottK stocks up on schadenfreud.
[01:28]  * infinity beans ScottK in the head with a high velocity Panda.
[01:30] <infinity> Tis driving me nuts.  I can understand not being able to reproduce the weird looping testsuite issue.  Seems entirely a timing thing, and maybe my Panda's just a little faster or something, I dunno.
[01:30] <infinity> But then the segv that the buildds *all* see right after the loop doesn't happen.  That segv just doesn't exist here.
[01:30] <infinity> Double-u, tee, eff.
[01:30]  * skaet figures it all depends on the binsort of the part you've got on that panda, and its tollerances  :P
[01:36] <wgrant> infinity, slangasek: Are you likely to miss a couple of publisher runs over the next few hours if we skip them?
[01:36] <skaet> wgrant,  yes
[01:37] <skaet> we're waiting on slangasek to review some grub2 patches,  and then get them built/published before kicking off the full set of candidate image builds.
[01:37] <infinity> wgrant: Right now, yes.
[01:37] <wgrant> Ah
[01:37] <infinity> wgrant: Ask that again after a new d-i is built and installed, and the answewr's likely "no".
[01:37]  * skaet nods
[01:37] <slangasek> I guess I should expedite this shim-signed upload then :P
[01:37] <wgrant> Thanks, will wait
[01:38] <wgrant> We'd like to get some DB patches out before we can't do anything next week
[01:38] <infinity> slangasek: Did d-i need to wait on your shim too?
[01:38] <wgrant> But each means skipping a publisher run, basically
[01:38] <infinity> wgrant: Understood.
[01:38] <slangasek> infinity: yeah, it kindasorta does
[01:38] <infinity> wgrant: We'll be a lot more slack pretty soonish.
[01:38] <wgrant> Right, I thought you were already basically done in that respect
[01:38] <infinity> slangasek: Then go forth and shimmy.  Colin implied I could d-i as soon as grub2-signed was published, so I'll back off the trigger. :P
[01:39] <infinity> wgrant: Turns out that secure boot sucks and wants us all to die in the face.
[01:39] <skaet> wgrant, no such luck.   blocker bugs discovered today.
[01:39] <wgrant> Indeed
[01:43] <slangasek> infinity: shim-signed uploaded to quantal-proposed; not sure a review is meaningful since the only diff is a binary blob, but if you want to accept that and then copy both shim+shim-signed from quantal-proposed to quantal once built, we should be good to go
[01:43] <slangasek> (and sorry for the extra publisher cycle involved)
[01:44] <slangasek> we could in theory push shim from quantal-proposed to quantal now and I could reupload shim to quantal instead of quantal-proposed if you prefer, but then the accept has to be delayed anyawy
[01:45] <infinity> Meh, whatever.  I have nothing better to do tonight but delay wgrant's plans.
[01:45] <wgrant> :)
[01:45] <infinity> And, really, nothing fills me with greater joy.
[01:46] <cjwatson> slangasek: Shouldn't necessarily be an extra publisher cycle.  I believe you can copy from accepted.
[01:46] <skaet> slangasek,  you going to be around to review infinity's d-i?
[01:46] <slangasek> skaet: yes
[01:46] <skaet> :)
[01:46] <skaet> thanks
[01:46] <infinity> Not much to review.
[01:46] <slangasek> cjwatson: oh, that's handy
[01:46] <infinity> cjwatson: Can you?
[01:46] <cjwatson> (I sometimes don't when being paranoid, but I really don't see why not.)
[01:46] <wgrant> You can't copy binaries before the publisher runs
[01:47] <infinity> ^
[01:47] <cjwatson> Oh.
[01:47] <wgrant> Binaries aren't published until they're in DONE
[01:47] <cjwatson> Blast then.
[01:47] <wgrant> Rather
[01:47] <wgrant> Thank custom uploads :)
[01:47] <infinity> Now, what you CAN do is time your copy so it happens between the two publisher runs.
[01:47] <infinity> But that's tricky.
[01:47] <wgrant> Right, if you're really fancy you can copy after process-accepted but before publish-distro
[01:47] <infinity> And involves a lot of OOPSes while you hammer at trying to get it right. :)
[01:47] <infinity> Not that I've done this...
[01:48] <cjwatson> wgrant: Err.  The check for that appears to be after the bit that says "if it's the same series, the same archive, and include_binaries, then skip all further checks".
[01:49] <wgrant> cjwatson: that doesn't mean it'll actually copy the binaries
[01:49] <wgrant> It just means it won't create conflicting builds
[01:50] <wgrant> The copier uses SPPH.getBuiltBinaries
[01:50] <wgrant> Which returns a BPPH for each distinct BPR that's built by the source and published in the source's context
[01:50] <wgrant> The BPPHs don't exist until process-accepted runs
[01:51] <cjwatson> Oh, I missed that detail.
[01:51] <cjwatson> Of course, still a PackageUploadBuild until then.
[01:52] <cjwatson> Not that this is an insurmountable barrier, but it all starts looking rather like delayed copies if you aren't careful ...
[01:52] <wgrant> Don't even think about it :)
[01:52] <cjwatson> I think perhaps I should make attempt number two at going to bed instead.
[01:53] <wgrant> We can create BPPHs at accept time if we make custom uploads sensible
[01:53] <cjwatson> Yeah, custom uploads need a fairly substantial overhaul
[01:54] <cjwatson> CustomUploadsCopier is a moderately decent band-aid by now, but it's fundamentally a hack ...
[01:54] <wgrant> Pretty much
[01:54] <wgrant> More hack than decent
[01:54] <cjwatson> When really what it ought to be is "copy publication record, done"
[01:55] <cjwatson> decent in the sense that it more or less meets our requirements
[01:55] <cjwatson> despite sucking
[01:57] <wgrant> Yes
[02:10] <infinity> slangasek: shims copied, BTW.  Waiting on publisher run(s) now.
[02:10] <infinity> slangasek: Say, do you have a non-ES Panda lying around with precise installed on it?
[02:21] <plars> I think this is probably actually an ubuntu website bug, but bug #1065789 - I'm just getting sent to ubuntu.com when I click the release notes link
[02:21] <ubot2> Launchpad bug 1065789 in ubiquity "release notes link in installer points to www.ubuntu.com" [Undecided,New] https://launchpad.net/bugs/1065789
[02:21] <slangasek> infinity: I have only an ES Panda
[02:21] <skaet> infinity,  after publisher run,  d-i upload/build  then publisher,  then build isos?
[02:21] <slangasek> skaet: precisely
[02:21] <infinity> skaet: Yep.
[02:21] <slangasek> though infinity could upload d-i now and let it sit in the queue until the publisher is done
[02:22] <plars> more bothersome right now is that I can't install, at least in virtualization, if I've previously installed any other way besides lvm+crypted.  That seems to be bug #1065502
[02:22] <ubot2> Launchpad bug 1065502 in ubiquity "Ubiquity failed to proceed to partman" [Undecided,Confirmed] https://launchpad.net/bugs/1065502
[02:22] <infinity> slangasek: Dang.
[02:22] <plars> I have to go kill the partitions manually before I can get it to proceed
[02:22] <slangasek> infinity: ?
[02:22] <slangasek> infinity: oh, the panda, not the upload - yep, sorry
[02:22] <infinity> slangasek: Yeah, that. :P
[02:24] <skaet> slangasek, infinity - any insight into the bug that plars is highlighting?
[02:25] <slangasek> no insight
[02:25] <infinity> Nein.
[02:25] <slangasek> I can go digging and try to reproduce, but I need to step away for food first
[02:26] <infinity> d-i bounce at the queue.
[02:26] <infinity> bounced, too.
[02:27] <plars> it seems to also happen if I'm trying to install on top of, or side-by-side with a precise system
[02:27] <slangasek> skaet: btw, do you happen to have seen bug #1051306?  I've escalated it and targeted it, asking xnox to investigate; it's in a class of bug that potentially leaves the user with no way to get their machine back on the network if there are any bugs with Ubuntu drivers, so I think it needs to be followed up on before release and is a potential respin trigger
[02:27] <ubot2> Launchpad bug 1051306 in os-prober "windows not found unless partion is mounted" [Critical,Confirmed] https://launchpad.net/bugs/1051306
[02:27] <slangasek> it may also turn out to be a minor corner case that's been there forever and that we should ignore
[02:28] <slangasek> but better safe than sorry
[02:28] <skaet> thanks for flagging slangasek,  that one hadn't crossed my radar.
[02:28] <infinity> Last thing in the syslog is udisks2 registering with dbus, can we blame pitti?
[02:28]  * skaet adding it to the pad.ubuntu.com/ubuntu-release
[02:29] <slangasek> stepping away for food now; back soonest
[02:29] <skaet> k,  thanks.
[03:04] <slangasek> infinity: is the publisher done?
[03:04] <infinity> slangasek: Done enough for d-i to be building.
[03:04] <infinity> Hence the self-accept up there.
[03:05] <slangasek> ah
[03:05]  * skaet was wondering who did... :P
[03:05]  * slangasek goes back to his dinner :P
[03:05] <infinity> Om nom nom.
[03:34] <infinity> Fun.  armhf missed the publisher by about 5 seconds.
[03:37] <ScottK> Wasn't the goal maximizing your interference with wgrant's plans anyway?
[03:37] <infinity> Fair point.
[03:44] <skaet> infinity,  can I turn over the kicking off of the full set of rebuilds to you?
[03:45] <infinity> skaet: Sure.
[03:45] <skaet> Thanks.
[03:45] <skaet> I think I've got the pad updated to the key points now,  but if you spot anything else,  please add.
[03:45] <infinity> Sure.  I'll mostly just be kicking things off and going away.
[03:45] <infinity> But if something comes up...
[03:46] <skaet> there have been a couple of somethings...   see the bugs on the pad.    any of them you can help with?
[03:46]  * micahg hopes the publisher will be available in ~3.5 hrs
[03:49] <infinity> skaet: Not sure on the 3 installer bugs listed at this point, though I may look into one or two later.  Certainly not for this round.
[03:50] <skaet> ack.
[04:00]  * skaet --> zzz 
[04:35] <infinity> wgrant: All done with the publisher for now.
[04:35] <infinity> wgrant: For bonus points, it overlapped by 2m, so it's not running right now.
[04:39] <wgrant> infinity: Heh, thanks
[04:39]  * infinity rules out lp-buildd's sbuild in his libatomic-ops hunt, and starts running out of ideas.
[04:40] <wgrant> That's still not solved? :/
[04:40] <infinity> wgrant: Depends on which "that".
[04:40] <infinity> wgrant: Fixed it on i386, only to discover that it's now broken on armel.  But.  Only on the buildds.
[04:41] <infinity> wgrant: Several different machines/setups/etc, and I can't reproduce at all.
[04:41] <infinity> So frustrating.
[04:43] <wgrant> (publisher disabled now, but should be back before the next run anyway)
[04:52]  * slangasek eyes the build failures
[04:52] <slangasek> where'd security.ubuntu.com go?
[04:52] <infinity> Yeah, I was just seeing that.
[04:52] <infinity> Oh, is that what failed the world?  Hadn't look at logs yet.
[04:57] <infinity> slangasek: I need to take off soonish, might need someone else to restart this mess later.
[04:57] <slangasek> infinity: just doing the stuff from the pad?
[04:58] <infinity> Also curious if I can safely interrupt all of this...
[04:58] <infinity> Probably, it'll just let the current livefs builds spin and quit, I assume.
[04:58] <infinity> slangasek: Yeah, was just all 3 pipelines.
[04:58] <infinity> slangasek: Though, I'll be back later tonight, I can re-spin before I nap.
[04:59] <infinity> I might pick up that ubuntu-release-upgrader in proposed while I'm at it.
[04:59] <slangasek> as long as we're waiting for Godot to fix security.u.c, why not
[05:00]  * stgraber waves from the other side of the ocean
[05:00]  * infinity waves back.
[05:17] <wgrant> slangasek, infinity: Will you mind if we kill generate-contents-files today? We've run into its window now.
[05:17] <slangasek> wgrant: I don't think we mind
[05:17] <wgrant> That's what I suspected
[05:23] <wgrant> DB update is done, publisher reenabled
[05:27] <slangasek> wgrant: thanks
[05:27] <slangasek> so since we're still waiting for security to be usable again, copying ubuntu-release-upgrader to -release
[05:38] <ScottK> Finally got an ISO download finished.  I really miss my FIOS when I'm not at home.
[05:38] <infinity> slangasek: It was already copied.
[05:38] <infinity> slangasek: Notice your sync was [1:0.189 => 1:0.189]
[05:39] <slangasek> infinity: erm; I guess the bot didn't notice because of the connectivity problems
[05:40] <infinity> slangasek: The bot didn't notice because mine didn't go through the queue.
[05:40] <slangasek> ah
[05:41] <slangasek> infinity: mind letting the rest of the channel know what you're doing then, since it's hidden from the usual notification system? :)
[05:42] <infinity> slangasek: Ahh, I thought I'd implied strongly enough that I was doing the copy. :)
[05:42] <infinity> slangasek: No big deal.  Two won't hurt. :P
[05:42] <slangasek> infinity: perhaps "might" expresses a different verb tense up north ;)
[05:42] <infinity> Also, this pipeline is so going to completely run its course...
[05:42] <slangasek> are you getting successful builds out?
[05:42] <infinity> slangasek: "I might go out for poutine" is our way of saying "OH GOD, CHEESE CURDS AND GRAVY NOW".
[05:43] <infinity> slangasek: Yeah, since that first batch of failures, everything else has been a success.
[05:44] <slangasek> mmk
[05:44] <infinity> slangasek: http://paste.ubuntu.com/1274384/ <-- progress, so far.
[05:45] <infinity> If those end up being the only failures, cherry-picking some retries shouldn't be hard.
[05:45] <infinity> slangasek: I'll be back in a few hours, I'll check my terminals and see what needs tidying.
[05:46] <infinity> slangasek: Feel free to, like, sleep or something.
[05:46] <slangasek> I will when I'm done fighting with sbsigntool
[05:47] <infinity> Trying to fix the signature removal not returning the binary to its original state thing?
[05:47] <slangasek> yes
[05:48] <slangasek> concluded it's not (reasonably) possible because there's undeclared padding being added so we don't know the size of the pre-signed binary
[05:48] <slangasek> I mean, *we* know it, but sbattach doesn't
[05:49] <slangasek> so instead I'm going to see about recreating the signed binary using the extracted pkcs7 blob plus the original binary
[05:50] <infinity> Your diff looks like more than just padding, though.
[05:51] <slangasek> it's the padding, plus the resulting checksum
[05:51] <slangasek> where the checksum algo adds in the file size at the end
[05:51] <slangasek> also, I'm having to implement the checksumming
[05:51] <infinity> Ahh.
[06:03] <babyface> slangasek, for bug: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/985634, I think it's obvious and easy to fix, could you have a look on it?       I(victor zhou) add some translation suggestion  here:  https://translations.launchpad.net/ubuntu/quantal/+source/apt/+pots/apt-all/zh_CN/498/+translate
[06:03] <ubot2> Ubuntu bug 985634 in apt "Wrong translation during the installation process of Ubuntu 12.04 with choosing Simple Chinese as the installation language" [Low,Triaged]
[06:03] <babyface> but don't know how to make it used in the current build
[06:10] <slangasek> skaet: ^^ it looks like we have some bad translations in apt, which requires an apt package upload; this normally should be done immediately after the non-langpack translation deadline by somebody pulling the translations from launchpad and uploading, but apt wasn't on anyone's radar for this
[06:11] <slangasek> skaet: should we pull this in?
[06:11] <infinity> slangasek: If you hand-verify the diff to make sure the strings aren't broken.
[06:11] <infinity> (Well, or lint them)
[06:12] <slangasek> babyface: your comment on the bug also indicates that you've made a suggestion, which would not result in any changes to the translation export.  Someone on the translation team would need to ack this suggestion first...
[06:12] <slangasek> infinity: hey, I always review all translations before uploading them.  My question was about the timing, because this would definitely push back the start of candidate images
[06:13] <infinity> slangasek: I'd push to proposed, if I were you, and we'll pull it in as soon as we have another reason to rebuild (which, let's be realistic, we'll find one).
[06:13] <slangasek> well
[06:13] <slangasek> my hands are full, I'm not pushing it to proposed tonight
[06:13] <infinity> And if we don't, well.  We can decide if it's worth rebuilding just for apt.
[06:18] <babyface> slangasek, yes, I  talked this in #ubuntu-cn-translator, but got no reply   ;(
[06:18] <ScottK> Bug #1065827 is a "It would really suck to release this way" bug.
[06:18] <ubot2> Launchpad bug 1065827 in jockey "Kubuntu 12.10 bcmwl install failure" [High,New] https://launchpad.net/bugs/1065827
[06:19] <ScottK> Kind of need to get the network working from the ISO.
[06:19]  * infinity blinks at https://launchpad.net/ubuntu/+source/grub2-signed/1.6/+build/3898519
[06:19] <infinity> ^-- How did that only just finish 29 minutes ago?
[06:19] <infinity> And did this just invalidate all our builds?
[06:20] <slangasek> babyface: I would suggest talking to dpm, the Ubuntu translations coordinator, to see if he can help get this fixed
[06:20] <slangasek> babyface: as a rule, I don't put myself in the middle of translation disagreements for languages I don't read
[06:20] <micahg> infinity: amd64 wasin depwait
[06:21] <infinity> micahg: Yeah, I'm assuming that, but on what?  grub2 finished 5h previously.
[06:21] <slangasek> infinity: yes, yes it does
[06:21] <infinity> Unless the auto-dep-waity cronjob was busted. :/
[06:21] <micahg> infinity: the -bin package I thing
[06:22] <slangasek> it would have been dep-wait on grub2 if anything
[06:22] <babyface> slangasek, "dpm" ?  a person? which channel to find him ?
[06:22] <infinity> slangasek: Yeah, it would have been, but like I said, that finished 5h ago.  So, ugh.  Something went south here. :/
[06:22] <slangasek> babyface: David Planella; I think it might still be a little early for him to be around, but he can generally be found on #ubuntu-devel among others
[06:22] <babyface> slangasek, ack. thanks.
[06:23] <slangasek> infinity: I'm trying to think if this invalidates the d-i builds
[06:23] <slangasek> or if it's just the images
[06:23] <slangasek> I don't think d-i uses grub2-signed
[06:24] <infinity> It doesn't use grub at all.
[06:24] <slangasek> yes it does
[06:24] <infinity> Except to pull in grub-installer.
[06:24] <slangasek> incorrect
[06:24] <slangasek> it generates EFI-bootable images
[06:24] <infinity> Oh.  Right.
[06:24] <infinity> EFI things.
[06:24] <slangasek> but it does that by pulling them directly from archive.u.c
[06:25] <slangasek> so if those were up-to-date, it should be ok
[06:25] <slangasek> but I'm not sure how to check that other than by peeling apart the tarball
[06:25] <infinity> The build log could help.
[06:26]  * infinity goes a'greppin'.
[06:27] <infinity> The log seems less than helpful here.
[06:28] <infinity> slangasek: Yeahp, it was current.
[06:29] <infinity> slangasek: The log wasn't helpful on the efi.signed bit, but it did show that the current grub2 was the latest, and then the actual code in d-i checks apt-cache policy and grabs the efi bits from the mirror from the versioned directory matching the grub2 it just installed.
[06:29] <infinity> slangasek: So, that seems all good.
[06:32] <infinity> slangasek: But all our amd64 ISOs certainly will need rebuilding.
[06:32] <slangasek> yes
[06:32] <slangasek> well, at least it's just amd64
[06:32] <infinity> Still getting intermittent failures anyway, so IS is still not done.
[06:36] <infinity> Right.  Back in a whileish.  Will redo the world anyway, since we accepted new packages.
[06:36] <infinity> Or, a new package.
[06:36] <slangasek> did we?
[06:37] <infinity> ubuntu-release-upgrader
[06:37] <slangasek> ah, so that was after the builds started
[06:37] <infinity> Yeah, it was after we noted the issues with security.u.c
[06:38]  * slangasek nods
[06:38] <infinity> 22:59 < infinity> I might pick up that ubuntu-release-upgrader in proposed while I'm at it.
[06:38] <infinity> 22:59 < slangasek> as long as we're waiting for Godot to fix security.u.c, why not
[06:38] <infinity> Anyhow, that hits pretty much every image, so once the buildds quiet down (or, if I get IS to slap them around for me), I'll restart the mess.
[06:38] <infinity> Once security/archive are also known-sane.
[06:39] <infinity> Which doesn't seem true yet.
[06:39] <infinity> So, back in a bit.  Respinning when I get back, ish.  Toodles.
[06:47] <ScottK> balloons: We need the "Install (entire disk with lvm and encryption)" test case added for Kubuntu live builds.
[06:48] <ScottK> infinity: When you get back, would you please look at Bug #1065827 and assign it to the right piece of the build infrastructure?
[06:48] <ubot2> Launchpad bug 1065827 in jockey "Kubuntu 12.10 bcmwl install failure" [High,New] https://launchpad.net/bugs/1065827
[06:48]  * ScottK needs to go to bed.
[06:49] <babyface> slangasek,  translation  suggested by me was reviewed by some guy in the translator team just now, so the change will affect in next build?
[06:50] <jibel> ScottK, testcase added as mandatory
[06:50] <ScottK> jibel: Thanks.
[06:52] <ScottK> OK.  Bed time.
[08:07] <Daviey> infinity: if you are still around, what was the fun and games building livefs?
[08:51] <didrocks> Laney: hello, here is the change we discussed about the legal notice. It's been tested by 5 persons, (english and french locale) to confirm the correct locale is picked up. The html file just have few changes since yesterday's push to the ppa regarding the comments. No code change. (see linked bug) ^
[09:08] <didrocks> cjwatson: hey, it seems Laney isn't around today, maybe you can have a look? (it's something on skaet's radar and legally required)
[09:23] <didrocks> Daviey: ^ (continuing my small route of hunting release team people :p)
[09:24] <xnox> skaet: I am marking bug 1065789 as ubiquity correctly reads the URL from the iso, and correctly goes there. The website then redirects to the homepage instead of quantal release notes.
[09:24] <ubot2> Launchpad bug 1065789 in ubiquity "release notes link in installer points to www.ubuntu.com" [High,Invalid] https://launchpad.net/bugs/1065789
[09:25] <xnox> skaet: I don't know the "making the release steps" so I don't know if the link was meant to be working already.
[09:26] <xnox> skaet: it would be nice to make that link work through all the milestones though =/ not just final images.
[09:26] <Laney> didrocks: yeah, sorry, I'm off today and won't have time to review
[09:27] <didrocks> Laney: no worry :)
[09:30] <Daviey> didrocks: hola
[09:30] <didrocks> Daviey: hey hey :-)
[09:30] <Daviey> didrocks: I am on holiday today...
[09:30] <Daviey>  .. nah, just kidding :)
[09:31] <didrocks> argh, you too?
[09:31] <didrocks> tsss :p
[09:31] <didrocks> Daviey: I would have continued my fallback list otherwise :p
[09:31] <Daviey> didrocks: This is the unity upload in the queue?
[09:31] <didrocks> Daviey: right, do not hesitate if you have any question
[09:32] <cjwatson> didrocks: mm, yeah, sorry, better somebody who's more awake deals - security vuln last night and then was up half the night with a sick child
[09:32] <cjwatson> somebody will probably need to add it to the pad as a rebuild trigger I guess
[09:32] <pitti> so, skaet asked me to take bug 985634
[09:32] <ubot2> Launchpad bug 985634 in apt "Wrong translation during the installation process of Ubuntu 12.04 with choosing Simple Chinese as the installation language" [Low,Triaged] https://launchpad.net/bugs/985634
[09:32] <pitti> that means pulling the updated translation into apt and doing an upload
[09:32] <didrocks> cjwatson: no worry, good luck with your child. I hope they'll get better soon
[09:32] <pitti> infinity: ^ I think you already discussed that some hours ago?
[09:33] <pitti> or is that just a minor thing not worth respinning?
[09:33] <didrocks> Daviey: basically, it's the same version that QA tested on the ubuntu-destkop ppa yesterday. I just fixed some html links (no code change) since.
[09:33] <Daviey> didrocks: is there a screenshot of the change in action?
[09:33] <didrocks> Daviey: can do some, one sec
[09:33] <cjwatson> xnox: invalid is incorrect, as it is still a bug although not in ubiquity.  I've reassigned to the proper place.
[09:35] <cjwatson> deleted bug 1065789 from the list of potential respin triggers, as a website fix will not require a respin
[09:35] <ubot2> Launchpad bug 1065789 in ubuntu-website-content "release notes link in installer points to www.ubuntu.com" [Undecided,New] https://launchpad.net/bugs/1065789
[09:35] <seb128> pitti, images will be respined anyway, there is an unity update that needs to go in
[09:35] <pitti> it affects all images, though; server, flavours, etc.
[09:36] <seb128> pitti, the shopping stuff needs a pointer to details about "what we do with your datas" to confirm to some UE laws
[09:36] <pitti> don't get me wrong, I'm not particularly pushing here; if you guys say "don't bother", I'll be more than happy :)
[09:36] <xnox> cjwatson: ok. I was not sure, hence mentioned it here.
[09:36] <seb128> confirm->conform
[09:36] <xnox> seb128: UE -> EU
[09:37] <seb128> xnox, not in french :p thanks ;-)
[09:37] <skaet> pitti, from my understanding from the backscroll,  I think the best course is to put it in -proposed,  and then we'll pick it up if possible.
[09:37] <xnox> seb128: well conform is not in frech either ;-)
[09:37] <seb128> dammit
[09:38] <Laney> ah, it only shows once, that's better than I feared
[09:38] <didrocks> Daviey: http://people.canonical.com/~didrocks/tmp/legal1.png this is the first time you open it
[09:38] <didrocks> Daviey: once you clicked on the link, you get the webpage opened and then further dash opening will show http://people.canonical.com/~didrocks/tmp/legal2.png
[09:38] <didrocks> clicking on the (!) icon opens the webpage again
[09:41] <Daviey> didrocks: I assume legal have ack'd the implementation as suitably closing the bug?
[09:42] <didrocks> Daviey: yeah, legal and design worked together on how this should be presented
[09:53] <pitti> skaet, infinity: apt uploaded to -proposed queue FYI
[09:53] <skaet> thanks pitti
[09:59] <Daviey> didrocks: another upload on the way?
[09:59] <didrocks> Daviey: I dputed -f 10 minutes ago… waiting…
[10:00] <didrocks> and checked the terminal that it took enough coffee :)
[10:01] <Daviey> didrocks: sure it hasn't been rejected ?
[10:01] <didrocks> Daviey: didn't get any email either
[10:01] <Daviey> I would have expected it to show by now.. ok, will wait another 5
[10:01] <didrocks> Daviey: I can try to dput again (but the last command succeeded)
[10:01] <cjwatson> Launchpad was just down briefly for a database update
[10:01] <Daviey> ah
[10:02] <wgrant> Yeah, cronjobs will be back on in a couple of minutes
[10:02] <cjwatson> So I expect the queue cron jobs were off
[10:02] <didrocks> cjwatson: does it catchup or it's going to the void? :)
[10:02] <cjwatson> It'll catch up
[10:02] <didrocks> ah ok :)
[10:02] <didrocks> thanks cjwatson, wgrant
[10:02] <didrocks> Daviey: I was starting to think I needed to EOW now :p
[10:03] <Daviey> didrocks: Can you add your screenshots to the bug report, and email ubuntu-docs to let them know.  I suspect it doesn't matter if they refresh the images or not for this, but they'll judge that.. It's clearly more important it lands.
[10:03] <wgrant> Right, we just stop processing incoming for 10-15 minutes around DB upgrades. It'll process the queue as soon as it's turned back on
[10:03] <didrocks> Daviey: indeed, doing it now
[10:03] <Daviey> super
[10:04] <cjwatson> wgrant: Although process-upload was apparently never turned off; I assume it's an earlier stage
[10:05] <cjwatson> Oh, ignore me, I can't read
[10:05] <cjwatson> "Disabled by DEFAULT section"
[10:05] <wgrant> Yeah
[10:05] <cjwatson> didrocks: it's in the queue now
[10:05] <wgrant> We turn them off centrally with a config file now
[10:05] <cjwatson> Yeah, I knew that but forgot :)
[10:05] <wgrant> Rather than having to push out new crontabs to 20 machines
[10:05] <didrocks> thanks :)
[10:06] <didrocks> Daviey: ^
[10:06] <Daviey> didrocks: will be lazy and wait for lp to generate a diff for me. :)
[10:06] <didrocks> heh ;)
[10:22]  * infinity catches up with the queue.
[10:27] <infinity> pitti: Did we not want to refresh all of apt's translations?
[10:27] <infinity> pitti: Rather than just the one?
[10:27] <pitti> infinity: not sure, I was rather cautious
[10:27] <infinity> pitti: Could you do a full import and see how big/scary the diff is?
[10:28] <xnox> isn't apt in a langpack anyway?
[10:28] <pitti> infinity: I guess we could, if you prefer that
[10:29] <pitti> xnox: well, it is because it's not that trivial to filter out, but we ship the mo files in the apt package
[10:29] <xnox> I see, ok. plus for the installer we want more langs than langpacks.
[10:29] <infinity> pitti: I'd like to see the results of such an import, I guess, then I can decide which one to take. :P
[10:30] <pitti> "Your request has been received. Expect to receive an email shortly."
[10:31]  * infinity tries to sort out why libmotif bumped SOVER if it's supposedly binary compatible with the previous version...
[10:36]  * infinity holds off on re-re-spinning until the apt translations are sorted out.
[10:36] <wgrant> (that translation export finished a few minutes back, so the email should be there)
[10:36] <infinity> wgrant: Stalker.
[10:37] <infinity> Hey, I think pypy might actually build on armhf this time around.  Neat.
[10:37] <wgrant> Just wanted to clarify that Launchpad really did mean "shortly" this time, and you don't have to wait for 3 hours :)
[10:39] <xnox> wgrant: you remind me of the xkcd comic about progress dialog.
[10:39] <infinity> cjwatson: I'm torn between "tear out cairo-5c from the archive, and its one rdep" and "beat Keith with a stick until he provides a source package that's (a) not crack, and (b) builds".
[10:45] <infinity> Oh, I may have spoken too soon on pypy, it still has a day to go...
[10:46] <didrocks> skaet: as unity will need to be rebuilt anyway and we need to respin an iso, can you have a look if we can sneak gsettings-desktop-schemas in? It fixes bug #1060249 which will be triggered by a lot of upgraders if they have a debconf question. It's a revert of a previous upload to readd a deprecated gsettings schema. ^
[10:46] <ubot2> Launchpad bug 1060249 in debconf "frontend crashed with signal 5 in free_pending_nulls()" [High,Confirmed] https://launchpad.net/bugs/1060249
[10:46] <didrocks> jibel: FYI ^
[10:47] <infinity> didrocks: Impressive duplicate list.
[10:47] <infinity> didrocks: Where's the diff?
[10:47] <didrocks> infinity: isn't it? quite surprising we didn't see it on our radar first
[10:47] <jibel> there are much more but all set to invalid because retracing failed
[10:47] <pitti> infinity: http://people.canonical.com/~pitti/tmp/apt-translation-refresh.patch FYI
[10:47] <didrocks> infinity: http://paste.ubuntu.com/1274710/
[10:47] <infinity> didrocks: Anyhow, if you're confident I'll like the diff, upload now, so I can get it built.
[10:48]  * xnox so wants that bugfix in. Isn't it one of the top crashes on errors?
[10:48] <pitti> infinity: caution, 5 MB beast
[10:48] <didrocks> infinity: it's in unapproved
[10:48] <didrocks> infinity: the diff is trivial, and I built and installed it to check that the schemas indeed is there then (and seen by gsettings)
[10:48] <infinity> didrocks: It's just an upgrade ordering issue?
[10:48] <infinity> didrocks: Couldn't a Breaks solve this for you?
[10:49] <jibel> xnox, does errors.u.c reports crashes that failed to retrace ?
[10:49] <didrocks> infinity: right, we try to do that on the safe side, because for next LTS, we'll need to transition it anyway
[10:49] <didrocks> infinity: and for that, we need the old schema around
[10:49] <skaet> didrocks,  I'll go along with infinity's recommendation on this one.  (that is an impressive list of duplicates indeed.  :P )
[10:49] <xnox> jibel: if you ask ev, he tells you the numbers =)
[10:49] <didrocks> thanks skaet :)
[10:50] <jibel> ev, ^ did errors.u.c catch #1060249 ?
[10:50] <cjwatson> bug 1065827 - oh dear, I think that's a casper bug
[10:50] <ubot2> Launchpad bug 1065827 in jockey "Kubuntu 12.10 bcmwl install failure" [High,Invalid] https://launchpad.net/bugs/1065827
[10:51] <cjwatson> and a nasty one - I saw it on Ubuntu too
[10:52]  * infinity tries to filter the noise out of that apt diff so he can read it before Tuesday...
[10:53] <didrocks> thanks infinity :)
[10:55]  * cjwatson adds 1065827 as a respin trigger and gets fixing
[10:55] <skaet> thanks cjwatson.
[10:56] <infinity> pitti: Yeah, pull the trigger on the refresh, assuming some po-linting thing thinks that's all formatted correctly.
[10:56] <infinity> pitti: I saw a ton of strings in there with obvious fixes.
[10:56] <infinity> (And I only read a few languages)
[10:57] <pitti> infinity: LP does some consistency checks, yes
[10:58] <cjwatson> pitti: Well, um, I'm not quite sure what's going on here with bug 1065827
[10:58] <ubot2> Launchpad bug 1065827 in casper "Kubuntu 12.10 bcmwl install failure" [Critical,Triaged] https://launchpad.net/bugs/1065827
[10:58] <cjwatson> The first part is a casper bug
[10:58] <cjwatson> It's checking for /.disk/info rather than /root/cdrom/.disk/info
[10:58] <cjwatson> So that much is an easy fix
[10:58] <pitti> infinity: so do you want to reject the current upload then? Then I'll alter history in bzr
[10:58] <cjwatson> After I do that, software-properties -> Additional Drivers is able to apply the change to bcmwl-kernel-source
[10:58] <infinity> pitti: Alter away.
[10:58] <cjwatson> But it doesn't actually load the wl module
[10:59] <cjwatson> And if I load the wl module, I don't appear to get a wireless interface
[10:59] <pitti> cjwatson: is that the same problem? i. e. apt not finding/using the package on the CD pool?
[10:59] <cjwatson> The casper fix deals with that part of it
[10:59] <pitti> your's sounds like you'd be a lot further
[10:59] <cjwatson> We seem to have a pyramid of fail, though
[11:00] <cjwatson> And I can't find much in the way of useful logs
[11:00] <cjwatson> I have to fix casper anyway since that bug's likely to have all kinds of weird side effects, and it's a clear identified regression
[11:03] <pitti> hm, it's green on https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-ubuntu-drivers-common/lastSuccessfulBuild/ARCH=i386,label=albali/, but we only check that "modinfo wl" works
[11:03] <pitti> not that it gets autoloaded or actually works (that wouldn't work in those tests)
[11:04] <cjwatson> Do you have a system where you can reproduce this, or would it be helpful to teleoperate me?
[11:06] <cjwatson> I was actually trying to reproduce a completely different bug, but seeing as I'm here ...
[11:07] <pitti> cjwatson: ScottK says it happens in the kubuntu live system
[11:07] <cjwatson> I'm running today's Ubuntu desktop amd64 image, from USB
[11:08] <pitti> but that applied to the earlier problem of not finding the packages in pool
[11:08] <cjwatson> With the casper fix applied manually using break=casper-bottom
[11:08] <pitti> cjwatson: let me download the current i386 and test on my netbook
[11:08]  * pitti trying to do 5 things at once
[11:08] <cjwatson> Boot with break=casper-bottom, run   sed -i 's,.disk/info,root/cdrom/.disk/info,' /scripts/casper-bottom/41apt_cdrom   and exit 0
[11:08] <cjwatson> You should then get a sensible sources.list
[11:09] <pitti> infinity: I uploaded a new apt_0.9.7.5ubuntu3.dsc with full LP export
[11:09] <infinity> pitti: Danke.
[11:11] <cjwatson> I'll try i386 in case there's a difference
[11:12] <pitti> cjwatson: I can try it on my atom netbook which is i386 only
[11:25] <infinity> Oh crap, that apt was to proposed, I didn't even look.
[11:25] <infinity> Oh well.
[11:26] <cjwatson> I suspect we have enough to do that it won't matter that much
[11:26] <pitti> infinity: wasn't it supposed to be?
[11:26] <infinity> Yeah, it's just the cycle to squeeze it in when I notice it's done everywhere. :P
[11:26] <infinity> pitti: Nah, we knew a respin was coming up anyway, so faster is better.
[11:26] <pitti> infinity: copying requires publication in -proposed first?
[11:27] <infinity> pitti: Yup.
[11:27] <infinity> pitti: Can't copy unpublished binaries.
[11:27] <pitti> infinity: ah, sorry; I got asked to upload to -proposed
[11:27] <infinity> pitti: Nah, s'all good.
[11:27] <infinity> pitti: Just blaming myself for not noticing the target. :)
[11:27] <cjwatson> pitti: identical symptoms here on i386
[11:27] <pitti> cjwatson: still waiting for usb-creator to finish
[11:28] <pitti> cjwatson: so module builds fine, but doesn't actually work?
[11:28] <cjwatson> why bother, just dd it
[11:28] <pitti> ah, right; old habit
[11:28] <cjwatson> indeed
[11:28] <cjwatson> the PCI ID is 14e4:4315, which is in the list if I'm reading modinfo correctly
[11:28] <cjwatson> Of course worth checking on your machine in case it's something bizarrely specific to this card ...
[11:29] <pitti> right, otherwise neither jockey nor u-d-common would even detect it; it reads the modaliases from the pacakge header, which come straight out of modinfo
[11:29] <cjwatson> slangasek: BTW, following last night, what's our dbx update plan for 12.10?
[11:30] <infinity> Whoa.  Haven't seen the chroot tarball uncompress failure in ages.
[11:30] <infinity> I thought it was gone. :/
[11:30] <pitti> erk, apt armhf FTBFS?
[11:30] <pitti> oh, CHROOTWAIT; I guess that's what infinity is looking at
[11:30] <infinity> Uh, everything on meissa for a long while.
[11:30] <infinity> Yeah, fixing.
[11:31] <cjwatson> Oh my, yes.
[11:32] <cjwatson> infinity: https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3842217 is spurious data corruption too
[11:34] <skaet> side effect of the launchpad work earlier?
[11:34] <infinity> No.  side-effects of Pandas being awful.
[11:34] <skaet> k  :P
[11:34] <infinity> Nothing new there, just sad that it's not magically resolved in the last year or two.
[11:35] <cjwatson> Yeah, been seeing it for ages.  It's just annoying.
[11:35] <cjwatson> Although I do worry that it might show up for, like, real users.
[11:36] <cjwatson> Launchpad database changes would have to be really inventive to manage to cause build failures; the build slaves are at arm's-length.
[11:36]  * xnox ponders if I am a real or an unreal user.
[11:37] <wgrant> Yeah, dropping DB tables and columns doesn't tend to corrupt files on buildds like that :)
[11:37] <pitti> cjwatson: product ID 4315 here as well; seddery worked fine, package installed from pool; but just as you modprobe wl doesn't actually do anything
[11:37] <infinity> wgrant: "Doesn't tend to" isn't ruling out the remote possibility.
[11:38] <pitti> cjwatson: that worked in earlier releases, seems our bcmwl isn't compatible with our current kernel any more?
[11:38] <wgrant> infinity: It's difficult to rule anything Launchpaddy out with certainty...
[11:38] <cjwatson> Yeah, but there's also no point in postulating magic causes.
[11:39] <cjwatson> pitti: I'm also suspicious about why wl wasn't auto-loaded; what's supposed to do that?
[11:39] <cjwatson> (This may be a complex of three bugs, not two ...)
[11:39] <pitti> cjwatson: normally udevtrigger at boot
[11:40] <pitti> cjwatson: I suppose ubiquity's magic to build it for you in the background before it offers you to choose a network does a manual modprobe?
[11:40]  * pitti RTFS
[11:40] <cjwatson> Err
[11:40] <infinity> pitti: udev isn't retriggered after we build modules?
[11:40] <cjwatson> I mean, what's supposed to do that when you run software-properties to enable the proprietary module
[11:40] <cjwatson> That's clearly neither boot nor ubiquity
[11:41] <pitti> hm, I see nothing in bcmwl's postinst
[11:41] <cjwatson> Didn't jockey use to do it, or am I misremembering?
[11:41] <pitti> yes, it did
[11:43] <pitti> but even after modprobe, I wonder why it doesn't actually detect any device
[11:43] <cjwatson> So is it not a bug that the jockey replacement fails to modprobe?
[11:43] <cjwatson> I agree that the failure to detect the device is yet another problem
[11:43] <pitti> oh, it is a bug
[11:44] <cjwatson> But currently you've changed the bug state such that there doesn't appear to be a bug task for the lack of modprobe
[11:44] <pitti> it'd need to go into the postinst
[11:44] <cjwatson> Oh, you think it should be there?  OK
[11:44] <pitti> i. e. some clever udevadm trigger, perhaps not just a blunt modprobe
[11:44] <pitti> well, my goal is to have "apt-get install bcm.." DTRT
[11:45] <cjwatson> OK
[11:45] <pitti> that doesn't affect the graphics drivers, but it does affect wl
[11:46]  * cjwatson draws #ubuntu-kernel's attention to it
[11:46] <infinity> Maybe udev itself needs a dpkg trigger that driver-related packages can register with (though that's way out of scope for a week before release)
[11:46] <infinity> So we can just do one big udevadm at the end of a run.
[11:46]  * pitti takes notes in the bug
[11:47] <pitti> I'll figure out an udevadm invocation and post it there
[11:49] <pitti> cjwatson: ooh
[11:50] <pitti> cjwatson: it gets claimed by the b43 driver
[11:50] <pitti> so bcmwl installs the blacklist file just fine, but apparently the postinst doesn't rmmod them
[11:51] <pitti> right now that package is designed for "works after reboot"
[11:51] <cjwatson> Ah, good catch
[11:51] <pitti> yep, that's it
[11:51] <cjwatson> Yes, modprobe -r b43; modprobe wl works
[11:51] <pitti> rmmoding b43 ssb, modprobe wl, et voila
[11:51] <cjwatson> Just after I'd unearthed a spare Ethernet cable :-)
[11:52] <pitti> hmm
[11:52] <pitti> the postinst actually has that already
[11:53] <pitti> ah no, I misread
[11:53] <cjwatson> Only if b44's loaded
[11:53] <pitti> right, but that's just written into the blacklist file, not executed
[11:53] <cjwatson> Well
[11:54] <cjwatson> Since it's an 'install wl' rule, it'd be executed on modprobe wl
[11:54] <pitti> so it seems to me the straightforward fix owuld be to add the rmmod || true and modprobe wl || true to the postinst
[11:54] <cjwatson> If it had been written
[11:54] <cjwatson> Which it hasn't
[11:55] <pitti> cjwatson: what you see there is just a workaround for loading b44 and wl in the right order
[11:56] <pitti> but that's just written into a modprobe.d file; it doesn't do anything to "run" those
[11:56] <pitti> I followed up to the bug again
[11:57] <pitti> want me to create/test/upload a fix?
[11:57] <cjwatson> Like I say, 'install' commands in modprobe.d files are executed if the corresponding module is loaded
[11:57] <cjwatson> I agree it doesn't do anything to load the module
[11:57] <cjwatson> Sure
[11:57]  * cjwatson moves on to the next bug :)
[11:59]  * apw smiles ... great
[12:01] <infinity> cjwatson: debian/rules reinvoking itself?  That seems an unorthodox way to write that. :P
[12:02] <cjwatson> infinity: I was matching binary-arch
[12:02] <cjwatson> It's certainly not the way I'd ordinarily write it, but when in Rome
[12:02] <infinity> I was waiting for you to say it matched context, so I could die a little inside.
[12:02] <cjwatson> That rules file is pretty awful.
[12:03] <cjwatson> dh solved so many ills by getting people to throw away their inability to write make.
[12:04] <infinity> Yeah, I'm wishing I hadn't read the context.
[12:06] <pitti> infinity, cjwatson: bcmwl to release or -proposed?
[12:06] <cjwatson> release
[12:06] <pitti> uploaded
[12:06] <pitti> admittedly I did some shortcuts to the testing; dpkg --unpack, scp the new postinst, and dpkg --configure -a
[12:06] <pitti> (faster than tryign to set up a full build env on the netbook)
[12:07] <pitti> that caused NM to see the device/networks right after configuration now
[12:07] <infinity> dpkg-deb -R && edit DEBIAN/postinst && dpkg-deb -b && dpkg -i
[12:07] <infinity> ^-- How I prefer to test maintscript mangling.
[12:08] <infinity> And kinda required if it's a preinst instead of a postinst.
[12:08] <cjwatson> I did not know about -R.
[12:08] <cjwatson> Learn something new ... some days.
[12:08] <infinity> cjwatson: I didn't until slangasek hit me with an RTFM bat after I mentioned I used ar and tar.
[12:09] <cjwatson> Oh, this is cheating, it was added after 1999
[12:09] <infinity> I think it's "new".  Which means "been around for years, but not since 199... Jinx".
[12:09] <cjwatson> (Specifically, in September 2011)
[12:09] <cjwatson> dpkg 1.16.1
[12:09] <infinity> Oh, not even years.  Year.
[12:09] <infinity> I don't feel so bad.
[12:09] <infinity> But yeah, it's pretty handy.
[12:14]  * infinity wonders if everyone goes through a phase of using ":" for "true" when they realise they're essentially synonymous builtins in most POSIX shells.
[12:15] <infinity> Except, y'know, : is only readable to people with good eyesight. :P
[12:16]  * skaet hands infinity a cup of coffee, as she pours one for herself.
[12:17] <infinity> At this time of night, a gin would be more appropriate.
[12:19]  * skaet hands infinity some "english coffee" then,  ;)  http://www.drinksecrets.com/drinks/english-coffee/d483
[12:20] <infinity> Sounds like a poor man's Massive Destruction Weapon.
[12:20] <skaet> yeah,  it is interesting what google turns up from paired keywords.  ;)
[12:21] <infinity> There's pretty much no way to respond that and not make it dirty, so I'll refrain.
[12:22]  * skaet laughing too much to type properly.
[12:26]  * ogra_ would leave the coffee out of that reciepe and keep it for the next morning though
[12:27] <ogra_> intresting that english coffee needs an irish glass :)
[12:28] <infinity> The UK is a confusing place.
[12:28] <infinity> I'm sure it's best served with cheese toasties too.
[12:28]  * infinity glares at this ghostscript build to get it to finish before :33
[12:29] <infinity> Hey, glaring worked.
[12:29] <ogra_> heh
[12:29] <skaet> infinity,  worth copying apt over from -proposed?
[12:30] <infinity> skaet: Yeah, can't until after it publishes.
[12:30] <infinity> I'm taking ghostscript too, hence the glaring.
[12:31] <skaet> k
[12:32] <infinity> So, in an hour or less, I'll be respinning the world, unless anyone has anything else that's a showstopper.
[12:33] <didrocks> "world creator", that's impressive :)
[12:33] <cjwatson> plars: I've chased the release notes symlink with the web team - it should be sorted later today
[12:34] <cjwatson> infinity: I'd like to chase bug 1051306
[12:34] <ubot2> Launchpad bug 1051306 in os-prober "Windows not found unless partition is mounted" [Critical,Confirmed] https://launchpad.net/bugs/1051306
[12:34] <cjwatson> Currently restoring my sacrificial Windows install to see if I can reproduce it
[12:34] <infinity> cjwatson: Alright.  If you make any progress (or complete lack) in the next hour, poke me.
[12:35]  * infinity copies apt and ghostscript.
[12:35] <cjwatson> :/true> : is defined as being a special built-in rather than a regular built-in, so it's marginally different
[12:37] <infinity> cjwatson: In some shells, they're the exact same codepath, but yes, I realise they're not necessarily identical.  In the case of "foo || [blank]", though, "true" is the more readable option.
[12:38] <cjwatson> I do tend to use "true" there, yes.
[12:38] <infinity> (That was what I was poking fun at pitti for, he had "|| :" in that last upload.
[12:38] <infinity> )
[12:39] <pitti> infinity: c'est ne pas bon?
[12:39] <pitti> infinity: I can reupload with || true if you prefer, but || : seems quite common in our scripts, too
[12:40] <infinity> pitti: I accepted it, it's bon enough.
[12:40] <pitti> the rmmod will always fail, as not all of the specified modules can be loaded at the same time (or even exist)
[12:40] <pitti> so at least it survived the dpkg -i tst
[12:40] <pitti> test
[12:40] <infinity> pitti: Anyone who knows POSIX shell knows what it means, and anyone who doesn't should learn.  I just find || true more readable, personally.
[12:41] <pitti> yeah, old "shell builtin vs. external program" thingy
[12:41] <tkamppeter> slangasek, hi
[12:41] <infinity> pitti: true is a builtin in most shells.
[12:41] <infinity> pitti: It's /bin/true that isn't. :P
[12:41] <pitti> infinity: yeah; I guess I shoudl change my habits
[12:42] <pitti> we all know how easy that is!
[12:42] <cjwatson> Also I prefer 'modprobe -r' to 'rmmod'
[12:42] <cjwatson> But too late now and it should do
[12:43] <infinity> pitti: Yeah, my habits need a pretty solid reason to change, generally.
[12:43] <pitti> cjwatson: OOI, what's the difference?
[12:44] <infinity> Plus, muscle memory.  Like, I've never switched to debuild from dpkg-buildpackage (for instance), not because I find debuild technically inferior (though it has some questionable defaults) but just because I type "dpkg-buildpackage -i -I -rfakeroot -uc -us -S -nc" so quickly, it's frightening.
[12:44] <cjwatson> Very minor :-)
[12:44] <cjwatson> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_14
[12:45] <infinity> And I'm pretty sure all or most of those switches are no longer necessary, even.
[12:46]  * infinity glances at the nvidia flood.
[12:46] <cjwatson> Oh, also special built-ins aren't guaranteed to be usable with execve.
[12:46] <cjwatson> And regular built-ins can be preempted by functions, but special built-ins can't.
[12:47] <cjwatson> true () { false; }
[12:47] <infinity> On the other hand, if you redefine true(), you kinda deserve what you get.
[12:47] <cjwatson> ^- how to confuse anyone reading your shell script
[12:47] <infinity> Which is likely a punch in the face.
[12:47] <cjwatson> Huh
[12:48] <cjwatson> Actually, I think bash is non-compliant here
[12:48] <cjwatson> You can redefine : in bash ...
[12:48] <cjwatson> dash won't even let you try - you get "bad function name"
[12:49] <cjwatson> But you can redefine, say, fg in dash too
[12:49] <cjwatson> Oh, no, that's a regular built-in
[12:49] <infinity> I must have missed the mention that specials can't be redefined.
[12:49] <cjwatson> Can't redefine break
[12:49] <infinity> Though, again, not sure why you'd want to.
[12:50] <cjwatson> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01
[12:55] <cjwatson> Ah, bash rejects : () { false; } in POSIXLY_CORRECT mode
[12:57] <cjwatson> Damn, I thought I'd found that rare beast, a bash bug. :-)
[12:59] <infinity> cjwatson: So, we totally distracted you with scintillating POSIX discussions.  How goes the OS probing?
[13:05] <cjwatson> infinity: cannae reproduce here.  I'd suggest not blocking on respins for it for the meantime.
[13:05] <cjwatson> I've asked the reporter for a bit more information
[13:06] <infinity> Hrm.  Seems somewhat ironic that the last upload of gmap was by BenC to "fix FTBFS on many arches", but powerpc failed.
[13:07] <infinity> cjwatson: Alright, respinning in ~20m then.
[13:09] <infinity> And WTF, mate?  Where did armel's kgpg binary go?
[13:09] <infinity> Oh, proposed.
[13:09] <infinity> Partial/early copy.
[13:09] <xnox> infinity: cjwatson: I use dpkg-deb -R but bash-completion doesn't know about it, so it's a pain.
[13:10] <cjwatson> infinity: resurrectable, or no-change rebuild?
[13:10] <infinity> cjwatson: Should be resurrectable.
[13:10] <cjwatson> We need to make sru-release check for this, I think.
[13:10] <infinity> Yeah, we do.
[13:10] <cjwatson> People get it wrong so often ...
[13:12] <infinity> cjwatson: Though, I'm not sure everyone uses sru-release -r for devel copying either.
[13:13] <infinity> cjwatson: (At least, I assume vorlon was using copy-package or something that landed his copy in the queue, rather than bypassing it)
[13:13] <infinity> Speaking of queues...
[13:13] <cjwatson> Indeed.
[13:13] <infinity> Let's see if that accepts or oopses.
[13:15] <cjwatson> You can use copy-package --auto-approve.  It depends whether you're wearing a developer hat or an archive admin hat.
[13:15] <infinity> cjwatson: Oh, also, fun on the ARMv5 rebuild.  libatomic-ops is totally a static library that gets included by a few compilers.  And it's been v7 on armel the whole time.
[13:15] <cjwatson> Score
[13:15] <infinity> Yeah, I'll need to try to trace just how bad that really is.
[13:15] <infinity> GCC doesn't use it on anything except ia64.
[13:15] <infinity> But GCJ uses it universally, I believe.
[13:16] <cjwatson> Same way syncpackage *could* auto-approve for archive admins, but doesn't, because people who happen to be archive admins might well sync stuff from Debian acting as developers and want review.
[13:16] <cjwatson> It's probably too late to rebuild GCJ now ...
[13:16] <infinity> Yeah.  If only "reviewing" wasn't a pain in the butt for syncs.
[13:16] <infinity> That's getting higher and higher on my annoyance list.
[13:17] <cjwatson> Yeah, either I should fix that LP bug, or I should make queuediff magically do pull-debian-source; pull-lp-source; debdiff
[13:17] <cjwatson> Fixing the LP bug might be easier ...
[13:17] <cjwatson> (Given it probably already *has* the packagediff from somewhere else.)
[13:17] <cjwatson> (Well, sometimes.)
[13:18] <infinity> It generates it after accept, I think, not before.
[13:18] <infinity> For syncs where it didn't have one for another reason.
[13:18] <cjwatson> In Ubuntu, sure, but it might well have it in Debian.
[13:18] <cjwatson> In any case, it ought to be trivial to get it to generate it
[13:18] <infinity> Oh, sure, it may have a debian->debian diff.
[13:18] <infinity> ubuntu->debian, it won't, but it should be made to.
[13:19] <infinity> Though, if there's queue diff bug hunting afoot, the much simpler (I suspect) "make queue diffs consider all subset pockets" bug also needs stabbing.
[13:19] <cjwatson> Hmm, rakudo at least gets past the buildd failure point on scheat
[13:20] <cjwatson> That's sadly not especially simple.  The whole ancestry handling code is a 'mre.
[13:20] <cjwatson> *'mare
[13:20] <cjwatson> I've looked at it in the past and been reduced to leaving despairing comments.
[13:21] <infinity> Oh, that's unfortunate.
[13:21] <infinity> It sounds easy, in principle.  But I wasn't thinking along the lines of actual ancestry tracing.
[13:21] <infinity> Just defining a table of pocket subset/superset, and searching down through your set for the most recent version to diff against.
[13:22] <infinity> Might still goof up in the case of security, which isn't a superset of updates, but occasionally bases updates on updates.
[13:22] <cjwatson> wgrant and I talked about it a while back.
[13:23] <infinity> Otherwise, it's pretty linear.
[13:23] <cjwatson> There are at least three different implementations of the same idea, arguably four
[13:23] <cjwatson> I think there might be an excuse for at most two different behaviours
[13:23] <cjwatson> The whole lot needs to be consolidated and done properly
[13:24] <ScottK> cjwatson and pitti: Thanks for tackling my bcmwl bug.  I've got about 5 hours of solid meeting in front of me, but should have some time to do additional testing before my flight home.
[13:25] <kenvandine> i have a an update for chromium for their stable channel, should i upload that to -proposed?  or let the security team put it in -security?
[13:25] <infinity> Oh, hrm.  This kgpg was in the same set that Ridell broke before and ScottK and wgrant spent time rescuing.
[13:26] <pitti> ScottK: yw; thanks for pointing this out, those were two rather general and important bugs
[13:26] <infinity> kenvandine: If you plan to test and bless it by release, -proposed is fine, and we can move it to the release pocket.
[13:26] <ScottK> infinity: We ended up reuploading everything.  I guess I missed one.
[13:27] <kenvandine> infinity, can do
[13:27] <infinity> ScottK: Oh.  Fun.  Care to do that one too? :P
[13:27] <ScottK> Sure thing.
[13:28] <cjwatson> infinity: meissa's exploding again
[13:28] <infinity> Ugh, meissa, again?
[13:28] <infinity> Jinx.
[13:29]  * infinity sets to manual, and will deal with it after kicking off builds.
[13:29] <infinity> So.  Rebuilding the world.  Any last objections?
[13:30] <cjwatson> Is kgpg on any of the images?
[13:30] <cjwatson> Kubuntu DVD apparently
[13:30] <infinity> Oh, indeed.
[13:30] <cjwatson> Which we don't seem to build any more
[13:30] <cjwatson> So whatever :)
[13:30] <infinity> Yeahp. :P
[13:31] <xnox> cjwatson: infinity: my hand made grab-sync wrapper: does the two pull sources, debdiff and test build... that's how I "sponsor" syncs =) http://paste.ubuntu.com/1274916/
[13:31] <cjwatson> Well, sure, I do something similar
[13:31] <cjwatson> But it would be more helpful for LP to do it
[13:32] <infinity> Especially for those of us with only 100Mbit at home.
[13:32] <highvoltage> skaet: sorry for not looking at those release notes for edubuntu before (and thanks for taking care of it, it's looking good)
[13:32]  * infinity is poverty-stricken, according to his Korean friends.
[13:33] <pitti> "only" 100 MBit, *weep*
[13:33] <ScottK> infinity: On the way.
[13:34] <infinity> pitti: It's only 10Mbit up, if that makes you feel better.
[13:34] <pitti> /quit patting my poor DSL line
[13:36] <ScottK> infinity: It's in the queue, not sure why queuebot didn't notice.
[13:37] <infinity> ScottK: Because queuebot is fickle.
[13:37] <infinity> ScottK: (And also not in the channel)
[13:37] <skaet> highvoltage,  adjust, sort, refine as needed.  :)
[13:37] <ScottK> That would do it.
[13:49] <Riddell> I just pushed a fix for visible formatting strings in kde frontend bug 1065989
[13:49] <ubot2> Launchpad bug 1065989 in ubiquity "[kde] formatting for strings visible in string" [Undecided,Confirmed] https://launchpad.net/bugs/1065989
[13:50] <xnox> Riddell: that's not enough.
[13:50] <xnox> Riddell: you should change the actual po files with sed and remove those bits as well.
[13:51] <xnox> otherwise you loose the translations to that string across the board.
[13:55] <cjwatson> skaet: I'm going to miss at least some of the update call today - there's a presentation I need to attend
[13:55] <cjwatson> Assuming G+ likes me this time round
[13:55] <smartboyhw> skaet, oh so there will not be a role of Release Manager ever?
[13:55] <skaet> cjwatson, understood.
[13:56] <skaet> thanks for letting me know.
[13:57] <ScottK> smartboyhw: Prior to slangasek we survived some years without one.  Hopefully making it possible for non-Canonical people to run more bits of the release process will get done, so we can help out.
[13:58] <smartboyhw> Ah:D
[13:58] <cjwatson> bug 1051306 looking like a GRUB bug - whee
[13:58] <ubot2> Launchpad bug 1051306 in grub2 "Windows not found unless partition is mounted" [Critical,Triaged] https://launchpad.net/bugs/1051306
[14:00] <ScottK> There's a chromium-browser update in the queue.  Do Lubuntu/Mythbuntu want to try and land that if there is an opportunity?
[14:01] <skaet> ScottK,  Mythbuntu isn't participating in 12.10 ;)
[14:01] <skaet> gilir, ^ thoughts?
[14:01] <ScottK> OK.  Well that narrows it down.
[14:01] <gilir> ScottK, is there a package to test somewhere ? or the changelog ?
[14:02] <infinity> ScottK: It's going in if/when it can.
[14:02] <ScottK> http://launchpadlibrarian.net/119585836/chromium-browser_22.0.1229.79~r158531-0ubuntu1_source.changes
[14:02] <ScottK> infinity: Any reason not to go ahead and get it building then?
[14:03] <infinity> ScottK: Nope, just hadn't reviewed it yet.  If you want to poke, have a look.
[14:04] <gilir> I would prefer to test it a bit just to be sure, or to push it as soon as possible to test it on the next ISO :)
[14:04] <plars> xnox: hi, are you looking at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1065034 actively?
[14:04] <ubot2> Ubuntu bug 1065034 in ubiquity "'ubuntu ubiquity: umount: /tmp/tmp.h3NCLhoxSh: not mounted' during a Reinstall attempt on a previously manually partioned vm installation" [High,Confirmed]
[14:05] <infinity> It's going to proposed, so we can test from there.
[14:05] <xnox> plars: yes.
[14:07]  * Riddell hugs skaet 
[14:07] <skaet> Thanks Riddell
[14:08]  * smartboyhw hopes that the Release Team will do better than before in 13.04!
[14:09] <xnox> skaet: /me is sad.
[14:09] <smartboyhw> skaet, /me also
[14:10] <ScottK> The linux-firmware in queue looks like something we ought to have.
[14:10] <smartboyhw> Actually who is NOT sad here raise up your hands please
[14:12] <ScottK> skaet: I'm going to accept linux-firmware to proposed and we can copy it over when there's a window.
[14:17] <skaet> ScottK,  ok
[14:17] <rtg> ScottK, the linux-firmware update is for a staging driver and doesn't affect many folks yet, though we will likely begin to see more of these devices in the real world.
[14:17] <infinity> "This commerts reverts to that older firmware."
[14:17] <infinity> rtg: Not awake yet? ;)
[14:18] <ScottK> Accepts.
[14:18] <IdleOne> skaet: This is not a major issue but you should also accept cheques as payment
[14:18] <ScottK> gilir: I accepted chromium-browser too, so there will be packages ~shortly.
[14:18] <smartboyhw> IdleOne, isn't check = cheques?
[14:19] <rtg> infinity, copy&paste from the original commit log entry.
[14:19] <skaet> IdleOne,  can you open a bug?  (me assuming this is about contribute, etc.)
[14:19] <cjwatson> what
[14:19] <infinity> rtg: Corpies and pastes, surely?
[14:19] <cjwatson> the comment was about the topic
[14:19] <IdleOne> skaet: no the topic :) Sorry for disrupting, won't happen again
[14:19] <rtg> surely
[14:20] <skaet> IdleOne, sorry got confused with http://www.omgubuntu.co.uk/2012/10/ubuntu-adds-new-donations-page
[14:22] <gilir> ScottK, ok thanks, I'll keep an eye on it
[14:22]  * skaet did mass mark
[14:22] <skaet> for rebuilding on iso tracker
[14:25]  * infinity decides to take another stab at libatomic-ops before admitting defeat.
[14:26] <smartboyhw> LOL
[14:28]  * skaet is betting on libatomic-ops at this point, given the past commentary on the subject, and lack of sleep infinity has been having.  :P
[14:28] <NCommander> jamespage, on bug #1065903, the Suggests change seems to be rather minimal, given it won't effect dependencies or even default apt-get behavior. Is there something I'm missing?
[14:28] <ubot2> Launchpad bug 1065903 in glance "glance should Suggest: python-ceph, not ceph-common" [Medium,In progress] https://launchpad.net/bugs/1065903
[14:29] <NCommander> morning skaet
[14:29] <skaet> morning NCommander
[14:33] <ev> ^ Another single line change that will bring much happiness. This lets us bucket KernelOops problems together.
[14:34] <Riddell> skaet: I put bug 1065989 under rebuild triggers
[14:34] <ubot2> Launchpad bug 1065989 in ubiquity "[kde] formatting for strings visible in string" [Undecided,Confirmed] https://launchpad.net/bugs/1065989
[14:34] <skaet> Thanks Riddell
[14:35] <jamespage> NCommander, its a very minimal but highly accurate change :-)
[14:35] <jamespage> I'd rather send out the right messages about how much we have tested ceph with openstack this cycle
[14:35] <jamespage> and I think suggesting the correct packages is quite important
[14:36] <jamespage> NCommander, I have a similar on for cinder which zul is working on ATM
[14:37] <NCommander> jamespage, I don't disagree, but we don't even show suggests information in the software center (or do we?), or in APT by default. Forcing a rebuild to merely update a bit of metadata that isn't used anywhere in the default install (and is well hidden 90% of the time) seems a bit crazy given the time to final release
[14:38] <jamespage> NCommander,  apt-cache show glance -> Suggests: ceph-common
[14:39] <NCommander> the well hidden bit :-)
[14:39] <jamespage> NCommander, not really concerned about software centre as this is a server related package
[14:41] <skaet> jamespage,  put it to -proposed.   If there is a good opportunity it may get considered as an opportunity target, but at this point we need to keep churn down to only the critical bits.
[14:41] <mvo> fwiw, software-center will use the "suggess" to display "addons" in the details page
[14:42] <mvo> (no idea if that matters or not in this case, but still wanted to mention it ;)
[14:42] <NCommander> mvo, good to know.
[14:42] <jamespage> NCommander, skaet: OK - please reject then and I'll re-upload to -proposed
[14:43] <infinity> ev: You would have made me much happier if that upload had been 2 hours ago.
[14:43] <NCommander> jamespage, done
[14:43] <ev> infinity: :)
[14:43] <smartboyhw> skaet, is this page actually updated? https://wiki.ubuntu.com/ReleaseManagement/ReleaseImageContacts
[14:44] <infinity> smartboyhw: Looks fairly stale to me.
[14:44] <smartboyhw> infinity, er at least the Xubuntu one is not correct......How could the project manager not = knome?
[14:44] <slangasek> infinity: oh huh; you didn't learn -R from me, -e was the one I pointed at
[14:44]  * smartboyhw is puzzled
[14:44] <infinity> smartboyhw: stale, meaning wildly out of date.
[14:45] <slangasek> tkamppeter: hey there
[14:45] <smartboyhw> infinity, oh hurray I learnt a new word!
[14:45] <infinity> slangasek: You told me about -e when I was using ar and tar and then I read the manpage and decided -R was awesome.
[14:45] <smartboyhw> stale:P
[14:46] <slangasek> infinity: nice :)
[14:47] <tkamppeter> slangasek, I have asked for some more info in the CUPS bug, and error_log with the "last words" of cupsd before dying, your cupsd.conf, and whether your cups is correctly broadcasting its queues via Avahi.
[14:48] <slangasek> tkamppeter: ack
[14:51] <skaet> smartboyhw, infinity is right,  that page is out of date, and we have been pretty much handling this by the manifest wiki page based on comments at last UDS.  I'll clean up the references.
[14:51]  * skaet adds it to the list.
[14:51] <smartboyhw> Yay!
[14:51] <smartboyhw> Thx skaet
[14:51] <jamespage> NCommander, re-uploaded to -proposed as requested
[15:20] <smartboyhw> skaet, https://wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/UbuntuStudio#System_Requirements we will change it to 768MB but then the 2GB or more memory thing will still exist:D
[15:21] <skaet> thats fine.  thanks smartboyhw,  just make the change.  :)
[15:21] <smartboyhw> skaet, :)
[15:22] <smartboyhw> skaet, changed it just now:D
[15:26] <infinity> ^-- Me admitting defeat for now.
[15:30] <cjwatson> Hah
[15:31] <cjwatson> It'll have to do
[15:32] <infinity> How are there no open Debian bugs on rhmessaging failing to build, like, everywhere?
[15:33] <infinity> For 127 days...
[15:33] <smartboyhw> Wow:D
[15:34]  * infinity just dumps the outdated ppc binaries and carries on.
[15:34] <smartboyhw> !
[15:38] <smartboyhw> Does anyone know if ubuntustudio-default-settings 0.38 is accepted?
[15:38] <cjwatson> https://launchpad.net/ubuntu/+source/ubuntustudio-default-settings
[15:38] <cjwatson> Says yes
[15:38] <infinity> Several days ago.
[15:38] <smartboyhw> cjwatson, duh I am still seeing ubuntustudio-default-settings	0.37 in the manifest
[15:39]  * smartboyhw is scratching his head
[15:39] <cjwatson> You're looking at an old image then.
[15:39] <cjwatson> Current one says 0.38/
[15:39] <cjwatson> .
[15:39] <smartboyhw> ...
[15:39] <infinity> http://cdimage.ubuntu.com/ubuntustudio/dvd/current/quantal-dvd-amd64.manifest
[15:39] <infinity> Definitely 0.38
[15:40] <smartboyhw> oh damn it is what did I go on? Sorry cjwatson infinity
[15:47] <slangasek> ^^ has a few bugfixes we want for our SB toolchain
[15:50] <plars> seb128: I was looking at bug 1060368, and it appears that it may be fixed now
[15:50] <ubot2> Launchpad bug 1060368 in libunity-webapps "reloading when a webapp is open causes the webapp icon to disappear from the launcher" [Medium,Confirmed] https://launchpad.net/bugs/1060368
[15:50] <plars> seb128: however, https://bugs.launchpad.net/ubuntu/+source/libunity-webapps/+bug/1060274 still seems to be there, yet it is marked fix released
[15:50] <ubot2> Ubuntu bug 1060274 in libunity-webapps "webapps do not show up in dash search after installation" [Undecided,Fix released]
[15:50] <cjwatson> So, I have two choices for fixing this grub-mount bug
[15:50] <cjwatson> I can implement full symlink support, making symlinks to directories show up properly
[15:51] <ScottK> slangasek: Accepted.
[15:51] <slangasek> ScottK: ta
[15:52] <cjwatson> Or I can implement a quick-and-dirty (and possibly non-upstream) hack to ignore GRUB_ERR_BAD_FILE_TYPE when reading a directory and trying to get the properties of a non-directory, which will have the effect that symlinks to directories will behave oddly (missing from directory listings, you get ENOTDIR when trying to list them individually, etc.) but won't make the rest of the containing directory appear empty
[15:52] <infinity> Okay, libatomic-ops can take a long walk off a short pier.  Now the testsuite's misbehaving on powerpc.
[15:52] <cjwatson> I'm inclined to do the latter
[15:55] <xnox> cjwatson: i am ok with a later. the OP had a symlink to directory. And os-probe doesn't require reading symlinks to directories to detect stuff.
[15:56] <cjwatson> xnox: Indeed, that's part of what tipped me off to this being the pattern
[15:56] <cjwatson> We hope it doesn't require reading symlinks to directories, anyway :)
[15:56] <cjwatson> I suspect the odd corner case may still fail, but it will be a lot rarer
[15:57] <cjwatson> You'd have to actually hit the sym->dir directly, rather than just trying to list a directory that contains one
[15:57]  * xnox takes mental note to symlink /etc for fun
[15:57] <cjwatson> Quite
[15:59] <slangasek> wat
[15:59] <slangasek> pretty sure Debian Policy doesn't guarantee the symlink won't reach up off the disk and strangle you if you do that
[16:00] <cjwatson> I don't see what's wrong with symlinking /etc, as long as it's to somewhere on the same fs
[16:00] <xnox> slangasek: who cares about Debian Policy, when we are crafting a test case to fail grub-mount when trying to os-detect Windows 7....
[16:01] <cjwatson> After all this is part of the reason why dpkg doesn't automatically replace symlinks with directories and vice versa
[16:04] <slangasek> cjwatson: well, there was a recent (< 2y) policy discussion about the rules for relative vs. absolute symlinks so maybe this has changed now, but it used to be that making symlinks out of system dirs would result in wrong traversals
[16:05] <slangasek> doko, infinity: seeded, thanks
[16:06] <cjwatson> slangasek: /etc -> /foo would be fine though
[16:06] <slangasek> I suppose :)
[16:10] <xnox> that was my cunning plan =)
[16:10] <xnox> and see how much stuff fails =)
[16:14] <plars> ogra_: yeah, on today's arm image (20121012.2) I'm getting this same issue with not being able to exit the installer and get to a live session
[16:15] <ogra_> well, thats rather minor i would say as long as the installer does its duty :)
[16:16] <ogra_> something we can release note
[16:16] <plars> ogra_: going to retry the install, but that's how I noticed it actually, when installer crashed on me last night
[16:17] <plars> ogra_: interestingly, if I ctrl-alt-f1 *before* quitting the installer, then I can get to a vt
[16:17] <cjwatson> I've moved bug 1051306 to a rebuild trigger, since I just uploaded a fix.
[16:17] <ubot2> Launchpad bug 1051306 in grub2 "Windows not found unless partition is mounted" [Critical,Fix committed] https://launchpad.net/bugs/1051306
[16:18]  * ScottK is confused.  I see .3 ^^^, but the latest at http://cdimage.ubuntu.com/kubuntu/daily-live/ is .1.  Am I looking in the wrong place?
[16:19] <cjwatson> ScottK: It's .3 on nusakan; it's probably just taking a while to sync to cdimage.u.c.
[16:22] <xnox> ogra_: vt 7 handover not happening properly on panda for me as well.
[16:22] <ScottK> cjwatson: Thanks.
[16:23]  * ogra_ isnt sure what to make out of that ... everything worked fine in beta2
[16:27] <plars> ogra_: yeah, ubiquity is crashing at the same place for me on arm.  I'll try it again with a different usb stick in a moment, but this is suspicious.  Rather than letting it kill the installer and restart my session this time, I just went to a text console
[16:28] <ogra_> hmpf, i geuss i'll try an install myself
[16:28] <rtg> ogra_, I did rebase ti-omap4 against master a couple days ago. I wonder if it introduced a regression.
[16:28] <rtg> ppisati, ^^
[16:31] <ogra_> hmm, probably
[16:32] <plars> ogra_: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1066046 is the bug, hggdh is also trying an install right now
[16:32] <ubot2> Ubuntu bug 1066046 in ubiquity "ubiquity crashes after user info screen on panda" [Undecided,New]
[16:33]  * ogra_ takes a look
[16:35] <ogra_> plars, oh, yeah there is an oops in the syslog
[16:36] <plars> ogra_: there's a python trace from install.py, and a slowpath warning from kernel, possibly from when I did ctrl-alt-f1
[16:36] <ogra_> yeah
[16:37] <infinity> rtg: The ARM coherent DMA stuff could relate.
[16:37] <xnox> I think I have a fix for bug 1065034
[16:37] <ubot2> Launchpad bug 1065034 in ubiquity "'ubuntu ubiquity: umount: /tmp/tmp.h3NCLhoxSh: not mounted' during a Reinstall attempt on a previously manually partioned vm installation" [High,Confirmed] https://launchpad.net/bugs/1065034
[16:37] <infinity> rtg: I'll note that the armadaxp rebase reverted a couple of those commits, claiming conflicts.
[16:38] <xnox> it affects all images but: core, cloud and pre-install. I think. partman-auto bug.
[16:38] <rtg> infinity, different source base, so Ike could well have had some patch conflicts.
[16:39] <infinity> rtg: Oh, no, I'm sure it really did *conflict* in his case, and not yours.  My point is that if it's conflicted with the armadaxp stuff, it's likely something nasty and intrusive, cause so is their patch. ;)
[16:39] <infinity> rtg: So, it may have broken ti-omap4, despite not actually conflicting in the patch sense.
[16:40] <rtg> infinity, true, especially with DMA coherency. I'll get ppisati to have a look when he gets back.
[16:42] <slangasek> cjwatson: so as of today, we have a server image that we think will boot on stgraber's laptop, correct?  (linux-signed + shim that avoids LoadImage)
[16:42] <cjwatson> slangasek: I hope so
[16:42] <slangasek> ok
[16:48] <seb128> plars, can you ping #webapps or kenvandine about those?
[16:48] <plars> seb128: already did
[16:48] <seb128> plars, thanks
[16:50] <plars> ogra_: I'm trying a different usb stick now, one that I've used before, and it seems to exit the installer at the same point but never gives me the screen saying it's going to restart the installer.  I'm left with just a spinning mouse cursor, and can't even exit to a text console
[16:54] <jibel> bug 1066049 on server
[16:54] <ubot2> Launchpad bug 1066049 in plymouth "No graphical boot screen on server installation" [Undecided,New] https://launchpad.net/bugs/1066049
[16:55] <cjwatson> I didn't think there was meant to be.
[16:55] <slangasek> there isn't
[16:55] <jibel> after installation ?
[16:55] <cjwatson> Netboot probably differs because it doesn't really know which product it's installing, in some sense.
[16:56] <slangasek> jibel: yes.  This is as specified by the server team
[16:56] <cjwatson> But the server ISO preseeds debian-installer/splash to false.
[16:56] <cjwatson> If you netboot with debian-installer/splash=false as a boot parameter you'll get the same effect.
[16:56] <jibel> ah ok, thanks, that was a quick fix :)
[16:56] <jibel> sorry
[16:57] <slangasek> :)
[16:58] <ScottK> Is bug 1065034 considered RC?
[16:58] <ubot2> Launchpad bug 1065034 in ubiquity "'ubuntu ubiquity: umount: /tmp/tmp.h3NCLhoxSh: not mounted' during a Reinstall attempt on a previously manually partioned vm installation" [High,Confirmed] https://launchpad.net/bugs/1065034
[16:58] <xnox> ScottK: yes
[16:58] <ScottK> Riddell: Are your ubiquity changes committed?
[16:58] <xnox> ScottK: have a fix. Doing final testing and will upload. actually it's a bug in partman-auto
[16:59] <ScottK> xnox: When you upload, please make sure you've got Riddell's string fix.
[16:59] <ScottK> slangasek: I have to head out, but if we've definitely got a new Ubiquity upload coming, I think linux-firmware should get copied to -release.
[16:59] <cjwatson> xnox: have you committed the partman-auto fix?
[16:59] <plars> ogra_: hggdh confirms this behavior on his board also
[16:59] <cjwatson> ScottK: yeah, it's in bzr
[16:59] <ScottK> I'll be back in a bit.
[16:59] <ScottK> Thanks.
[16:59] <xnox> cjwatson: didn't commit it yet. doing one last test, and then will push a branch for you to see merge proposal and then upload.
[16:59] <ogra_> plars, yeah , looks like multiple bugs though
[17:00] <cjwatson> xnox: or I can just have a quick look at a paste
[17:00] <ogra_> but i cant find any upload the recent days that could have broken the user setup in ubiquity
[17:00] <plars> ogasawara: any chance they could all be related to the kernel update that rtg mentioned?
[17:00] <rtg> plars, yes, which is why I'd like ppisati to have a look (as I don't have HW)
[17:02] <slangasek> ScottK: linux-firmware and ubiquity> confirmed, looking now
[17:03] <slangasek> Riddell, skaet: AIUI, bug #1065989 touches ubiquity, so seems to be a respin trigger for all desktop images, not just the Kubuntu ones?
[17:03] <ubot2> Launchpad bug 1065989 in ubiquity "[kde] formatting for strings visible in string" [Undecided,Fix committed] https://launchpad.net/bugs/1065989
[17:03] <infinity> slangasek: Check.
[17:04] <slangasek> marked as such on the pad
[17:04] <cjwatson> slangasek: Yes.  A bit moot given the grub2 upload though.
[17:04] <slangasek> mm that too
[17:04] <xnox> cjwatson: http://paste.ubuntu.com/1275233/ for the same reasons reuse choises was failing, the do_options fails as well (ro mount fails if journal replay is required, while grub-mount handles it fine)
[17:04] <slangasek> cjwatson: well, it means we shouldn't start respinning other desktop images between the time grub and ubiquity land
[17:04] <xnox> slangasek: *cough* partman-auto
[17:05] <infinity> Dear qemu-user-static, please stop segfaulting.  Thanks.
[17:05] <slangasek> xnox: context?
[17:05] <xnox> slangasek: the ubiquity bug is actually in partman-auto.
[17:05] <xnox> slangasek: and I did reproduce it with server images.
[17:05] <slangasek> xnox: there are multiple ubiquity bugs in flight :)
[17:05] <infinity> xnox: Two different u... What he said.
[17:05] <xnox> slangasek: ah, sure. =)
[17:06] <xnox> we will respin the world....
[17:06] <slangasek> good times
[17:08] <cjwatson> xnox: That looks right as far as it goes, but could you please also make automatically_partition/replace/choices use grub-mount in the same way for the same reason?
[17:08] <cjwatson> (I think I commented on this when you fixed reuse/choices :-) )
[17:08] <cjwatson> slangasek: true
[17:08]  * xnox will be switching to gnome-session-fallback compiz is eating more cpu time than kvm
[17:09] <xnox> cjwatson: heh. I feel like refactoring that snippet now.
[17:09] <cjwatson> Perhaps, but not for 12.10 :-)
[17:09] <cjwatson> I agree there's a lot of cut-and-pasting hre
[17:09] <cjwatson> *here
[17:10]  * infinity copies glance to the release pocket, since there's respinning afoot, and it's a harmless change.
[17:10] <xnox> cjwatson: yeah, don't want to refactor 12.10 release out of 2012.
[17:10]  * cjwatson fixes up 1065034's metadata
[17:12] <slangasek> linux-firmware in
[17:16] <xnox> cjwatson: what is replace option and how to test it?
[17:17] <ppisati> rtg: ogra_ sorry, which bug i'm a bit lost
[17:18] <ogra_> ppisati, well, all of them :)
[17:18] <ogra_> seems everyone had display issues with today panda image
[17:18] <rtg> ppisati, not sure a bug has been assigned, but I'll let ogra_ tell you about it.
[17:18] <ogra_> *todays
[17:18] <cjwatson> xnox: don't remember offhand, ev would know
[17:18] <skaet> slangase,  Riddell,  is there evidence of it showing up anywhere else?
[17:18] <skaet> slangasek, ^
[17:18] <cjwatson> xnox: the code is very similar though so you ought to be able to apply it mechanically
[17:18] <ogra_> ppisati, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1066046
[17:18] <ubot2> Ubuntu bug 1066046 in ubiquity "ubiquity crashes after user info screen on panda" [Critical,Confirmed]
[17:19] <ogra_> ppisati, and the one you filed today
[17:19] <ogra_> there might be more
[17:19] <slangasek> skaet: of what?
[17:19] <ppisati> well
[17:19] <cjwatson> xnox: oh, it's "use entire partition" when there's already an existing Ubuntu installation there, I think
[17:20] <ppisati> ogra_: jsalisbury with a yesterday image was able to complete an installation
[17:20] <ppisati> ogra_: but the "black screen until you switch tty was there"
[17:20] <slangasek> skaet: if you meant the kubuntu ubiquity bug, we can't exactly have the desktop images going out without an up-to-date ubiquity...
[17:20] <ppisati> ogra_: he went back to beta2 and he said he was there too
[17:21] <ppisati> ogra_: i remember i had this problem too when i couldn't test some patches from linaro
[17:21] <cjwatson> skaet: we'll need an updated ubiquity for xnox's partman-auto fix anyway, which is more pervasive
[17:21] <ppisati> ogra_: in fact i sent the kernel to rsalveti to test it
[17:21] <skaet> yes,  that's the one.   Just wondering if the symptom was showing up elsewhere.
[17:21] <ogra_> well, i havent seen it ever
[17:21] <cjwatson> so it's moot
[17:21] <ppisati> ogra_: but he said everything was ok
[17:21] <skaet> cjwatson,  yup, that makes it moot.
[17:21] <ppisati> ogra_: IMO today's ubiquity exploding has nothing to do with the video bug
[17:22] <ogra_> no
[17:22] <ogra_> i didnt claim that :)
[17:22] <ppisati> ah ok
[17:22] <ogra_> but until today i havent heard about video probs
[17:22] <ppisati> you mean the screen switching problem?
[17:22] <ogra_> thes seem to have shown up recently
[17:22] <ppisati> lp 1065902
[17:22] <ubot2> Launchpad bug 1065902 in linux-ti-omap4 "black/blue screen before installer, tty switch fixes it" [Medium,Confirmed] https://launchpad.net/bugs/1065902
[17:22] <ppisati> this one?
[17:23] <ogra_> there was another one
[17:23] <ogra_> but yeah, that one as well
[17:28] <xnox> cjwatson: ok. confirmed that reuse is fixed. now will test that replace works/doesn't explode and then will upload.
[17:28] <xnox> http://paste.ubuntu.com/1275283/
[17:29] <ppisati> ogra_: i'm downloading beta2 now
[17:29] <ogra_> k
[17:30] <cjwatson> xnox: Looks plausible except for the spurious change of "replace" to "reuse" in two places.
[17:31] <xnox> cjwatson: aha.
[17:32] <xnox> cjwatson: thanks.
[17:34] <xnox> http://paste.ubuntu.com/1275289/
[17:35] <xnox> why is kubuntu-alternate on the pad again....?!
[17:35] <plars> ev: what's the story with wubi-r273-signed.exe? Should it not complain about the digital signature when you try to run it?
[17:37] <slangasek> stgraber: jet lagged? :)
[17:37] <slangasek> plars: -signed.exe should not complain about the digital signature.  What's the complaint?
[17:38] <seb128> skaet, btw the thunderbird-messaging menu fix, we will aim at SRU, it's just too late to land that for release
[17:38] <plars> slangasek: it's just the typical windows warning that it can't verify the publisher when I try to run it
[17:38] <skaet> thanks seb128,  gotcha
[17:38] <seb128> skaet, https://wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/UbuntuDesktop should be mostly good as well, so if people want to start proofreading of fixing style they are welcome to
[17:38] <slangasek> ev: ^^ wubi signatures are still done through IS, right?
[17:38] <seb128> of->or
[17:39] <plars> slangasek: but it wasn't clear to me if that's expected, or needs an extra step to tell windows where to verify the signature
[17:39] <infinity> xnox: It's not actually being built, no idea why it's listed.
[17:39]  * infinity removes.
[17:39]  * skaet hugs seb128 :)   will start bring others in then.  :)
[17:39]  * seb128 hugs skaet back
[17:40] <ppisati> jsalisbury: didn't you find lp 1065902 in beta2 images?
[17:40] <ubot2> Launchpad bug 1065902 in linux-ti-omap4 "black/blue screen before installer, tty switch fixes it" [Medium,Confirmed] https://launchpad.net/bugs/1065902
[17:41] <balloons> skaet, who on the call this morning was mentioning the ARM bug?
[17:41] <jsalisbury> ppisati, yes
[17:41] <ppisati> ogra_: ^
[17:41] <slangasek> plars: fortuitously, the digital signature format should be the same as what's used for Secure Boot, so we might actually have some tools now that work for inspecting this.  What's the URL of the wubi you're using, and is there any chance you can get a more detailed error message out of Windows?
[17:41] <jsalisbury> ppisati, I confirmed it with the daily build from yesterday
[17:42] <ogra_> jsalisbury, what brand is your monitor ?
[17:42] <slangasek> plars: but yes, the "signed" copy is the one that's explicitly supposed to be signed into the Microsoft PKI chain
[17:42] <plars> slangasek: it does appear that it is signed, if I look at properties it says name: Canonical UK Ltd. Email: Not available, and has a countersignature from symantec time stamping services signer -G3
[17:42] <slangasek> ok
[17:43] <jsalisbury> ogra_, It's a Samsung P2350
[17:43] <plars> slangasek: http://people.canonical.com/~evand/wubi/quantal/
[17:43] <plars> slangasek: ah, I think I see the problem
[17:43] <ogra_> jsalisbury, hmm, samsung here too ...
[17:44] <plars> if I look at the certificate, it says it's valid from 10/6/2010 to 10/6/2012
[17:44] <jsalisbury> ogra_, I'm using a HDMI cable through a HDMI to DVI converter
[17:44]  * ogra_ remembers there were issues with samsungs EDID reporting in omap in the past
[17:44] <ogra_> a converter ?
[17:44] <slangasek> plars: the certificate itself expired, not the signature?
[17:44] <ogra_> oh, your monitor only has DVI in ?
[17:45] <jsalisbury> ogra_, well, adapter.  HDMI in on one side and DVI out on the other
[17:45] <jsalisbury> ogra_, correct
[17:45] <plars> slangasek: it would appear so, yes
[17:45] <slangasek> ok
[17:45] <ogra_> jsalisbury, and you attached to the DVI socket on the panda ?
[17:45] <slangasek> fyi, sbsigntool segfaults on wubi, so I'm no help ;)
[17:45] <skaet> balloons,  not remembering clearly,  sorry.
[17:46] <jsalisbury> ogra_, yes.  I booted Oneiric and didn't have the issue.
[17:46] <slangasek> plars: can you screenshot the full certificate output or something, so we can raise an RT?
[17:46] <jsalisbury> ogra_, I could try precise as well and maybe perform a bisect
[17:46] <infinity> zul: Can you reupload that nova to -proposed?
[17:46] <zul> infinity: sure
[17:47] <infinity> zul: Thanks.
[17:47] <plars> slangasek: sure, let me see what I can get from this
[17:47] <ogra_> jsalisbury, well, in quantal we have to ship the binaty x driver by default on the image, oneiric to precise is plain xfbdev
[17:47] <ogra_> so there is quite some difference across the board
[17:47] <jsalisbury> ogra_, ok
[17:49] <ppisati> ogra_: i can confirm the same issue with beta2 img, pandaes and a benq monitor
[17:50]  * infinity thinks it might be time for a siesta.
[17:51] <infinity> FWIW, the last batch of builds are all done, so the livefs builders are unblocked once people are ready for another spinneroo.
[17:52] <ogra_> ppisati, do you know if its still there after installation ?
[17:52] <infinity> slangasek, skaet, whoemever ^
[17:52] <ppisati> ogra_: yes, it's still there
[17:52] <slangasek> infinity: ta
[17:52] <ogra_> hmpf
[17:52] <ogra_> rsalveti, any idea ? ^^^
[17:52] <skaet> infinity,  ack.
[17:52] <ppisati> are beta1 images available anywhere?
[17:52] <jsalisbury> ogra_, I see it after every reboot
[17:54] <skaet> ppisati, http://cdimage.ubuntu.com/releases/quantal/beta-1/
[17:54] <ppisati> skaet: found them, thans
[17:54] <ppisati> *thanks
[17:54] <ogra_> http://cdimage.ubuntu.com/releases/quantal/beta-1/
[17:54] <ogra_> bah, skaet beats me
[17:54] <skaet> :)
[17:54] <ogra_> :)
[17:55] <ppisati> beta1 had the flickering issue
[17:55] <ogra_> ah, yeah, indeed
[17:57] <ogra_> i wonder if fbcon changed somwhow
[17:58] <ogra_> that it could interfere here
[18:01] <xnox> cjwatson: ^ uploaded
[18:02] <xnox> note that ubiquity src needs to embed partman-auto.
[18:03] <plars> slangasek: attached screenshot to 1066065.  Windows makes it stupidly difficult to get a screenshot these days it seems
[18:05] <xnox> plars: prtscr button + open paint + ctrl-v no longer works? *sigh*
[18:05] <plars> xnox: not here at least. They have another tool you can run to capture a region of the screen though, just had to find it
[18:06]  * plars is just glad he only has to use windows for wubi testing :)
[18:06] <xnox> plars: there is some ubuntu-one testing that needs to be done....
[18:07] <plars> xnox: of course, but that's not part of the ubuntu release
[18:09] <ppisati> ogra_: it's in beta1 too
[18:09] <ogra_> ppisati, not for me
[18:10] <ogra_> neither in B2
[18:10] <ppisati> ogra_: just tried
[18:10] <ogra_> yeah, i belive you
[18:10] <ogra_> but i'm also 100% sure i didnt have it
[18:10] <ogra_> i woudldnt have signed off the image if i had had it
[18:11] <ppisati> i don't know what to say
[18:11] <ppisati> i was even in vacation back then
[18:11] <ogra_> yeah
[18:11] <ogra_> beta2 also rsalveti tested
[18:11] <xnox> ppisati: i believe i started to get the same bug as well. Can we figure out what's common between you and me, but different to ogra?
[18:12]  * ogra_ uses a pretty std setup, usb key, mouse kbd and a samsung T240 monitor
[18:13]  * xnox uses usb dongle for wireless keyboard & mouse, hdmi monitor, usb stick (32gb), sd card (8gb) dd'ed with the install image.
[18:13] <ogra_> i just notice that i'm plugged into HDMI on the board
[18:13] <ppisati> actually rsalveti said TI *might* have the same issue
[18:14]  * jsalisbury is using a KVM switch, so my keyboard/mouse only use one USB port and I can share them with my laptop.  
[18:14] <ogra_> jsalisbury, but no KVM for the displa i hope
[18:14] <ogra_> *display
[18:14] <ogra_> :)
[18:14] <jsalisbury> ogra_, correct
[18:14] <jsalisbury> ogra_, I use the vga port on the monitor for my laptop and the DVI port for the pandaboard
[18:14] <balloons> ogra_, et la https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1066064
[18:15] <ubot2> Ubuntu bug 1066064 in ubiquity "Installer unrecoverable error during install of Ubuntu Quantal Final on Panda board" [Undecided,New]
[18:15] <balloons> I'm going to try and confirm it now
[18:16] <ogra_> balloons, yeh, plars already reported that, there must be something wrong with usersetup
[18:16] <ogra_> i dont get why it only shows on panda though
[18:17] <balloons> I thought someone might have mentioned it, hence my earlier question
[18:17] <balloons> so will there be a respin?
[18:17] <slangasek> plars: RT 56704 opened
[18:17] <xnox> ogra, the logs are sparse
[18:18] <ogra_> xnox, plars at least has a backtrace with a broken pipe
[18:18] <ogra_> not much info in it either
[18:19] <xnox> ogra_: well maybe it's no usersetup, but e.g. webkit failing to start the slideshow
[18:19] <ogra_> i'll do an install with debug-oem-config set
[18:19] <ogra_> that should shed some light
[18:21] <MCR1> slangasek: Hi :) Got a minute ?
[18:22] <slangasek> MCR1: hi there
[18:23] <MCR1> I think you are the right person for SRU - am I correct ?
[18:24] <slangasek> MCR1: I'm on the SRU team, if that's what you mean
[18:24] <MCR1> I fixed 2 Unity bugs regarding showdesktop which need to get to Quantal and also be backported to Precise.
[18:24] <MCR1> One has already been merged to trunk, the other is ready to land at the moment
[18:26] <MCR1> didrocks said I need to take care of the SRU to get them in - both have 0 regression potential and are tested
[18:26] <slangasek> MCR1: do I understand correctly that didrocks is saying to do an SRU for quantal, as well as to precise?
[18:26] <ppisati> guys, i've people for dinner comming, i need to go
[18:26] <ogra_> ppisati, did you have proper plymouth output on boot ?
[18:26] <MCR1> Also they are imho important because both can heavily impact on user experience if not fixed
[18:26] <ppisati> ogra_: yes
[18:27] <ppisati> ogra_: plymouth was always working
[18:27] <ogra_> well, installer comes up here with no probs at all
[18:27] <MCR1> slangasek: I do not exactly know - I will re-read - back in a minute
[18:27] <slangasek> MCR1: that's most likely correct, as we're in the last stages of finalizing images for release and there's no slack for any uploads to quantal that aren't show-stopper bugs
[18:27] <slangasek> MCR1: just want to make sure you understand the implications
[18:27] <MCR1>  didrocks: MCR1: if you want that in quantal, you need to make the bugs compliant with the SRU process
[18:28] <MCR1> quote ^^
[18:28] <slangasek> right
[18:28] <slangasek> so, that's https://wiki.ubuntu.com/StableReleaseUpdates
[18:28] <slangasek> MCR1: once you have the requisite information in the bugs and the packages are uploaded to quantal-proposed, I can help with getting them into the archive for SRU testing
[18:30]  * ppisati -> dinner
[18:30] <ogra_> xnox, hmm, your webkit idea sounds compelling
[18:31] <xnox> ogra_: easy to test as well - purge slideshow package ;-)
[18:31] <MCR1> slangasek: oh this all sounds very complicated, maybe I'll simply wait for them to land automatically...
[18:31] <slangasek> MCR1: hmm, not sure what you mean by "automatically"
[18:31] <MCR1> slangasek: In some future update
[18:32] <MCR1> slangasek: they are already in Unity trunk, so... or better 1 is the other is waiting for the merge
[18:32] <slangasek> packages do not automatically get updated in stable releases, and someone will still need to do the work around the SRU bugs to get them included in an update :)
[18:33] <MCR1> slangasek: Maybe you want to take a look at the bugs then ?
[18:34] <slangasek> MCR1: I'm rather busy with other aspects of the 12.10 release at the moment, can't really afford to go deep on this, sorry
[18:34] <MCR1> slangasek: Otherwise I could also talk to sil2100, who AFAIK does the Unity releases - np - thanks 4 your help anyway. :)
[18:34] <ogra_> xnox, well, purging anything isnt easy .. pitchblack screen ... not even consoles
[18:37] <xnox> meh
[18:38] <xnox> MCR1: PS are doing regularly scheduled SRUs of the unity stack following all the SRU procedures. Please get in touch with them to cherrypick that bug you want and ask them to do it properly =)
[18:39] <slangasek> cjwatson: wubi doesn't actually need a respin for the grub change, does it?
[18:39] <MCR1> xnox: PS ?
[18:39] <slangasek> MCR1: Canonical Product Strategy team, the upstream for unity
[18:40] <MCR1> ah ok, thx
[18:41] <slangasek> cjwatson: can you review the partman-auto upload, or should I put my partman brain in?
[18:42] <xnox> slangasek: cjwatson did review the diff I pastebined.
[18:42] <slangasek> xnox: is that the same as the diff you uploaded? :P
[18:43] <xnox> slangasek: yeah.
[18:43] <slangasek> ok
[18:43] <xnox> slangasek: with the typo fix, cjwatson pointed out. read scrollback =)
[18:43] <xnox> tested as well =)
[18:43] <slangasek> accepted
[18:43] <slangasek> still in progress on the ubiquity side?
[18:44] <xnox> slangasek: yeah. needs to update/embed partman-auto "udeb"
[18:44] <slangasek> xnox: right; does that require it to be in the archive first?
[18:44] <slangasek> I thought cjwatson sometimes takes a shortcut :)
[18:44] <xnox> slangasek: I do. cjwatson does shortcuts that I don't like.
[18:44] <slangasek> heh
[18:45] <xnox> slangasek: I have added the bzr-bd pre-build script to ubiquity trunk, such that `$ bzr bd -S` does everything right or throws a fizzy fit =)))))
[18:46] <xnox> kubuntu ubiquity & grub are in. cjwatson did translation sync earlier.
[18:46] <xnox> so we maybe ready to upload ubiquity soon =)
[18:47] <slangasek> perfect
[18:47] <ogra_> xnox, i owe you a beer
[18:48] <ogra_> works fine once the slideshow is removed
[18:48] <slangasek> xnox: look out, you're going to have to drink beer
[18:48] <ogra_> so i suspect webkit crashes the pvr driver somehow
[18:48] <ogra_> :(
[18:48] <ogra_> easily worked aroudn by a seed change but still :((
[18:49]  * xnox *hehe*
[18:49] <xnox> if all fails, blame webkit =)
[18:49] <ogra_> hahah
[18:49] <slangasek> launchpad translation exports make me sad
[18:50] <xnox> ogra_: I don't drink beer. Ciders or tennessee whiskey is for me =)
[18:51] <ScottK> Could we have another armel builder or so.  What we have isn't keeping up.
[18:51] <slangasek> infinity, doko: ^^ if one of you can make magic happen?
[18:54] <ogra_> seb128, so how well was your webkit upload tested on arm ?
[18:54] <seb128> ogra_, "my"? last time I uploaded webkit was like in july?
[18:54] <slangasek> plars: is bug #1062428 a priority from your side?  IIRC you referenced it in your release report, but it's marked 'incomplete' by pitti awaiting udev debugging info
[18:54] <ubot2> Launchpad bug 1062428 in udev "omap4 desktop install image sometimes boots without keyboard working" [Medium,Incomplete] https://launchpad.net/bugs/1062428
[18:54] <plars> slangasek: no, it's a minor thing
[18:54] <seb128> ogra_, or your mean desktop? I guess "not"
[18:55] <ogra_> seb128, err, sorry, cjwatson uploaded it apparently, it just has your name in the changelog for the new upstream
[18:55] <slangasek> plars: ok, wiping it from my memory ;)
[18:55] <plars> slangasek: I need to look into it more, but it's mostly been working for me lately.  It's one of those that comes and goes
[18:55] <seb128> ogra_, which I would agree it's an issue, it took like a month to get the thing to build on amd64
[18:55] <slangasek> xnox: er, bug #1066076 - does this mean base-files hasn't been uploaded yet?
[18:55] <ubot2> Launchpad bug 1066076 in base-files "lsb_release: code name is not Capitalised during developement." [Medium,Confirmed] https://launchpad.net/bugs/1066076
[18:55] <seb128> ogra_, Laney uploaded I think, cjwatson probably pocket copied
[18:55] <ogra_> well, it completely trashes panda installs ... i can work around it though
[18:56] <slangasek> xnox: I see "Ubuntu 12.10" in /etc/lsb-release here
[18:56] <seb128> ogra_, :-(
[18:56] <seb128> ogra_, how come that was not raised before?
[18:56] <xnox> slangasek: no. base-files are fine. the screenshots are from stale / unupgraded quantal. hence for quantal it's invalid (unless I missclicked)
[18:56] <ogra_> no idea, likely not to enough desktop testing
[18:56] <xnox> slangasek: it's just a hint to open r-series as R-series (note the capitalisation)
[18:56] <slangasek> xnox: ah ok
[18:57] <ogra_> seb128, though the package only went in on tue.
[18:57] <xnox> slangasek: when I saw the bug-titles - i was like please let it not be base-files (cause than it's really the whole world respin)
[18:57] <xnox> it's fine =)
[18:58] <cjwatson> slangasek: wubi.exe itself doesn't, but GRUB is in the Wubi filesystem tarballs
[18:58] <xnox> ogra_: Laney cjwatson doko and others have been almost hand-building webkit on arm....
[18:58] <cjwatson> xnox: It's much better now that the buildds have that their sysctl tweak
[18:58] <cjwatson> s/that/had/
[18:58]  * cjwatson stares at his fingers
[18:59] <slangasek> cjwatson: ok
[18:59] <ogra_> xnox, looks like that didnt help :)
[18:59] <ogra_> i'll just drop the slideshow from the panda images, its just sad that we have again an image thats not 100%
[18:59] <cjwatson> ScottK: rebalanced builders
[18:59]  * xnox ponders if cjwatson need his fingers I/O sysctl tweak ;-)
[19:00] <ScottK> cjwatson: Thanks.
[19:01] <jdstrand> so, it finally dawned on me how important bug #1058356 is
[19:01] <ubot2> Launchpad bug 1058356 in upstart "fails to install when kernel does not provide block_suspend capability" [High,In progress] https://launchpad.net/bugs/1058356
[19:02] <jdstrand> this was originally reported against cups
[19:02] <jdstrand> the problem is that when upgrading from 12.04 to 12.10, we are running a 12.04 kernel when cups is restarted
[19:03] <jdstrand> the upstart job for cups correctly uses /lib/init/apparmor-profile-load usr.sbin.cupsd
[19:03] <ScottK> infinity: Maybe you could take the golang-tip armel builds from the gophers/go PPA out back and shoot them in the head.  They are somewhat inconvenient at the moment.
[19:03] <jdstrand> which itself calls apparmor_parser. apparmor_parser will fail though because of a new capability rule that is in the cups profile
[19:04] <jdstrand> so cups unsuccessfully restarts which may affect upgrades
[19:04] <cjwatson> ScottK: I might be able to temporarily lower that archive's score.
[19:04] <cjwatson> If I can remember how.
[19:05] <jdstrand> I have attached a minimal patch to upstart to make /lib/init/apparmor-profile-load not fail on apparmor_parser error. this has been discussed with the security team and we feel this is the best option at this point
[19:05] <ScottK> That'd help.
[19:06] <jdstrand> skaet: may I upload this to quantal-proposed?
[19:06] <ScottK> Does permanently shooting the builds take lamont's special kind of love?
[19:06] <slangasek> jdstrand: as an upgrade-only issue, this is SRUable; please upload to -proposed and SRUify the bug report
[19:06] <skaet> jdstrand,  yes,
[19:07] <xnox> jdstrand: and there is no pre-depend in cups you can use, because of the old kernel? or for example not restart cups.
[19:07] <jdstrand> hmm
[19:07] <skaet> jdstrand,  using quantal-proposed as target for SRUs.
[19:07] <jdstrand> I could also adjust the cups upstart job
[19:07] <cjwatson> ScottK: Yes, and I'd generally rather not.  I'll add another armel build instead.
[19:07] <slangasek> xnox: we need upgrades to happen successfully on the old kernel, not require a second pass post-reboot
[19:07] <ScottK> cjwatson: OK.  Thanks.
[19:08] <jdstrand> but this is a better fix because it will fix all errors at this time-- and only one place to undo the workaround once apparmor_parser is smarter
[19:08] <xnox> slangasek: true. just keep the old cups running. same way e.g. we keep mdadm running. otherwise it will not even be funny.
[19:08] <cjwatson> Or two.  I'll rebalance back later.
[19:08] <skaet> slangasek,  since I suspect that infinity and cjwatson may be zzz ing soon,  can you keep an eye on the respin triggering for the next couple of hours.   I've got an appt, and will be back online after.
[19:08] <skaet> ?
[19:08] <slangasek> skaet: oh, I thought I was already doing that ;)
[19:09] <skaet> slangasek,  yeah,  just wanting to make it explicit.  :)
[19:09] <slangasek> ack
[19:09] <jdstrand> (in other words, there are other packages that ship upstart jobs that could run into this in the future)
[19:09]  * skaet -> appt,  biab
[19:10] <skaet> Thanks.  :)
[19:10] <slangasek> jdstrand: just upload ;)
[19:10] <xnox> jdstrand: i see. indeed it's a catch all this class of upgrade bugs, instead of fixing it on per-package basis.
[19:10] <slangasek> jdstrand: btw, please be sure to commit to the bzr branch when doing so
[19:10] <jdstrand> xnox: yeah
[19:10] <jdstrand> slangasek: ack
[19:10] <cjwatson> ScottK: Amusingly, the entire reason that ~launchpad-buildd-admins now has the ability to edit per-archive build scores is because of contention with ~gophers/go almost exactly six months ago. :-)
[19:10] <xnox> jdstrand: please upload. and let the audience here look at the queuediff =)
[19:11] <jdstrand> well, the queuediff is https://launchpadlibrarian.net/119603620/upstart_1.5-0ubuntu9.debdiff
[19:11] <ScottK> cjwatson: Funny.  It does seem to consume a lot of buildd time on slow archs.
[19:11]  * micahg has no idea why they need tip built on oneiric at this point anyways
[19:11] <jdstrand> or at least, it will be
[19:12] <lamont> ScottK: webops is the giver of buildd love these days
[19:12] <cjwatson> micahg: I suspect inertia.
[19:14] <jdstrand> slangasek: there is no Vcs line. I assume you mean ubuntu:quantal/upstart
[19:14] <jdstrand> slangasek: is that right? or something else
[19:14] <slangasek> jdstrand: yes
[19:14] <jdstrand> k
[19:15] <slangasek> jdstrand: feel free to add the missing Vcs field while you're at it (sorry about that)
[19:16] <jdstrand> I just rejected that to add a Vcs line
[19:17] <slangasek> jdstrand: meh, if you didn't get it already I'd rather just un-reject that upload and get on with it
[19:19] <ScottK> cjwatson: Thanks.  That got partman auto built on armel.
[19:19] <xnox> people bug 1065935 is not even funny.
[19:19] <ubot2> Launchpad bug 1065935 in compiz "compiz eats 90% CPU time most of the time, more than kvm to run VMs" [Critical,New] https://launchpad.net/bugs/1065935
[19:20] <slangasek> jdstrand: so is one of the implications here that cups (and related packages) are running unconfined after restart on upgrade, until restart?
[19:20] <slangasek> until system restart
[19:20] <ScottK> Between gophers/go and unity-team/staging PPAs have 5 of 6 working armel builders right now.
[19:20] <jdstrand> slangasek: yes. the alternative is cups not running
[19:20]  * slangasek nods
[19:20] <slangasek> jdstrand: oh, or does the old pre-upgrade policy continue to be applied?
[19:21] <xnox> jdstrand: the other alternative it to keep the old secured cups to be left running (e.g. do not restart)
[19:21] <jdstrand> that's a good question
[19:21] <jdstrand> I'm not particularly concerned about that
[19:22] <slangasek> xnox: that would be a gross kludge
[19:22] <slangasek> jdstrand: your changes aren't pushed to the branch yet AFAICS - are you waiting for the accept?
[19:22] <jdstrand> the upgrade asks you to restart. the system is not going to behave well most likely for a whole bunch of other reasons
[19:22] <jdstrand> I haven't uploaded yet
[19:22] <jdstrand> I will momentarily
[19:22] <xnox> slangasek: ok.
[19:22] <slangasek> jdstrand: er, yes you did - I said I was going to accept from rejected
[19:22]  * xnox learns a new noun & verb: kludge
[19:23] <jdstrand> oh, I missed that
[19:23] <slangasek> jdstrand: either way - I just don't want the UDD branch to blow up or fail to match :)
[19:25] <jdstrand> slangasek: pushed without the Vcs change
[19:27] <slangasek> thanks, accepting
[19:27] <jdstrand> thanks
[19:27] <ogra_> plars, balloons, hggdh, i removed the slideshow from the panda images, please test the next image and comment on bug 1066046
[19:27] <ubot2> Launchpad bug 1066046 in webkit "pvr driver crashes when ubiquity-slideshow starts" [High,Confirmed] https://launchpad.net/bugs/1066046
[19:28] <balloons> ogra_, will do
[19:28] <slangasek> ogra_: so that's a ubiquity commit that will be included in the next upload?
[19:28] <hggdh> ogra_: will do
[19:28] <ogra_> slangasek, only a change to the live seed
[19:28] <slangasek> ok
[19:28] <ogra_> next publisher run should have it
[19:28] <hggdh> ogra_: BTW, I asked retoaded to take a picture of the pandas in the lab
[19:28] <ogra_> cool !
[19:28] <ogra_> i'll do a followup bamboo feeder post
[19:28] <hggdh> :-)
[19:29] <hggdh> they will be nicely stacked...
[19:30] <slangasek> jdstrand: one thing I'm confused about... why did this not trip in the jenkins autotests?
[19:30] <cjwatson> ScottK: I was going to worry about that, but then I realised there wasn't much else in the queue.
[19:31] <cjwatson> ogra_: Please remember that seed changes often take at least one more publisher run than people expect
[19:31] <ScottK> It happens quite frequently that these PPAs take over completley on the slow archs for long periods.
[19:31] <ScottK> I agree it's fine for now though.
[19:32] <slangasek> jdstrand: this log clearly shows the cups service being successfully started on upgrade: https://jenkins.qa.ubuntu.com/view/Quantal/view/Upgrade%20Testing%20Dashboard/job/quantal-upgrade-precise-desktop/ARCH=amd64,LTS=non-lts,PROFILE=desktop,label=upgrade-test/181/artifact/results/apt-term.log
[19:32] <ogra_> cjwatson, well, i didnt expect immediate rebuiolds anyway :)
[19:32] <cjwatson> The test rebuild should be done by the end of the weekend, and then we'll be back to way over capacity again
[19:32] <slangasek> ogra_: rebuilds are coming almost immediately
[19:32] <slangasek> ogra_: (as soon as ubiquity is in)
[19:33] <ogra_> well,. then hold back arm please until the seed change got picked up
[19:33] <xnox> ogra_: well. ubiquity will trigger a publish, so we are fine =)
[19:33]  * slangasek nods
[19:33] <ogra_> xnox, yeah, i thought so too
[19:34] <cjwatson> It has to be a publisher run after a germinate run after the seed change.
[19:34] <slangasek> ogra_, xnox: you may be missing the point that seed changes take two publisher runs to show up in the Packages file
[19:35] <slangasek> which means we do have to wait for this to propagate before respinning
[19:35] <slangasek> (at least, I'm hoping ubiquity is coming soon? :)
[19:35] <ogra_> well, i think i made it before upstart went in
[19:35] <cjwatson> Technically, as I say, one publisher run after the germinate run at the end of the previous publisher.
[19:35] <cjwatson> The previous publisher doesn't have to have done anything.
[19:35] <ogra_> so that would be two (if i made it, i didnt stopwatch :) )
[19:37] <rsalveti> ogra_: the pvr issue must be related with the hardware/monitor used
[19:37] <ogra_> geez, when did screen develop a screensaver function ?!?
[19:38] <xnox> cjwatson: shall I upload ubiquity? partman-auto is ready now.
[19:38] <ogra_> rsalveti, no, its webkit killing it, regardless which monitor
[19:38] <rsalveti> ogra_: I mean, the blue/black thing
[19:38] <ogra_> rasyeah, that one could be monitor .. i dont care to much about thais one
[19:38] <ogra_> rsalveti, ^^
[19:39] <ogra_> rsalveti, but that webkit can hang the board hard is a bit worrying
[19:40] <cjwatson> xnox: please
[19:41] <xnox> ok
[19:41] <rsalveti> ogra_: yeah
[19:44] <plars> seeing some dbus-server error on boot in i386-server, but I'm not sure how to figure out which application is hitting it.  Apparmor maybe?
[19:44] <plars> process 318: arguments to dbus_server_disconnect() were incorrect, assertion "old_refcount > 0" failed in file ../../dbus/dbus-server.c line 786.
[19:45]  * xnox pep8
[19:45] <slangasek> plars: or something in upstart?
[19:46] <plars> slangasek: I get another similar message, then the next thing in the boot log is:
[19:46] <plars> Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
[19:46] <plars> then Starting Apparmor profiles
[19:47] <slangasek> I don't think the adjacency means anything
[19:48] <jdstrand> dbus is not confined by apparmor
[19:49] <slangasek> jdstrand: I think he was implying that apparmor was invoking dbus, which is obviously not the case :)
[19:51] <plars> no, I'm saying that I have no idea what's throwing it, but it seems to happen pretty regularly around the same time as I get that in the log and I'm not sure at the moment what the offending application is
[20:04] <jsalisbury> ogra_, should the Quantal omap4 server image install on a panda?  I downloaded it from http://releases.ubuntu.com/quantal/ubuntu-12.10-beta2-server-armhf+omap4.img  It hangs at the installer language selection screen
[20:06] <ogra_> jsalisbury, try the serial install ... i know ppisati fixed the USb kbd issue but i think that was after beta2
[20:07] <jsalisbury> ogra_, will do, thanks
[20:07] <ogra_> jsalisbury, mount the first partition and copy preEnv.txt-serial over preEnv.txt
[20:07] <slangasek> plars: which server tasks do you have installed?
[20:08] <plars> slangasek: I installed them all
[20:08] <xnox> lean cloud server, eh?! =) plars edition
[20:08] <plars> xnox: heck yeah!
[20:08] <plars> :)
[20:09] <slangasek> plars: in theory, I think these are your suspects: http://paste.ubuntu.com/1275576/
[20:09] <xnox> I wonder if all tasks simultaniously are even remotely supportable.
[20:12] <slangasek> xnox: ubiquity upload in progress?   (not trying to rush you, just checking where things stand)
[20:12] <jsalisbury> ogra_, serial install is working.  Thanks!
[20:13] <ogra_> :)
[20:13] <xnox> slangasek: just about. finished all unit-tests and sbuild.
[20:13] <slangasek> xnox: spiff
[20:14] <hggdh> jsalisbury: it does install, just did it
[20:14] <hggdh> jsalisbury: but mine worked on DVI/keyboard at the panda
[20:16] <jsalisbury> hggdh, hmm, I get a lockup at the install language selection screen, but serial install works.  It could be that I'm using a kvm switch for keyboard/mouse.  I'll try different configs.
[20:16] <micahg> ogra_: only major difference on arm is webkit is built with -01
[20:16] <hggdh> jsalisbury: I am using a usb switch
[20:16] <micahg> and that's armhf actually
[20:17] <ogra_> micahg, well, we should probabyl swithc to -O0
[20:17] <jsalisbury> hggdh, me to.  Did you use this image: http://releases.ubuntu.com/quantal/ubuntu-12.10-beta2-server-armhf+omap4.img
[20:17] <hggdh> jsalisbury: no, I used today's image
[20:18] <jsalisbury> hggdh, ahh.  Let me try that :)
[20:18] <xnox> thanks to new gtk (?!) ubiquity started to read more of itself with orca. -1 rsl-q-tracking bug
[20:19] <xnox> AlanBell++
[20:21] <xnox> slangasek: there you go =)
[20:21] <slangasek> xnox: ta
[20:28] <slangasek> xnox: so, before I accept this and go respinning the world - you still have four rls-q-tracking bugs on ubiquity all assigned to yourself. :)  Are these still being worked on for 12.10?
[20:28] <slangasek> bug #1025420 bug #1045798 bug #1045803 bug #1053030
[20:28] <ubot2> Launchpad bug 1025420 in ubiquity "AssertionError: Returned to partman/choose_partition with nothing to do" [High,Incomplete] https://launchpad.net/bugs/1025420
[20:28] <ubot2> Launchpad bug 1045798 in ubiquity "Screen reader does not read mismatching passwords during installation" [High,Confirmed] https://launchpad.net/bugs/1045798
[20:28] <ubot2> Launchpad bug 1045803 in ubiquity "Information about Installation Complete dialog is not read back by the screen reader installation" [High,Fix released] https://launchpad.net/bugs/1045803
[20:28] <ubot2> Launchpad bug 1053030 in ubiquity "highly confusing UI on desktop when installation media is big enough and no external storage is attached" [High,Confirmed] https://launchpad.net/bugs/1053030
[20:29] <slangasek> ah, there's the fixed accessibility bug
[20:29] <slangasek> so, three ;)
[20:29] <xnox> and the first one is Incomplete, the OP is not responding.
[20:29] <xnox> So two in total.
[20:29] <slangasek> hggdh: xnox thinks you don't like him (bug #1025420)
[20:29] <ubot2> Launchpad bug 1025420 in ubiquity "AssertionError: Returned to partman/choose_partition with nothing to do" [High,Incomplete] https://launchpad.net/bugs/1025420
[20:30] <slangasek> xnox: rather than leaving bugs 'incomplete' on this list, we should turf them if we're not committed to fixing them; rls-q-notfixing this one now
[20:31] <xnox> 1045798 (best effort respin ) and 1053030 (best effort respin or respin pandas) I still hope to fix.
[20:31] <xnox> slangasek: ok.
[20:31] <slangasek> (otherwise, it's legitimate for a bug to be "we're committed to fixing this but are currently waiting for submitter feedback")
[20:32] <slangasek> xnox: cool, leaving the other two on the list then; and ubiquity accepted
[20:32] <xnox> slangasek: i think it's a legitimate bug, if we know the sequence of hoops the OP jumped through to get there.
[20:32] <xnox> ....
[20:32] <slangasek> yep
[20:32] <slangasek> but "legitimate bug" is not the same as "we're committed to fixing this for release" :)
[20:32] <xnox> =)
[20:33] <jsalisbury> hggdh, todays daily image fixes the omap4 server installer issue, thanks!
[20:34] <hggdh> slangasek, xnox: sorry, these have been hectic days. So far I have been unable to reproduce it
[20:34] <hggdh> jsalisbury: perfect!
[20:34] <slangasek> infinity: not sure if pad.u.c is telling the truth about name/color mappings; I'm confused about "rebuild trigger" 19, whoopsie/kerneloops integration
[20:35] <slangasek> hggdh: ok, we're happy to deprioritize that bug in favor of ones you are hitting, then :)
[20:35] <hggdh> slangasek, xnox: I suggest dropping it, yes
[20:35] <xnox> slangasek: it was "if you respin the world, included that"
[20:35] <xnox> slangasek: 19 that is.
[20:36] <slangasek> xnox: ok.  I would say the pad doesn't clearly express that :)
[20:36] <slangasek> anyone here aware of anything else pending, besides the arm task update and the ubiquity build+publication?
[20:39] <xnox> slangasek: well it was a 3 line chat between ev & infinity. I'm surprised it even made it to the pad to be honest.
[20:41]  * xnox thinks it's time to read how Katniss got a goat for Prim & configure znc bouncer
[20:50] <slangasek> so I suppose I should test today's images on SB maybe
[20:51] <slangasek> ogra_: seed change has taken effect.  Is it an issue that ubiquity-slideshow-ubuntu is still listed as part of the ubuntu-usb-live task?
[20:52] <slangasek> (it's no longer in the ubuntu-live task)
[20:52] <slangasek> AFAICS that task is only used for the no-longer-extant ubuntu-dvd images
[21:02] <slangasek> ok, why is adding an attachment to a Launchpad bug broken for me?
[21:03] <xnox> because cosmic rays are not shining onto armel buildds
[21:03] <plars> slangasek: removing postfix seems to get rid of the error
[21:03] <plars> slangasek: the dbus error
[21:03] <slangasek> nice
[21:04] <lamont> plars: I suspect that it's the lack of an MTA, not specifically postfix
[21:04] <slangasek> lamont: er?
[21:05] <slangasek> lamont: I suspect that you have an irc script that spits out random redirections in response to mention of postfix on Ubuntu channels )
[21:05] <slangasek> ;)
[21:05] <lamont> slangasek: well, highlighting on 'bind' turned out to just be silly.  postfix has far less false-positives
[21:06] <slangasek> lamont: the context here is that plars sees a dbus-related error message on boot, only if postfix *is* installed
[21:07] <lamont> sweet.
[21:07] <lamont> I suspect that he'd see it if sendmail were installed, too
[21:07] <slangasek> why?
[21:08] <lamont> because postfix does nothing dbus-ish other than provide an mta.  things like cron recommend: mail-transport-agent, and then behave differently based on whether or not it is installed.
[21:08] <lamont> alternatively, dbus hates chrooted things
[21:08] <slangasek> cron does nothing dbus-ish either
[21:08] <lamont> but that seems less likely, imo
[21:09] <plars> easy enough to try :)
[21:14] <plars> nope, I don't get the problem with sendmail, just postfix
[21:16] <plars> slangasek: even still, do you think it's more likely to be upstart rather than postfix? Any suggestions of something I could look for?
[21:16] <slangasek> plars: if I were to throw darts, I'd say avahi
[21:17]  * xnox had a good darts throw with webkit & slideshow on panda =)
[21:18] <slangasek> infinity: ubuntu core is not being built for armel but is still listed as such in the manifest; which is right?
[21:19] <plars> slangasek: hmm, well with avahi-daemon removed, but postfix still in place, I still get the error
[21:19] <slangasek> plars: then that dart hits me in the foot, ohwell
[21:19] <slangasek> plars: consolekit?
[21:20] <slangasek> there's not too many other options
[21:20]  * plars starts with colord since it's a dep
[21:20] <xnox> slangasek: not that foot again.... at least this time you don't need spanish or crutches.
[21:21] <slangasek> or even canadian crutches, as they apparently call them
[21:22]  * lamont is out of ideas, which was quick with dbus involved. :(  pardon my interruption
[21:25] <slangasek> infinity, skaet: pipelines queued up to trigger on ubiquity 2.12.11 publication; wandering afk for a few
[21:41] <Riddell> evening
[21:42] <Riddell> ScottK: yes my fix to ubiquity is in, xnox was working on another fix so I didn't upload
[21:42] <lamont> plars: thanks for tracking it down
[21:42] <xnox> Riddell: it's uploaded now.... waiting to build & trigger rebuild.
[21:43] <plars> lamont: well, I opened bug #1066144 as a placeholder, but so far I haven't been able to narrow it down past postfix
[21:43] <ubot2> Launchpad bug 1066144 in postfix "arguments to dbus_server_disconnect() were incorrect" [Undecided,New] https://launchpad.net/bugs/1066144
[21:43] <lamont> oh, and here I thought that it was beyond placeholder.  shucks
[21:43] <plars> lamont it's easily reproducible at least :)
[22:15] <retoaded> ogra_, hggdh: The Leaning  Tower of Panda has been constructed. You may be able to see the few pics at  https://plus.google.com/u/0/photos/111809657190034387974/albums/5798548368855386737
[22:16] <ogra_> hmm, thats 403 for me
[22:20] <slangasek> perhaps https://plus.google.com/photos/111809657190034387974/albums/5798548368855386737 (without the /u/0/)?
[22:21] <slangasek> retoaded: missing from this picture is the lego mindstorm controller
[22:21] <slangasek> after all, pandas are a /mobile/ reference platform, right?
[22:22] <slangasek> infinity: heh, the 'wait' usage in the pipelines seems to have bitrotted a bit thanks to my aggressive backgrounding of processes... is that known?
[22:24] <slangasek> so I see pad.ubuntu.com is back to being reliable
[22:24] <retoaded> slangasek, I figured I'd pick all things lego at UDS.
[22:24] <slangasek> haha
[22:25] <slangasek> natch
[22:25] <phillw> slangasek: you must have read my mind, I was just going to ask where
[22:25] <phillw> what was happening :)
[22:28] <slangasek> phillw: it appears I overlooked that the Lubuntu preinstalled image didn't need respinning, so it's currently in the pipe; we can discard it and roll back to 20121012.1 if that's the Lubuntu team's preference
[22:29] <phillw> slangasek: is that the arm one?
[22:30] <slangasek> phillw: yes
[22:30]  * xnox it's not like that image will have a need for os-probing windows....
[22:30] <phillw> you'd need to ask the arm guys, they are the ones looking after that.
[22:30] <slangasek> oh right, lubuntu/ac100 is ogra_
[22:30] <slangasek> ogra_: ^^
[22:31] <slangasek> xnox: it's preinstalled, it doesn't even use ubiquity :)
[22:31] <phillw> but, if it need not be respun, save the computer time?
[22:31]  * ogra_ looks up 
[22:31] <ogra_> slangasek, it does ... oem-config
[22:31] <slangasek> phillw: too late, it's in the command pipeline
[22:31] <ogra_> it doesnt use partitioning
[22:31] <slangasek> ogra_: ah, then I suppose we keep it
[22:32] <ogra_> so if changes are partitioner specific feel free to skip
[22:32] <slangasek> ogra_: a) too late to skip, b) we don't ship images with out-of-date packages so you get to update anyway
[22:32] <phillw> ogra_: thanks, sorry if that came acrross harsh, but I really have no kit whatsoever to even try it out on.
[22:32] <ogra_> oh, indeed, i didnt mean for the final release :)
[22:33] <ogra_> just for the convenience ot keep the builder free
[22:33] <ogra_> phillw, no worries, i'll do the testing etc
[22:33] <phillw> did you sort the slide show out?
[22:34] <xnox> phillw: removed from seed =(
[22:34] <xnox> which is "sorted out" to some degree =/
[22:34] <ogra_> phillw, yep, resulted in a fix for all derivative distros in the end, thanks for pointing it out
[22:34] <ogra_> xnox, wrong seed :)
[22:34]  * xnox is confused
[22:34] <ogra_> lubuntu slideshow is still in
[22:34] <phillw> he he, well, thanks goes to Julien, he who said that was the most likely cause. He's a really nice guy :)
[22:35] <xnox> ah, the bit about wrong slideshows used. yeap.
[22:35] <ogra_> right
[22:35] <xnox> happy respin?
[22:35] <ogra_> i have high hopes the slideshow will work there
[22:35] <ogra_> else i will have to drop it from ac100 too :/
[22:36] <slangasek> yes, mass-marking the builds for respin on the tracker
[22:37] <xnox> slangasek: alternates are done already?! well it's lubuntu only....
[22:43] <phillw> xnox: I thought server also used alternate install?
[22:43] <phillw> or so the etherpad says?!
[22:44] <xnox> hmm.. you are right
[22:44] <wgrant> infinity, ScottK: FWIW the bug that prevented us from recovering those binaries is fixed, so if it happens again we can try recovering without a reupload
[22:45] <phillw> one of the big hopes for lubuntu to keep alternate for 13.04 :)
[22:48] <slangasek> erm, ok, why is ubuntu desktop not in the etherpad pipeline
[22:49] <slangasek> oh, because it's under 'arm'
[22:55] <infinity> wgrant: Oh, well, I tried, but nothing seemed to happen.  Maybe I did it wrong.  Too late now to retest.
[22:56] <wgrant> infinity: Yeah
[22:56] <infinity> slangasek: "arm" unhelpfully means "anything that produces ARM" not "just ARM".
[22:56] <wgrant> infinity: The trick is that the latest source publication has to be in the place with the binaries
[22:56] <wgrant> So you have to copy it back to proposed first
[22:56] <slangasek> infinity: yep, so I've gleaned
[22:56] <infinity> wgrant: Ah-ha.
[22:57] <infinity> wgrant: Coulda, shoulda, will next time this comes up.
[22:58] <wgrant> infinity: We should probably add a source pocket argument, or let getBuiltBinaries examine the entire distroseries, maybe.~
[22:58] <infinity> slangasek: As for core/armel, it's not being built because we only have one livefs buildd for ARM, and while one buildd can build mulitple arches, because of the way we name output, it can't build multiple arches of the same image.
[22:59] <infinity> slangasek: So, no armel/core unless I either fix that misfeature of our build system (not happening this close to release, obviously), or a second buildd magically appears.
[22:59] <slangasek> infinity: er, ok
[22:59] <slangasek> infinity: how did we end up with only one livefs buildd for arm again?
[23:00] <slangasek> (or maybe I mean "still")
[23:00]  * xnox go
[23:00] <infinity> slangasek: We were meant to get more when Mandabox 2.0 went live, and... It had/has issues.
[23:00] <infinity> slangasek: And with the limited set of ARM images we build right now, no one was screaming particularly loudly.
[23:03] <slangasek> right
[23:39]  * skaet --> back
[23:41]  * slangasek waves
[23:41] <skaet> :)
[23:43] <bkerensa> =o
[23:58]  * infinity glares at another touches-every-image upload.
[23:59] <slangasek> hmm?
[23:59] <slangasek> it's in -proposed for a reason
[23:59] <infinity> Yeah, I know. :)