| cjwatson | stgraber: I did an updated precise build for you, in case you're still around | 00:05 |
|---|---|---|
| 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:15 |
| 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:27 |
| 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:28 |
| stgraber | can't find one... I'll file a new one against shim so we can track that issue | 00:29 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:36 |
| 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:38 |
| slangasek | stgraber: yes, for debugging you definitely want to be using self-signed binaries :) | 00:40 |
| slangasek | (at least self-signed shim) | 00:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| stgraber | will do once I'm back to my standard desktop (currently in the middle of the precise install) | 00:44 |
| 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 | 02:58 |
| stgraber | and back to a working laptop, now let's see what was broken this time around :) | 03:10 |
| 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:12 |
| stgraber | cjwatson: installer log: http://paste.ubuntu.com/1416091/ | 03:13 |
| stgraber | cjwatson: btw, to make things simpler this time around I unplugged my internal ssd before the installation | 03:15 |
| 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:17 |
| 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 | 03:28 |
| 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:00 |
| 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:02 |
| 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:06 |
| slangasek | strange | 05:11 |
| 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:12 |
| 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:13 |
| stgraber | anyway, enough uefi fun for the evening, will wait for cjwatson to show up | 05:15 |
| 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:22 |
| * 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:26 |
| ScottK | Additionally, it doesn't appear it was accepted into quantal by a member of ubuntu-sru | 05:29 |
| slangasek | sigh | 05:29 |
| 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:30 |
| ScottK | Since infinity accepted it for one release, maybe he'll take responsiblity for getting the bug unprivate .... | 05:31 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| 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:17 |
| ScottK | OK, so removed walinuxagent and pinged the bug/uploaders. | 06:35 |
| ScottK | (to complete the record here for backscroll readers) | 06:36 |
| === doko_ is now known as doko | ||
| === yofel_ is now known as yofel | ||
| infinity | ScottK: Gah. I could have sworn walinuxwhatever used to reference a public bug. | 09:34 |
| infinity | Err, it does. | 09:35 |
| === henrix_ is now known as henrix | ||
| 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:36 |
| 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:37 |
| 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:38 |
| * 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:39 |
| 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:40 |
| xnox | infinity: the bug causes dataloss & renders machines unreachable. I'd want to see both packages restored asap. | 09:41 |
| infinity | xnox: That's no excuse for non-SRU members accepting SRUs. | 09:42 |
| 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:43 |
| xnox | infinity: what do you want to happen for quantal SRU to be re-published? | 09:44 |
| 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:46 |
| Daviey | xnox: This is something that has only been clarified recently. | 09:48 |
| infinity | Daviey: Uhm. If "recently" means "before you were an archive admin", I agree. | 09:49 |
| 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:50 |
| Daviey | infinity: erm, that isn't quite what happened.. And i'd appreciate a less sarky attitude please. | 09:51 |
| infinity | Daviey: What isn't what happened? | 09:52 |
| Daviey | infinity: you are shooting off comments, without facts. It is inappropriate. | 09:53 |
| infinity | Daviey: Which comment lacks facts? | 09:53 |
| 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:54 |
| 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:55 |
| 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:57 |
| 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. | 09:58 |
| Riddell | how do I put a block on migrating from proposed (for KDE SC)? | 10:00 |
| 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:09 |
| infinity | Riddell: (ScottK appears to be on the case) | 10:10 |
| Riddell | lovely | 10:20 |
| 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. | 10:30 |
| === mmrazik is now known as mmrazik|lunch | ||
| === infinity1 is now known as infinity | ||
| 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:32 |
| 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:36 |
| 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:38 |
| cjwatson | (a.k.a. /EFI/ on the EFI System Partition) | 11:39 |
| === mmrazik is now known as mmrazik|afk | ||
| 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:02 |
| 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:03 |
| jdstrand | I didn't know the list would do that | 13:04 |
| jdstrand | infinity: ok, sorry for the noise :) | 13:04 |
| === soren_ is now known as soren | ||
| 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:41 |
| cjwatson | psivaa: Thanks | 13:44 |
| cjwatson | xnox: ^- Do you think you could have a look at that, please? I think you've touched this code most recently | 13:45 |
| xnox | cjwatson: ok. I will look into it later today. | 13:46 |
| psivaa | xnox: cjwatson: thanks | 13:47 |
| cjwatson | xnox: Thanks | 13:52 |
| 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 | 14:28 |
| 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:46 |
| 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:48 |
| 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:49 |
| 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. | 16:50 |
| 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:58 |
| 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 | 17:59 |
| 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:11 |
| === henrix is now known as henrix_ | ||
| cjwatson | stgraber: ok, I think I'm actually free 16 to 17 - but maybe Tuesday then? | 18:17 |
| stgraber | cjwatson: I have nothing on Tuesday so that'd work a lot better :) | 18:19 |
| 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:06 |
| === hggdh_ is now known as hggdh | ||
| utlemming | infinity: on walinuxagent, I've cleared the private bug -- its now public | 19:26 |
| utlemming | infinity: all confidential information has been hidden. | 19:27 |
| infinity | utlemming: We decided that wasn't necessary in the end, but thanks anyway. :) | 19:28 |
| 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:29 |
| 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 | 19:30 |
| slangasek | infinity: hmmm my copy of your mail to u-release includes 0 CC:s | 20:07 |
| infinity | slangasek: mailman strips the CC header. | 20:10 |
| infinity | slangasek: I assure you that people got the mail. | 20:10 |
| slangasek | wat | 20:10 |
| 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:11 |
| 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:19 |
| 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:20 |
| slangasek | except for ubuntu core | 20:21 |
| 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:22 |
| 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:28 |
| 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:30 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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 | 20:38 |
| 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:12 |
| 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:14 |
| infinity | *sigh*... Has anyone yelled at seb128 about breaking ubuntu-desktop? | 22:15 |
| slangasek | infinity: er? | 22:17 |
| infinity | http://people.canonical.com/~ubuntu-archive/testing/raring_probs.html | 22:17 |
| 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:18 |
| 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:19 |
| slangasek | stgraber: ok, then please do :) | 22:21 |
| 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:22 |
| 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:23 |
| infinity | We do. Somewhere. | 22:25 |
| slangasek | https://wiki.ubuntu.com/UbuntuDevelopment/RevertLog, editing | 22:25 |
| slangasek | infinity: were there any bug reports for this? | 22:29 |
| 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:30 |
| slangasek | ah, thanks | 22:31 |
| infinity | Might even build before the publisher. | 22:31 |
| infinity | Nothing new on language-selector, but heaven knows what other random packages it could have been filed on. | 22:32 |
| infinity | And my build beat the publisher. | 22:33 |
| infinity | Yay. | 22:33 |
| slangasek | no obvious bug reports that I can see | 22:35 |
| stgraber | slangasek: http://iso.qa.ubuntu.com/qatracker/series/32/manifest | 22:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| * infinity emails the responsible parties. | 22:46 | |
| 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:51 |
| slangasek | infinity: oh; correction, the macs are not kidnapped in my direction, they are sitting on my doorstep | 22:54 |
| * slangasek fixes this | 22:54 | |
| 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:08 |
| * 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:10 | |
| 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:11 |
| 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:14 |
| xnox | infinity: yes, you should be asking me. Let's see if I can double this up together with fix 5-cross-compiles. | 23:16 |
| 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:18 |
| 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:19 |
| xnox | hah =) | 23:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| barry | multitrack audio! | 23:28 |
| * xnox is reminded of the "WE LOVE BARRRRRY" chants during NoNameYet band debut gig. | 23:29 | |
| barry | oh gawd | 23:29 |
| barry | chanting the bass players name has killed universes | 23:30 |
| xnox | barry: was it recoreded? | 23:30 |
| barry | good question for pgraner | 23:30 |
| slangasek | xnox: the gig, or the death of universes? | 23:32 |
| barry | slangasek: you wouldn't be able to hear the latter. it's at 1 x 10 ^ (-graham's number) hz | 23:33 |
| 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) | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!