| === slangase` is now known as slangasek | ||
| 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) | 02:45 |
| infinity | Don't accept the d-i upload I just uploaded, I'll accept it once the PPC kernels publish. | 03:53 |
| === doko__ is now known as doko | ||
| === psivaa_afk is now known as psivaa | ||
| 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:03 |
| 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:21 |
| cjwatson | I don't know whether the mainline kernel builds have the right things turned on to support SB. | 10:22 |
| 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:23 |
| 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:24 |
| cjwatson | It's a fair amount of work | 10:25 |
| === ZarroBoogs is now known as Pici | ||
| 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:16 |
| 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:17 |
| 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:18 |
| smartboyhw | That's the strange thing | 13:19 |
| cjwatson | $ host -t mx conanical.com | 13:22 |
| cjwatson | Host conanical.com not found: 3(NXDOMAIN) | 13:22 |
| cjwatson | smartboyhw: ^- | 13:23 |
| smartboyhw | lol | 13:23 |
| davmor2 | Yay Ubuntu is working against secureboot again with todays iso :) | 13:40 |
| cjwatson | davmor2: great | 13:41 |
| 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:54 |
| cjwatson | stgraber: well, a newer one than when I asked :) | 13:55 |
| 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:56 |
| 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:57 |
| cjwatson | xnox: he was uploading haskell packages as recently as Sunday, at least | 13:58 |
| xnox | Oh, ok =) | 13:58 |
| cjwatson | the other haskell problem that I currently know to be a porting issue is haskell-cipher-aes/powerpc | 13:59 |
| === gema_ is now known as gema | ||
| 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:00 |
| === rsalveti_ is now known as rsalveti | ||
| === Ursinha_ is now known as Ursinha | ||
| cjwatson | that one is curious for (a) first 128 bits of output are correct (b) weirdest hex encoding ever | 14:06 |
| ogra_ | cjwatson, hmm, i just got a strange erros from the nexus7 daily-preinstalled | 14:23 |
| ogra_ | looks like the new lock check code has a hiccup for builds that just failed without lock issues | 14:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:29 |
| 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:30 | |
| ogra_ | hmm, you quietened the cmdline output too when doing manual builds | 14:31 |
| cjwatson | Yep - use DEBUG=1 or tail the log | 14:35 |
| cjwatson | (DEBUG=1 won't publish) | 14:36 |
| 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:37 |
| cjwatson | doko: mind if I use ~ubuntu-toolchain-r/test to test a haskell-cipher-aes/powerpc fix? I'll delete it afterwards | 14:49 |
| ogra_ | cjwatson, hmm, now it returned but i didnt get a failure mail | 14:51 |
| doko | cjwatson, sure | 14:51 |
| ogra_ | ah, ignore that ... mail delivery was just slow | 14:52 |
| smartboyhw | infinity: ping | 14:52 |
| 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 | 14:56 |
| 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:09 |
| 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:10 |
| balloons | is infinity about yet? looking for the final beta milestone + images to pop up on the tracker ;-) | 15:31 |
| 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:41 |
| balloons | stgraber, thank you | 15:42 |
| stgraber | jbicha: I assume you'll be participating in beta2? | 16:05 |
| balloons | stgraber, the raring daily is still up | 16:13 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| jbicha | stgraber: yes, there wasn't an email about it this time though, right? | 16:40 |
| infinity | jbicha: No, I didn't send a "who's participating" email, assuming (perhaps naively?) that the answer was "everyone". | 16:43 |
| 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:44 |
| === mmrazik is now known as mmrazik|eod | ||
| * ogra_ sighs about arm lifefs builders | 16:59 | |
| ogra_ | *livefs too | 16:59 |
| doko | infinity, any reason for you linux-omap4 action? | 17:14 |
| 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:16 |
| doko | infinity, is this documented somewhere? | 17:17 |
| infinity | Does it need to be? | 17:17 |
| 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:18 |
| 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:19 |
| xnox | doko: we are not getting any new driver blobs for omap4/panda so the kernel is "frozen" at quantal, until EOL. | 17:22 |
| 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:23 |
| infinity | (Because of the lack of GLES blobs) | 17:24 |
| 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:25 |
| 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:26 |
| ogra_ | celbalrai falls over once a week with the stale lock atm ... and since today it cant even unpack packages anymore it seems | 17:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| * 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| ogra_ | LOl | 17:41 |
| ogra_ | that will also make it easier for doko to port it to Mir :) | 17:41 |
| doko | infinity, go ahead. with you QA hat on, your "doing stuff" side does lack a bit ;-P | 17:42 |
| 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. | 17:52 |
| doko | infinity, afk now, would be nice if you could look at the eclipse migration | 18:23 |
| infinity | Will do. | 18:29 |
| blitzkrieg3 | could we upgrade biosdevname from version 3.11 to 4.1 in precise through an SRU? | 18:36 |
| 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:11 |
| bdmurray | slangasek: oh, I see your opinion in the bug now | 19:14 |
| slangasek | like magic :) | 19:17 |
| 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. | 21:09 |
| 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:44 |
| 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:50 |
| cjwatson | stgraber: thanks | 22:51 |
| cjwatson | I think I filed a bug about that a few years back ... | 22:51 |
| ScottK | pidgin in the Kubuntu packageset. How odd. | 23:51 |
| ScottK | Ah. libpurple. | 23:52 |
| 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:56 |
| 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:57 |
| 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. | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!