[01:04] doko: Grr. So, it's /usr/lib/arm-linux-gnueabihf/crtn.o that's vaguely broken. Totally eglibc's fault. Not sure how it got broken, though. [01:46] * infinity goes crosseyed at these Makefiles and decides to EOD instead. [02:02] doko_: not sure I really see the need for blacklisting python3.2. the auto-sync wouldn't have brought it back anyway, and we have a poor record of pruning cruft from the blacklist. [02:04] from my point of view the more cases where auto-sync can dtrt automatically and the fewer things we have to add to the blacklist, the better [02:04] I realise this is a change from the crappy old pile of workarounds for sync-source.py -a [08:46] doko_: Yeah \0/ [09:24] seb128: are you in the process of rebuilding stuff for libcogl11, and/or do you need help? [09:25] cjwatson, that's my plan for the morning, I should be fine without help thanks [09:25] cool, thanks === henrix_ is now known as henrix [09:29] Unpacking libreoffice-common (from .../libreoffice-common_1%3a3.6.2~rc2-0ubuntu5_all.deb) ... [09:29] dpkg: error processing /var/cache/apt/archives/libreoffice-common_1%3a3.6.2~rc2-0ubuntu5_all.deb (--unpack): [09:29] corrupted filesystem tarfile - corrupted package archive [09:29] dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) [09:29] BAH ! [09:29] again [09:29] eagle-data is no longer built by eagle package but britney makes up an excuse "out of date on all arches: eagle-data" [09:29] there is something seriously wrong with the panda livefs builder [09:30] its the second day in a row it has decompression errors (yesterday it was gzip, not tar though but a similar error) [09:31] xnox: That's odd. I'll look once I've dug myself out from under python-apt [09:32] thanks. [09:35] hmm, did we change something wrt the adm group to be used beyond for reading logs ? [09:47] cjwatson, speaking of cogl ... it will stay in proposed until rebuilds are done right? [09:47] seb128: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt looks like yes. [09:47] cjwatson, is that info with the list of rdepends somewhere? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says "Valid candidate " [09:48] xnox, that page is a bit rough to read ;-) [09:48] seb128: see update_output.txt where britney "tries" to migrate "valid candidates" and fails to do so for cogl. [09:49] seb128: Yes, it will, and unfortunately not yet [09:49] Though there will be [09:49] seb128: apparently the format imprints in your brain after a while =) [09:49] or set up a transition tracker [09:49] cjwatson, ok, that's fine, getting the list is easy enough, I was mostly wondering if there was a page I didn't know about there [09:50] Unless you set up a transition tracker as Laney suggests then update_output is the only such page right now [09:50] ok, I will stick to "reverse-depends libcogl9" ;-) [09:51] * seb128 gets started === dbarth__ is now known as dbarth [10:16] doko_: bug 1076305 [10:16] Launchpad bug 1076305 in python3.3 (Ubuntu Raring) "plat-x86_64-linux-gnu is still incomplete" [Critical,Confirmed] https://launchpad.net/bugs/1076305 [10:16] breaks ubiquity & hence all live images. [10:20] I had a quick shot at visualising dependencies in -proposed. But it doesn't show much... lp:~stefanor/+junk/britney-visualisation [10:28] got some sample output? [10:32] for me personally dependencies are easy enough to parse. It's the excuses which are confusing, i.e. the distinction between "building/queued to build" vs "actually failed to build" [10:32] requires an extra lookup on launchpad =) [10:39] xnox, that's not a bug. ubiquity using these looks like a bug ... [10:39] Laney: http://people.ubuntu.com/~stefanor/excuses.dot [10:39] ev, cjwatson: ^^^ [10:39] Laney: as I said, not showing much [10:39] I excluded eeverything outside dependency graphs. [10:40] but it parses the britney output, and could do useful things with the other information... [10:40] mmm [10:41] doko_: hmm... we use it because python-dbus calculates max limit of time-out based on INT_MAX. [10:42] well, DBus does, but yeah [10:42] doko_: but why should it not be exposed any more? I understand that int type in python3 is arbitrary precision, but it kind of helps to know that value in python when interfacing with C / compiled code. [10:43] ev: ack. [10:46] xnox, 3.3 generates this module at build time now, before, it wasn't updated for years. so it much depends which headers are included from in.h. you can't rely on this [10:48] MAX_DBUS_TIMEOUT is dead code anyway [10:48] I'll just remove it [10:48] ok. [10:49] doko_: and limits.h is not included? oh well, such is life. [10:50] doko_: from my point of view, feel free to close the python3.3 task [10:55] doko_: did you mean to close the seriesless task too? [10:57] cjwatson, done. I'm fine to reconsider this, but if it's just in our own code ... [10:57] hah, so it's eglibc2.16 at fault after all. [10:58] cjwatson, done. hmm, it only did show up after changing the raring task ... [10:58] Yes, usual behaviour when wontfixing series tasks === mmrazik is now known as mmrazik|lunch === mmrazik|lunch is now known as mmrazik === Ursinha is now known as Ursinha-afk === Ursinhal is now known as Ursinha === Ursinha-afk is now known as Ursinha [14:00] xnox: OK, so, I more or less have a fix for the eagle-data situation, but it will actually require *some* manual resolution since it has apparently deliberately started building on fewer architectures, which is a situation that requires forcing [14:00] xnox: But there was definitely a bug since it shouldn't have been showing as out-of-date on i386, so thanks for the heads-up [14:04] cjwatson: interesting. Well I synced it, so I did "babysit it" =))))) [14:04] cjwatson: did you respin ubiquity images? it's blocking qa to setup jenkins installer jobs.... [14:05] if not, please do =) [14:07] xnox: respinning Ubuntu desktop now [14:10] cjwatson: thanks. [14:11] usb-creator also has INT_MAX usage & it does use MAX_DBUS_TIMEOUT. Should it just stop using that like ubiquity did? [14:11] ev: ^ [14:12] yes [14:12] ack. [14:13] harder in that case since it actually uses it, but you could just pick a large number [14:13] e.g. hardcode 32-bit INT_MAX [14:13] it's not like it needs to be larger [14:14] cjwatson: ack. [14:25] cjwatson, do you know why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt is not getting cleaned for cogl? [14:25] cjwatson, I might be reading it wrong but we should have things mostly all rebuilt [14:26] how/where is the list of what blocks it still there? [14:31] seb128: it'll be waiting for things to finish building [14:32] seb128: update_excuses is a first pass of package-local checks, such as "is it built everywhere"; update_output is the second pass and considers only things that were allowed through the first pass [14:32] cjwatson, do we have a current list just to make sure I didn't forget any? [14:32] not unless you've set up a transition tracker [14:32] ok [14:38] * cjwatson makes archive-reports lots faster [14:39] is there documentation on setting up a transition tracker entry? [14:39] google is failing me [14:39] ask Laney or xnox [14:39] there's a simple README, but generally just copy an existing one [14:40] oh, http://people.canonical.com/~ubuntu-archive/transitions/readme.txt [14:40] ok [14:41] xnox: eagle forced in now [14:42] seb128: I tend to browse http://release.debian.org/transitions/ and try to find the most similar one. [14:42] seb128: and then tweak the .build-depends & .depends as appropriate. [14:42] xnox, thanks [14:43] there's a fair few examples in our repo now too, which helps [14:43] seb128: also `$ reverse-depends libfoo1 ` and `$ reverse-depends -b libfoo-dev` help a lot =)))) [14:43] xnox, I went through the reverse-depends libfoo but I think I'm done and I've very low visibility if that's right or if I missed one [14:44] yeah, tracker helps in those cases. Plus it shows if any of them FTBFS. [14:45] cjwatson: I still see OLD_PROPOSED_MTIME at archive-reports:85; shouldn't that be updated too? [14:47] uh, what [14:47] oh, blast, that wasn't actually committed so I missed it [14:47] my fault, I didn't know it was VCSed [14:47] well, I saw that it had a branch pointing to Riddell so assumed that it was crufty [14:47] fixing [14:47] yeah, ignore that [14:48] it's just locally vcsed although I'm working on it with a bzr+ssh checkout now [14:50] Laney: better now, I think [14:51] I think that makes sense [14:51] this should make some difference to lillypilly's performance in general - it was periodically being caned by a zillion apt-get processes [15:58] Can somebody have a look at my grub2/precise-proposed SRU? It blocks most of the rest of the SB stack. [16:28] and there we go for the product manifest (currently only on staging): http://iso.qa.dev.stgraber.org/qatracker/series/20/manifest [16:30] stgraber: looks like we are ready to release =) [16:31] nice [16:49] we have a working image \0/ [16:49] hooray [16:49] quick, break it! [16:49] * xnox goes to rebase my ubiquity branches & partman merges [16:50] seb128: I don't understand why update_output thinks empathy is still uninstallable; if it's still that way tomorrow I'll poke at it then [16:51] cjwatson, thanks [16:55] slangasek: there is a 2nd (and probably older than the one you approved) webapps-applications in the quantal proposed queue, should it just be rejected? [16:57] older, really? hmm, I guess so :/ [17:00] slangasek: actually the dates inthe changelog are the same so I've no idea what is up [17:36] cjwatson: Looking at grub2/precise. [17:37] Thanks. Sorry it's kind of long. [17:37] I know how the kernel guys feel all the time now. [17:41] The kernel folks seem to continue to be shocked to realise that I actually read their diffs, too. :P [17:44] cjwatson: Did you test this in a signing-capable PPA to test the results? [17:44] hum, ok, I went through what I think are cogl rdepends, not sure why it's not getting out of proposed, I will need help to understand why [17:45] seb128: I'll look at cogl after I'm done with this review. [17:45] cjwatson, is there anywhere I could check or I just better wait tomorrow when you said you would have a look to the empathy issue? [17:45] infinity: No [17:45] infinity, thanks, please let me know what you look at so next time I'm less stupid and can try to figure out the issue without pinging you guys [17:46] infinity: I did test-build locally and check that it looked about right [17:46] seb128: It's probably a bug in the migration code - no useful report [17:46] I tested empathy in chdist and it was fine there [17:47] cjwatson: If you don't have one set up, care to hand it to Andy to upload to his signing PPA? Might be nice to see it doing what appears to be the right thing. [17:47] My guess would be YA bug in the partial-suite merging code [17:47] mkay [17:47] cjwatson, ok, I will let it to you guys then, thanks, let me know if I can help on anything [17:47] cjwatson: Though, I guess, modulo the actual signing bit, a local build should be about the same. [17:47] apw: would you mind fishing grub2 out of the precise queue and dropping it in your PPA? [17:48] cjwatson, sure [17:48] https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=grub2 [17:48] maybe with a slightly decremented version [17:49] yep [17:49] 3.5~ppa1 works. [17:52] cjwatson: Why are we limiting linuxefi to amd64? Surely, some day, there may be an i686 efi machine? [17:52] It failed to build on i386 for some reason I forgot [17:53] Check. [17:53] So I put it in the "worry about it when it happens" bucket [17:53] * infinity nods. [17:53] Maybe the ia32 vendors will stick with BIOS forever anyway. Who knows. [17:53] There was talk about it on Atom [17:54] But anyway the amd64-only bit is in quantal too [17:54] Certainly not worth doing EFI for old skool (now embedded) i486/i586 stuff, so the Atom is the only likely concern. [17:54] i thought most atom was 64bit capable now, even if one does put 32 on it [17:54] apw: Most new ones are 64-bit, but they're still producing 32-bit parts. So, it's really what the vendors do with those parts. We'll see. [17:54] Last UDS there were not-terribly-specific comments from some vendors that we might need 32-bit EFI at some point [17:55] But it's not reached the stage of being a problem [17:55] And even if they do, it might well not involve secure boot, since Windows 8 only supports UEFI in 64-bit mode IIRC [17:56] (Though this is just from reading articles six months ago rather than direct experience) [17:56] cjwatson, grub2> is in my PPA -- https://launchpad.net/~apw/+archive/signing/+packages [17:58] ta [17:58] "This is only intended as a temporary measure." <-- Famous last words? [17:59] yeah yeah :) [17:59] In theory it still is [17:59] But I didn't get round to revisiting that decision before 12.10 [18:00] I *suspect* that it can be reverted now that we know we're not requiring signed kernels (it predates that being clear) [18:00] But need to check and think about it a bit, and make sure it does something reasonable in the fallback path [18:02] cjwatson: Also, a patch pointing to bzr.lp.net imports as "upstream" is a bit strange, but whatever. :P [18:02] So I thought it better to backport something as close as possible to what we tested in 12.10, at least in terms of SB policy [18:03] cjwatson: Oh, absolutely, if we're going to mangle any of this branching, we need to do it in an unstable release first. [18:03] I generally use LP as the reference because savannah's loggerhead installation at least historically hasn't been very reliable [18:03] It's a mirror rather than an import though - upstream uses bzr [18:03] Oh, right. [18:07] I tried to keep the 1.99-specific mangling to the "supporting backports" patch wherever possible, although there are a few other details like the module list needing to be different for 1.99 [18:07] I will confess I haven't actually tested this on SB because OMG the pain of setting all that up independently [18:08] I thought it was likely to be rather more economical to assemble it all in -proposed and then build images off that [18:08] Indeed. [18:08] But I can possibly try grub-mkrescue off apw's PPA or something [18:08] Well, images aren't necessary. We could stage it all in a PPA and... Yeah. [18:35] cjwatson: The backport support thing wasn't as scary as I thought it would be. Except for the whole utf8 handling bit. [18:37] * infinity blinks at his INBOX... [18:37] cjwatson: Did britney go crazy last night and copy apt 6 times in a row? [18:41] cjwatson: Okay, want to poke at http://ppa.launchpad.net/apw/signing/ubuntu/dists/precise/main/uefi/grub2-amd64/ and see if it seems to be what you think it should be? [18:41] cjwatson: I didn't see anything obviously broken in the diff, so I'm inclined to accept once you've had a poke at the PPA output. [18:42] why does the diff for shotwell in quantal proposed include a version that is already in quantal? [18:42] http://launchpadlibrarian.net/121739080/shotwell_0.13.0-0ubuntu2_0.13.1-0ubuntu1.diff.gz [18:42] bdmurray: The diff is generated against the last version that was in proposed. [18:42] because queuediff diffs against the last version of the package that was in quantal-proposed :/ [18:42] bdmurray: Longstanding bug. [18:43] is there a workaround? [18:43] Yeah, download the sources and diff yourself. :P [18:44] apt-get source foo && queue fetch foo && debdiff *dsc [18:44] (Or however you prefer to obtain A and B) [18:45] bdmurray: pull-lp-source $package [$distro[-$pocket]] is also nice. [18:46] I need to train my fingers to use that. [18:47] I assume it just does an API lookup for the latest published in $series, and then dgets it (ish)? [18:52] infinity: yeah. But it's clever and with $ pull-lp-source package it tries raring-proposed and then raring ;-) [18:52] and it fetches from librarian, not from archive mirrors. [18:52] so you can request _any_ version e.g. $ pull-lp-source package 0.3.2-21build3 [18:53] also pull-debian-source does the same but for debian (again series or versions) and it fetches _any_ version from snapshots.debian.net =))))) [18:53] cunning pair of beasts. [18:53] xnox: I was just about to ask. [18:53] xnox: I hit snapshot and dget all the time. [18:53] xnox: This could prove a handy tool to train myself to actually use. [18:54] xnox: thanks [18:54] infinity: well I did wrapper scripts for both =))) to do grab-sync & grab-merge to bang ubuntu&debian versions together, show debdiff and test sbuild them. Handy for sponsorship. [18:59] this is packaging remaining tools needed to build nexus7 images on ubuntu. [19:00] sources were already part of the source package, but the binaries were not previously built. [19:00] please accept =))))) [19:04] xnox: Your changelog doesn't match reality. :P [19:05] infinity: in what sense? [19:05] xnox: Did you want it to be android-tools-fsutils or android-tools-ext4-utils? [19:05] xnox: Changelog says the latter, package says the former. [19:06] infinity: meh... i had three names and kept on changing them. the one that is actually built as a deb is the one I wanted. [19:06] Alright. [19:06] "fsutils" [19:06] sorry about confusion. [19:06] * xnox naming packages is hard [19:16] Grr, seb left just as I was about to tell him why cogl was broken. :P [19:17] Laney: Any urge to update gnome-desktop3 to >= 3.6.1? That's snagging a bunch of stuff in proposed, and you're TIL. [19:23] infinity: tells us, why is cogl broken? =) === yofel_ is now known as yofel [19:46] oh, I guess gnome-desktop3 is my fault, I can upload the new version === henrix is now known as henrix_ [19:46] infinity: lol ;-) [19:49] jbicha: Ahh, thanks. [19:50] xnox: It was that. Or, rather, that a bunch of stuff is all snagged together, and some things depend on the new gnome-desktop, which doesn't exist yet. :P [19:56] bdmurray: can you take a look at bug 205509 and let me know if I have put enough detail/info to get the fix picked up for quantal? [19:56] Launchpad bug 205509 in transcode (Ubuntu) "tcdecode(dvdrip) fails to work" [Undecided,Fix released] https://launchpad.net/bugs/205509 [19:58] i suppose that question could also apply to ScottK and skaet [20:00] jetsaredim: the test case could use some more details but it seems fine to me [20:01] jetsaredim: Your test case isn'ta test case. [20:01] bdmurray: Jinx. [20:01] suggestions? [20:02] jetsaredim: Test cases should just be something like "run 'foo-command --switch argument' and watch it fail before update, and succeed after" [20:02] infinity: fair enough [20:02] jetsaredim: The point being that someone other than you should be able to follow the directions to reproduce, if required. ;) [20:02] does it necessarily have to be the the exact command [20:02] cause it's much easier to reproduce the issue through dvdrip [20:03] since all the flags and whatnot are set for you [20:04] jetsaredim: Sure. Doesn't matter what the testcase is, as long as it's descriptive steps that show the problem. [20:04] jetsaredim: Anyhow, it otherwise looks fine, and the 1-line diff isn't exactly hard to understand. [20:04] sure [20:05] what is the process for getting this into quantal-updates? [20:05] jetsaredim: Actually, the original bug description seems to have a command line that would be a reasonable test-case. :P [20:05] not that it's a major earth-shattering issue but its bugging the hell out of me [20:05] yea [20:05] i was just about to copy/paste that [20:05] jetsaredim: The next step would be finding someone willing to sponsor the upload, if you're not an uploader yourself. [20:05] yes, i'm not [20:06] Wow, old bug. [20:07] jetsaredim: Would you be able to test packages on both precise and quantal if someone (say, me) were to do the actual SRUs for you? [20:07] i'm sure i could fire up a vm for precise [20:08] i don't currently have this in a branch at the moment [20:08] so i guess i'd need to do that first? [20:08] jamespage: Don't worry about that. It's a 1-line patch, I'll JFDI. [20:08] Err. [20:08] jetsaredim: ^ [20:08] jamespage: Nevermind, tab fail. [20:08] heh [20:08] kthen [20:12] jetsaredim: Oh, hrm. Looks like precise has --enable-libmpeg2convert [20:12] jetsaredim: Can you confirm that in a VM? I'll do the quantal SRU now. [20:12] sure [20:13] infinity: i'll have to do an install first but shouldn't take that long [20:13] Makes a more valid argument for the Q SRU, if it's a regression from precise. [20:14] indeed [20:18] bdmurray: If you want to give the above 1-line diff a quick once-over, then we can get The Guy Who Knows How To Test This to test it soon. :P [20:18] * infinity hates verifying bugs where the test case, ultimately, starts with "obtain some data file you may not have". [20:19] infinity: as far as I'm concerned, that's not a valid test case [20:19] yea - unfortunately there's really not much use for transcode without a random datafile to "trans" [20:20] if the test case can't be followed by someone who doesn't already have the environment/data/package, it's not a complete test case [20:20] slangasek: Well, in this case, I suspect it fails on nearly any vob. But if you don't happen to have any vobs handy, I'm not sure it's sane to demand someone furnish you with one, rather than just asking them to test. [20:20] slangasek: And if the test case involves, say, a copyrighted vob you can't distribute... [20:21] sure; in most cases you can probably link to whoever /is/ distributing it, though [20:22] slangasek: Link to, as in "Step 1: Buy a copy of Fight Club, director's cut, region 2"? [20:22] heh, not so much [20:22] "here's a torrent" <- wfm ;P [20:22] Naughty. [20:22] i suspect that's why not too many people have commented on the bug [20:23] jetsaredim: That fine line between not wanting to admit you rip DVDs and wishing the tool worked right? [20:23] indeed [20:23] jetsaredim: Thankfully, it's perfectly legal to rip copyrighted DVDs in many places that aren't the US. :P [20:24] infinity: ahwell, I just wrote an SRU test case that says "make smoser test", so I'm clearly not as much a purist as I pretend either [20:27] slangasek: *laugh* [20:33] jetsaredim: If you're on amd64, the build's done, if you want to go forth and verify: https://launchpad.net/ubuntu/+source/transcode/3:1.1.7-2ubuntu1/+build/3967662 [20:33] precise still building [20:34] jetsaredim: I'm pretty sure it should be fine in precise, from looking at debian/rules, but verifying there would be nice too, sure. [20:34] doesn't like Big Bunny offer a *free* dvd. Can it be reproduced with that? [20:34] (I already invalidated my precise task) [20:34] xnox: I'm sure it can probably be reproduced with free data from somewhere. On the other hand, with someone here right now who can test, I don't really care what data they use. [20:35] (In the absence of a tester, I likely wouldn't have SRUed at all) [20:35] infinity: seems to workie on quantal [20:36] jetsaredim: Shiny, follow up to the bug with that info and set the verification-done tag, s'il vous plaît. [20:40] let me know if you *do* want me to test the precise version [20:42] jetsaredim: Well, precise's debian/rules looks correct. Based on that, I invalidated the precise task, so I'm not wildly picky. If someone decides it doesn't work, they can reopen the bug on precise. [20:42] jetsaredim: (Looks like this regressed in Q when we synced with Debian, which had the flag disabled) [20:42] ok [20:43] i'm updating my precise vm at the moment and can verify shortly [20:44] jetsaredim: Alright, cool. [20:44] Laney: You're off the hook for gnome-desktop3, jbicha delivered. [20:44] many thanks [20:44] I saw [20:45] what was snagged on it? [20:45] Let's see if this makes britney happy with the gnome/cogl/etc mess. Should do. [20:45] I'd rather the person who made /that/ happen be on the hook (perhaps that was jbicha) [20:45] Laney: It was probably him, yes. :P [20:47] Laney: Yeah, it was his gnome-shell upload that bumped some deps to 3.6.1 [20:48] * Laney nods [20:50] infinity, cjwatson: QA tracker changes landed in production so we now have the manifest API and all the needed magic for his cycle. [20:50] *this [20:50] stgraber: \o/ [20:50] stgraber: Can you take a very long coffee break for a few days, so I don't feel like such a slacker? [20:50] stgraber: Thanks. [20:51] :) [21:00] sometimes I wonder if stgraber really ever sleeps. [21:00] oh I'm sure I'm sleeping a lot more than some of my colleagues ;) [21:15] highvoltage: What's "sleep"? [21:18] slangasek, thats fine. i did at least sniff the raring stuff. [21:19] but i didntn look at read-only iscsi root. [21:26] infinity: I dumped the work items from the pad into https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-release-manifest-streamlining so I could mark mine as done, I'll let you do the rest of the drafting though :) [21:29] stgraber: Gee thanks, I was really worried someone else might draft it for me. :P [21:31] infinity: no problem, I know how much you like drafting those, I wouldn't take that away from you ;) === henrix_ is now known as henrix [21:44] smoser: right; this is for the SRU to precise, to let your cloud-init stuff work in all its glory, so certainly needs more complete testing [21:45] sort of. [21:45] i'm fairly confident in the non-iscsi root case. [21:46] and, at least fo rth eime being, the iscsi-root case is covered as the images already have a patched mountall and patched cloud-init. [21:47] smoser: you're using a non-distro patched mountall package for official Ubuntu cloud images? [21:47] no. [21:47] for the maas.ubuntu.com/images images. [21:47] which are only used in maas. [21:47] hmm, alright [21:47] i wasn't happy about that. [21:48] well anyway, I'd like you to not have to do that either [21:48] but... i'm using copied mountall from quantal. [21:48] which is why I've pushed the mountall SRU to precise [21:48] right. === henrix is now known as henrix_ === doko_ is now known as doko [23:32] infinity: the structure of that grub2 build looks ok. not tried actually booting as yet, as I say ... [23:32] cjwatson: Meh, booting is overrated. [23:34] That's a whole lot of tasks on bug 1075181... [23:34] Launchpad bug 1075181 in shim (Ubuntu Precise) "Backport UEFI Secure Boot support for Ubuntu 12.04.2" [High,In progress] https://launchpad.net/bugs/1075181 [23:35] I *think* I got them all [23:36] * infinity adds linux-lts-quantal-signed. [23:37] awesome, thanks. will continue with the rest of the stack tomorrow === henrix_ is now known as henrix [23:38] Cute that I can assign bug tasks to it, even though it only exists in a PPA. [23:39] infinity: britney/apt> six is a bit excessive, but if it gets a bit lost and runs multiple times during a single publisher run then that kind of thing can happen [23:39] cjwatson: Was the plan to also make this work with 3.2.0, or only with the backport kernels? [23:39] yeah, all you need is an SPN === henrix is now known as henrix_ [23:39] only with the enablement kernels [23:39] Alright, then I'll delete the linux-signed task from there. [23:39] ok [23:40] 'cos otherwise we have to backport the efi handover protocol stuff [23:40] and meh === henrix_ is now known as henrix [23:42] infinity: gnome-desktop3 migrated but cogl is still stuck [23:42] jbicha: Fun. Let me look why now. [23:45] jbicha: Hrm. Looks installable to me now. Let's see if britney tries harder this next cycle. [23:47] Oh, wait. My "looks installable" apt run shows both libcogl11 and libcogl9 being installed. I suspect that's ungood. :P [23:49] libclutter-gst-1.0-0 : Depends: libcogl9 (>= 1.9.6) but it is not going to be installed [23:49] * infinity checks if a no-change rebuild will fix that. [23:52] jbicha: What I used to determine this, BTW: http://paste.ubuntu.com/1343991/ [23:53] jbicha: Basically "explicitly don't install libcogl9, and try to install everything that britney was complaining about being broken". [23:54] jbicha: And for added fun, clutter-gst doesn't build against raring-proposed. Is there a new upstream? [23:54] infinity: oh yeah, it looks like we didn't even try to rebuild it [23:55] jbicha: I just tried, iz broke. [23:57] jbicha: Ahh, there's a 1.9 going on upstream, perhaps that's what we want. [23:57] infinity: no, that's clutter-gst-2.0 [23:58] Though, you'd think not, as that's un... Yeah. [23:58] jbicha: Well, either way, the 1.6 no workie, so needs fixing. [23:59] infinity: ok at least we know where the problem is; I'll try poking on it tonight [23:59] jbicha: Danke.