[00:05] <cjwatson> stgraber: I did an updated precise build for you, in case you're still around
[00:15] <stgraber> cjwatson: ah cool, I'll give it a try
[00:15] <stgraber> now that I'm done banging my head against the wall trying to figure out how nih-dbus-tool does its magic :)
[00:27] <slangasek> stgraber: do you have a bug # handy for the "can't boot unsigned kernels" bug on your system?  I'd like to start digging into that with you too before .2
[00:28] <stgraber> hmm, I can't remember whether I filed a bit for that one or not, let me look at my recently filed bug list :)
[00:29] <stgraber> can't find one... I'll file a new one against shim so we can track that issue
[00:32] <stgraber> slangasek: bug 1087501
[00:32] <ubot2> Launchpad bug 1087501 in shim (Ubuntu) "Unable to boot unsigned kernel, boot freezes in shim call" [Undecided,New] https://launchpad.net/bugs/1087501
[00:32] <slangasek> ok
[00:33] <stgraber> slangasek: once I'm done testing the new precise image for Colin, I'll do another run of grub with debug=all and attach a picture to the bug. I doubt it's going to really help though as all that we'll see is that it's calling a function that the shim exports.
[00:33] <slangasek> yep
[00:34] <slangasek> so as a first step, I'd like to do a build of the new upstream version of shim, where mjg59 has entirely dropped the fallback code for calling the UEFI protocol
[00:34] <slangasek> (the same UEFI protocol that was popping up dialogs on signature failure)
[00:36] <stgraber> I've been playing with EFI a bit lately and I think I have a working .efi binary that when called will load my local PKI's certificate into the firmware, allowing me to sign my own binaries. That should help quite a bit.
[00:36] <stgraber> I know that in theory I can also just write new entries from Ubuntu while in setup mode but I haven't found a good tool for that yet (that just takes a standard SSL cert and loads it)
[00:38] <cjwatson> stgraber: debug=all> we already tried that at UDS and showed it just calling said function, indeed - I don't think it was useful for debugging this
[00:40] <slangasek> stgraber: yes, for debugging you definitely want to be using self-signed binaries :)
[00:40] <slangasek> (at least self-signed shim)
[00:41] <stgraber> slangasek: btw, is there any reason why /sys/firmware/efi/efivars is world readable but /sys/firmware/efi/vars is only root readable?
[00:42] <stgraber> found it a bit weird considering they export the exact same information just with different paths :)
[00:42] <slangasek> stgraber: ummm because the former is a mountpoint and I didn't think to change the defaults? :)
[00:43] <slangasek> it shouldn't be a security issue in practice, but maybe we do want to lock it down to be root-only by default
[00:43] <slangasek> can you file a bug report on mountall for this?
[00:44] <stgraber> will do once I'm back to my standard desktop (currently in the middle of the precise install)
[02:58] <stgraber> cjwatson: well, the good news is that grub is booting
[02:58] <stgraber> cjwatson: the bad news is that it has no menu and can't seem to find anything
[02:58] <stgraber> so I'm stuck in grub minimal
[03:10] <stgraber> and back to a working laptop, now let's see what was broken this time around :)
[03:12] <stgraber> cjwatson: so at first glance, my bet would be on the missing grub directory under /boot/efi/
[03:12] <stgraber> cjwatson: at the end of this install the EFI partition only contains two directories, EFI and LOST.DIR, no grub
[03:13] <stgraber> cjwatson: installer log: http://paste.ubuntu.com/1416091/
[03:15] <stgraber> cjwatson: btw, to make things simpler this time around I unplugged my internal ssd before the installation
[03:17] <stgraber> cjwatson: that may explain why my previous test had the grub directory present as the EFI boot partition was shared with the one from my raring system and therefore already had a grub directory.
[03:28] <stgraber> slangasek: efivars bug 1087546
[03:28] <ubot2> Launchpad bug 1087546 in mountall (Ubuntu) "efivars filesystem gives more access than the exists vars directory" [Undecided,New] https://launchpad.net/bugs/1087546
[05:00] <slangasek> stgraber: /boot/efi> secureboot doesn't get a grub directory, you get a monolithic grub .efi because it's not allowed to load unsigned code?
[05:02] <stgraber> slangasek: ah, ok, so I must have it on my laptop because grub-install has been running a few times without secureboot. So it's something else that's broken in the secureboot grub that's on the precise image
[05:06] <stgraber> so trying to boot the same disk in a VM (so I can slow it done and see what's going on), I'm seeing a bunch of "error: efidisk read error.", then drop in a minimal grub shell and that's all I get
[05:06] <stgraber> *down
[05:11] <slangasek> strange
[05:12] <slangasek> "efidisk read error" isn't anything I'm familiar with, I guess it could be a grub-specific error message when it tries to use the efi disk protocols
[05:12] <stgraber> yeah, and that VM isn't running with secureboot enabled, so it's not the firmware blocking access or anything like that
[05:13] <stgraber> and just to be 100% sure, I checked that the md5sum of /boot/efi/EFI/ubuntu/grubx64.efi matches that of /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed, so it's not some kind of random vfat corruption that happened at install time
[05:15] <stgraber> anyway, enough uefi fun for the evening, will wait for cjwatson to show up
[05:22] <ScottK> Looking at the SRUs in -proposed, I see that walinuxagent is fixing a private bug (bug  	#1077147).  It seems to me that any bug being dealt with in the SRU process ought to be public (if needed, support people could make a sanitized version of the bug for public consumption.)
[05:22] <slangasek> yes, I agree; this has been communicated in the past, but it needs to be repeated from time to time
[05:26]  * ScottK wonders if removing the upload from proposed would be an adequate form of 'communication'?
[05:26] <cjohnston> lol
[05:26]  * ScottK is not kidding.
[05:26] <slangasek> preferably telling the uploader why at the same time?
[05:26] <ScottK> Yes.  That too.
[05:26] <slangasek> then yeah
[05:26] <slangasek> it clearly can't be accepted as-is
[05:29] <ScottK> Additionally, it doesn't appear it was accepted into quantal by a member of ubuntu-sru
[05:29] <slangasek> sigh
[05:30] <slangasek> hmm, no, infinity accepted it
[05:30] <slangasek> (per the comment on the private bug)
[05:30] <ScottK> For precise
[05:30] <slangasek> oh
[05:30] <ScottK> https://bugs.launchpad.net/ubuntu/+source/walinuxagent/+bug/1079897/comments/11 indicates Dave Walker for quantal
[05:30] <ubot2> Launchpad bug 1079897 in walinuxagent (Ubuntu Quantal) "[SRU] walinuxagent mangles server identity and access on upgrade" [Critical,Fix committed]
[05:31] <ScottK> Since infinity accepted it for one release, maybe he'll take responsiblity for getting the bug unprivate ....
[06:17] <slangasek> man, I really don't feel like I'm accomplishing anything with these precise new queue approvals without queuebot to cheer me on
[06:35] <ScottK> OK, so removed walinuxagent and pinged the bug/uploaders.
[06:36] <ScottK> (to complete the record here for backscroll readers)
[09:34] <infinity> ScottK: Gah.  I could have sworn walinuxwhatever used to reference a public bug.
[09:35] <infinity> Err, it does.
[09:36] <infinity> ScottK: Oh, that was just a "new upstream" bug from a previous changelog entry.  I'm not sure that was worth removing for. :/
[09:37] <infinity> ScottK: I don't agree that asking people to revise their changelog to sanitize out dupe bugs is sane at all.
[09:37] <infinity> ScottK: It clearly was a dupe of an identical public bug, from the changelog.
[09:37] <xnox> ScottK: walinuxagent is a valid bug. And references public bugs. Also that SRU causes dataloss and rendering sertain machines unreachable.
[09:38] <xnox> ScottK: infinity: can we please revert removal?
[09:38] <infinity> xnox: You can't "revert" removal.
[09:38] <infinity> xnox: It'll need a new upload with a bumped version.
[09:38] <infinity> Oh, actually.  That might not be true.
[09:38] <xnox> infinity: it is scheduled "in 3h time or something?!"
[09:38] <infinity> We can copy from proposed to proposed to make it magically reappear.
[09:38] <xnox> =)))))
[09:39]  * infinity tries that.
[09:39] <xnox> ScottK: infinity: while the SRU procedure was not followed, it is best to speak with individual in question publically on u-d, instead of blindly removing packages from -updates.
[09:39] <infinity> xnox: The procedure was followed.
[09:39] <xnox> righ.
[09:40] <xnox> So why is ScottK removed both of them?
[09:40] <infinity> (It's just that the changelog references one private (dupe) bug).
[09:40]  * xnox thinks about grammar.
[09:40] <infinity> And I'm not editing the changelog and reuploading, when it's obvious that's the case.
[09:40] <infinity> xnox: That said, the procedure absolutely was NOT followed for Quantal. :P
[09:40] <infinity> xnox: I'm only restoring the one I accepted into precise.
[09:41] <xnox> infinity: the bug causes dataloss & renders machines unreachable. I'd want to see both packages restored asap.
[09:42] <infinity> xnox: That's no excuse for non-SRU members accepting SRUs.
[09:43] <xnox> Daviey: jamespage: ^^^^^^^ walinuxagent - Daviey, you shouldn't accept SRUs. (you can via AA rights, but you shouldn't due to not being SRU team member). And now walinuxagent is being removed from the updates pocket.
[09:43] <xnox> win \o/
[09:44] <xnox> infinity: what do you want to happen for quantal SRU to be re-published?
[09:46] <infinity> xnox: I want to wait until I discuss this with ScottK and slangasek tomorrow to grasp why it was such a monumentally big deal to have a changelog reference a private bug (when it was clearly a dupe, I know exactly why it's bad when it's not).
[09:48] <Daviey> xnox: This is something that has only been clarified recently.
[09:49] <infinity> Daviey: Uhm.  If "recently" means "before you were an archive admin", I agree.
[09:50] <Daviey> No.
[09:50] <infinity> ScottK / slangasek: I absolutely agree that SRUs shouldn't ref private bugs, but I also think that people reviewing these things should have the ability to read changelogs instead of blindly clicking on a list in a UI.
[09:51] <Daviey> infinity: erm, that isn't quite what happened.. And i'd appreciate a less sarky attitude please.
[09:52] <infinity> Daviey: What isn't what happened?
[09:53] <Daviey> infinity: you are shooting off comments, without facts.  It is inappropriate.
[09:53] <infinity> Daviey: Which comment lacks facts?
[09:54] <Daviey> infinity: Firstly, i was informed from an ~ubuntu-sru member that it was agreed at UDS before last that AA's could handle SRU's. Secondly, i checked with another member that it wouldn't cause upset.. and thirdly, "blindly clicking on a list in a UI." is just flippant.
[09:55] <Daviey> That is not what i did.
[09:55] <infinity> Daviey: That last comment had nothing to do with you, it had to do with people clicking bugs and noticing they're private and knee-jerking, rather than reading the changelog to see the ref.
[09:55] <Daviey> Oh, ok.  Apologies.
[09:57] <infinity> Anyhow, the first part is a twisting of the part where we had a conversation suggesting AA/SRU/Release should perhaps be merged (and then opted not), second, whoever you checked with was, well, wrong?  Third, this is all documented. :/
[09:58] <Daviey> infinity: I wasn't in the session i don't think.. But when a ~ubuntu-sru member tells you something like that, it seems reasonable.
[10:00] <Riddell> how do I put a block on migrating from proposed (for KDE SC)?
[10:09] <infinity> (base)adconrad@cthulhu:~/britney/hints-ubuntu$ cat kitterman
[10:09] <infinity> # Keep KDE SC 4.9.90 from migrating before we are ready
[10:09] <infinity> block kde4libs
[10:09] <infinity> Riddell: ^-- Like that one?
[10:10] <infinity> Riddell: (ScottK appears to be on the case)
[10:20] <Riddell> lovely
[10:30] <infinity> ScottK: So there's public record of this in the channel, Daviey and I have talked privately, and I'll be giving him some formal training, but there won't be any more SRU accepting by him until after that happens.
[11:32] <cjwatson> stgraber: For your VM test, make sure you have enough RAM.  I wasted a couple of hours a few weeks ago because I was running kvm with its default of 128MB, but UEFI/OVMF/whatever is too memory-hungry for that to work
[11:36] <cjwatson> Daviey: If you mean with me, since the conversation was in person I don't have a word-for-word record; but I believe I said that I thought it was acceptable for AAs to step in occasionally outside their usual line of work if other avenues had been exhausted
[11:36] <cjwatson> I don't think it should be a routine thing
[11:38] <Daviey> cjwatson: Actually, that wasn't you.. you were the followup.  The outcome of our conversation IIRC was that it was 'OK', but should really look to get in officially.. Which is what i did.
[11:38] <cjwatson> stgraber: What's in /boot/efi/EFI/ ?
[11:39] <cjwatson> (a.k.a. /EFI/ on the EFI System Partition)
[13:02] <jdstrand> infinity: hey, fyi, you mentioned a CC in the team status reminder, but there was no CC. I'll forward it along to my guy
[13:03] <infinity> jdstrand: SRSLY?
[13:03] <infinity> Cc: brendan.donegan@canonical.com, didrocks@ubuntu.com, marc.deslauriers@canonical.com,
[13:03] <infinity>         leann.ogasawara@canonical.com, antonio.rosales@canonical.com, fathi.boudra@linaro.org,
[13:03] <infinity>         para.siva@canonical.com, jriddell@ubuntu.com, ogra@ubuntu.com, alan.pope@canonical.com
[13:03] <infinity> jdstrand: It was CCed, the header just got stripped off the lists copy.
[13:03] <jdstrand> oh, interesting
[13:04] <jdstrand> I didn't know the list would do that
[13:04] <jdstrand> infinity: ok, sorry for the noise :)
[13:41] <psivaa> cjwatson: i have attached ubiquity debug logs as asked in bug 1080701
[13:41] <ubot2> Launchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [High,Confirmed] https://launchpad.net/bugs/1080701
[13:44] <cjwatson> psivaa: Thanks
[13:45] <cjwatson> xnox: ^- Do you think you could have a look at that, please?  I think you've touched this code most recently
[13:46] <xnox> cjwatson: ok. I will look into it later today.
[13:47] <psivaa> xnox: cjwatson: thanks
[13:52] <cjwatson> xnox: Thanks
[14:28] <stgraber> cjwatson: a single ubuntu directory containing shimx64.efi and grubx64.efi
[14:28] <stgraber> cjwatson: the VM had 2GB of RAM, so shouldn't be the problem and I get the same on baremetal with 16GB
[16:46] <slangasek> infinity: in the changelog I looked at, it was note a dupe: Backport new upstream version (LP: #1078074) from current development release including fix for critical issue during upgrade (LP: #1079897).
[16:46] <ubot2> Launchpad bug 1078074 in walinuxagent (Ubuntu Quantal) "[SRU] Update walinuxagent to version 1.1" [High,Triaged] https://launchpad.net/bugs/1078074
[16:46] <ubot2> Launchpad bug 1079897 in walinuxagent (Ubuntu Quantal) "[SRU] walinuxagent mangles server identity and access on upgrade" [Critical,Triaged] https://launchpad.net/bugs/1079897
[16:48] <slangasek> infinity: in this case I mentioned to ScottK I didn't mind if it was published with that particular bug reference present since the bug itself was nothing more than "New upstream release"
[16:48] <infinity> slangasek: That's not the private bug.
[16:48] <infinity> * New upstream version (LP: #1078074, #1077147).
[16:48] <ubot2> Launchpad bug 1078074 in walinuxagent (Ubuntu Quantal) "[SRU] Update walinuxagent to version 1.1" [High,Triaged] https://launchpad.net/bugs/1078074
[16:48] <infinity> ^-- The second one there is the private.
[16:49] <slangasek> infinity: ah, then apparently I got my wires completely crossed while looking at changelogs
[16:49] <infinity> https://launchpad.net/ubuntu/+source/walinuxagent/1.1-0ubuntu2~12.04.1
[16:49] <infinity> Had the top-referenced bug been private, I would have had the same grump.
[16:49] <slangasek> infinity: so I don't object to this SRU being resuscitated as-is
[16:50] <infinity> Check.
[16:50] <infinity> I'll review the Q one and copy it back in (I already did so for precise)
[16:50] <infinity> And I'm going to give Daviey some training $soon.
[17:58] <cjwatson> stgraber: I think the answer is going to be that I have to pair-debug this with you at a time when it's mutually convenient
[17:58] <cjwatson> stgraber: But today my head is full of cold and I don't think I'm in a useful state to do much about it
[17:59] <cjwatson> stgraber: So maybe Monday?  What kind of time do you start then?
[17:59] <cjwatson> the efidisk read error might be a consequence of a wrong bootstrap config file in the embedded memdisk
[17:59] <cjwatson> at any rate that's my best guess at the moment - but I'd have to stare at it
[18:11] <stgraber> cjwatson: Monday morning is pretty bad for me because of a bunch of meetings. I start at 14:00 UTC but have meetings between 15:00 and 16:00 and between 17:00 and 17:30
[18:17] <cjwatson> stgraber: ok, I think I'm actually free 16 to 17 - but maybe Tuesday then?
[18:19] <stgraber> cjwatson: I have nothing on Tuesday so that'd work a lot better :)
[19:06] <infinity> cjwatson: Oh, pursuant to an old conversation, here's a prime example of my subconscious need to (almost) fully-justify things without really thinking about it:
[19:06] <infinity> https://launchpadlibrarian.net/125129559/qemu_1.2.0.dfsg-4_source.changes
[19:06] <infinity> cjwatson: Extra sad, since that was just a test package I did for hallyn.
[19:26] <utlemming> infinity: on walinuxagent, I've cleared the private bug -- its now public
[19:27] <utlemming> infinity: all confidential information has been hidden.
[19:28] <infinity> utlemming: We decided that wasn't necessary in the end, but thanks anyway. :)
[19:29] <infinity> utlemming: I've recopied both SRUs to proposed (binaries and all, so if you'd previously done verification on them, that verification is still valid)
[19:29] <utlemming> inifinity: okay great...do we know when it will land?
[19:29] <infinity> Was all the verification done and ready to go?
[19:29] <infinity> If so, I can quickly run through the paperwork and do some releasy magic.
[19:30] <utlemming> infinity: yup. That was private tracking bug that we used for talking to MS. It really shouldn't have been referenced. But, yes, verification is done
[20:07] <slangasek> infinity: hmmm my copy of your mail to u-release includes 0 CC:s
[20:10] <infinity> slangasek: mailman strips the CC header.
[20:10] <infinity> slangasek: I assure you that people got the mail.
[20:10] <slangasek> wat
[20:11] <infinity> slangasek: (Or, so I've been told by $people)
[20:11] <slangasek> mailman has never, ever stripped cc:s for me before
[20:11] <slangasek> but ok, as long as you're sure people got the memo
[20:11] <infinity> slangasek: It did this time.  Perhaps because it tripped the "too many recpients" thing?  (which it did, I had to moderate it)
[20:11] <slangasek> right, that could be a special case
[20:19] <slangasek> stgraber: on iso.qa, I see that desktop and preinstalled are both "active" products for armhf+omap*.  Is this because the list is used for both the current release and the LTS point releases?
[20:19] <stgraber> slangasek: yep
[20:19] <slangasek> ok
[20:20] <stgraber> hmm, not that we do point release for armhf, do we?
[20:20] <stgraber> if we don't we can probably just disable preinstalled
[20:20] <slangasek> it doesn't appear that we did 12.04.1 for armhf
[20:21] <slangasek> except for ubuntu core
[20:22] <infinity> Yeah, we don't do point releases on those images.
[20:22] <ogra_> slangasek, hmm, i thought respinning armhf was undesired
[20:22] <infinity> ogra_: It is.  This is just the tracker that needs to learn that, the rest of us know. :)
[20:22] <ogra_> oh. ok
[20:28] <cjwatson> stgraber: though it occurs to me that I could build myself a grub image that thinks it's SB and refuses to load modules, even though it really isn't
[20:28] <cjwatson> I might have a go at that on Monday.  Not sure why I haven't tried that before
[20:30] <stgraber> cjwatson: oh, I may have forgotten to mention that SB or non-SB gives me the same thing, so if you have an EFI system, booting the signed binary should trigger the bug
[20:30] <slangasek> stgraber: so IIRC, the theory was that we would ditch the wiki manifest in favor of something that lives in the iso tracker; I cannot currently find any page in the ISO tracker that accurately shows me what we're expecting to release for raring.  Halp?
[20:34] <stgraber> slangasek: right, so we have a way of storing the manifest on the tracker, by going to a manifest page under the series tab in the admin. However the implementation has discussed at UDS had a flaw ;) we said we wouldn't need that list to be overridable per-milestone but we clearly do.
[20:34] <cjwatson> stgraber: no, I test-installed in OVMF before I gave it to you, so it's not that simple
[20:35] <med_> infinity, as I understand scrollback, walinuxagent is about to go "live" in precise-updates and quantal-updates?  Is there a timetable for that (ie, within 24 hours?)
[20:35] <cjwatson> it might be the memory allocation bug that Dell want me to fix, I guess ...
[20:35] <slangasek> stgraber: ehm, so, I was expecting this to be the manifest for the release
[20:35] <stgraber> cjwatson: I can send you a compressed disk image of my drive if you want? "sudo qemu-system-x86_64 -L . -hda /dev/sdc -m 2048" clearly gives me the same bug here as on metal
[20:35] <infinity> med_: Less, probably, I just need to stop multitasking and poke it.
[20:36] <cjwatson> stgraber: couldn't hurt ...
[20:36] <slangasek> stgraber: is the problem here that it's being used by nusakan to control the actual milestone publishing, and therefore needs to keep track of the differences?
[20:36] <med_> infinity, nod, thanks.
[20:37] <stgraber> slangasek: so the way it works currently is that you can set a milestone to be based on the manifest, in that case, whenever a daily that's pushed by nusakan is present in the manifest, it'll be automatically added to the milestone.
[20:37] <stgraber> slangasek: so if we had listed everything in the manifest for alpha-1, then all the products would have showed up in the alpha-1 milestone on the tracker
[20:38] <stgraber> slangasek: my current thought of a quick fix for this limitation is to add a disabled flag to those manifest entries, so that we can choose which are currently active and should be used when posting images
[20:38] <stgraber> that way we can add all the products and their contacts for the release and before a milestone, disable them all and only enable those that are participating
[22:12] <slangasek> stgraber: what about not automatically posting the images to the milestone?
[22:12] <slangasek> wouldn't require code changes, could be implemented immediately
[22:14] <stgraber> slangasek: well, I surely intend to lend the active/inactive flag way before the next milestone
[22:14] <stgraber> slangasek: so there's no problem populating the manifest already
[22:14] <stgraber> *land
[22:15] <infinity> *sigh*... Has anyone yelled at seb128 about breaking ubuntu-desktop?
[22:17] <slangasek> infinity: er?
[22:17] <infinity> http://people.canonical.com/~ubuntu-archive/testing/raring_probs.html
[22:18] <infinity> slangasek: Due to the im-switch -> im-config change without an MIR (or two).
[22:18] <slangasek> stgraber: ok, so... do we have the data somewhere, that can be used to repopulate this?
[22:18] <slangasek> infinity: britney allowed this?
[22:19] <stgraber> slangasek: nope because I don't think we actually asked th product leads what they're planning on releasing for raring. We can base it on quantal though and then ask everyone to check that it's correct
[22:19] <infinity> slangasek: Britney doesn't deal in components currently.
[22:19] <slangasek> stgraber: I think that's a good place to start then.  Can you do that easily?
[22:19] <stgraber> slangasek: yep
[22:21] <slangasek> stgraber: ok, then please do :)
[22:22] <slangasek> infinity: so, are you reverting language-selector?
[22:22] <infinity> slangasek: I suppose that's the way forward for the weekend.
[22:22] <infinity> slangasek: And the seeds, and ubuntu-meta.
[22:22] <infinity> Oh, maybe not meta.
[22:23] <infinity> Nope, meta hasn't been refreshed yet.
[22:23] <slangasek> yes, and we have a wiki page somewhere for tracking reverts, right?
[22:23] <infinity> But I'll revert the seed change.
[22:25] <infinity> We do.  Somewhere.
[22:25] <slangasek> https://wiki.ubuntu.com/UbuntuDevelopment/RevertLog, editing
[22:29] <slangasek> infinity: were there any bug reports for this?
[22:30] <infinity> slangasek: It just landed in the archive a few hours ago and Andy whined that upgrade was taking out ubuntu-desktop.
[22:30] <infinity> Let me go see if there's a bug report.
[22:30] <slangasek> infinity: well, if you're doing the reverting upload, please do that first :)
[22:30] <slangasek> we can find and fix bug reports after
[22:30] <infinity> Already done.
[22:31] <slangasek> ah, thanks
[22:31] <infinity> Might even build before the publisher.
[22:32] <infinity> Nothing new on language-selector, but heaven knows what other random packages it could have been filed on.
[22:33] <infinity> And my build beat the publisher.
[22:33] <infinity> Yay.
[22:35] <slangasek> no obvious bug reports that I can see
[22:35] <stgraber> slangasek: http://iso.qa.ubuntu.com/qatracker/series/32/manifest
[22:36] <infinity> Why do I keep ending up ad server amd64+mac?
[22:36] <infinity> I swear I fixed that in the wiki before.
[22:36] <stgraber> based on quantal's manifest and dropped armel products. I don't think I missed anything but that's a long list
[22:37] <stgraber> infinity: well, you didn't fix https://wiki.ubuntu.com/QuantalQuetzal/ReleaseManifest apparently ;)
[22:37] <infinity> (And I'm positive it's cause someone saw "mac" and saw I was on the hook for PPC, and extrapolated)
[22:37] <slangasek> heh
[22:37] <stgraber> I'm not even sure why we build a +mac server image to start with :)
[22:37] <infinity> We probably shouldn't.
[22:38] <infinity> Well, ideally, we shouldn't have to build any +mac images.
[22:38] <stgraber> yeah, would be nice to finally get the full hybrid images working and getting rid of +mac
[22:38] <stgraber> not sure how far cjwatson got on that though
[22:39] <infinity> Did he ever manage to kidnap a Mac from the kernel team?
[22:39] <slangasek> infinity: thanks for volunteering to hack the ISOs in your spare time!  Hardware is on its way
[22:39] <slangasek> ;)
[22:39] <infinity> AFAIK, he was blocking on having real hardware to debug with.
[22:39] <slangasek> no, actually the hardware is kidnapped in my direction
[22:39] <infinity> Ahh.
[22:39] <infinity> Plz fix.
[22:46]  * infinity emails the responsible parties.
[22:51] <infinity> Weird.  mailman is definitely munging CCs.
[22:51] <infinity> In my =Sent folder, I have "Cc: gunnarhj@ubuntu.com, seb128@ubuntu.com"
[22:51] <infinity> The mail from the list only has Gunnar.
[22:54] <slangasek> infinity: oh; correction, the macs are not kidnapped in my direction, they are sitting on my doorstep
[22:54]  * slangasek fixes this
[23:08] <xnox> slangasek: so you are joining the apple crowd =) I am sure ev & barry would give you a hug. (and doko & myself to some extend)
[23:08] <slangasek> xnox: I'm only here to kill off an ISO
[23:08] <slangasek> after that the hardware goes away again ;)
[23:10]  * ScottK cheers killing off an ISO.
[23:10]  * xnox can image slangasek using a separate tagged vlan for macs in a quarantine room, just in case they pollute the rest of machines.
[23:11] <stgraber> you don't need network access to test iso images
[23:11] <infinity> Nor a room.
[23:11] <slangasek> hahaha
[23:11] <infinity> In fact, I recommend testing ISOs on Macs in the middle of corn fields.
[23:11] <ScottK> Not unless there will be excessive public displays of affection otherwise (re the room)
[23:14] <infinity> ev: Say, how many iProducts do I need to send you to make the wubi-e2fsprogs-doesn't-support-ext4 thing go away?
[23:14] <infinity> xnox: Or, since you seem to have some perverse obsession with cross-building Win32 stuff, maybe I should be asking you. :P
[23:16] <xnox> infinity: yes, you should be asking me. Let's see if I can double this up together with fix 5-cross-compiles.
[23:18] <slangasek> you cannot
[23:18] <slangasek> :P
[23:18] <infinity> Wow, e2fsprogs still uses dh_movefiles.
[23:18] <slangasek> that's a work item for cross-compiling to /real/ platforms :)
[23:18] <infinity> slangasek: He may well be able to, e2fsprogs is broken in http://people.canonical.com/~cjwatson/cross/armhf/raring/
[23:18] <slangasek> hah
[23:18] <slangasek> ok fine
[23:19] <infinity> slangasek: If he fixes it for the armhf cross case, it might Just Work for a mingw32 target.
[23:19] <infinity> (might)
[23:19] <slangasek> the converse seems more likely
[23:19] <infinity> True.
[23:21] <xnox> hah =)
[23:22] <barry> you'll pry my mbp out of my hands when i get a 1440x900 ultrabook :)
[23:22] <infinity> barry: Will 1600x900 do?
[23:22] <slangasek> infinity: ok, this cc: issue is clearly something on your end, you said "hi guys" but have only one Cc :)
[23:23] <infinity> barry: The Carbon is definitely ultrabooky.  And pretty sexy.
[23:23] <barry> infinity: it just might
[23:23] <infinity> slangasek: I mentioned this half an hour ago.
[23:23] <barry> infinity: i basically want a macbook air that's not a mac :)
[23:23] <infinity> barry: The ThinkPad X1 Carbon is pretty much exactly that.
[23:24] <infinity> barry: With the bonus of being a less crap keyboard, and a sexier cover.
[23:24] <slangasek> infinity: ah yes, missed that
[23:24] <infinity> Also, a nipple.
[23:24] <xnox> there is also a new asus ultrabook which I didn't compare to thinkpad yet.
[23:24] <barry> infinity: i'll have to try to play with on.  my last thinkpad's keyboard killed my hands :/
[23:24] <slangasek> infinity: anyway, I have a hard time believing it's mailman
[23:25] <infinity> barry: Was that the classic ThinkPad keyboard they've shipped for the last decade, or the new chicklet ones?
[23:25] <xnox> barry: surprisingly X1's keyboard is similarish to the spread out mb keyboards.
[23:25] <barry> infinity: pre-chicklet
[23:25] <infinity> barry: Well, if you're using chicklet Macs, my personal opinion is that the Lenovo chiklets are much more pleasant.
[23:25] <infinity> barry: But YMMV.
[23:26] <barry> infinity: definitely something to investigate.  thanks.  (i'm up for refresh next month)
[23:26] <infinity> I'd probably buy a Carbon tomorrow if they shipped with more RAM.
[23:26] <infinity> 8G.  Bah.
[23:26] <barry> yeah.  air max is 8g but 512 ssd i think
[23:27] <infinity> That Carbon's SSD appears to top out at 256 on the web form.
[23:27] <infinity> Then again, I don't know why I need more local storage than that (I don't).
[23:28] <barry> multitrack audio!
[23:29]  * xnox is reminded of the "WE LOVE BARRRRRY" chants during NoNameYet band debut gig.
[23:29] <barry> oh gawd
[23:30] <barry> chanting the bass players name has killed universes
[23:30] <xnox> barry: was it recoreded?
[23:30] <barry> good question for pgraner
[23:32] <slangasek> xnox: the gig, or the death of universes?
[23:33] <barry> slangasek: you wouldn't be able to hear the latter.  it's at 1 x 10 ^ (-graham's number) hz
[23:35] <xnox> slangasek: former in flac, later in 3D video (I expect something no less exiting to hitchhickers guide to the galaxy style launching space ships into stars)