| cjwatson | ddebs> Ah, now that I catch up on one of the sysadmin channels I see it was handled there. | 00:03 |
|---|---|---|
| slangasek | stgraber: you have bug #1181789 assigned to yourself for raring; do you still mean to follow through on it | 00:52 |
| ubot2` | Launchpad bug 1181789 in upstart (Ubuntu Raring) "second call of 'initctl start' leads to fork instead of exec ('mount: / is busy' during shutdown)" [Critical,Triaged] https://launchpad.net/bugs/1181789 | 00:52 |
| slangasek | ? | 00:52 |
| infinity | cjwatson: Agreed on carobness. However I go about that. | 02:14 |
| stgraber | slangasek: ah yeah, I suppose I should SRU that. | 02:41 |
| stgraber | slangasek: it's one of those tasks I opened because the bug is bad and really should be SRUed, but AFAIK nobody other than me reported it on raring so it's not very pressing. | 02:41 |
| slangasek | stgraber: no, there were lots of other reports of this issue in raring (see the now-duped bug); if you're not going to SRU it, please tell me and I'll take care of it. | 06:07 |
| xnox | slangasek: stgraber: we should push out raring sru with all the fixes that needed to go in. as far as I remember raring sru never validated. | 08:15 |
| cjwatson | infinity: According to RT#53566 you should actually have carob access already ... | 09:09 |
| cjwatson | infinity: As in, it's supposed to be based on ubuntu_archive group membership, which you have | 09:10 |
| xnox | Which kylin seeds are authoritative? lp:~ubuntukylin-members/ubuntukylin/ubuntukylin-meta or lp:~ubuntukylin-members/ubuntu-seeds/ubuntukylin.saucy ? | 10:28 |
| smartboyhw | xnox, I heard that seeds will be used at 14.04 LTS | 10:28 |
| smartboyhw | So, probably the first link | 10:28 |
| smartboyhw | (For Kylin) | 10:29 |
| cjwatson | I sincerely hope it's the second | 10:29 |
| cjwatson | Maintaining metapackages by hand in bzr is daft | 10:29 |
| smartboyhw | I actually questioned them before | 10:29 |
| xnox | cjwatson: both have recentish commits =/ | 10:29 |
| cjwatson | Send them to me, I can supply clue on these matters :) | 10:29 |
| xnox | cjwatson: i guess they do maintain something for their precise spins. | 10:30 |
| infinity | cjwatson: Ahh, well, then maybe I just need to figure out what that means and use it. :P | 12:59 |
| infinity | cjwatson: I do indeed have access to the machine. | 12:59 |
| cjwatson | infinity: Logs are in /srv/launchpad.net-logs/production/<blah> | 13:00 |
| cjwatson | infinity: You may want to lift ~cjwatson/bin/rtail (which I cargo-culted from wgrant, in turn) | 13:00 |
| cjwatson | infinity: Stuff in /home/archvsync/scripts/ shows where the logs are rsynced from, in cases where you can't wait for the regular rsyncs | 13:01 |
| infinity | cjwatson: Shiny. This should prove handy. | 13:01 |
| cjwatson | The copy logs from yesterday were in production/ackee/launchpad/celeryd-production_launchpad_job.log* | 13:02 |
| cjwatson | And of course you'll probably like production/alphecca/buildd-manager.log* | 13:02 |
| infinity | Very tempted to symlink alpaca to alphecca. | 13:03 |
| cjwatson | It's owned by archvsync, you can't :P | 13:05 |
| cjwatson | Though I guess you have a homedir | 13:05 |
| tumbleweed | what needs to be kicked to get ncbi-tools6 to migrate? It's complaining about libvibrant6 being out of date, but I don't see that in Packages | 13:18 |
| cjwatson | Oh, I think last time I looked at that it was proposed-internal NBS | 13:21 |
| cjwatson | Let me have a poke | 13:21 |
| tumbleweed | I'd understand libvibrant6a being NBS, but libvibrant6 is long gone | 13:22 |
| * tumbleweed has no idea what proposed-internal NBS means :P | 13:22 | |
| cjwatson | So | 13:22 |
| cjwatson | We track not-built-from-source (NBS) binaries in saucy | 13:22 |
| cjwatson | http://people.canonical.com/~ubuntu-archive/nbs.html | 13:22 |
| tumbleweed | yes | 13:22 |
| cjwatson | And if a binary is in saucy but not in saucy-proposed, proposed-migration assumes that the NBS binaries are removed when deciding whether the source can be migrated | 13:23 |
| tumbleweed | right | 13:23 |
| cjwatson | But, there is a corner case here | 13:23 |
| cjwatson | Let's say we have version 1 in saucy, version 2 in saucy-proposed which never migrated, and now version 3 in saucy-proposed which is trying to migrate | 13:24 |
| cjwatson | If version 2 built a binary not in version 3, we don't track that | 13:24 |
| cjwatson | So the binary needs to be checked by hand and removed from saucy-proposed | 13:24 |
| tumbleweed | ah, that's possibly the case here | 13:24 |
| cjwatson | It's basically an awkward side-effect of -proposed being a partial suite | 13:25 |
| cjwatson | It's exactly the case here | 13:25 |
| cjwatson | ncbi-tools6 | 6.1.20120620-2 | saucy/universe | source | 13:25 |
| cjwatson | ncbi-tools6 | 6.1.20120620-5 | saucy-proposed/universe | source | 13:25 |
| cjwatson | libvibrant6 | 6.1.20120620-3 | saucy-proposed/universe | amd64, armhf, i386, powerpc | 13:25 |
| cjwatson | libvibrant6-dbg | 6.1.20120620-3 | saucy-proposed/universe | amd64, armhf, i386, powerpc | 13:25 |
| tumbleweed | aah, libvibrant6 was never removed from -proposed | 13:25 |
| tumbleweed | that makes sense | 13:25 |
| cjwatson | Exactly | 13:25 |
| cjwatson | Just checking for rdepends now | 13:25 |
| === didrocks1 is now known as didrocks | ||
| cjwatson | tumbleweed: removed, thanks | 13:31 |
| tumbleweed | cjwatson: thank you | 13:33 |
| stgraber | slangasek,xnox: oh, apparently I'm not subscribed to bugs for the upstart package in Ubuntu, that'd explain why I didn't see any bug trafic. | 13:37 |
| stgraber | slangasek: I believe at the time we had an SRU in proposed so that's why I didn't upload it directly, though I see that's no longer the case, so I'll at least push the cherry-pick to the branch and update the bug with a testcase (not sure if it has the SRU headers already) | 13:44 |
| xnox | right. and we might be missing a few other bug-fixes on the SRU that should go in. | 13:46 |
| === blitzkrieg3 is now known as jmleddy | ||
| cjwatson | stgraber: ^- | 14:59 |
| stgraber | looking | 14:59 |
| stgraber | cjwatson: there you go ^ | 15:01 |
| infinity | cjwatson: Want to add any-ppc64el to debian/control upstream so we don't forget later? | 15:01 |
| infinity | cjwatson: Hrm, and any-x32 ... How did no one complain about that yet? | 15:01 |
| infinity | I suppose I have commit, don't I. Maybe I'll do that. | 15:02 |
| infinity | Not a branch: "bzr+ssh://bzr.debian.org/bzr/pkg-grub/branches/2.00/" | 15:02 |
| cjwatson | Uh, are you sure upstream configure would handle that? | 15:02 |
| infinity | grump. | 15:02 |
| cjwatson | bzr+ssh://bzr.debian.org/bzr/pkg-grub/trunk/grub/ | 15:03 |
| infinity | cjwatson: Oh, fair point on the ppc64el thing, might need to check. (Though, it should work with a sufficiently new config.{sub,guess}) | 15:03 |
| infinity | cjwatson: But I'm confused that no one's complained about the missing x32... | 15:03 |
| cjwatson | Anyway it needs a bit more than a control tweak - there'll be stuff in rules and files in debian/ too. | 15:03 |
| infinity | Yeah, so I'm seeing upon a grep. | 15:04 |
| infinity | I'll poke it $later, it's certainly not urgent. | 15:04 |
| cjwatson | I can do it nowish. | 15:04 |
| infinity | For 14.04, I need to make some time to see if I can switch to grub2 on all yaboot subarches. | 15:06 |
| infinity | I certainly don't want to bring up any new PPC ports with yaboot. | 15:06 |
| cjwatson | What's x32 in config.{guess,sub} speak? | 15:09 |
| infinity | x86_64-linux-gnux32 | 15:09 |
| infinity | I believe. | 15:09 |
| cjwatson | infinity: Actually, I've uncommitted my ppc64el change. This needs actual build-testing first, because configure.ac does need to be updated. | 15:10 |
| infinity | cjwatson: Yeah, hence my "$later" thing. | 15:10 |
| cjwatson | Ditto I'd really rather be able to see whether x32 works first. | 15:11 |
| infinity | cjwatson: Yeah, don't worry about it. It was an observation in passing when I saw the arches in .dsc | 15:11 |
| infinity | cjwatson: x32 doesn't matter deeply to me, but I can test it in Debian sometime. And ppc64el, I'll argue with it when we have a port. | 15:11 |
| infinity | (The latter will definitely happen due to my previously-mentioned not wanting to have another yaboot port) | 15:12 |
| cjwatson | It's probably just a matter of powerpc64-* -> powerpc64-*|powerpc64le-* and similar in configure | 15:12 |
| infinity | Probably. | 15:12 |
| cjwatson | Oh, heck, it might be more than that, maybe the ELF relocator needs porting | 15:12 |
| infinity | And x32 might be a zero issue thing, since it's x86_64, and the ILP32 part doesn't factor in for the bootloader bit, just for the userspace tools. | 15:13 |
| cjwatson | Yeah, just install it via multiarch | 15:13 |
| cjwatson | Might be nice to build it though | 15:13 |
| * infinity nods. | 15:13 | |
| cjwatson | Wouldn't be too surprising to find a wrong type size somewhere though | 15:14 |
| slangasek | stgraber: yes, 1.8-0ubuntu1.2 had a regression, bug #1199778; so we should get a re-SRU... :) | 15:23 |
| ubot2` | Launchpad bug 1199778 in upstart (Ubuntu Raring) "upstart crashes if re-exec'ed with active chroot sessions" [Undecided,New] https://launchpad.net/bugs/1199778 | 15:24 |
| stgraber | slangasek: ok, if I push the bugfix for the restart bug to the branch and update the bug report with the SRU paperwork, can you or xnox take it from there? | 15:28 |
| xnox | ok, by me. | 15:28 |
| slangasek | stgraber: yes | 15:32 |
| slangasek | stgraber, cjwatson: so I'm happy to see that bug #1187233 is indeed resolved in saucy with the new shim-signed, which means it's time for me to start worrying about SRUs. I'm considering that the best option might be: 1) pull back the gnu-efi source; 2) verify that all revdeps (including shim) build in precise with the updated gnu-efi; 3) pull back sbsigntool; 4) binary copy shim from saucy (so we don't have to submit a new binary to | 15:35 |
| ubot2` | Launchpad bug 1187233 in OEM Priority Project "Grub2 fails on ASUS X201E with secure boot is enabled" [High,Confirmed] https://launchpad.net/bugs/1187233 | 15:35 |
| slangasek | ... reupload shim-signed, with the build-deps adjusted for sbsigntool | 15:35 |
| slangasek | does that sound reasonable / possible? | 15:35 |
| cjwatson | Yeah, unless you think you can figure out a gnu-efi backport | 15:37 |
| infinity | Does your sbsigntool alignment fix also apply to kernel signing? Should we make sure the new version is on ftpmaster? | 15:39 |
| infinity | We've had this discussion, I think. Was the concensus just "meh, wait until ftpmaster is upgraded to precise"? | 15:40 |
| cjwatson | Not sure what the timescale on that's going to be. Might be better to push to lucid-cat. | 15:40 |
| slangasek | infinity: we don't care about the sbsigntool alignment except in the case where we're trying to reproduce the MS-signed output | 15:46 |
| slangasek | the current sbsigntool already produces perfectly valid signed objects that work fine | 15:47 |
| slangasek | so yes, I don't care about pushing this back to lucid-cat | 15:47 |
| infinity | Mmkay, so it's not producing buggy output, per se, just slightly weird output? | 15:50 |
| slangasek | not even weird, just not identical to MS | 15:51 |
| * infinity nods. | 15:51 | |
| infinity | Though, "identical to MS" seems like what you want for SB stuff. | 15:51 |
| slangasek | cjwatson: "does anyone feel desperately that we have to keep this or shall I just go ahead and drop it" - surely those are not mutually exclusive! | 15:52 |
| cjwatson | maybe not well-phrased :) | 15:53 |
| stgraber | xnox: is lp:~ubuntu-core-dev/ubuntu/raring/upstart/raring the right branch to use for the upstart raring SRU? | 16:01 |
| xnox | stgraber: yes, it is. | 16:03 |
| stgraber | cjwatson: did you upload grub2-signed? I can't remember seeing it on saucy-changes | 16:09 |
| cjwatson | Oh, no, I'll go and do that now | 16:10 |
| tjaalton | could someone have a look at glamor-egl in NEW, phoronix is making fun of us still not supporting 3d on newest radeons.. | 16:10 |
| tjaalton | it was uploaded before FF | 16:11 |
| tjaalton | (barely= | 16:11 |
| tjaalton | ) | 16:11 |
| cjwatson | stgraber: done | 16:15 |
| barry | hi folks. i have one package that entered new before ff (nose2) and two packages i submitted ffe's on (pip and virtualenv). i don't mean to be a noodge (and will happily wait patiently) but i just want to make sure they aren't waiting on something from me. | 17:50 |
| rsalveti | in case someone has the time to review another FFe :-), bug 1224665 | 20:03 |
| ubot2` | Launchpad bug 1224665 in gst-plugins-bad1.0 (Ubuntu) "[FFe] Android media support over hybris for gst-plugins-bad1.0" [Undecided,New] https://launchpad.net/bugs/1224665 | 20:03 |
| rsalveti | needed for touch to have hardware decode & rendering support in gstreamer, using the android video hal (over libgstagefright) | 20:03 |
| Laney | rsalveti: what is [i386 armhf] about? | 20:06 |
| rsalveti | Laney: it uses hybris (android), so it can only be tested in i386 and armhf because we only have android devices for those archs | 20:07 |
| rsalveti | that's why I didn't enable it for all archs | 20:07 |
| Laney | sorry, got to leave - no time to review | 20:12 |
| Laney | but what would the harm be in building it everywhere it can? (seems that means !ppc) | 20:12 |
| * Laney leaves it for others | 20:12 | |
| rsalveti | Laney: wouldn't cause any harm I guess, but I know it could only work i386 and armhf as of now | 20:13 |
| infinity | I'm fine with the arch restriction for now. | 20:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!