=== slangase` is now known as slangasek [02:45] I want to marry sagari and have sexy little powerpc babies with it. Is that wrong? [02:45] (Alternately, just buy a few more machines like it) [03:53] Don't accept the d-i upload I just uploaded, I'll accept it once the PPC kernels publish. === doko__ is now known as doko === psivaa_afk is now known as psivaa [10:03] 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] I haven't had enough coffee to understand that - could you add in the punctuation to help me, please? :-) [10:21] 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] 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] I don't know whether the mainline kernel builds have the right things turned on to support SB. [10:23] There's normally a separate linux-signed-image-* package. [10:23] 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] 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] 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] It's a fair amount of work === ZarroBoogs is now known as Pici [13:16] Hello Ubuntu Release Team, isn't the Beta 2 milestone supposed to be created on the ISO QA Tracker for testing??? [13:16] infinity: ^- [13:16] smartboyhw, hey ! [13:16] * ogra_ hugs smartboyhw ... [13:16] i didnt mean to shock you like that with my april fools blogging :) [13:16] ogra_ thank you for your joke;) [13:17] lol [13:17] (though saying that we consider the euro the most stable currency should have told you ... ) [13:17] ogra_ no I don't know anything about economics;) [13:18] heh ... k [13:18] then the mailing list at the end should :) [13:18] That is;) [13:18] “Ubuntu Engineering Ltd.” ubuntu-april-1st@conanical.com [13:18] ;) [13:18] Does this email address exist actually;) [13:18] dunno, ask conanical.com :) [13:19] That's the strange thing [13:22] $ host -t mx conanical.com [13:22] Host conanical.com not found: 3(NXDOMAIN) [13:23] smartboyhw: ^- [13:23] lol [13:40] Yay Ubuntu is working against secureboot again with todays iso :) [13:41] davmor2: great [13:54] 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] cjwatson: looks like the QATracker eventually noticed the new d-i [13:55] stgraber: well, a newer one than when I asked :) [13:56] cjwatson, I was told that Laney is afak this week. is this the missing bit to get haskell into raring? [13:56] doko: Laney's on holiday but he said he was going to be hacking on haskell while on holiday [13:56] ahh [13:56] doko: it's one of several missing bits, certainly not the only one [13:57] Laney is considerably better at this than I am but I've been trying to move things along where I know how [13:57] 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] xnox: he was uploading haskell packages as recently as Sunday, at least [13:58] Oh, ok =) [13:59] the other haskell problem that I currently know to be a porting issue is haskell-cipher-aes/powerpc === gema_ is now known as gema [14:00] 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] haven't quite tracked it down yet, but that would unstick another chunk of the stack === rsalveti_ is now known as rsalveti === Ursinha_ is now known as Ursinha [14:06] that one is curious for (a) first 128 bits of output are correct (b) weirdest hex encoding ever [14:23] cjwatson, hmm, i just got a strange erros from the nexus7 daily-preinstalled [14:24] looks like the new lock check code has a hiccup for builds that just failed without lock issues [14:25] ogra_: No, that's fine, it's just an extra mail [14:25] But essentially the same failure as before [14:25] Previously it would silently not have run the image-generation part of the build if all the livefs builds failed [14:26] 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] well, i got a proper failure log from the livefs builder (libc6-dev couldn't be installed) [14:26] Yeah, I know, I'm looking at both the mails [14:26] ah, k [14:26] They're different from before, I know, but I did expect this [14:26] ok [14:27] I suppose I might silence the mail notifications in this case; the logging's still useful [14:27] yup, well, if i know i can ignore the traceback i'm fine [14:27] (i see it properly raises the error msg in the last line) [14:29] Unpacking libc6-dev:armhf (from .../libc6-dev_2.17-0ubuntu4_armhf.deb) ... [14:29] dpkg: error processing /var/cache/apt/archives/libc6-dev_2.17-0ubuntu4_armhf.deb (--unpack): [14:29] corrupted filesystem tarfile - corrupted package archive [14:29] GRRR [14:29] i guess thats just a retry [14:29] (i doubt we have corrupt packages in the archive :) ) [14:30] OK, I've silenced the image build failure mail in this case [14:30] Indeed, that's much more likely to be builder-side corruption [14:30] * ogra_ fires off a manual build ... [14:31] hmm, you quietened the cmdline output too when doing manual builds [14:35] Yep - use DEBUG=1 or tail the log [14:36] (DEBUG=1 won't publish) [14:37] 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] k, no prob ... i just noticed it [14:37] (wasnt a complaint ... or at least shouldnt have been) [14:49] doko: mind if I use ~ubuntu-toolchain-r/test to test a haskell-cipher-aes/powerpc fix? I'll delete it afterwards [14:51] cjwatson, hmm, now it returned but i didnt get a failure mail [14:51] cjwatson, sure [14:52] ah, ignore that ... mail delivery was just slow [14:52] infinity: ping [14:56] Unpacking aptdaemon (from .../aptdaemon_1.0-0ubuntu8_all.deb) ... [14:56] dpkg-deb (subprocess): decompressing archive member: internal gzip read error: ': incorrect data check' [14:56] tar: This does not look like a tar archive [14:56] tar: Exiting with failure status due to previous errors [14:56] SIGH ! [14:56] starts looking serious [15:09] 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] cjwatson, sounds ok, I'm currntly not using it [15:10] ok, tweaking [15:10] for the 4.8 test rebuild I ddidn't want -proposed [15:31] is infinity about yet? looking for the final beta milestone + images to pop up on the tracker ;-) [15:41] 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] stgraber, thank you [16:05] jbicha: I assume you'll be participating in beta2? [16:13] stgraber, the raring daily is still up === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [16:40] stgraber: yes, there wasn't an email about it this time though, right? [16:43] jbicha: No, I didn't send a "who's participating" email, assuming (perhaps naively?) that the answer was "everyone". [16:44] well, final beta is not an optional milestone... if a flavor is releasing, they're expected to be part of the beta :) [16:44] 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 === mmrazik is now known as mmrazik|eod [16:59] * ogra_ sighs about arm lifefs builders [16:59] *livefs too [17:14] infinity, any reason for you linux-omap4 action? [17:16] 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] infinity, is this documented somewhere? [17:17] Does it need to be? [17:18] well, apparently two people didn't know about it [17:18] And now they do. I'm not sure documentation would have solved that. [17:18] and I don't think it would hurt to fix these to eliminate the noise [17:19] 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] Just need to make sure the people involved know. [17:22] doko: we are not getting any new driver blobs for omap4/panda so the kernel is "frozen" at quantal, until EOL. [17:23] nice, so we are getting new buildds for 14.04? ;-P [17:23] Yes, AIUI [17:23] Yes. [17:23] Though, that doesn't relate. [17:23] Cause the -generic kernel will boot omap4 just fine and work for buildds. [17:23] Just not for desktops. [17:24] (Because of the lack of GLES blobs) [17:25] 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] given thee current reoccuring probs with the buildds i would actually vote for trying -generic right now on them :P [17:25] (5year - 6 months) [17:25] infinity, ^^^ [17:26] ogra_: No thanks. [17:26] well, then no images :P [17:26] unless there is a HW error which i dont belive there is [17:27] celbalrai falls over once a week with the stale lock atm ... and since today it cant even unpack packages anymore it seems [17:28] That sounds like hardware to me. [17:28] Unless you think celbalrai's kernel is somehow magically different from all the other buildds. [17:28] well, it was only different for the first two weeks when it was newly set up [17:28] since then its a regular thing [17:28] 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] yeah, i know [17:29] infinity: what was before? [17:29] 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] xnox, babbage imx51 [17:29] xnox: Beagles, Babbages, qemu, some old Marvell armv5 platform. [17:30] ok. [17:30] and *they* were crap ... [17:30] 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] even in the brtoken state the pandas are more stable [17:30] Debian still uses those as armel buildds, and they're pretty solid. [17:30] did we actually have beagles in ubuntu ? [17:31] ogra_: Yeahp, all the a*ceaea machines were beagles. [17:31] * ogra_ thought that was linaro stuff only [17:31] They were livefs builders and lp-buildds. [17:31] anyway ... [17:32] * ogra_ goes to file an RT so we possibly have livefses by end of the week again :P [17:32] ogra_: Are both livefs builders broken? [17:32] ogra_: If not, we can just shove all the builds on to the other. [17:32] hmm [17:33] the omap images seem to have built [17:33] which omap? [17:33] and celbalrai seems fine up to the point where it thinks that the tarball it wants to unpack isnt one [17:33] err, not omap ... [17:33] Hrm? [17:33] server [17:34] ogra_: Point me at a log of this tarball thing? [17:34] http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/ubuntu-nexus7/20130402.1/livecd-20130402.1-armhf.out [17:34] http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/ubuntu-nexus7/20130402.1/livecd-20130402-armhf.out [17:35] dpkg-deb (subprocess): decompressing archive member: internal gzip read error: ': incorrect data check' [17:35] tar: This does not look like a tar archive [17:35] Found it, yeah. [17:35] tar: Exiting with failure status due to previous errors [17:35] dpkg-deb: error: subprocess tar returned error exit status 2 [17:35] dpkg: error processing /var/cache/apt/archives/language-selector-gnome_0.108_all.deb (--unpack): [17:35] right [17:35] That could just need a reboot and some prayer. [17:35] it does that randomly on different packages [17:35] and i have seen it before ... several times [17:36] though usualy the next build was fine then ... until it went ro with a stale lock [17:36] 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] ogra_: The ro thing, though, sounds like hardware. [17:36] i suspect its the same [17:37] and i suspect the USB layer [17:37] We certainly don't have all the Pandas going ro for no reason constantly. [17:37] or more ... power of the USB layer [17:37] Yeah, lacking power is also possible. That's still "hardware issue" to me. [17:37] since thats a typical point of failure on the panda [17:38] 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] ++ [17:39] do people even use eclipse from the archive at all ? [17:39] there are not that many masochists [17:39] heh [17:39] i meant on x86 actually [17:39] I have a friend who uses the archive version. [17:39] doko: go ahead [17:40] every time i come across any eclipes howto the general suggestion is to use the upstream packages [17:40] Because he's had the Debian ethos of "if it's packaged, use that one" drilled into him. [17:40] by you [17:40] :) [17:40] Probably. [17:40] Anyhow, eclipse on armhf should just be a metapackage that depends on vim, gdb, and build-essential. [17:41] LOl [17:41] that will also make it easier for doko to port it to Mir :) [17:42] infinity, go ahead. with you QA hat on, your "doing stuff" side does lack a bit ;-P [17:52] 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] infinity, afk now, would be nice if you could look at the eclipse migration [18:29] Will do. [18:36] could we upgrade biosdevname from version 3.11 to 4.1 in precise through an SRU? [19:11] slangasek: do you have an opinion on bug 1040833? [19:11] 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] slangasek: oh, I see your opinion in the bug now [19:17] like magic :) [21:09] 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] balloons: I'm going to be respinning the world, yeah. It should all be ready tonight/tomorrow. [22:44] 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] 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] 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] stgraber: thanks [22:51] I think I filed a bug about that a few years back ... [23:51] pidgin in the Kubuntu packageset. How odd. [23:52] Ah. libpurple. [23:56] 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] infinity: Agreed. I didnt' see anything that needed to get in now. [23:57] 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] 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] *nod* [23:58] We can accept and build them after the respins are done, so they land on the next potential respin. [23:58] I just didn't want the archive in a state of flux while the world was building.