[02:45] <infinity> I want to marry sagari and have sexy little powerpc babies with it.  Is that wrong?
[02:45] <infinity> (Alternately, just buy a few more machines like it)
[03:53] <infinity> Don't accept the d-i upload I just uploaded, I'll accept it once the PPC kernels publish.
[10:03] <davmor2> cjwatson: Hey dude the UEFI + Secureboot would the Secureboot need to be enabled for the kernel to build against it or should it do it with the secureboot disabled do you know?
[10:03] <cjwatson> I haven't had enough coffee to understand that - could you add in the punctuation to help me, please? :-)
[10:21] <cjwatson> davmor2: do you mean "does UEFI Secure Boot need to be enabled in order to build a kernel that supports UEFI Secure Boot"?  No.
[10:21] <davmor2> cjwatson: sorry :(  I had the issue with secure boot not working on the latest raring install.  I was asked to try some main line kernels.  These install and create new efi entrys.  However in order to boot the machine to get the kernels to install I needed to disable secureboot.
[10:22] <cjwatson> I don't know whether the mainline kernel builds have the right things turned on to support SB.
[10:23] <cjwatson> There's normally a separate linux-signed-image-* package.
[10:23] <cjwatson> If you only have linux-image-*, then the intent is for it to boot anyway even with SB, but some firmware has bugs that prevent this working.
[10:23] <davmor2> cjwatson: which would explain why they aren't working when I enable secureboot again, thanks I'll catch up with jsailsbury when he is online thanks
[10:24] <cjwatson> In order to support linux-signed-image-*, the kernel team would have to be building their mainline kernels in a PPA with appropriate server-side configuration, and there'd probably also have to be a shim-signed with the corresponding key built into it
[10:25] <cjwatson> It's a fair amount of work
[13:16] <smartboyhw> Hello Ubuntu Release Team, isn't the Beta 2 milestone supposed to be created on the ISO QA Tracker for testing???
[13:16] <cjwatson> infinity: ^-
[13:16] <ogra_> smartboyhw, hey !
[13:16]  * ogra_ hugs smartboyhw ... 
[13:16] <ogra_> i didnt mean to shock you like that with my april fools blogging :)
[13:16] <smartboyhw> ogra_ thank you for your joke;)
[13:17] <smartboyhw> lol
[13:17] <ogra_> (though saying that we consider the euro the most stable currency should have told you ... )
[13:17] <smartboyhw> ogra_ no I don't know anything about economics;)
[13:18] <ogra_> heh ... k
[13:18] <ogra_> then the mailing list at the end should :)
[13:18] <smartboyhw> That is;)
[13:18] <ogra_> “Ubuntu Engineering Ltd.” ubuntu-april-1st@conanical.com
[13:18] <ogra_> ;)
[13:18] <smartboyhw> Does this email address exist actually;)
[13:18] <ogra_> dunno, ask conanical.com :)
[13:19] <smartboyhw> That's the strange thing
[13:22] <cjwatson> $ host -t mx conanical.com
[13:22] <cjwatson> Host conanical.com not found: 3(NXDOMAIN)
[13:23] <cjwatson> smartboyhw: ^-
[13:23] <smartboyhw> lol
[13:40] <davmor2> Yay Ubuntu is working against secureboot again with todays iso :)
[13:41] <cjwatson> davmor2: great
[13:54] <cjwatson> Laney: what do you think of the notion of removing the entire conduit stack on armhf?  it looks like, at best, it's going to take a while to resolve
[13:54] <stgraber> cjwatson: looks like the QATracker eventually noticed the new d-i
[13:55] <cjwatson> stgraber: well, a newer one than when I asked :)
[13:56] <doko> cjwatson, I was told that Laney is afak this week. is this the missing bit to get haskell into raring?
[13:56] <cjwatson> doko: Laney's on holiday but he said he was going to be hacking on haskell while on holiday
[13:56] <doko> ahh
[13:56] <cjwatson> doko: it's one of several missing bits, certainly not the only one
[13:57] <cjwatson> Laney is considerably better at this than I am but I've been trying to move things along where I know how
[13:57] <xnox> well given that he is posting pictures with loads of snow & it's actually sunshine in typical parts of england, I take it he is quite afk.
[13:58] <cjwatson> xnox: he was uploading haskell packages as recently as Sunday, at least
[13:58] <xnox> Oh, ok =)
[13:59] <cjwatson> the other haskell problem that I currently know to be a porting issue is haskell-cipher-aes/powerpc
[14:00] <cjwatson> that's very likely a big-endian bug, based on the similar haskell-cryptohash/powerpc problem I fixed (by the same upstream author)
[14:00] <cjwatson> haven't quite tracked it down yet, but that would unstick another chunk of the stack
[14:06] <cjwatson> that one is curious for (a) first 128 bits of output are correct (b) weirdest hex encoding ever
[14:23] <ogra_> cjwatson, hmm, i just got a strange erros from the nexus7 daily-preinstalled
[14:24] <ogra_> looks like the new lock check code has a hiccup for builds that just failed without lock issues
[14:25] <cjwatson> ogra_: No, that's fine, it's just an extra mail
[14:25] <cjwatson> But essentially the same failure as before
[14:25] <cjwatson> Previously it would silently not have run the image-generation part of the build if all the livefs builds failed
[14:26] <cjwatson> Now the livefs build is done inside the image-generation lock/logging so that buildlive output shows up in the image build logs
[14:26] <ogra_> well, i got a proper failure log from the livefs builder (libc6-dev couldn't be installed)
[14:26] <cjwatson> Yeah, I know, I'm looking at both the mails
[14:26] <ogra_> ah, k
[14:26] <cjwatson> They're different from before, I know, but I did expect this
[14:26] <ogra_> ok
[14:27] <cjwatson> I suppose I might silence the mail notifications in this case; the logging's still useful
[14:27] <ogra_> yup, well, if i know i can ignore the traceback i'm fine
[14:27] <ogra_> (i see it properly raises the error msg in the last line)
[14:29] <ogra_> Unpacking libc6-dev:armhf (from .../libc6-dev_2.17-0ubuntu4_armhf.deb) ...
[14:29] <ogra_> dpkg: error processing /var/cache/apt/archives/libc6-dev_2.17-0ubuntu4_armhf.deb (--unpack):
[14:29] <ogra_>  corrupted filesystem tarfile - corrupted package archive
[14:29] <ogra_> GRRR
[14:29] <ogra_> i guess thats just a retry
[14:29] <ogra_> (i doubt we have corrupt packages in the archive :) )
[14:30] <cjwatson> OK, I've silenced the image build failure mail in this case
[14:30] <cjwatson> Indeed, that's much more likely to be builder-side corruption
[14:30]  * ogra_ fires off a manual build ... 
[14:31] <ogra_> hmm, you quietened the cmdline output too when doing manual builds
[14:35] <cjwatson> Yep - use DEBUG=1 or tail the log
[14:36] <cjwatson> (DEBUG=1 won't publish)
[14:37] <cjwatson> It was an accident of implementation that the buildlive output always landed on stdout; personally I found it rather annoying and find it more useful in the log
[14:37] <ogra_> k, no prob ... i just noticed it
[14:37] <ogra_> (wasnt a complaint ... or at least shouldnt have been)
[14:49] <cjwatson> doko: mind if I use ~ubuntu-toolchain-r/test to test a haskell-cipher-aes/powerpc fix?  I'll delete it afterwards
[14:51] <ogra_> cjwatson, hmm, now it returned but i didnt get a failure mail
[14:51] <doko> cjwatson, sure
[14:52] <ogra_> ah, ignore that ... mail delivery was just slow
[14:52] <smartboyhw> infinity: ping
[14:56] <ogra_> Unpacking aptdaemon (from .../aptdaemon_1.0-0ubuntu8_all.deb) ...
[14:56] <ogra_> dpkg-deb (subprocess): decompressing archive member: internal gzip read error: '<fd:4>: incorrect data check'
[14:56] <ogra_> tar: This does not look like a tar archive
[14:56] <ogra_> tar: Exiting with failure status due to previous errors
[14:56] <ogra_> SIGH !
[14:56] <ogra_> starts looking serious
[15:09] <cjwatson> doko: hmm, ~ubuntu-toolchain-r/test doesn't build against -proposed - is there another handy powerpc-enabled PPA you know of with -proposed already enabled, or should I just flip -proposed on briefly?
[15:10] <doko> cjwatson, sounds ok, I'm currntly not using it
[15:10] <cjwatson> ok, tweaking
[15:10] <doko> for the 4.8 test rebuild I ddidn't want -proposed
[15:31] <balloons> is infinity about yet? looking for the final beta milestone + images to pop up on the tracker ;-)
[15:41] <stgraber> balloons: I created the milestone and added upgrades+netboot images. I also updated the manifest to enable all products but I didn't turn on auto-publish for those as that should only be done once infinity is ready to do the first respin
[15:42] <balloons> stgraber, thank you
[16:05] <stgraber> jbicha: I assume you'll be participating in beta2?
[16:13] <balloons> stgraber, the raring daily is still up
[16:40] <jbicha> stgraber: yes, there wasn't an email about it this time though, right?
[16:43] <infinity> jbicha: No, I didn't send a "who's participating" email, assuming (perhaps naively?) that the answer was "everyone".
[16:44] <slangasek> well, final beta is not an optional milestone... if a flavor is releasing, they're expected to be part of the beta :)
[16:44] <infinity> jbicha: So, we just decided in a quick release call to default to that assumption, and if someone doesn't want to be betaing, we can remove them. :P
[16:59]  * ogra_ sighs about arm lifefs builders 
[16:59] <ogra_> *livefs too
[17:14] <doko> infinity, any reason for you linux-omap4 action?
[17:16] <infinity> doko: Yes, because it's intentionally a copy from quantal and always will be.  Forking the packaging for raring add work for zero benefit, as it would now need to go through SRU verification twice, etc.
[17:17] <doko> infinity, is this documented somewhere?
[17:17] <infinity> Does it need to be?
[17:18] <doko> well, apparently two people didn't know about it
[17:18] <infinity> And now they do.  I'm not sure documentation would have solved that.
[17:18] <doko> and I don't think it would hurt to fix these to eliminate the noise
[17:19] <infinity> It came up when we were deciding to keep the Q kernel in R for pvr-omap reasons, but it's certainly not something I think is worth documenting all over the place as some sort of policy.
[17:19] <infinity> Just need to make sure the people involved know.
[17:22] <xnox> doko: we are not getting any new driver blobs for omap4/panda so the kernel is "frozen" at quantal, until EOL.
[17:23] <doko> nice, so we are getting new buildds for 14.04? ;-P
[17:23] <cjwatson> Yes, AIUI
[17:23] <infinity> Yes.
[17:23] <infinity> Though, that doesn't relate.
[17:23] <infinity> Cause the -generic kernel will boot omap4 just fine and work for buildds.
[17:23] <infinity> Just not for desktops.
[17:24] <infinity> (Because of the lack of GLES blobs)
[17:25] <xnox> doko: well quantal's kernel is backported to precise and gets 5 year support, so yeah by 16.04 we should get "supported" armhf builders ;-))))
[17:25] <ogra_> given thee current  reoccuring probs with the buildds  i would actually vote for trying -generic right now on them :P
[17:25] <xnox> (5year - 6 months)
[17:25] <ogra_> infinity, ^^^
[17:26] <infinity> ogra_: No thanks.
[17:26] <ogra_> well, then no images :P
[17:26] <ogra_> unless there is a HW error which i dont belive there is
[17:27] <ogra_> celbalrai falls over once a week with the stale lock atm ... and since today it cant even unpack packages anymore it seems
[17:28] <infinity> That sounds like hardware to me.
[17:28] <infinity> Unless you think celbalrai's kernel is somehow magically different from all the other buildds.
[17:28] <ogra_> well, it was only different for the first two weeks when it was newly set up
[17:28] <ogra_> since then its a regular thing
[17:28] <infinity> Pandas are crap.  This isn't news.  We've been suffering with them because they were better than the crap we had before. :P
[17:29] <ogra_> yeah, i know
[17:29] <xnox> infinity: what was before?
[17:29] <infinity> Anyhow, the -generic kernel has had almost zero testing, and I don't see it being any better.
[17:29]  * xnox ponders raspberry-pi?!
[17:29] <ogra_> xnox, babbage imx51
[17:29] <infinity> xnox: Beagles, Babbages, qemu, some old Marvell armv5 platform.
[17:30] <xnox> ok.
[17:30] <ogra_> and *they* were crap ...
[17:30] <infinity> xnox: (Actually, the Marvell v5 kit was great, in comparison to all the rest, but it was v5, so we had to ditch it)
[17:30] <ogra_> even in the brtoken state the pandas are more stable
[17:30] <infinity> Debian still uses those as armel buildds, and they're pretty solid.
[17:30] <ogra_> did we actually have beagles in ubuntu ?
[17:31] <infinity> ogra_: Yeahp, all the a*ceaea machines were beagles.
[17:31]  * ogra_ thought that was linaro stuff only
[17:31] <infinity> They were livefs builders and lp-buildds.
[17:31] <ogra_> anyway ...
[17:32]  * ogra_ goes to file an RT so we possibly have livefses by end of the week again :P
[17:32] <infinity> ogra_: Are both livefs builders broken?
[17:32] <infinity> ogra_: If not, we can just shove all the builds on to the other.
[17:32] <ogra_> hmm
[17:33] <ogra_> the omap images seem to have built
[17:33] <cjwatson> which omap?
[17:33] <ogra_> and celbalrai seems fine up to the point where it thinks that the tarball it wants to unpack isnt one
[17:33] <ogra_> err, not omap ...
[17:33] <infinity> Hrm?
[17:33] <ogra_> server
[17:34] <infinity> ogra_: Point me at a log of this tarball thing?
[17:34] <ogra_> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/ubuntu-nexus7/20130402.1/livecd-20130402.1-armhf.out
[17:34] <ogra_> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/ubuntu-nexus7/20130402.1/livecd-20130402-armhf.out
[17:35] <infinity> dpkg-deb (subprocess): decompressing archive member: internal gzip read error: '<fd:4>: incorrect data check'
[17:35] <infinity> tar: This does not look like a tar archive
[17:35] <infinity> Found it, yeah.
[17:35] <infinity> tar: Exiting with failure status due to previous errors
[17:35] <infinity> dpkg-deb: error: subprocess tar returned error exit status 2
[17:35] <infinity> dpkg: error processing /var/cache/apt/archives/language-selector-gnome_0.108_all.deb (--unpack):
[17:35] <ogra_> right
[17:35] <infinity> That could just need a reboot and some prayer.
[17:35] <ogra_> it does that randomly on different packages
[17:35] <ogra_> and i have seen it before ... several times
[17:36] <ogra_> though usualy the next build was fine then ... until it went ro with a stale lock
[17:36] <infinity> ogra_: Well, it's either a recurring hardware issue, or it's that same goofy bug that causes buildds to hate their chroot tarballs occasionally.
[17:36] <infinity> ogra_: The ro thing, though, sounds like hardware.
[17:36] <ogra_> i suspect its the same
[17:37] <ogra_> and i suspect the USB layer
[17:37] <infinity> We certainly don't have all the Pandas going ro for no reason constantly.
[17:37] <ogra_> or more ... power of the USB layer
[17:37] <infinity> Yeah, lacking power is also possible.  That's still "hardware issue" to me.
[17:37] <ogra_> since thats a typical point of failure on the panda
[17:38] <doko> cjwatson, would you mind, if I remove the eclipse binaries for armhf, and for dependent packages? gave up on getting the recent eclipse built on armhf
[17:38] <ogra_> ++
[17:39] <ogra_> do people even use eclipse from the archive at all ?
[17:39] <doko> there are not that many masochists
[17:39] <ogra_> heh
[17:39] <ogra_> i meant on x86 actually
[17:39] <infinity> I have a friend who uses the archive version.
[17:39] <cjwatson> doko: go ahead
[17:40] <ogra_> every time i come across any eclipes howto the general suggestion is to use the upstream packages
[17:40] <infinity> Because he's had the Debian ethos of "if it's packaged, use that one" drilled into him.
[17:40] <ogra_> by you
[17:40] <ogra_> :)
[17:40] <infinity> Probably.
[17:40] <infinity> Anyhow, eclipse on armhf should just be a metapackage that depends on vim, gdb, and build-essential.
[17:41] <ogra_> LOl
[17:41] <ogra_> that will also make it easier for doko to port it to Mir :)
[17:42] <doko> infinity, go ahead. with you QA hat on,  your "doing stuff" side does lack a bit ;-P
[17:52] <infinity> doko: I'm not fundamentall against removing eclipse/armhf for raring.  I'd like it if we could fix it, but I'm certainly not going to.
[18:23] <doko> infinity, afk now, would be nice if you could look at the eclipse migration
[18:29] <infinity> Will do.
[18:36] <blitzkrieg3> could we upgrade biosdevname from version 3.11 to 4.1 in precise through an SRU?
[19:11] <bdmurray> slangasek: do you have an opinion on bug 1040833?
[19:11] <ubot2`> Launchpad bug 1040833 in The Dell-poweredge project "Upgrade biosdevname to 4.1 in precise" [High,In progress] https://launchpad.net/bugs/1040833
[19:14] <bdmurray> slangasek: oh, I see your opinion in the bug now
[19:17] <slangasek> like magic :)
[21:09] <balloons> what's up with the builds for beta2? are we re-spinning everything or something? Long day.. hit me if I'm just confused
[21:09] <infinity> balloons: I'm going to be respinning the world, yeah.  It should all be ready tonight/tomorrow.
[22:44] <cjwatson> balloons: could you please not reassign bugs to ubiquity (the upstream project)?  Please reassign them to ubiquity (the source package in Ubuntu) instead
[22:44] <cjwatson> It's an LP bug that it even lets you do this, I think, since I don't think ubiquity upstream is configured for bug tracking
[22:50] <stgraber> cjwatson: looks like we have a few more (just did an API query). I'll move those too. It's indeed rather annoying that LP doesn't prevent that and that the web UI won't let you see them
[22:51] <cjwatson> stgraber: thanks
[22:51] <cjwatson> I think I filed a bug about that a few years back ...
[23:51] <ScottK> pidgin in the Kubuntu packageset.  How odd.
[23:52] <ScottK> Ah.  libpurple.
[23:56] <infinity> ScottK: Yeah.  I've intentionally not accepted anything seeded since I'm in the middle of respin-mania.  If you spot anything in the queue you think is urgent enough to trigger a respin of the bits it affects, speak up.  None of them looked critical to me.
[23:57] <ScottK> infinity: Agreed.  I didnt' see anything that needed to get in now.
[23:57] <infinity> Although, some of the Chinese stuff in NEW is probably wanted for kylin.  I suspect that'll have to wait until after beta.
[23:57] <ScottK> If we do respin Kubuntu, it'd be nice to throw Qapt/Muon in too, but certainly not respin worthy on their own.
[23:57] <infinity> *nod*
[23:58] <infinity> We can accept and build them after the respins are done, so they land on the next potential respin.
[23:58] <infinity> I just didn't want the archive in a state of flux while the world was building.