[00:06] <slangasek> skaet: so I'm starting to go through https://wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/CommonInfrastructure and clean it up a bit; what are the criteria for the bugs listed in the kernel section?  Because they seem quite scattershot to me, and many of the ones listed had never been confirmed on quantal
[00:07] <slangasek> ("scattershot" in that they seem to be bugs of varying importance, I'm not sure why these are the kernel bugs that wound up in the release notes)
[00:14] <skaet> slangasek,  I took them from the list that ogasawara reports on each week.   I expected they'd be pruned down but figured I'd leave it to her.
[00:24] <skaet> slangasek, as you clean up, feel free to remove the status info I included from the blueprint scans.
[00:52] <doko_> slangasek, https://launchpadlibrarian.net/119290440/buildlog_ubuntu-quantal-armel.update-notifier_0.125_FAILEDTOBUILD.txt.gz expected?
[00:56] <infinity> doko_: Fixed in 0.126
[00:56] <doko_> ohh, thanks
[01:13] <stgraber> Riddell: http://paste.ubuntu.com/1270326/ <- seems like the langpack mess isn't quite solved yet
[01:51] <slangasek> skaet: ah; I wouldn't have expected there to be any correlation between the list of worked / release-relevant bugs and the ones we would want to release note.  Ok, I'll let Leann take it from there.
[01:51] <slangasek> skaet: as for blueprints, yes, I've cleaned up most of those; there are still a few that need followed through on
[02:05] <skaet> slangasek, ack.
[03:12] <slangasek> reuploading shim-signed, because we now have a signed shim \o/
[03:14] <skaet> :)
[03:14] <skaet> nice news to hear.
[03:48] <skaet> stgraber, highvoltage - https://wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/Edubuntu - could you please review and have updated before Thursday?
[04:29] <pitti> zyga: I am online now
[04:30] <pitti> Daviey, stgraber: thanks for reviewing checkbox; we really need to move away from the old udisks 1.x stuff, and checkbox is the second-last package in main holding it
[04:30] <pitti> zyga: nice to see you got it in, thanks muchly!
[05:40] <Daviey> pitti: woot
[06:29] <tkamppeter> pitti, cjwatson, yesterday I have uploaded the fix for bug 1014852. Will this get into Quantal?
[06:29] <ubot2> Launchpad bug 1014852 in pyppd "openprinting-ppds crashed with UnicodeEncodeError in ls(): 'ascii' codec can't encode character '\ufffd' in position 92: ordinal not in range(128)" [Medium,Confirmed] https://launchpad.net/bugs/1014852
[06:29] <pitti> tkamppeter: I'm not on the release team any more
[06:29] <pitti> but simple bug fixes have a good chance to make it, I think
[07:25] <Daviey> tkamppeter: I don't see it in the queue?
[07:28] <Daviey> ogra_: Hey, do you fancy looking into why LiveFS failed to build for server ompa/omap4?
[07:28] <Daviey> armhf
[07:30] <cjwatson> looked like a checksum error on some package or other iirc, which is usually transient
[07:47] <tkamppeter> Daviey, it should be in quantal-proposed, and someone accepted it there.
[07:55] <cjwatson> tkamppeter: I've copied foomatic-db to quantal now
[07:57] <cjwatson> infinity: any luck with fso-frameworkd?
[08:20] <mvo> is http://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main/revision/2553 acceptable at this point ? or SRU? its nr12 on errors.u.c for 12.10
[08:21] <apw> mvo, the distro entry in that changlog is borked
[08:21] <seb128> mvo, UNRELEASEDquantal
[08:21] <seb128> what apw said
[08:21] <cjwatson> mvo: Looks fine to me
[08:21] <mvo> I know
[08:21] <mvo> thanks, I will unbork/upload
[08:22] <cjwatson> MIR folks: we need bug 1064899 looked at as a matter of urgency
[08:22] <ubot2> Launchpad bug 1064899 in shim-signed "[MIR] shim, shim-signed" [Critical,New] https://launchpad.net/bugs/1064899
[09:04]  * cjwatson copies libreoffice, finally
[09:34] <tkamppeter> cjwatson, thanks.
[10:02] <cjwatson> doko_,didrocks: ^- see my MIR above for shim/shim-signed (1064899)
[10:03] <cjwatson> close to being blocked on this
[10:04] <didrocks> cjwatson: looking
[10:08] <didrocks> cjwatson: I guess the link to amd64 only and having shim only built for this arch is on purpose?
[10:09] <cjwatson> didrocks: Yes - we're only attempting to support UEFI at all on amd64 at the moment
[10:09] <cjwatson> (Which may have to change in the future, if we don't manage to avoid it, but that's not today's headache)
[10:09] <didrocks> cjwatson: ok, of course, I'm not competent enough seeing the rush to do a full code review, will trust you on it :)
[10:13] <cjwatson> I believe the security-sensitive bits are basically copied from Tianocore
[10:15] <didrocks> cjwatson: hum, what about debian/copyright for shim-signed? From what I understand, it's a binary efi version we got signed from Microsoft, shouldn't that be mentionned in it?
[10:16] <cjwatson> Actually Microsoft only supplied the signature
[10:16] <cjwatson> Which I don't believe is copyrightable
[10:16] <didrocks> ok, so no code change at all?
[10:17] <cjwatson> No, it just has to be in a separate package because the process involves building shim, submitting through a Microsoft website, and then you get the sig back
[10:17] <cjwatson> We've verified independently that the binaries match
[10:17] <cjwatson> (cf. 'make check' there)
[10:17] <didrocks> cjwatson: ok, good, just checking some small things and it should be ok :)
[10:17] <didrocks> cjwatson: just for my personal knowledge, does Built-Using has any meaning?
[10:18] <didrocks> I never saw it before
[10:18] <cjwatson> It's a recent thing in Debian policy 3.9.4
[10:18] <cjwatson> It's intended to influence garbage-collection in the archive
[10:18] <cjwatson> Launchpad doesn't implement it yet; not even sure if the Debian archive does
[10:18] <didrocks> well, the case of having a binary content built and slightely modified from another package is not widespread I guess :)
[10:18] <didrocks> interesting :)
[10:18] <cjwatson> There are a number of cases where it's relevant; consider debian-installer, say
[10:19] <cjwatson> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using
[10:19]  * didrocks looks
[10:19] <cjwatson> For now, we're just being excessively pedantic by including it, but hopefully eventually it'll actually be useful
[10:20] <didrocks> cjwatson: shim-signed is enough on its own, right? on the targeted machine. it's the binary content + the signature in one file? (we don't need shim, hence the built-using instead of dep)
[10:21] <cjwatson> shim-signed Build-Depends: shim
[10:21] <cjwatson> But target machines don't need shim,no
[10:21] <didrocks> yeah, it was what I meant :)
[10:21] <cjwatson> We need both in main due to the build-dep
[10:21] <didrocks> indeed
[10:22] <cjwatson> But yeah, it includes the signature, it's not detached
[10:22] <cjwatson> (sbattach(1) can manipulate this)
[10:22] <didrocks> oh, interesting :)
[10:23] <didrocks> ok, both looks good to me (apart from the code that I can't look in that rush, even not sure to be competent enough), do you want me to do the promotion?
[10:23] <RAOF> Oooh, that was nice and quick.
[10:24] <cjwatson> didrocks: If you want to just leave it approved for now, I can promote it a little later when I'm ready to upload debian-installer with a build-dep on it
[10:24] <Laney> Ah, you are here!
[10:24] <Laney> RAOF: I couldn't see that the patches are forwarded - are they?
[10:24] <cjwatson> That way there won't be noise in component-mismatches in the meantime
[10:24] <didrocks> cjwatson: sure, acked on the bug then :)
[10:24] <cjwatson> Thanks!
[10:24] <didrocks> yw ;)
[10:25] <RAOF> Laney: I'm actually upstreamish on colord; the simple one is forwarded, the complicated one is... complicated.
[10:26] <RAOF> Laney: colord-sane has been entirely removed in git, because libsane is a steaming pile of terrible. The complicated patch should work around the vagries of libsane, and once errors.ubuntu.com gives me confidence that it does, I'll re-introduce sane support upstream with that approach.
[10:27] <Laney> Hm, alright
[10:27] <Laney> Is it infeasible to fix libsane itself?
[10:27] <RAOF> I think it is, yes. Partially because there are plugins involved, and I believe some are proprietary.
[10:28] <RAOF> And the plugin interface is part of the problem.
[10:36] <didrocks> Laney: just uploaded a small and simple fix for the video lens as it seems to start getting duplicates, maybe you want to consider it for finale (basically just type É and you get a crash) ^
[10:38] <Laney> didrocks: OK, I can't reproduce that myself (perhaps because that has no results here?) but will look
[10:38] <didrocks> Laney: yeah, it's when you have matching results
[10:39] <didrocks> thanks :)
[10:39] <Laney> unfortunate we got no webapp upload
[10:48] <didrocks> yeah, let's see once ken is around
[10:48] <didrocks> it's still really flacky for me
[10:48] <didrocks> like not working yesterday at all but gmail
[10:48] <didrocks> today, with no updates, working on youtube, linuxfr and launchpad
[11:00] <didrocks> thanks Laney
[11:00] <Laney> np
[11:20] <Riddell> stgraber: what were you doing to get those langpack errors?
[11:23] <Riddell> ah we still have the -kde-xx-base packages
[11:26] <cjwatson> ^- please review - bug noticed while working on debian-installer, critical path for secure boot images
[11:36] <cjwatson> Daviey,Laney: ^- sorry to ask directly but I need to unblock myself on this fairly urgently
[11:37] <Laney> cjwatson: right
[11:39] <Laney> build-efi-images is only called on amd64?
[11:39] <cjwatson> Yes
[11:44] <Laney> done
[11:45] <cjwatson> thanks!
[11:45] <cjwatson> end in sight.  or at least being able to test things for real.
[12:03] <mdeslaur> I've got a security update for bind9 in quantal, can I upload it, or do I wait for a 0-day USN?
[12:06] <cjwatson> I'd say upload it
[12:06] <Daviey> cjwatson: Sorry, i was eating.
[12:06] <cjwatson> Direct to quantal should be fine; no arch skew problems that I can see
[12:06] <cjwatson> Daviey: np, Laney dealt with it
[12:08] <mdeslaur> cjwatson: thanks
[12:19] <doko> cjwatson, would you approve a libffi upload only touching arm64 files?
[12:20] <cjwatson> Probably
[12:23] <cjwatson> Oh no, grub2 failed to build
[12:24] <skaet> :(
[12:25] <cjwatson> Sigh, local .mtoolsrc made mtools laxer
[12:29] <cjwatson> infinity: ^- oh, hah, I didn't notice fso-* in the queue earlier
[12:30] <cjwatson> thanks for that
[12:31] <psivaa> probably a very low priority one atm but just in case it has not been noticed, the precise alternate images seem oversized
[12:32] <Daviey> psivaa: Yeah, i don't think anyone will look at that for the next 2 weeks
[12:32] <psivaa> Daviey, yep understand, thanks
[12:35] <cjwatson> What was wrong with libffi?
[12:36] <cjwatson> Aha
[12:37] <doko> sorry, added ppc64 symbol files in the second
[12:37] <cjwatson> doko: Build-tested on any current architectures?
[12:37] <doko> amd64 and i386
[12:38] <cjwatson> (The only non-arm64/ppc64 changes here are testsuite, so I think that's all that could plausibly go rong)
[12:38] <cjwatson> *wrong
[12:38] <cjwatson> OK, thanks
[12:41] <cjwatson> ^- please review - should actually work this time
[12:41]  * cjwatson goes for lunch
[13:00] <doko> cjwatson, skaet: the grub2 change looks plausible. can't accept myself
[13:11] <highvoltage> skaet: will do
[13:14] <jdstrand> cjwatson: per discussions from yesterday, thunderbird 16/quantal would be copied today (or later). I just got the go ahead from upstream that this is the final version and want to copy into quantal. is now an ok time?
[13:15] <jdstrand> cjwatson: (this was discussed with inifinity and skaet. it's all built and just needs a copy)
[13:15] <cjwatson> jdstrand: Now's fine
[13:15] <jdstrand> thanks
[13:16] <jdstrand> done
[13:18] <skaet> doko, will do.  Thanks for reviewing.
[13:18] <skaet> thanks jdstrand
[13:18] <jdstrand> skaet: ah, didn't think you were here yet. np! :)
[13:18] <stgraber> Riddell: sudo apt-get install language-pack-kde-.*
[13:22] <Riddell> stgraber: gosh I never knew you could do that with apt
[13:22] <Riddell> stgraber: anyway the -base packages should be really removed now
[13:24] <stgraber> Riddell: ok, thanks. I'll retry after the next publisher run
[13:25] <Riddell> stgraber: seems to work now
[13:37] <doko> stgraber, while the buildds are idle, would it be possible to review and accept gcc-4.6 for precise? if if that is built, gccgo-4.7?
[13:39] <cjwatson> I brought us down to two armel builders to get the test rebuild done faster, but we can always steal one back if need be.
[13:40] <stgraber> doko: I'm not in -sru
[13:40] <doko> stgraber, ahh, ok
[13:45] <Daviey> hmm, anyone else seen "supported_versions: WARNING: Unknown Ubuntu release: 12.10" ?
[13:46] <Daviey> http://pb.daviey.com/kvPM/
[13:48] <cjwatson> I *think* that's from postgresql-common
[13:48] <cjwatson> Maybe
[13:50] <Laney> yeah
[13:50] <Laney> knows about 12.10 here though
[13:51] <Daviey> google seems to agree
[13:52] <infinity> cjwatson: Were you going to release that d-i staged in bzr, or did you have more changes to go in first?
[13:53] <skaet> cjwatson, infinity - ok to now accept that apport that's being held in reject queue now,  so that the next set of images (candidates hopefully ;) ) will have it.
[13:57] <cjwatson> infinity: Waiting for next publisher run, then grub2-signed, then build+publish, then I'll upload it
[13:58] <cjwatson> infinity: Otherwise I'll just have to rebuild again
[13:58] <cjwatson> skaet: Fine by me
[13:58] <skaet> k, doing
[14:00] <infinity> cjwatson: Check, and check.
[14:02] <infinity> cjwatson: I was going to take a stab at fixing bug #1040393, but that requires actual testing to make sure I don't blow up the images in the process, so maybe I'll hold off for SRU time.
[14:02] <ubot2> Launchpad bug 1040393 in debian-installer "omap netboot partition too small for flash-kernel backup procedure" [Undecided,New] https://launchpad.net/bugs/1040393
[14:03] <cjwatson> Your call, I never understood that stuff :)
[14:03] <cjwatson> (Or wanted to)
[14:03] <infinity> cjwatson: Well, the fix is simple, it's making sure it actually boots and installs after fiddling with it that takes a bit of time. ;)
[14:04] <infinity> cjwatson: Maybe I'll play locally today, and if I get nowhere, postpone it.
[14:04] <skaet> infinity, can you handle disabling the kerneloops for the candidates?
[14:05] <infinity> skaet: I'm sure I have the technology to do that.
[14:05] <skaet> :)  thanks infinity
[14:05] <infinity> skaet: Ooooor, it's already been disabled. :P
[14:06] <Laney> yeah, I was going to say that IIRC it's been off for half the cycle already
[14:06] <infinity> (As in, it's been disabled for all of Q, except for a 3 day period when it wasn't)
[14:11] <cjwatson> Oh, bah, we missed our publisher slot again
[14:12] <cjwatson> So I'll upload this grub2-signed, but it'll need half an hour before it can build
[14:12] <cjwatson> (It has tight build-deps so it doesn't matter if somebody feels like accepting it earlier)
[14:18] <mvo> sorry for the last minute upload of python-apt but it would be great if that could go in, the new auth.py module breaks puchases in quantal right now :/
[14:18] <mvo> (fix should be pretty obvious fortunately)
[14:48] <Daviey> mvo: You also refreshed the mirrors list for python-apt?
[14:48] <cjwatson> the pre-build hook does that
[14:48] <cjwatson> it's safer to let it, ime :)
[14:48] <Daviey> ahh
[14:49] <Daviey> well sounds wise to have a later mirror listing anyway!
[14:49] <mvo> its automatic
[14:49] <infinity> Accepted.
[14:49] <mvo> yeah :)
[14:49] <infinity> mvo: ^
[14:49] <mvo> thanks \o/
[14:49] <infinity> And so did someone else. :)
[14:49] <Daviey> I did.
[14:49] <mvo> thanks to both of you!
[14:50] <Daviey> cjwatson: grub2-signed.. you aren't waiting on anything for it, are you?
[14:50] <cjwatson> Daviey: A publisher run; although it's OK to accept it early, since it has tight build-deps
[14:51] <Daviey> Yeah, that is what i spotted.
[15:23] <plars> psivaa: is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1065034 reproducible every time?
[15:23] <ubot2> Ubuntu bug 1065034 in ubiquity "'ubuntu ubiquity: umount: /tmp/tmp.h3NCLhoxSh: not mounted' during a Reinstall attempt on a previously manually partioned vm installation" [Undecided,New]
[15:24] <plars> xnox: ^ might be worth taking a look at
[15:24] <xnox> plars: yeah. reading.
[15:24] <psivaa> plars, yes on vm's it is
[15:24] <plars> psivaa: have you tried it on hardware?
[15:25] <psivaa> plars, yes only on mac and there this is not occurring, this is only occurring in vm's
[15:26] <xnox> psivaa: it's interesting, i'll look into it.
[15:26] <psivaa> xnox, plars thanks
[15:33] <bdmurray> infinity: is there anything we can do about reducing the 7 day period though?
[15:35] <infinity> bdmurray: Verify it faster, and ask nicely.
[15:35] <infinity> bdmurray: Including re-verifying the bug that was fixed in the previous release, since it never passed through to updates.
[15:36] <infinity> bdmurray: If you verify both bugs are well and truly fixed and poke me, we'll fudge dates. :P
[15:40] <bdmurray> infinity: sounds good thanks!
[15:51] <cjwatson> ^- next stage in secure boot critical path
[15:51] <cjwatson> debian-installer, that is
[15:52] <cjwatson> once that's built it's a one-liner to arrange for it to be on images
[15:52]  * cjwatson reviews libqt4pas
[15:57] <cjwatson> doko: Have you test-built this libqt4pas sync on powerpc?
[15:58] <doko> cjwatson, no armhf only, but succeeded on debian unstable
[15:58] <cjwatson> doko: I think I'd better try it, then - I can't read the symbols diff well enough to make sure
[15:58] <doko> thanks
[16:02] <cjwatson> doko: I think I might have to give up and remove aspectc++ and reverse-deps on powerpc, unless you have any better ideas
[16:02] <cjwatson> I couldn't get BenC's suggested -mlong-double-64 trick to work
[16:03] <doko> sounds fine. really need to figure out my access to davis again
[16:03] <cjwatson> Can somebody review debian-installer, please?
[16:03] <stgraber> cjwatson: I'll take it
[16:03] <cjwatson> davis just works for me ...
[16:03] <cjwatson> stgraber: thanks
[16:07] <stgraber> cjwatson: ok, I won't pretend to have followed all the EFI/apt magic in my head, but it looks reasonable. accepted :)
[16:09] <cjwatson> stgraber: Yeah, slangasek understands 2/3 of it and I understand the other 2/3 ;-)
[16:09] <cjwatson> But it's been boot-tested in VMs at least
[16:10] <slangasek> haha
[16:11] <cjwatson> (That's actually almost literally true, because the extra 1/3 lives in grub2 ...)
[16:12] <Daviey> Surely combined you understand more than the problem dictates ? :)  there is a remainder of 1/3? </pedant>
[16:15] <slangasek> stgraber: pfft, you didn't push to the bzr branch for your nfs-utils upload :(
[16:16]  * cjwatson replaces Daviey with a very small equation
[16:17] <stgraber> slangasek: doh... sorry for that... I need to hack something on top of dput to make sure I push before I upload...
[16:18] <slangasek> stgraber: I'm mangling the branch now so that I get my commit history back :)
[16:19] <stgraber> slangasek: ok. I checked and I don't have the branch around anymore, otherwise I'd have checked that it matches the wanted history and used --overwrite
[16:20] <slangasek> stgraber: bzr import-dsc && bzr push --overwrite done here
[16:23] <gilir> is there someone available to review lubuntu-artwork ? The full story is on bug 1043129, but I can make a quick summary if it's needed :-)
[16:23] <ubot2> Launchpad bug 1043129 in lubuntu-artwork "[UIFe] Black borders on some active controls" [Undecided,Fix committed] https://launchpad.net/bugs/1043129
[16:25] <plars> xnox: I seem to recall a bug about it being impossible to remove physical partitions, and thus, encrypted volumes when doing manual partitioning, still seems to be the case
[16:25] <plars> xnox: is that one of them that got lumped in with https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1042647 ?
[16:25] <ubot2> Ubuntu bug 1042647 in ubiquity "[FFe] [UIFe] Manual Partitioning LVM" [High,New]
[16:29] <xnox> plars: well revert does something sensible but results in even more confusing bug 1056744
[16:29] <ubot2> Launchpad bug 1056744 in ubiquity "Ubiquity crashes after creating an encrypted partition manually" [Medium,Confirmed] https://launchpad.net/bugs/1056744
[16:29] <xnox> plars: read description, title is a bit incomplete.
[16:30] <plars> xnox: not as far as I can tell, reverting leaves me with /dev/mapper/sdaN_crypt volume
[16:30] <xnox> plars: yeah. that's a bug I'm woring on fixing right now.
[16:30] <xnox> plars: it's inconsistent.
[16:31] <plars> xnox: ok, so you have a bug open for that already then?
[16:31] <plars> wouldn't happen to have the bug# would you?
[16:31] <xnox> that is my analysis/cause for bug 1056744 i.e. revert does something odd after partman-crypto has been activated.
[16:31] <ubot2> Launchpad bug 1056744 in ubiquity "Ubiquity crashes after creating an encrypted partition manually" [Medium,Confirmed] https://launchpad.net/bugs/1056744
[16:32] <xnox> either it should not leave /dev/mapper/sdaN_crypt around or it should fail to revert properly.
[16:32] <plars> thanks xnox !
[16:42] <cjwatson> doko: No, this libqt4pas sync fails on powerpc: http://paste.ubuntu.com/1271463/
[16:42] <cjwatson> doko: I'm going to reject this as I don't think we should trade one FTBFS for another at this point; please could you upload a merge instead?
[16:44] <doko> cjwatson, ok, later tonight, now afk
[16:44] <cjwatson> thanks
[16:46] <infinity> cjwatson: If you'd accepted the sync, it'd be painless to snag the log output on all 5 arches and bump the symbols.
[16:47] <cjwatson> infinity: feel free if you know the runes
[16:47] <cjwatson> and are prepared to chase it
[16:47] <infinity> pke-kde-tools has a no-brainder "symbol merge from build logs" thingee.  Works great for people who insist on tracking C++ symbols.
[16:47] <infinity> I'll do it.
[16:47]  * infinity goes to accept.
[16:48] <infinity> no-brainer, too.  Unlike typing.
[16:48] <infinity> Oh, can't resurrect rejected syncs, right.
[16:48]  * infinity resyncs.
[16:49] <infinity> Oh.
[16:49] <infinity> Except that this is just a new packaging update?
[16:49] <infinity> Right.
[16:49] <infinity> I'll merge. :P
[16:52] <zyga> hey,I just tried the current alternate i386 iso and grub-pc cannot be installed at the end, has anyone reported this?
[16:53] <xnox> zyga: which alternate?
[16:53] <cjwatson> Not that I've seen
[16:53] <infinity> Or, no.  I won't merge.  I'll use your pastebin. :P
[16:53] <cjwatson> But yeah, alternate kind of dead
[16:53] <cjwatson> Unless you mean some non-Ubuntu product
[16:53] <cjwatson> Er, flavour
[16:53] <xnox> no kubuntu/ubuntu alternates. (if there are any, they are stale)
[16:53] <zyga> xnox: define which? do you want the checksum?
[16:53] <cjwatson> zyga: Which URL, please?
[16:54] <cjwatson> I don't want the checksum
[16:54] <zyga> er, alternate
[16:54] <cjwatson> Which URL, pleae
[16:54] <cjwatson> *please
[16:54] <zyga> it was daily, let me dig it up
[16:54] <cjwatson> There are/were several
[16:54] <zyga> http://cdimage.ubuntu.com/daily/current/quantal-alternate-i386.iso
[16:54] <zyga> ah
[16:55] <cjwatson> zyga: That's a month old and no longer supported - look at the timestamp
[16:55] <xnox> cjwatson: purge it =)
[16:55] <zyga> hmm
[16:55] <cjwatson> I should probably nuke it at some point
[16:55] <zyga> indeed
[16:55] <cjwatson> Use server or netboot as appropriate
[16:55] <zyga> that's confusing
[16:55] <xnox> why?
[16:55] <zyga> so where is the most current daily build now?
[16:55] <cjwatson> It's gone now *sniff*
[16:55] <cjwatson> zyga: alternate no longer exists
[16:56] <cjwatson> what are you trying to do?
[16:56] <zyga> ah, right
[16:56] <cjwatson> daily-live for desktop; ubuntu-server/daily for server; netboot for netboot
[16:56] <zyga> cjwatson: deploy a small VM to debug some things with multiple nics
[16:56] <zyga> right, I want the latter than
[16:56] <cjwatson> then server or netboot was probably more appropriate anyway, yeah
[16:56] <zyga> thanks for the tip, I now recall alternate going away
[16:57] <zyga> cjwatson: while we're on the topic, I'm interested in using those new network interface naming schemes
[16:57] <zyga> cjwatson: do you know if it is possible to emulate that in a VM
[16:58] <zyga> cjwatson: I'm looking for docs on the topic, some dell/redhad docs claim I need smbios 2.6
[17:00] <cjwatson> I'm not sure
[17:01] <cjwatson> Sorry
[17:01] <cjwatson> Daviey,slangasek: doing an amd64-only server build to see how/if it works with secure boot
[17:18] <cjwatson> And I'll try an amd64-only desktop build as well while I'm testing this.
[17:20] <skaet> cjwatson, infinity - we're going to need to keep the arm builders clear later today/early tomorrow for a security fix landing that needs to go in release candidate
[17:21] <cjwatson> How many packages?
[17:21] <cjwatson> Source packages, I mean
[17:22] <skaet> 11 hour window
[17:22] <cjwatson> If it's just one, then we have enough builders that that won't be a problem.  It'll just pre-empt something in the test rebuild.
[17:23] <cjwatson> (Even if we accept a fair bit of other stuff, we have 10 builders that aren't doing anything desperately long-running right now.
[17:23] <cjwatson> )
[17:24] <micahg> cjwatson: 10
[17:24] <Daviey> cjwatson: works for me
[17:24] <cjwatson> micahg: 10 source packages? *blink* Would appreciate details in /msg
[17:25] <cjwatson> Anyway, can't keep them very much clearer than they are right now, really
[17:26] <Daviey> rbasak (or anyone): Do you know why why maas-enlist precise was rejected?
[17:27] <rbasak> Daviey: I wasn't aware of this, but I do know that roaksoax re-uploaded with a second fix (the IPMI enlistment stuff) after my fix (the subarch enlistment stuff). Is the rejection of the first upload what you're seeing? I still see a maas-enlist in the queue.
[17:29] <Daviey> rbasak: i suppose it was, thanks
[17:34] <balloons> skaet, btw, feedback on the ARM upgrades from beta1 is it does not work.. the desktop won't boot, or boots to pure graphics corruption
[17:35] <cjwatson> How about ARM upgrades from precise?
[17:35] <balloons> if we wish to diagnose, I have a dd'd image of the issue
[17:35] <balloons> the dailies are installing usable images however
[17:36] <balloons> cjwatson, I don't know :-) That's a more interesting case
[17:36] <balloons> upgrading these things takes FOREVER
[17:39] <slangasek> beta1?  weren't we still missing the binary video drivers at beta1?
[17:41] <zyga> so, grub-pc failed to install on current daily server i386 iso
[17:41] <zyga> cjwatson: ^^
[17:41] <cjwatson> zyga: logs plz
[17:41] <cjwatson> or a bug
[17:41] <zyga> cjwatson: coming right up
[17:41] <cjwatson> well, preferably in a bug :)
[17:42] <skaet> ^ accepted  based on discussions with lubuntu yesterday that this was least risk path forward.
[17:44] <skaet> balloons,  thanks for finding that out.   was worried something like that might be the case.     Please open a bug number, so we can track things there, and see if we can figure out best path forward.
[17:44]  * skaet thinks likely to be a release note as long as dailies installing usable images
[17:44] <skaet> balloons,  has anyone tried from beta2?
[17:45] <cjwatson> skaet: I think we'll be OK, but I've worked out some timings with micahg and dropped doko a note in case we need to kill running GCC builds (I hope not).  Either infinity or I will rebalance builders as needed.
[17:45] <skaet> thanks cjwatson.  :)
[17:46] <zyga> cjwatson: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1065163
[17:46] <ubot2> Ubuntu bug 1065163 in grub2 "grub-pc fails to install at the end of installation from server iso" [Undecided,New]
[17:46] <cjwatson> zyga: OK.  Dinnertime now - I'll look later
[17:47] <zyga> k
[17:47] <cjwatson> zyga: Er, no logs
[17:47] <cjwatson> zyga: Can you get at the contents of the installed filesystem?
[17:48] <cjwatson> zyga: I need /var/log/installer/syslog and /var/log/installer/partman - that is, if they've been copied
[17:48] <zyga> trying to
[17:48] <cjwatson> If not, I need /var/log/syslog and /var/log/partman from *before* rebooting the installer
[17:48] <cjwatson> 'anna-install openssh-client-udeb' from tty2 and you can scp them out
[17:49] <zyga> cjwatson: there's no /var/log/installer or did you mean from /target ?
[17:50] <cjwatson> from /target
[17:50] <cjwatson> but if you're in the installer environment, just grab /var/log/{syslog,partman} directly
[17:50] <zyga> cjwatson: still not there /target/var/log/
[17:50] <zyga> ok
[17:51] <cjwatson> right, anyway, dinner
[17:53] <balloons> slangasek, yes we were missing drivers @ beta1.. the installed system is really painful to use
[17:53] <balloons> skaet, no one from beta2
[17:58] <slangasek> blah, whose idea was it to make 'eject' of a USB disk cause the partition mapping to disappear from the kernel?
[17:58] <infinity> Because "eject" != "umount"?
[17:58] <highvoltage> it's been like that since... forever though
[17:58] <slangasek> infinity: "eject" is the only option being shown
[17:58] <slangasek> which means I can't, from the GUI, unmount the automounted installer image that I want to overwrite
[17:59] <infinity> slangasek: Yeah, there used to be two options that were (mostly) redundant, except for that one difference, but I'm pretty sure that was crazy user-unfriendly.
[17:59] <slangasek> right, so now it's just crazy-user unfriendly
[17:59] <infinity> slangasek: I suspect the assumption is "people who want to umount but not make the device go away probably also know how to use command-lines for their weird use-case".
[17:59] <slangasek> infinity: why would I *ever* care about making the device go away
[18:00] <slangasek> I don't understand why this option is presented for a USB stick in the first place
[18:00] <infinity> (Used to be "Eject" and "safely Remove" which was all kinds of confusing)
[18:00] <infinity> slangasek: So, your contention is that when they removed one of the two options, they removed the wrong one?  Maybe.
[18:01] <infinity> slangasek: Though, completely making it go away prevents other processes from remounting behind your back, or otherwise mucking with it.
[18:01] <infinity> Which fits the "it's actually safe to pull it, honest" message.
[18:04] <slangasek> infinity: for the USB disk case, yes, I think the wrong one is removed
[18:15] <slangasek> ok, why am I getting an email that's telling me the exact opposite of http://people.canonical.com/~ubuntu-archive/component-mismatches.txt regarding the linux-ti-omap4 binary packages?
[18:16] <infinity> Both are lies, ignore them. :P
[18:16] <slangasek> infinity: is this your doing? :)
[18:16] <infinity> No, it's just what happens when d-i and seeds and new kernel ABIs all interact slightly out of sync.
[18:17] <slangasek> it is?  I wouldn't expect anything to say "these need promoted to main" as part of an ABI transition
[18:17] <slangasek> which is what the mail says
[18:18] <infinity> Hrm.  I don't have that mail.  Only the 212 to universe one.
[18:18] <infinity> Which is a lie, cause it really means "delete please".
[18:18] <infinity> Maybe I deleted the earlier mail.
[18:19] <slangasek> yes, I know how to interpret "to universe"
[18:19] <infinity> And it's entirely possible that whoever did the binary NEW missed the main promotion in the same breath.
[18:19] <slangasek> these were 212
[18:19] <slangasek> not 213
[18:19] <slangasek> and it said "to main", not "to universe"
[18:19] <stgraber> slangasek, cjwatson: bug 1065180
[18:19] <ubot2> Launchpad bug 1065180 in grub2 "Wrong EFI boot entry on system with secure boot" [Undecided,New] https://launchpad.net/bugs/1065180
[18:19] <infinity> Oh, you've had 212 going both directions?
[18:20] <slangasek> infinity: the only mail I saw was "to main", which was the opposite of c-m; so maybe a bug in the mail-generating script
[18:20] <infinity> That sounds more like someone demoted 212 instead of deleting it, but the seeds hadn't changed yet, and hilarity ensued.  Or something.
[18:20] <slangasek> right
[18:20] <infinity> Oh!
[18:20] <infinity> I didn't read the subject!
[18:20] <infinity> Silly me.
[18:20] <infinity> I just read the body, which matched the file.
[18:20] <infinity> Reading.  Hard.
[18:20] <infinity> Need lunch.
[18:20] <slangasek> so if that's the case, could people please stop moving things around in components before they show up on c-m?
[18:21] <infinity> So, yeah, it could also just be the diffing script being daft.
[18:22]  * skaet contemplating some lunch as well.
[18:23] <infinity> Anyhow, old binaries removed now, it can stop annoying us. :P
[18:26] <slangasek> stgraber: could you attach the output of 'sh -x /usr/sbin/grub-install --uefi-secure-boot'?
[18:27] <stgraber> slangasek: done. http://paste.ubuntu.com/1271664/
[18:27] <slangasek> stgraber: attach :)
[18:27] <infinity> slangasek: Want to accept that lsb before you lose context and actually have to review it all over again? ;)
[18:28] <stgraber> slangasek: I pasted the link on the LP bug too. Do we actually care about it being an attachment vs URL to a paste?
[18:28] <slangasek> stgraber: yes
[18:28] <slangasek> because paste.ubuntu.com is a PITA for grepping
[18:28] <infinity> And, more importantly, pastes timeout and you lose context in old bugs.
[18:29] <infinity> (which drives me BATTY)
[18:29] <slangasek> also that
[18:29] <slangasek> infinity: accepted
[18:29] <stgraber> slangasek: alright, attached
[18:29] <slangasek> stgraber: thanks :)
[18:32] <cjwatson> infinity: although as it happens paste.ubuntu.com never times out (so I'm told), though other pastebins do
[18:33] <infinity> cjwatson: Oh, curious.  Not that I'd count on that forever.
[18:33]  * stgraber uses experimental pbget with paste.ubuntu.com support (pbget <URL> | grep ... is actually much easier than going to LP grab the attachment)
[18:35] <slangasek> stgraber: so the grub-install output shows efibootmgr being called with the right option (-l \EFI\ubuntu\shimx64.efi), but this doesn't match the output you showed from efibootmgr after the fact
[18:35] <slangasek> stgraber: is something else calling efibootmgr out from under us?
[18:36] <slangasek> stgraber: and, does 'efibootmgr --verbose' currently show the right entry?
[18:36] <stgraber> slangasek: hmm, it does now... that's odd. All I ran since it last returned the wrong thing was update-grub and grub-install --uefi-secure-boot
[18:36] <stgraber> so it might have been that you need grub-install --uefi-secure-boot + update-grub to get it to update to the right value?
[18:37] <slangasek> stgraber: no, the update-grub doesn't matter for this
[18:37] <slangasek> and I don't see any bugs in grub-install
[18:37] <stgraber> oh, hold on a sec, I think I know what happened, it's right around the time unattended-upgrades applies updates...
[18:37] <slangasek> so I'm wondering what else could have happened *after* you ran grub-install --uefi-secure-boot to cause the entry to be overwritten with the wrong value
[18:37] <slangasek> oh, hah
[18:38] <slangasek> there you go then ;)
[18:38] <slangasek> mind updating the bug and closing it as invalid?
[18:39] <stgraber> yep, will do with a note to "reboot immediately after running grub-install --uefi-secure-boot" otherwise the entry will get overwritten whenever grub/shim updates
[18:40] <stgraber> alright, let's see if that machine boots now :)
[18:41] <TheLordOfTime> hate to be annoying, but... when's this being migrated to the repos for precise from -proposed?
[18:41] <TheLordOfTime> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978
[18:41] <ubot2> Ubuntu bug 997978 in qemu-kvm "KVM images lose connectivity with bridged network" [High,Fix committed]
[18:42] <stgraber> slangasek, cjwatson: so, different problem now :)
[18:42] <micahg> TheLordOfTime: 7 days is up today, so probably soonish
[18:42] <infinity> TheLordOfTime: Vaguely around nowish.  It only just hit 7 days.
[18:42] <stgraber> the machine boots and gets the now usual "Image failed to verify with *ACCESS DENIED*". Hitting enter at that point gets me into grub, trying to boot something fails.
[18:43] <stgraber> hmm, wondering if I have a signed kernel, /me reboots into setup mode again
[18:43] <TheLordOfTime> micahg, infinity, its one of those "high priority" issues for an organization i work with, so... sorry for another prod about that one :P
[18:43] <slangasek> stgraber: you shouldn't need a signed kernel
[18:43] <slangasek> stgraber: why are you getting "Image failed to verify"?
[18:43] <infinity> TheLordOfTime: When I say "nowish", I mean "now".
[18:43] <TheLordOfTime> micahg, infinity, its one of those "high priority" issues for an organization i work with, so... sorry for another prod about that one :P:P
[18:43] <infinity> TheLordOfTime: As in, just released.
[18:43] <TheLordOfTime> oops
[18:43]  * TheLordOfTime kicks xchat
[18:43] <slangasek> stgraber: also, why does hitting enter get you to grub?!
[18:44] <TheLordOfTime> infinity, nice.
[18:44] <zyga> cjwatson: hey, I've added the logs that you've requested
[18:44] <stgraber> slangasek: no idea ;)
[18:45] <stgraber> firmwares don't seem terribly good at logging
[18:46] <stgraber> so yeah, I'm getting: firmware splash => boot menu => select ubuntu => get access denied => hit enter => get to grub menu => try to boot anything hangs (purple screen)
[18:46] <slangasek> stgraber: no, I mean, if it actually failed to verify the signature, it's a violation of the Win8 cert requirements for it to let you boot by pressing enter
[18:46] <slangasek> oh, so you only get access denied after the grub boot menu?
[18:46] <stgraber> nah, the "select ubuntu" part there means select the ubuntu entry in the EFI boot menu
[18:47] <slangasek> hmm
[18:49] <stgraber> only entry in grub that doesn't hang is the "System setup" entry which reboots the laptop and get me into the config screen
[18:53] <stgraber> switched back to setup mode and it boots fine (first time I actually use the shim to boot)
[18:53] <slangasek> hmm
[18:55] <stgraber> if you want something even weirder :) I installed linux-signed-generic and it now boots
[18:55] <stgraber> still showing the access denied error though
[18:56] <stgraber> and the variable in /sys/firmware is now set to 1 as expected
[18:56]  * stgraber reboots to confirm that the same unsigned kernel still won't boot
[18:57] <slangasek> I'm not sure why you would be seeing this; I'm definitely able to boot an unsigned kernel here in secureboot mode
[18:58] <stgraber> well, I confirmed that an unsigned kernel won't boot here. I edited the Ubuntu entry and removed .efi.signed from the kernel filename and hit F10 and it hangs
[18:59] <stgraber> now, how can we debug that mess? (considering that dropping splash vt.handoff and adding verbose doesn't give me anything)
[19:01] <psivaa> xnox, i see that the personal files are destroyed when i use live session path, in the Reinstall option, but the straight install does not destroy them
[19:10] <TheLordOfTime> infinity, what's the time-to-build for stuff just moved from proposed to -updates (or similarly)?
[19:11] <TheLordOfTime> or is it just a copy from proposed to whatever it goes to (probably -updates for precise)
[19:11] <infinity> TheLordOfTime: It's just a copy, if it rebuilt, all the previous testing would be pointless.
[19:11] <TheLordOfTime> you never know, so it never hurts to ask ;P
[19:18] <stgraber> slangasek: I'll try to boot the Windows 8 install media to check that I'm not getting that weird access denied message with it
[19:18] <stgraber> but I'd think Lenovo would have tested that as it's a production firmware I'm using...
[19:22] <infinity> cjwatson: Should be a new lbqt4pas landing in the queue soon with sane symbols for armel, armhf, and powerpc (the latter being based on your build, so I hope your chroot was sane).
[19:43] <slangasek> hmm, anyone else seeing firefox plugins broken by unresolved reference to libxul.so in /usr/lib/firefox/plugin-container ?
[19:43] <slangasek> oh, ignore that
[19:43] <slangasek> that's just me invoking it wrong from the commandline when debugging
[19:44] <mdeslaur> can I upload a moin security fix?
[20:09]  * skaet --> appt, bbl
[20:15] <slangasek> stgraber: you said that the 'access denied' message came only after the grub menu, though?
[20:15] <slangasek> not sure how that can be the firmware's fault
[20:16] <stgraber> slangasek: no, that error shows up right before grub, possibly somewhere between the shim and grub2, no idea
[20:16] <slangasek> ah, hmm
[20:16] <stgraber> slangasek: though when trying to boot grub directly I get the access denied and then the laptop just gives me a blank screen
[20:16] <slangasek> if you try to boot shim directly, do you get the access denied message?
[20:16] <stgraber> so going through the shim certainly triggers a different behaviour that then lets me boot (but only a signed kernel)
[20:17] <stgraber> slangasek: how do I do that?
[20:17] <slangasek> perhaps the 'access denied' is in response to the firmware trying to boot some other image before it tries your configured one
[20:17] <slangasek> stgraber: ah, well, every UEFI UI is different, so... I have no idea :P
[20:17] <slangasek> stgraber: however, the ref platform I have here has a 'boot from file' option
[20:18] <slangasek> which was what I had in mind
[20:18] <slangasek> or if not that, then at least a boot menu to explicitly select the boot device?
[20:18] <xnox> psivaa: please give me a little more context or a bug # .
[20:18] <stgraber> yeah, I have a boot menu on F12 to choose what to boot, but it only lets me choose EFI boot entries
[20:19] <stgraber> so I guess I need to add a couple of test entries with efibootmgr
[20:19] <slangasek> stgraber: ok, if you explicitly choose Ubuntu from F12, do you still get the message?
[20:19] <stgraber> yeah
[20:19] <slangasek> right
[20:19] <slangasek> so I'll consider that Not My Problem for now
[20:20] <slangasek> I'm more concerned about the kernels not booting
[20:20] <slangasek> does your firmware give you a UI for loading keys into KEK?
[20:21] <slangasek> because effectively, for debugging a boot failure under SB, you're going to want direct control of being able to sign test images
[20:21] <stgraber> not that I could find. All I can do is wipe all the entries or reload the Windows ones
[20:24] <slangasek> ok
[20:27] <stgraber> slangasek: do we have a signed CD image yet? I could try to write that to USB and see if I get a different result
[20:28] <slangasek> stgraber: yes, the current daily server and desktop images use the signed bootloader
[20:28] <slangasek> the server one gives me a garbled framebuffer; I'm struggling to sync the desktop one now to test
[20:28] <stgraber> ok, grabbing the desktop image here
[20:30] <Laney> ah, fun, /me tries too
[20:30] <slangasek> Laney: you have UEFI?
[20:30] <Laney> think so, checking
[20:31] <Laney> I just got this hardware last week, so here's hoping
[20:32] <stgraber> you may need a firmware update. I got my laptop last month and the UEFI firmware didn't have secure boot, I had to reflash to get the win8-compliant version with secureboot
[20:37] <Laney> I have "UEFI/Legacy boot"
[20:37] <slangasek> that's no guarantee of SecureBoot availability; but all the same you mind find it worth testing whether the images boot for you in UEFI mode
[20:37] <Laney> yeah
[20:37] <stgraber> Laney: no secureboot/windows8 option hidden in some security menu?
[20:38] <Laney> dunno, I'm just looking at the manual
[20:38] <Laney> dding the iso now
[20:39] <stgraber> gah, cdimage is slow today, I'm just getting 700kB/s out of it...
[20:39]  * xnox can't see any updates from my OEM, but they are Latvian so I am not holding my breath. Last time around it did not boot the CD in UEFI mode will try usb.
[20:39] <psivaa> xnox, sorry dont worry that was a confusion on my part, ignore that
[20:40] <xnox> psivaa: ok =) got me worried there for a second.
[20:41]  * stgraber reboots
[20:44] <cjwatson> stgraber: I'm a bit confused by you marking your own grub-install bug invalid; the --uefi-secure-boot option is not supposed to be required, and if grub is reinstalled - even by unattended-upgrades - while the system is in SB mode, it should install a signed version
[20:45] <slangasek> cjwatson: he wasn't booted under SB mode when this happened
[20:45] <cjwatson> stgraber: the grub-install trace you uploaded shows that the system was not ...
[20:45] <slangasek> he was bootstrapping his way to it :)
[20:45] <cjwatson> yeah, that
[20:45] <cjwatson> ah, OK, I thought this was a fresh install
[20:45] <psivaa> xnox, coincidently i had used the same username for ubiquity and different ones for for live session re-installs and that made me suspect the installer :)
[20:46] <xnox> psivaa: =) I see.
[20:47] <stgraber> slangasek: ok, so my machine is at least very consistent in its behavior :) botting the ISO from USB I'm getting the access denied, then once I select OK, I'm getting into grub and from there any attempt to boot a kernel hangs
[20:48] <stgraber> (assuming that the kernel on the image isn't signed, that means I'm getting the exact same behaviour as my installed system)
[20:48] <cjwatson> oh, yeah, the kernel on the image isn't signed
[20:49] <cjwatson> blast, we're going to need to fix that
[20:50] <stgraber> cjwatson: is it normal for grub to just hang on an unsigned kernel? (slangasek said earlier that grub should still happily boot an unsigned kernel)
[20:51] <cjwatson> it isn't normal
[20:51] <slangasek> cjwatson: in the meantime, I've successfully booted your latest desktop image to a desktop with secureboot enabled
[20:51] <cjwatson> neat
[20:51] <Daviey> \o/
[20:51] <cjwatson> slangasek: do you think that using a signed kernel on the image (and hence efi handoff) would help with your efifb woes?
[20:52] <slangasek> cjwatson: no
[20:52] <cjwatson> at least efifb is built in so it shouldn't require d-i modifications to handle that ... hopefully
[20:52] <cjwatson> slangasek: but we ought to do it anyway, yes?
[20:52] <slangasek> cjwatson: I think the desktop CD works because it's switching to inteldrmfb, and it's possible the server image isn't
[20:53] <cjwatson> slangasek: IIRC inteldrmfb is modular, so that would be quite plausible
[20:53] <slangasek> cjwatson: yeah, I think we ought to get the signed kernels into the images
[20:54] <cjwatson> isn't the efifb stride configurable with boot parameters?
[20:54] <cjwatson> (not to mention that grub is supposed to handle configuring it properly ...)
[20:54] <slangasek> is it configurable?  dunno
[20:55] <slangasek> this was a kernel bug that mjg59 and pjones were hacking on during plugfest, fwiw
[20:55] <slangasek> the fix must not have made the round trip
[20:58] <slangasek> cjwatson: do you think d-i *should* be loading the same fb modules that get used in the desktop installer?
[20:58] <cjwatson> I would hesitate to state that as a general principle
[20:59] <slangasek> from the "dropping alternate" thread, I get the impression that not using the kms drivers may be a feature for some users
[21:02] <Laney> aha, firmware update → secure boot options
[21:04] <stgraber> slangasek: I copied the win8 installer bootloader in /boot/efi and added a boot entry, that one loads without the weird access denied error, though all it gets me is a blank screen (makes sense as I only copied the loader and not the actual install media)
[21:05] <stgraber> slangasek: are you aware of any secureboot test binaries that are signed by microsoft? I'd like to check that it's really only the shim+grub2 that's triggering that weirdness
[21:06] <slangasek> stgraber: uh, there is one, but I forget what it's called and where it lives; try pinging manjo
[21:06] <slangasek> stgraber: he should know
[21:07] <slangasek> cjwatson: desktop daily successfully installed and booted with SecureBoot=1
[21:09] <cjwatson> gosh
[21:09] <cjwatson> zen coding ftw
[21:09] <slangasek> :)
[21:09] <cjwatson> and it installed all the right -signed packages?
[21:10] <slangasek> including the signed kernel packages, yes
[21:10] <cjwatson> \o/
[21:11] <slangasek> confirmed also that the grub.cfg got written correctly using the signed images
[21:15] <cjwatson> tracked down zyga's bug earlier to a busted es.archive
[21:15] <stgraber> slangasek: manjo said to ping jk but he's not around at the moment. Anyway, I successfully booted the MS countdown efi binary (Press any key to boot from CDROM... with a countdown) without getting the weird message from the BIOS
[21:16] <slangasek> oh, you know what
[21:16] <stgraber> slangasek: so apparently something in the shim/grub is triggering that weird behaviour on the Lenovo firmware
[21:16] <slangasek> the reason he's redirecting you to jk is because of a test binary that's in the RT queue waiting for me to sign off on
[21:16] <slangasek> sorry about that
[21:17] <vanhoof> stgraber: ~5am for jk, he's usually on in a couple hours or so
[21:17] <slangasek> (this is for getting our UEFI test app signed by MS)
[21:17] <Laney> should I be disabling the CSM?
[21:17] <stgraber> Laney: yes, you'll have to if you want to get secureboot enabled
[21:17] <Laney> yeah, it refuses to boot with that because of my graphics card apparently
[21:18] <slangasek> the Crawling Spaghetti Monster?
[21:18] <Laney> "Disable the CSM to fully support the Windows Security Update and Security Boot."
[21:18] <Laney> good old asu
[21:18] <Laney> s
[21:21] <slangasek> cjwatson: I believe this is the efifb stride patch in question: https://lkml.org/lkml/2012/7/27/307
[21:30] <cjwatson> slangasek: I'm a little surprised that I can't find evidence of a corresponding boot loader patch to fix the GOP detection
[21:31] <slangasek> ah, so grub2 never sets this bit anyway?
[21:31] <slangasek> < helpful
[21:32] <cjwatson> not afaics
[21:32] <cjwatson> and if it did, we wouldn't need that patch ...
[21:32] <slangasek> wouldn't we?
[21:32] <cjwatson> (because presumptively it'd be getting things right)
[21:33] <cjwatson> oh, ISWYM I think
[21:33] <slangasek> my understanding of the problem is that the bootloader gets it right, then the kernel doesn't pay attention to what the bootloader did
[21:33] <slangasek> and asks dmi again, which gives a wrong answer
[21:34] <cjwatson> yeah, I misread
[21:34] <cjwatson> Laney: compatibility support module - i.e. BIOS mode
[21:35] <cjwatson> stgraber: "access denied" - I wonder if that's being printed by grub
[21:35] <Laney> yeah, gleaned a quantum of insight
[21:35] <cjwatson> stgraber: any chance of a screenshot or something?
[21:35] <slangasek> cjwatson: mjg59 just confirmed on #ubuntu-kernel that there's no patch available for grub
[21:35] <fginther> infinity, ping
[21:35] <Laney> seems like this no VGA support business is a blocker
[21:35] <slangasek> that they're using the kernel efi stub instead
[21:35] <stgraber> cjwatson: sure, I can take a few photos
[21:37] <cjwatson> slangasek: so using a signed kernel *would* avoid this
[21:37] <cjwatson> because we'd use efi handover
[21:37] <cjwatson> as I read it ...
[21:37] <slangasek> would it?  or would it only do so with this patch?
[21:37] <cjwatson> hmm
[21:37] <slangasek> cjwatson: can you join #ubuntu-kernel?
[21:38] <cjwatson> done
[21:38] <cjwatson> you may be right
[21:39] <cjwatson> for booting with the signed kernel: I'll have to add linux-signed-image-generic or whatever to the live seed, but that will affect non-SB systems since they'll have to ensure that that gets removed
[21:40] <cjwatson> now, I *think* my ubiquity patches handle that
[21:40] <cjwatson> though actually ... I don't think s
[21:40] <cjwatson> o
[21:40] <stgraber> cjwatson: http://www.stgraber.org/download/DSC02667.JPG http://www.stgraber.org/download/DSC02668.JPG http://www.stgraber.org/download/DSC02669.JPG
[21:41] <infinity> fginther: Pong.  Might want to hit me up in /msg, I'm about to head to lunch and don't want to lose context.
[21:41] <stgraber> cjwatson: that's when I get when turning on (first), pressing F12 (second), choosing ubuntu (third)
[21:41] <stgraber> cjwatson: I then press enter at that last message and the system boots fine (so long as I'm using a signed kernel too, otherwise it hangs)
[21:42] <cjwatson> OK, so not directly from GRUB, although I hope that isn't what happens when the shim fails to verify something
[21:42] <cjwatson> I don't think it is though
[21:42] <cjwatson> So that zaps my hypothesis and leaves me none the wiser really
[21:43] <cjwatson> Unless perhaps the shim isn't installed
[21:43] <cjwatson> That's an installed system, not a CD/USB image?
[21:43] <stgraber> I'm 99% sure the message comes from the firmware as I'd get it when trying to boot grubx64.efi directly, though in that case it wouldn't let it boot at all
[21:43] <cjwatson> The "press OK" "yeah, whatever" business is just bizarre
[21:43] <stgraber> correct, that's an installed system, though I'm getting exactly the same behaviour when booting form the latest desktop daily (expect that the kernel won't boot as it's not signed)
[21:44] <slangasek> I haven't inspected the shim's protocol handler very closely
[21:44] <cjwatson> It doesn't contain that text
[21:44] <stgraber> yeah, that message is weird but it doesn't look like selecting OK actually bypasses secureboot as the bit is still set to 1 after boot and booting grubx64.efi directly won't let me boot at all
[21:44] <slangasek> could this be a firmware message output because grub does *not* verify under firmware?
[21:45] <slangasek> and so shim trips the message, then applies its own check and boots it anyway?
[21:45] <cjwatson> I thought it copied the tiano code rather than calling out to the firmware, though
[21:45] <cjwatson> I mean, that's why it has its own embedded cryptlib
[21:46] <cjwatson> why would it need to make a firmware call for that?
[21:46] <stgraber> it certainly feels like the shim is doing a call that's rejected by the firmware but recovers from it and still lets me boot fine
[21:47] <cjwatson> huh, except it *does* call LoadImage
[21:48] <stgraber> and it could be that Lenovo implemented a nice visual error message instead of just silently rejecting it, which would explain why it doesn't show up on slangasek's system (really just guessing, but that'd kinda make sense)
[21:48] <cjwatson> ah, it tries that first
[21:48] <cjwatson> Yeah, that would make sense
[21:48] <cjwatson> see shim/README
[21:49] <stgraber> hmm, right, well, looks like we should remove the LoadImage/StartImage part if we want a reasonable user experience on Lenovo machines (apparently all the new ivy bridge laptops run essentially the same firmware as I have currently so will be affected)
[22:00] <cjwatson> stgraber: can you arrange to have 'set debug=all' in the grub.cfg stanza that tries to boot an unsigned kernel (warning: should produce shedloads of output) so we can see how far grub gets?
[22:00] <cjwatson> this'll be a "take photo of end of output" kind of deal
[22:01]  * infinity lunches.
[22:04] <stgraber> cjwatson: http://www.stgraber.org/download/DSC02670.JPG
[22:05] <cjwatson> bah, that's really not especially helpful
[22:05] <cjwatson> "hi, I read some stuff off the filesystem"
[22:05] <cjwatson> does it behave the same way if you flip to setup mode and boot grub either (a) directly or (b) via shim?
[22:06] <slangasek> IIRC in setup mode he had a clean boot
[22:06] <cjwatson> I guess that may not signify much since grub checks internally whether SB is on
[22:06] <stgraber> boots fine in setup mode both through shim and directly to grub
[22:08] <cjwatson> and because you can't install your own keys the only way we can add more debugging is to upload stuff to the archive
[22:08] <cjwatson> THANKS, EVERYONE
[22:10] <stgraber> there may be a weird way of getting to some screen where I can manage the keys, though the new firmware is only a couple of weeks old, pretty much nobody is using it and there's no documentation on it...
[22:10] <cjwatson> I really can't see anything wrong by code inspection :-/
[22:11] <cjwatson> That doesn't look like enough output for it to have read the whole kernel
[22:12] <cjwatson> Which it should have done before verifying the sig
[22:12] <cjwatson> Oh, wait, wrong units
[22:13] <cjwatson> It's read between 6291456 and 6815744 bytes, I think
[22:13] <cjwatson> Does that match the kernel size?
[22:13] <cjwatson> Though actually the first 1.5MiB or so of that is from a different location, so maybe I should just ask "how big's the kernel?"
[22:17] <stgraber> -rw------- 1 root root 5129040 Oct  9 15:54 /boot/vmlinuz-3.5.0-17-generic
[22:17] <cjwatson> OK, that's the above figure minus the three blocks from a different location
[22:18] <cjwatson> So I can at least say that it's loaded the kernel, probably from linuxefi
[22:19] <cjwatson> Tempted to stick a load more grub_dprintf in the next upload
[22:31] <cjwatson> slangasek: ^-
[22:37] <slangasek> cjwatson: looking
[22:41] <slangasek> cjwatson: ^^ trade ya
[22:42] <cjwatson> Already there
[22:42] <cjwatson> Also have a ubiquity upload coming up, which I'd like to sneak in before the builders get eaten
[22:44] <cjwatson> slangasek: looks ok - have you managed to boot-test or anything, even unsigned?
[22:45] <slangasek> cjwatson: yes, have verified both allowed and denied boot paths with shim's handler
[22:45] <cjwatson> OK, cool
[22:46] <slangasek> SB enabled, boot Canonical-signed image: succeed; SB enabled, boot unsigned image: fail; SB enabled, boot unsigned image whose hash is added to db: succeed
[22:48] <slangasek> (SB disabled, boot unsigned image: succeed)
[22:49] <slangasek> cjwatson: efibootmgr accepted
[22:53] <cjwatson> stgraber: I guess your mysterious inability to boot an unsigned kernel means that you can't verify whether you suffer from bug 1065263?
[22:53] <ubot2> Launchpad bug 1065263 in linux "wrong stride for efifb on some systems" [High,Triaged] https://launchpad.net/bugs/1065263
[22:54] <slangasek> :-)
[22:54] <slangasek> cjwatson: except boot in setup mode works
[22:54] <slangasek> and that bug isn't tied to SB
[22:54] <cjwatson> Sure, but that means SecureBoot=0
[22:54] <cjwatson> Which takes different code paths
[22:55] <cjwatson> OK, so perhaps stgraber can verify that he doesn't suffer from it, but still can't actually test the server image
[22:55] <slangasek> ah, right
[22:55] <cjwatson> Which means we have zero QA of that right now
[22:55] <slangasek> well
[22:55] <slangasek> we had zero qa of it at all before
[22:55] <slangasek> at least now we boot to a kernel :P
[23:02] <cjwatson> slangasek: could I get a ubiquity review asap?  want to preempt some other builds ...
[23:02] <slangasek> ah oops, yes
[23:02] <slangasek> sorry, misread the bot as 'accepted'
[23:03] <stgraber> cjwatson: I'll grab a new 64bit server image and try to boot it in setup mode see if I'm getting any corruption in d-i
[23:03]  * stgraber kicks the download and gets back to packing
[23:06] <slangasek> cjwatson: so I'm fine with this ubiquity change for now, but isn't one of the consequences that, when we do get the efifb bug fixed, only users running with SB=1 get the advantage of it?
[23:06] <cjwatson> Yes (although we could set that capability bit in grub2 as well, in principle)
[23:06] <cjwatson> If you think it's preferable to leave the signed image installed, I could live with that too
[23:07] <slangasek> I think it is preferable
[23:07] <slangasek> but I've already accepted :P
[23:07] <cjwatson> Hah
[23:07] <cjwatson> Well, I can revert before release if you like I guess
[23:07] <slangasek> the kernel efi stub is going to be the better-supported path, on account of the work RH/Fedora are putting into it
[23:07] <cjwatson> It's 5MiB extra download on every kernel update
[23:08] <cjwatson> I guess these days that's lost in the noise
[23:08] <slangasek> hmm
[23:08] <infinity> Does someone want to review my libqt4pas that's hidden under all the langpacks?
[23:08] <cjwatson> Now maybe not the optimal time for lots of queue flushing
[23:08] <infinity> cjwatson: Oh, we can make ubiquity happy.
[23:08] <cjwatson> Unless it's RC-critical
[23:09] <cjwatson> I don't mean that, I mean the way security's about to sit on all the ARM builders
[23:10] <infinity> If by "about to", you mean they already are.
[23:10] <infinity> I didn't realise that happened while I was lunching.
[23:10] <cjwatson> No, only some
[23:10] <slangasek> cjwatson: could vmlinuz.efi.signed conceivably be synthesized at install time from vmlinuz + stub + sig?
[23:10] <cjwatson> I did actually mean "all"
[23:10] <slangasek> that would address the issue with duplicate download time
[23:10] <cjwatson> slangasek: Yes, but we'd have to MIR sbsigntool
[23:10] <slangasek> right
[23:10] <cjwatson> slangasek: I think this would be sensible for R
[23:10]  * slangasek nods
[23:11] <slangasek> I might try to MIR sbsigntool yet this week anyway
[23:11] <infinity> Yeah, if we rely on it, not supporting it seems silly. :P
[23:11] <slangasek> since jk found a fix for the sbverify bug that was preventing me using it in shim-signed
[23:17] <cjwatson> slangasek: moved linux-signed from ship-live to live; may eventually want to move into boot (not sure about for 12.10)
[23:30]  * skaet starting to clean out some of the language packs translations that are in queue now....
[23:30] <cjwatson> skaet: um
[23:31] <skaet> cjwatson,  best not?
[23:31] <cjwatson> I'd leave them until after the mozillathon
[23:31] <cjwatson> hmm, so why are aatxe and lamiak idle
[23:32] <skaet> cjwatson,  ok.    Please let them through tomorrow morning your time then.
[23:32] <cjwatson> oh, please don't tell me it's that thing where a given PPA can only use up so much of the farm
[23:32] <cjwatson> skaet: will do
[23:32] <cjwatson> This is going to suck for ARM more than is strictly ideal
[23:32] <infinity> cjwatson: Oh, it almost certainly is that, the real security PPA gets a pass, the mozilla security PPA is just a normal devirt. :/
[23:33] <infinity> No idea how or where that free pass is given.
[23:33] <infinity> If it's a simple twiddly on an admin page, we should untwiddle it.
[23:34] <cjwatson> Trying to find it
[23:35] <doko> cjwatson, this is easy, first make all armhf builders armel until armel builds, then make the opposite ...
[23:35] <cjwatson> Bah
[23:35] <infinity> Oh, actually, that would totally work. :P
[23:35] <cjwatson> Way too much hand-management
[23:35] <infinity> But eww.
[23:35] <cjwatson> I'm not sure it would actually; 10/14 may be over the limit
[23:36] <infinity> Plus, ubuntu-mozilla-security should have the same restrictions as ubuntu-security-proposed.
[23:36] <cjwatson> (Given I don't know what the limit is, but 4/5 is over it)
[23:36] <infinity> cjwatson: Make a bunch of x86 buildds manual and switch them to armel too.
[23:36] <infinity> (Or wait until they have long builds and do so)
[23:36]  * infinity vomits a little for suggesting this.
[23:36] <cjwatson> Ewwwwwwwwwwww
[23:37] <cjwatson> The limit is 80%
[23:37] <cjwatson> So 10/14 might actually work, but ...
[23:37] <cjwatson> (lib/lp/soyuz/model/buildpackagejob.py)
[23:38] <doko> did do the dance on Monday
[23:39] <infinity> Alright.  Let's just do that for now.
[23:39] <doko> infinity, *that's* insane, but if it works =)
[23:39] <infinity> doko: It would work.  But yes, disgusting, and we won't need to.
[23:39] <stgraber> cjwatson: I tried the server amd64 image in setup mode, boots fine and no framebuffer corruption (right resolution and getting KMS)
[23:40] <infinity> Anyhow, time to dance.
[23:40] <slangasek> stgraber: you're getting kms within the installer?
[23:40] <slangasek> stgraber: are you sure you mean kms, and not just fb?
[23:41] <slangasek> stgraber: (what does /proc/fb say, at the point the installer first boots?)
[23:42] <stgraber> slangasek: probably just fb, sorry, used KMS to mean "something that looks better than some kind of text mode"
[23:42] <slangasek> stgraber: right - the distinction is material, because once inteldrmfb is loaded on this hardware here, the problem goes away
[23:43] <slangasek> stgraber: so if you are managing to get a kms driver loaded by the installer, I'd be interested to know that
[23:44] <stgraber> slangasek: I'll be able to retest some time on Friday, I just finished wiping that disk and packed it in my bag
[23:44] <cjwatson> I don't think the installer has access to inteldrmfb - not in the relevant udebs
[23:44] <slangasek> stgraber: ok.  by friday, we should in theory have an updated signed shim, so you might actually be able to test the server in SB mode
[23:45] <stgraber> yay!


[00:46] <Laibsch> Can somebody help and identify the kernel patches that apparently fixed bug 745836 in oneiric?  They are in desperate need to be backported to maverick, natty and lucid.
[00:46] <ubot2> Launchpad bug 745836 in linux "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [High,Confirmed] https://launchpad.net/bugs/745836
[07:45] <smb> morning .+
[07:50] <apw> morning
[08:08] <BigWhale> Greetings
[08:09] <BigWhale> Who do I have to talk to, to get the latest RTL8111E driver in the Oneiric? :) The one that is currently present is acting really strange.
[08:09] <BigWhale> and isn't what I would call a production quality :/
[08:09] <ogra_> nobody does
[08:10] <apw> BigWhale, its a bit late in the day for those kind of size changes, thats why we have alphas
[08:10] <cking> hope it's not a case of "if it compiles then ship it"
[08:11] <BigWhale> apw: well I just got new motherboard and noticed the problem now. :)
[08:11] <BigWhale> well it is sort of working
[08:12] <BigWhale> just dmesg is full of [  493.664950] r8169 0000:04:00.0: eth1: link up
[08:12] <BigWhale> every second or so
[08:12] <BigWhale> I'll file a bug report ...
[08:13] <apw> BigWhale, hang on isn't that a wired card thats reporting errors ?
[08:13] <BigWhale> it is a wired card yes
[08:14] <apw> so its working ok other than log spam ?
[08:15] <BigWhale> apw, but this is not really nice: http://pastebin.com/wp2PwNAa
[08:15] <BigWhale> apw, no it is not working as it should... packets are being dropped
[08:15] <apw> well indeed file a bug, never know might be fixable
[08:15] <BigWhale> I installed latest driver from realtek and it is working correctly
[08:16] <apw> yeah but their stupid drivers arn't exactly designed to be integrated in a way which works with everything else
[08:16] <apw> those guys need a serious reality check
[08:17] <BigWhale> perhaps that's why their installation script didn't work and I had to compile it manually and copy it to /lib/modules/... :>
[08:17] <apw> BigWhale, likely, what driver name did it make
[08:18] <BigWhale> r8168.ko which is odd since it used to be r8169.ko :>
[08:19] <apw> BigWhale, see what i mean, you got a driver for one card and it makes a driver which would replace all drivers for that name ... bah
[08:20] <BigWhale> well the driver itself is for multiple cards...
[08:20] <BigWhale> but not for 8169 :>
[08:22] <BigWhale> Now I am starting to wonder if this new module will autoload
[08:23] <apw> well i doubt it will
[08:24] <BigWhale> apw, kernel will probably look for r8169.ko
[08:27] <apw> BigWhale, and this just demonstrates my point, their drivers are hopeless integration wise
[08:27] <apw> why they cannot work with teh upstream kernel and give us and you a fighting chance i have no idea
[08:28] <BigWhale> I can see that openSuse guys had/have the same problem
[08:28] <BigWhale> *curses* what is the package name for kernel? :>
[08:29] <apw> BigWhale, realtek are renouned for this issue
[08:29] <apw> kernel == linux
[08:30] <BigWhale> ah, thanks
[08:33] <BigWhale> is launchpad acting up? it seems I can't report new bugs?!
[08:33] <BigWhale> Oops!
[08:41] <apw> BigWhale, for you you may find blacklisting r8169.ko in /etc/modprobe.d might make the other one preferred
[08:43] <BigWhale> I'll reboot now and see what happens...
[08:43] <BigWhale> :>
[10:21] <txomon> hi, does anyone know about any kernel config's documentation program? I need to build a very specific kernel for a 16core computer
[10:27] <apw> txomon, not sure i know what you mean by a "documentation program"
[10:28] <apw> txomon, configs are self documented if you are looking to see what they do ?
[10:30] <txomon> apw, I am looking for specific knowledge about each value of the menuconfig, to know if it is adequate for me
[10:30] <apw> txomon, beyond what is documented in the help for each option i don't know of more detailed information
[10:31] <txomon> I meant if there was any "kernel-config documentation project"
[10:31] <txomon> something like that
[10:31] <apw> there are a heck of a lot of them it doesn't seem feasable to look a tthem all
[10:31] <apw> txomon, no not to my knowledge anyhow
[10:37] <txomon> ok.. so for each option I should UFG ? (Use th F Google)
[10:44] <apw> txomon, most options have extensive help on them, several paragraphs of description
[10:44] <apw> which should be exposed in the menu config
[10:53] <txomon> apw, commonly yes, but sometimes, it is not enough, as I don't know how to retrieve data to decide whether if that option is good for me
[10:54] <apw> txomon, you must have some very tight requirements, good luck
[10:54] <txomon> I my research group we are working in a kernel module that occupies all the CPU, and we want to optimize it
[10:55] <txomon> thank you btw
[10:55] <txomon> Can I add comments in the config_old ?
[10:56] <txomon> I mean, If I compile for the next kernel, it will tell me that there has been found a new config_old, and I was wondering if in the new config file comments would be still there
[10:57] <apw> i don't beleieve that it will honour them no, i think it rebuild it from its internal representation
[10:57] <txomon> ok, so I will have to /replace
[10:57] <txomon> thank you!
[11:03] <brendand> does anyone know why this page isn't updating : http://people.canonical.com/~kernel/reports/sru-report.html?
[11:03] <brendand> the info looks out of date
[11:03] <apw> brendand, what about it looks out of date ?
[11:04] <apw> Friday, 30. September 2011 11:01 UTC
[11:04] <apw> it seems to think it updated itself 'just now'
[11:04] <brendand> yeah, but e.g. there is no reference to the natty -proposed tracking bug
[11:05] <apw>      linux | 2.6.38-11.50 | natty-security | source
[11:05] <apw>      linux | 2.6.38-11.50 | natty-updates | source
[11:05] <apw> natty seems to have no more up to date version ?
[11:05] <apw> ie it is released ?
[11:07] <apw> hmm but there is a 12.51 build and ready to go, hmmm wonder why its not listed, i wonder if it lists things before they are in -proposed
[11:07] <brendand> apw - it normally shows the tracking bug, i.e. this one https://bugs.launchpad.net/ubuntu/+source/linux/+bug/860832
[11:07] <ubot2> Launchpad bug 860832 in linux "linux: 2.6.38-12.51 -proposed tracker" [Medium,In progress]
[11:08] <brendand> i thought it showed the tracking bug through its entire life
[11:08] <apw> brendand, it cirtainly makes sense that it might, you are beyond my understanding now, as it is updating at least
[11:08] <apw> i'd have to refer you to sconklin and herton
[11:10] <brendand> apw - i'll have to wait then. thanks
[11:10] <apw> sorry about that, i'll have to get some knowledge transfer on it
[12:53] <apw> herton, the latest natty kernel tracking bug seems to be missing from: http://people.canonical.com/~kernel/reports/sru-report.html
[12:53] <apw> (brendend reported it)
[12:54] <herton> apw: I think that's because the current natty update wasn't copied yet to -proposed, but better check with brad
[12:54] <apw> bjf, ^^
[12:54] <apw> herton, i was assuming the contents of the build PPA was on there too ... hmmm, will wait on brad
[13:28] <apw> anyone point me at a conversion between mAh and mWh ?
[13:29] <sconklin> apw, it depends on voltage,
[13:29] <sconklin> mWh = mAh * voltage
[13:29] <apw> sconklin, it is a little odd that some machines report battery capacity in one, and otehrs the other
[13:56] <brendand> herton - do you know is this page updating properly? the section on natty at least seems to be wrong - http://people.canonical.com/~kernel/reports/sru-report.html
[13:58] <apw> ahhh wern't you here, the discusssion was that we weren't sure and bjf is in the frame for answering now
[13:58] <herton> yes, I think the page only shows when things are copied to -proposed, latest natty isn't copied to -proposed yet
[14:34]  * bjf seems to be popular this morning, maybe he should just go back to bed
[14:34] <bjf> apw, herton is correct, the tracking bug should only show up on that page when the package has reached -proposed
[14:37] <apw> brendand, ^^
[14:38] <apw> bjf, would it be hard to add a new psudo pocket of like -build which had what was in the PPA
[14:38] <bjf> apw, why?
[14:39] <apw> then the whole life cycle would be represented in the one place ?
[14:40] <bjf> apw, but that wasn't the purpose of that report and i believe it would add confusion to others that view it
[14:43] <bjf> apw, i could add just the version in the ppa like what's on: http://people.canonical.com/~kernel/reports/versions.html
[14:45] <apw> bjf yeah unsure not really a big consumer of it either way
[14:45] <brendand> bjf - can you recommend a quick way to find the current tracking bug without going back through email?
[14:46] <bjf> brendand, http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
[14:51] <bjf> brendand, does that have what you are looking for ?
[15:27] <brendand> bjf - perfect
[15:55]  * herton -> lunch
[15:58] <apw> is anyone else getting asked for the passowrd for their wireless everytime they resume ?
[16:03] <smb> apw, nope
[16:04] <apw> starting to get on my nerves
[16:04] <tgardner> apw, testing....
[16:04] <apw> perhaps i am too many milliseconds behind the bleeding edge
[16:04]  * smb has not upgraded for 2 days...
[16:04] <apw> smb, yeah it was ok a couple of days ago
[16:04]  * bjf neither, been afraid
[16:04]  * smb probably won't do that then
[16:04] <tgardner> apw, I just upgrade 15 minutes ago
[16:05]  * bjf dist-upgrading right now (will probably regret it)
[16:05] <tgardner> apw, so it resumed and connected OK, but I didn't get the screen lock login.
[16:05]  * apw giggle
[16:06] <tgardner> apw, I wonder if thats because I have screen lock turned off
[16:06] <apw> apparently i am 169 packages out of date _again_ so, i'll shut up until i've upgraded yet more
[16:06] <tgardner> apw, yeah, I picked up 60 or so this AM
[16:07] <bjf> i am 185 behind
[16:07] <apw> bah my wifi is degraded out here on the balcony ... sigh
[16:07] <apw> how can this be, my house is made of sheets of paper
[16:08] <tgardner> apw, drag a cable out there :)
[16:09] <apw> tgardner, tempting indeed
[16:10] <tgardner> apw, until someone slams the sliding door shut
[16:10] <apw> heh, ouch :(
[16:12] <tgardner> apw, hey, while you're just scoping the great outdoors, how about having a look at /usr/bin/dpkg-gencontrol with an eye towards developing a patch the protects multiple writers to debian/files. cjwatson suggested using the flock primitive.
[16:13] <tgardner> my perl foo is a bit weak these days
[16:13] <apw> tgardner, is that what is stopping us from doing parallel builds ?
[16:13] <tgardner> apw, I think its the source of random errors
[16:14] <apw> tgardner, added to my todo, there seems to be another perl-y one on there too will have a look
[16:16] <tgardner> apw, I'm working on an alternative for the kernel package, but fixing dh-gencontrol would help others to parallelize their packaging.
[16:17] <apw> tgardner, sounds reasonable to moi
[16:22] <bjf> apw, i dist-upgraded, suspended, resumed, did not get prompted for ap password
[16:22] <apw> bjf heres hoping i'll be ok once i update then
[16:43] <komputes> Does anyone know why uname -a now shows arch 3 times?
[16:47] <broder> komputes: it's "machine", "processor", and "hardware platform"
[17:05] <komputes> broder: sorry i'm still a bit confused. by that logic wouldn't a processor capable of doing 64-bit cause uname to show i686 x86_64 1386
[17:15]  * bjf is rebooting
[17:30]  * tgardner -> lunch
[17:52] <tkamppeter> I have an old 32-bit HP Compaq 12-inch laptop and it does not boot with the 3.0.0-12 kernel, but only with the last Natty kernel. How to report a bug/debug this?
[19:01]  * jjohansen -> lunch
[19:03]  * bjf -> lunch
[19:08]  * ogasawara lunch
[19:57] <hallyn_> smb: ppetraki: at least, a simple reproducer script for bug 861656 .
[19:57] <ubot2> Launchpad bug 861656 in linux "many ext4 errors " [Undecided,Confirmed] https://launchpad.net/bugs/861656
[19:58] <hallyn_> should have been obvious to me from the start....
[20:01] <ppetraki> hmm, that isn't much different from someone changing the state of an SD device to offlline or echo 1 > delete
[20:05] <ppetraki> whatever framework is managing this, or the user, that's their problem. There has been a push recently to try communicate "use count" to lower layer devices in the case of virtualization, but it was not well received.
[20:05] <ppetraki> hallyn_, http://www.spinics.net/lists/linux-scsi/msg54687.html
[20:06] <tkamppeter> I have an old 32-bit HP Compaq 12-inch laptop and it does not boot with the 3.0.0-12 kernel, but only with the last Natty kernel. How to report a bug/debug this?
[20:06] <ppetraki> hallyn_, and the nak: http://www.spinics.net/lists/linux-scsi/msg54688.html
[20:07] <ppetraki> so unless we can come up with a better solution, we'll have to work around it
[20:31] <hallyn_> ppetraki: terrific
[20:32] <hallyn_> ppetraki: though that is for scsi.  I'm not sure what paths the nbd driver takes.  Lemme take a look
[20:34] <ppetraki> hallyn_, well, hotplug is hotplug
[20:35] <tgardner> sconklin, GPG sign your entry at https://wiki.ubuntu.com/HertonKrzesinski/PerPackageUploaderApplication
[20:35] <ppetraki> hallyn_, now this nbd thing *may* have an additional interface where this count could be determined
[20:36] <hallyn_> right that's my hope
[20:36] <ppetraki> hallyn_, I hate to dash your hopes but it probably doesn't have one
[20:36] <sconklin> tgardner, really? This hasn't been widely done or enforced in the past. But whatever.
[20:36] <tgardner> sconklin, I'm just following directions....
[20:37] <sconklin> heh, and I'm was flagrantly igoring them.   Seems like adding a check over the list of mounted supers shouldn't be a big deal...
[20:39] <hallyn_> (at NBD_DISCONNECT)
[20:40] <ppetraki> hallyn_, so you basically want to block disconnect until the write-back has a chance to complete?
[20:41] <ppetraki> hallyn_, that could get confusing quick, as in if it's due to a transport error, that flush may never occur and block forever.
[20:41] <hallyn_> yes, just return -EBUSY
[20:41] <hallyn_> true
[20:42] <ppetraki> hallyn_, so adding more transparency to the supers wouldn't be a big deal but now you just gave userspace more to chew on, and take action subjectively.
[20:43] <ppetraki> hallyn_, the right answer here may just be "don't do that"
[20:44] <sconklin> tgardner, fixed, thanks!
[20:45] <hallyn_> ppetraki: it's just an ioctl... returning -EBUSY seems fine
[20:45] <hallyn_> ppetraki: the problem is, it's not just "don't do that."  Because if you do
[20:46] <hallyn_> well, bc the umount may fail :)
[20:46] <ppetraki> hallyn_, so looking back at the bug, you state that nbd starts dropping out under load.
[20:47] <hallyn_> oh, disgregard most of what i wrote there
[20:47] <ppetraki> gee thanks :)
[20:47] <hallyn_> in the end, the little script is all you need.  no load needed
[20:48] <hallyn_> heh, that's why i said "i should've seen it earlier" - i was chasing down the idea of ext4 or nbd corruption due to high load
[20:49] <hallyn_> ppetraki: anyway i may pursue a patch doing -EBUSY tomorrow afternoon.
[20:50] <ppetraki> hallyn_, you can try, though I don't think it'll be accepted. block devices, and generally block device stacking depend on the current behavior. Special casing NBD isn't a "good thing"
[20:50] <ppetraki> hallyn_, I can rip out a multipath device right now from a mount and the kernel can't stop me
[20:53] <hallyn_> wouldn't be my first lkml rejection experience :)
[20:57] <ppetraki> hallyn_, actually, nbd has it's own list
[20:58] <hallyn_> i don't want to be on another list :(
[20:58] <hallyn_> ppetraki: i'm still thinking - wondering if it should go in qemu/qemu-nbd.c instead
[20:59] <ppetraki> hallyn_, well, userspace programs generally can't dictate when a kernel resource decides to quit, unless a reference count was taken
[21:00] <hallyn_> no but they can refuse to tell the kernel to shoot itself in the foot
[21:02] <ppetraki> hallyn_, oh wait, the unmount is occuring in the guest?
[21:03] <ppetraki> hallyn_, nm, looking at your script
[21:04] <hallyn_> ppetraki: yeah for the script, ignore any mention of clouds or virt
[21:04] <hallyn_> it just runs on the host
[21:05] <ppetraki> hallyn_, hmmm, best thing to do here is flush on exit from qemu-nbd -d, and kill the queue so it won't accept any new requests. Then the unmount won't have anything to flush
[21:05] <ppetraki> hallyn_, you should update the description :-p
[21:05] <hallyn_> ppetraki: i did
[21:05] <hallyn_> it's now called Kernel oops when nbd device is removed before it is unmounted
[21:06] <ppetraki> hallyn_, right, the journal is in flight so you never get it all.
[21:09] <ppetraki> hallyn_, I'm still not a huge fan of the use case.
[21:09] <hallyn_> ppetraki: i think it's worse than that.  it's not a corrupt fs in the guest i'm worried about.  it's submit_bh() on the host doing opcode 0000
[21:09] <hallyn_> [ 6016.938260] invalid opcode: 0000 [#1] SMP
[21:09] <hallyn_> use case?
[21:10] <ppetraki> hallyn_, the script, if you just swapped qemu-nbd -d /dev/nbd1 and mount /mnt/1, the problem disappears right?
[21:10] <hallyn_> of course :)
[21:11] <ppetraki> hallyn_, yeah, I don't like that use at all, again, it's a block device, no different than any other.
[21:11] <hallyn_> ppetraki: the idea isn't that you didn't do umount.  It's that you did umount but umount failed (i.e. a file on the fs was open)
[21:11] <hallyn_> yeah, it's just easier to shoot yourself this way
[21:11] <ppetraki> hallyn_, now, if you were to perhaps change qemu-nbd -d to add say a --lazy switch, that might be a good way around
[21:12] <ppetraki> hallyn_, then you're giving people the choice of whether to destroy that resource once it's users have left
[21:12] <hallyn_> that'd be nice, yes
[21:12] <hallyn_> but like i say i think i'll ignore it for nwo and just fix the caller that's bugging me
[21:13] <ppetraki> hallyn_, I like that one best, you'd also have to consider raw io, no superblocks to check there, just open count.