[01:33] <TheDrums> stgraber: I'm guessing this isn't the once a year you fixup pastebinit?
[02:23]  * dtchen is very confused about the rejection of libfilesystem-ruby_0.5-3.1ubuntu1 (e.g., https://launchpadlibrarian.net/138047596/upload_4512415_log.txt)
[02:27] <infinity> dtchen: It's replaced by ruby-filesystem
[02:27] <dtchen> infinity: ah, thanks
[02:32] <darkxst> would it be possible to get my gnome-shell/mutter SRU for Q approved? it has been in the queue for 2 months now!
[03:11] <plars> infinity: know if anything more is going to be done on the iso size?
[03:13] <ScottK> Accepted pidgin for (probably) an SRU.  I'm not unblocking, but it'll be there if there's a respin.
[03:15] <dtchen> ScottK: thanks
[03:16] <ScottK> dtchen: No problem.  I've got the easy part of the job.
[03:32] <phillw> sot
[03:32] <phillw> ScottK: pidging?
[03:32] <phillw> 8
[03:32] <phillw> 8pidgin
[03:32] <phillw> awa,
[03:33] <phillw> back to hey
[03:33] <phillw> key board
[03:36] <phillw> sorry about that, ScottK. (04:13:07) ScottK: Accepted pidgin for (probably) an SRU.  I'm not unblocking, but it'll be there if there's a respin. as the world is being re-spun, will this arrive?
[03:36] <ScottK> I meant another one.
[03:36] <ScottK> Those respins are already in progress.
[03:37] <phillw> crikey!! I hope we do not have a respin the world after this one...
[03:39] <phillw> thus
[03:41] <phillw> Thursday is not running away. If you guys want to make a week on Friday.. the testers will no complain. :D
[03:42] <ScottK> Come one.  We've respun on Thursday before and made it.
[03:45] <phillw> ScottK: indeed we have, but is that a standard, or an exception. I was still pulling in test reports as versions were being accepted as okay to release... Possible, it is, correct it is not :)
[03:45] <ScottK> You gotta do what you gotta do.
[03:45] <ScottK> We aren't going to respin without a good reason.
[03:46] <ScottK> That's why I said "if".
[04:01] <ScottK> Don't accept jockey yet.
[04:25] <cjwatson> phillw: given bug 1080701, at least one further respin-world is likely.
[04:25] <ubot2> Launchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [Critical,Confirmed] https://launchpad.net/bugs/1080701
[04:41] <ScottK> cjwatson: The jockey upload is respin worthy for Kubuntu (all variants) only.  No rush though since another one is likely coming.
[04:43] <cjwatson> ack
[04:59] <ScottK> You might want to unblock pidgin too, not sure.  I'm off to bed.
[05:07] <ScottK> stgraber: I tried to mark all the Kubuntu images for rebuild and got " An illegal choice has been detected. Please contact the site administrator."  If that button does what it thinks, I should be able to do that, right?
[05:07] <ScottK> cjwatson: Assuming you can, would you please mark the Kubuntu images for rebuild in the ISO tracker?
[05:08]  * ScottK goes to bed (really this time).
[05:16] <cjwatson> ScottK: Done.  No ability to tell/guess why it didn't work for you, though.
[06:47] <stgraber> good morning
[06:47] <stgraber> ScottK: hmm, that's very weird. I think slangasek once reported something similar. I'll take a look at the logs see if I can spot something useful in there
[06:48] <stgraber> TheDrums: nope it's not
[06:49] <TheDrums> 'Tis a pity, think debian is broken again. :P
[06:51] <stgraber> TheDrums: well, paste.debian.net seems kinda dead indeed, but that has nothing to do with pastebinit ;)
[06:51] <TheDrums> Indeed not. :)
[06:51] <TheDrums> (DDoS provided by pastebinit! ;) )
[08:19] <smartboyhw> Release Team: When will the upgrade testcases land in http://iso.qa.ubuntu.com/qatracker/milestones/269/builds ?
[08:19] <smartboyhw> It should be just a matter of copying:)
[08:20] <stgraber> I'll do that
[08:23] <smartboyhw> stgraber, thanks \o/
[08:23]  * smartboyhw hugs stgraber 
[08:29] <psivaa> cjwatson: xnox: http://pastebin.ubuntu.com/5594979/ is the failure that i was talking about in #u-installer
[08:31] <gema> psivaa: which line has the problem?
[08:33] <psivaa> gema: error removing libgksu2-0 is the pop up on the installer
[08:34] <gema> psivaa: ack
[08:34] <psivaa> gema: if you look for Removing libgksu2-0 ... in the above paste there after some errors reported
[08:37] <stgraber> psivaa: do you still have access to that machine?
[08:39] <psivaa> stgraber: yes, that's in the lab
[08:39] <stgraber> psivaa: do you have SSH installed on it? (I have a VPN key for the lab)
[08:40] <gema> stgraber: yes
[08:41] <stgraber> ok, let me quickly setup my VPN here (reinstalled my laptop on Sunday) and I'll take a look
[08:41] <psivaa> stgraber: utah-7938-raring-amd64 is the machine in aldebaran
[08:44] <xnox> psivaa: do you have the rest of the utah logs? how big is the hard-drive?
[08:44] <stgraber> xnox: looks like a miscompile of some python module to me which then causes all the crashes, should be easy enough to confirm once I've got access to it
[08:45] <cjwatson> it's a python2.7 failure, encodings.normalize_encoding failing with AttributeError; but the code on disk looks fine; looks like either what stgraber says or data corruption copying the source file to disk
[08:45] <cjwatson> not an installer bug as such, in any case
[08:47] <stgraber> ok, so I'm on aldebaran, now to figure out how to connect to that VM :)
[08:48] <psivaa> sorry had to reboot
[08:49] <stgraber> psivaa: I'm on aldebaran though that VM (utah-7938-raring-amd64) doesn't answer on port 22, how do I get a shell in there?
[08:51] <xnox> stgraber: connect to vnc / kvm via virt-manager?
[08:51] <psivaa> stgraber: virt-manager  -c qemu+ssh://the.machine.ip/system
[08:55] <psivaa> xnox: the drive is 5G and i'll give you the rest of the logs in a sec
[09:10] <xnox> psivaa: Somehow I don't think 5GB is big enough anymore, as we peak higher in disk usage and then remove a few things.
[09:11] <stgraber> /dev/vda1       7.3G  2.7G  4.3G  39% /target
[09:12] <stgraber> cjwatson: it's not corrupted pyc files for once...
[09:13] <stgraber> I just wiped them all and still get the stacktrace
[09:15] <stgraber> oh wow, something went extremely wrong
[09:15] <cjwatson> have a look at /usr/lib/python2.7/encodings/__init__.py ?
[09:15] <stgraber> cjwatson: just did, the file sizes match but the content is full of nothing
[09:15] <stgraber> root@utah-7938-raring-amd64:/# hd /usr/lib/python2.7/encodings/__init__.py
[09:16] <stgraber> 00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
[09:16] <stgraber> *
[09:16] <stgraber> 00001642
[09:16] <stgraber> root@utah-7938-raring-amd64:/# ls -l /usr/lib/python2.7/encodings/__init__.py
[09:16] <stgraber> -rw-r--r-- 1 root root 5698 Apr 19 19:20 /usr/lib/python2.7/encodings/__init__.py
[09:16] <cjwatson> this isn't xfs is it? :-)
[09:16] <cjwatson> (to be fair I think that problem is a thing of the distant past)
[09:16] <stgraber> nope, good old ext4 ;)
[09:17] <cjwatson> default data= ?
[09:17] <stgraber> /dev/vda1 /target ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
[09:17] <cjwatson> data=ordered is the default and IIRC the sane one
[09:17] <stgraber> the __init__.py outside of /target looks good (matches the one on my laptop)
[09:18] <cjwatson> as long as it's not the crazy data=writeback
[09:18] <stgraber> and there's no error whatsoever in dmesg
[09:19] <stgraber> psivaa: was that the first time you had this issue or did you see it in previous tests too?
[09:20] <cjwatson> and is it reproducible?
[09:21] <psivaa> this is the first time i'm seeing this issue, and the second run has just finished with http://pastebin.ubuntu.com/5595062/
[09:21] <cjwatson> so you're getting a succession of different random data corruption ...
[09:21] <cjwatson> I would be inclined to suspect the host hardware
[09:22] <pgraner> psivaa, what box is that on?
[09:23] <stgraber> aldebaran
[09:23] <psivaa> yes
[09:23] <psivaa> stgraber: /var/cache/utah/iso is where the is is picked up from
[09:23] <pgraner> psivaa, thats the box we replaced the raid controller on a few weeks ago
[09:24] <psivaa> pgraner: no that's alderamin
[09:24] <stgraber> I'll stop digging into this one and will instead finish setting up my laptop to run VMs here. If it's not an hardware issue with that host, we should see it show up in standard iso testing so the more we do the better.
[09:24] <psivaa> pgraner: well alderamin was a week ago, not sure about aldebaran
[09:24] <pgraner> psivaa, prob should check with retoaded he should be online anytime now
[09:25] <psivaa> pgraner: ack
[09:25] <pgraner> stgraber, I just ran it in KVM & Virt box and no issues
[09:25] <stgraber> psivaa: the .iso looks good to me
[09:25] <stgraber> psivaa: but if the .iso was the problem we'd be seeing squashfs errors in dmesg and the file outside of /target would also be corrupted
[09:26] <stgraber> psivaa: so it looks like we're getting data corruption on the VM hdd, not from the source media
[09:26] <psivaa> stgraber: ack, strange timing though
[09:26] <stgraber> so it could be an hardware issue (though I'm not seeing anything in the host's dmesg) or some weird bug in virtio
[09:27] <psivaa> stgraber: ack, would me try and install a vm on the host manually help narrow down?
[09:30] <xnox> stgraber: well, a bug in virtio, disk emulation (sata, ide, virtio), VM write strategy. After all we don't want our kvm/qemu loosing files either.
[09:33] <stgraber> psivaa: I guess you could boot a VM from the iso, with an HDD attached (virtio disk), then try to copy a bunch of files and see how many end up being corrupted. That'd give us an idea of how common the problem is, though actually debugging it won't be easy at all and the solution may be as simple as rebooting the host...
[09:34] <psivaa> stgraber: ack
[09:35] <stgraber> the fact that we got a file of the right size containing only \0 and not some random corruption at the middle of it and didn't get any error from the host or VM kernel would suggest some kind of ext4/virtio interaction (as it's "too clean" for hardware corruption)
[09:36] <cjwatson> maybe?  not sure I have good intuition about what that might or might not cause
[09:37] <cjwatson> if the metadata write was committed properly but the data write was just dropped on the floor then you'd see that
[09:37] <ScottK> TheDrums: The machine that paste.debian.net lives on died.  It'll live again once the hardware is replaced.
[09:37] <TheDrums> ScottK: Ah, thank you for the info.
[09:38] <stgraber> cjwatson: hmm, indeed, what's surprising though is that this didn't trigger any kind of error in the VM dmesg. You'd expect ext4 to complain a bit if something like that happened.
[09:39] <xnox> fsck? =)
[09:41] <stgraber> xnox: running
[09:42] <stgraber> xnox: nothing, looks clean (just did a standard fsck.ext4 -f -v)
[09:45] <cjwatson> retoaded: let me know when you're around - would like to get a patch tested
[10:04]  * ScottK hopes someone has ping mark for the new name high on their TODO list.
[10:06] <cjwatson> in progress, so I hear
[10:07] <cjwatson> I've bumped the size limits for Ubuntu desktop
[10:08] <cjwatson> (since they were artificial anyway)
[10:08] <cjwatson> kubuntu/daily-live: raring-desktop-powerpc.iso oversized by 41590784 bytes (1115332608)
[10:08] <cjwatson> Riddell,ScottK: anything you want to do about that?  bump the limit?
[10:08] <Riddell> drop it as far as I'm concerned
[10:08] <cjwatson> the image or the limit?
[10:08] <cjwatson> ScottK was trying to get testing lined up, I thought
[10:09] <cjwatson> 23:00 <ScottK> Did we stop making the Kubuntu powerpc image on purpose?
[10:09] <cjwatson> 23:00 <ScottK> Someone's actually testing it, so it might be nice to have one less than three weeks old.
[10:09] <cjwatson> 23:00 <ScottK> (or point me to a failure log please)
[10:09] <Riddell> he does like to keep those old things going :)
[10:09] <ScottK> Riddell: We actually have a tester, so let's see how it goes.
[10:09] <Riddell> ok up to you
[10:09] <ScottK> bump the limit please.
[10:10] <smartboyhw> Riddell, ScottK and I think I was mentioned yesterday in here about the powerpc image:(
[10:10] <ScottK> Not much we can do about size.
[10:10] <cjwatson> OK - uh, let me poke a bit, the size limit isn't arch-specific right now so I'll need to fix that
[10:34] <infinity> ScottK: There are some things we can do about the size, but it might be a bit too much hassle to try to bring it down right now.
[10:42] <cjwatson> So what can we strip out of the server-ship seed to make amd64 within size?  We only need ~6MB
[10:44] <cjwatson> munin maybe?  Would take libdate-manip-perl with it
[10:46] <pgraner> Daviey, ^^^^ suggestions?
[10:46]  * jamespage takes a look
[10:47] <cjwatson> Or python-svn
[10:47] <cjwatson> quagga?
[10:47] <cjwatson> if quagga is useful to you then you have a network :)
[10:48] <cjwatson> ah, as Adam points out it might be network infrastructure, OK
[10:48] <jamespage> I was thinking quagga as well
[10:48] <cjwatson> No, Adam's right, you might need it to get your network working, and you might need to preseed it
[10:48] <jamespage> python-genshi
[10:48] <jamespage> hmm
[10:49] <cjwatson> python-genshi is tiny
[10:49] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.raring/server-ship
[10:49] <cjwatson> ^- to help prioritise things
[10:49] <infinity> Dropping munin seems like an obvious win.  I can't imagine it being the sort of thing you'd ever preseed into an install.
[10:49] <cjwatson> munin might actually be close to sufficient
[10:50] <cjwatson> if it's something you can drop
[10:50] <cjwatson> $ GET http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.raring/server-ship | grep munin | cut -d\| -f5 | numsum
[10:50] <jamespage> well I'd rather drop backuppc than munin
[10:50] <cjwatson> 4916980
[10:50] <cjwatson> $ GET http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.raring/server-ship | grep backuppc | cut -d\| -f5 | numsum
[10:50] <cjwatson> 718528
[10:51] <infinity> I was looking at it from a "what might people build into their seeds to preinstall?"... You'd think backuppc might be something you'd install in a base image, but munin not so much?  I dunno.
[10:51] <infinity> python-svn is likely not widely used, given the fact that you don't actually ship subversion.
[10:52] <jamespage> nut might be a contender
[10:53] <cjwatson> python-svn does seem like an obvious win.  It's about 1.5MB
[10:53] <cjwatson> nut's about 1.7MB
[10:54] <cjwatson> miscfiles?
[10:55] <cjwatson> I guess we might want the wordlists
[10:55] <cjwatson> openssh-blacklist*?
[10:56] <cjwatson> I dropped those to Suggests in openssh a while back - it's been long enough since that vuln
[10:56] <infinity> Pretty much nothing pulls in miscfiles, I have a hard time believing people install it intentionally except for Debian oldskoolers who know it exists.
[10:56] <infinity> It's not the most obviously cool package name.
[10:57] <jamespage> I'd +1 miscfiles
[10:57] <jamespage> and siege  as well (but that is tiny)
[10:57] <cjwatson> python-svn + miscfiles + openssh-blacklist* would be sufficient
[10:58] <cjwatson> We wouldn't need to strip anything else after that
[10:58] <stgraber> cjwatson: won't dropping openssh-blacklist in turn drop openssl-blacklist, saving a total of > 15MB? (or am I misreading the germinate output)
[10:58] <cjwatson> No
[10:58] <cjwatson> openssl-blacklist is pulled in by openssl-blacklist-extra which is seeded independently
[10:59] <cjwatson> And I think the tradeoffs for installing openssl-blacklist-extra are different
[10:59] <stgraber> ah yeah, missed that line
[11:00] <jamespage> cjwatson, works for me
[11:00]  * jamespage takes an action to do a full server seed review in the next month or so
[11:01] <xnox> jamespage: i wonder if libjs-yui3-full could be avoided in mass-region-controller, by either embedding just the bare minimal, or creating a -medium yui package.
[11:01] <xnox> jamespage: I somehow daubt that every single piece of yui is used.
[11:01] <jamespage> xnox, please don't make me cry
[11:01] <xnox> jamespage: well, maybe something for s-series to look into, to bring things back.
[11:01] <jamespage> xnox, agreed
[11:04] <cjwatson> I'll start making the seed changes for the above then
[11:04] <cjwatson> (python-svn + miscfiles + openssh-blacklist*)
[11:16] <cjwatson> rejecting live-build for a tweak, Adam will reupload
[11:18] <retoaded> cjwatson, I'm around
[11:19] <retoaded> pgraner ^^^^
[11:19] <pgraner> retoaded, thanks, cjwatson will be right with ya
[11:19] <retoaded> np
[11:20] <cjwatson> retoaded: great.  I'd like to get http://paste.ubuntu.com/5594654/ tested on a machine that fails bug 1080701
[11:20] <ubot2> Launchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [Critical,Confirmed] https://launchpad.net/bugs/1080701
[11:20] <cjwatson> retoaded: that patch won't quite apply to the live filesystem because of slightly different path names - can you deal or do you want a version with the paths mangled into shape?
[11:21] <retoaded> cjwatson, let me peek
[11:21] <cjwatson> actually why don't I just give you a mangled version anyway
[11:21] <cjwatson> retoaded: http://paste.ubuntu.com/5595274/
[11:22] <retoaded> cjwatson, ack
[11:22] <xnox> stgraber: can you add wubi test-cases back into e.g. raring-daily milestone ? we don't do disk-image installs, but I still want to follow the test-case to do old-style wubi install to verify fixes and store the test results in the iso tracker.
[11:23] <xnox> stgraber: e.g. product (wubi) same as currently in precise daily.
[11:23] <tjaalton> hrm, could someone reject my lightdm upload, it's missing depends on the new plymouth version
[11:23] <retoaded> cjwatson, let me reconnect all drives that were disconnected during testing then I'll give it a go.
[11:24] <psivaa> cjwatson: xnox: stgraber: the latest preseeded installation has passed on the same host with amd64 image.
[11:24] <cjwatson> retoaded: thanks
[11:24] <cjwatson> psivaa: oh good
[11:24] <infinity> tjaalton: Done.
[11:24] <tjaalton> infinity: thanks
[11:26] <infinity> tjaalton: Is this plymouth/lightdm thing meant to be an SRU, or are you angling for a last-minute fix?
[11:26] <tjaalton> infinity: sru
[11:26] <infinity> Kay.
[11:26] <infinity> Then I'll switch hats before I review it.
[11:27] <tjaalton> it's acked by slangasek already, I've tested it thoroughly here apart from this packaging detail :)
[11:27] <cjwatson> ScottK: unblocked pidgin
[11:27] <infinity> tjaalton: Check.
[11:27] <tjaalton> same should be applied to other *dm's too, but I'll probably leave that up to their maintainers
[11:27] <cjwatson> that's nasty enough that I'd rather take it, and it has confirmations in the bugs
[11:27] <xnox> tjaalton: are there packages anywhere? I'd like to test is on my laptop which is affected by it.
[11:27] <cjwatson> *bug
[11:28] <tjaalton> xnox: plymouth is on ubuntu-x/x-staging already, I'll push lightdm too
[11:28] <tjaalton> cjwatson: you mean my bug?
[11:28] <xnox> tjaalton: please do =)
[11:28] <cjwatson> tjaalton: no, I mean pidgin
[11:28] <tjaalton> ah, cool :)
[11:28] <stgraber> xnox: hmm, ok. I guess it'll confuse some people though as it'll link to non-existing files.
[11:29] <xnox> stgraber: hmm.. I think pgraner is trying to activate it now. Meh.... i'm tested the upgraded signed wubi.exe as is on the cd and that has disk-image installs disabled....
[11:29] <stgraber> xnox: done
[11:29] <pgraner> stgraber, thanks
[11:30] <stgraber> hmm, what? I added those to daily, not to final...
[11:31] <pgraner> stgraber, I did the final by accident, I'll remove
[11:31] <stgraber> ah, ok, it got added back to the manifest, so it then got auto-copied to Raring Final
[11:31] <pgraner> stgraber, I'll let you fix it
[11:31] <tjaalton> xnox: ok, uploaded.. should be built soonish
[11:32] <xnox> tjaalton: thanks.
[11:32] <stgraber> fixed
[11:35] <retoaded> cjwatson, with all three drives connected it appears to have resolved the problem. The installer progresses to the point where I am able to select how I want to install (overwrite, alongside, something else) and takes me to the disk layout when I select something else.
[12:17] <cjwatson> retoaded: ooooooh
[13:34] <psivaa> cjwatson: will the upcoming respin include server images as well?
[13:37] <cjwatson> psivaa: yes
[13:37] <psivaa> cjwatson: ack, thanks
[13:38] <Laney> can we have them marked on the iso tracker?
[13:39] <xnox> stgraber: thanks a lot for wubi test cases! we may have found something.
[13:48] <stgraber> cjwatson, infinity: just a quick update. I'm working with jodh on the two bugs smoser mentioned yesterday.
[14:16] <cjwatson> new wubi in place which is actually the correct revision and will pop up the right things, thanks xnox
[14:45] <cjwatson> respinning world for fix for bug 1070801
[14:45] <ubot2> Launchpad bug 1070801 in OCS Inventory: OCSReports "Can't activate packages with automatic method" [Medium,Confirmed] https://launchpad.net/bugs/1070801
[14:45] <cjwatson> er, not that
[14:45] <cjwatson> bug 1080701
[14:45] <ubot2> Launchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [Critical,Fix released] https://launchpad.net/bugs/1080701
[14:46] <cjwatson> (note part of that's in partman-auto, so applies to alternates/servers too)
[14:46] <cjwatson> hopefully this is the last ...
[14:46] <smartboyhw> cjwatson, all images?
[14:47] <cjwatson> Yeah
[14:48] <cjwatson> Unless you like partitioner hangs :)
[14:48] <cjwatson> We only just figured out the fix this morning
[15:03] <infinity> jbicha: Ouch.
[15:03] <jbicha> can we get that u-g-default-settings fix in ^ before we respin ubuntu gnome?
[15:03] <jbicha> oh, too late?
[15:03] <cjwatson> might be lucky
[15:03] <infinity> jbicha: We'll respin again if we missed the current one. :P
[15:03] <cjwatson> the builds are all racing a lock
[15:03] <infinity> jbicha: So, we'll see. :)
[15:04] <jbicha> sorry about that, I was out for 30 minutes
[15:04] <infinity> jbicha: Meh.  It happens.  At least your spins are quick.
[15:18] <stgraber> sorry for the bad timing but three different people reported a breakage caused by the recent isc-dhcp update in quantal.
[15:18] <stgraber> it looks like it's caused by some setups requiring access to a RAW socket now (likely as a result of the xen checksum offload patch)
[15:19] <stgraber> the fix is a one line apparmor change that we already had in raring (which explains why we didn't see the problem there)
[15:19] <stgraber> I'll upload the fix in a couple of minutes and would appreciate it if we could fast track that SRU as I've got no clue what kind of percentage of users we're talking about but I've got a feeling it's rather high
[15:20] <slangasek> stgraber: ok, I can push it through when it shows up
[15:25] <infinity> Nobody accept sphinxtrain until sphinxbase publishes on armhf.
[15:26] <infinity> And same for pocketsphinx.
[15:42] <stgraber> slangasek: looks like Launchpad's done diffing isc-dhcp if you want to take a look
[15:54] <slangasek> stgraber: ok, accepted
[16:11] <cjwatson> retoaded: sorry, we've had a bit of a build ordering snafu so Ubuntu desktop is delayed, but could you try the Xubuntu desktop images that just came out?  For the purposes of this kind of installer bug it should be the same
[16:12] <retoaded> cjwatson, sure
[16:12] <cjwatson> thanks
[16:38] <slangasek> cjwatson, xnox, stgraber: so there have been a number of reports coming in here at the end about the "remove the media and hit enter" message not showing up in raring.  I'm pretty sure nothing's changed in plymouth; maybe something has changed elsewhere to regress the special-case handling of getting the necessary files all loaded before unmounting? (bug #1171792, bug #1170421)
[16:38] <ubot2> Launchpad bug 1171792 in plymouth (Ubuntu) "message to remove external drive and press ENTER is hidden" [Medium,New] https://launchpad.net/bugs/1171792
[16:38] <ubot2> Launchpad bug 1170421 in plymouth (Ubuntu) "Live session shutdown "hangs" (not showing "Please remove media ..." message)" [Undecided,Confirmed] https://launchpad.net/bugs/1170421
[16:39] <stgraber> slangasek: FWIW I've seen that bug on and off since at least precise, so I doubt it's a new bug, however maybe we did something to make it more likely to happen
[16:39] <infinity> Depends on how reliably it doesn't work...
[16:39] <slangasek> hmm; I wasn't aware it was an ongoing problem, I thought it had been fixed in precise-ish with the casper file cache handling
[16:39] <cjwatson> Yeah, I've been hearing reports of that for a long time; it's true that it's fragile
[16:39] <retoaded> cjwatson, it might be a little while. my download speeds are horribly slow today.
[16:39] <cjwatson> retoaded: ok
[16:40] <cjwatson> let me know at some point so I know when I can hit the pub :)
[16:40] <cjwatson> slangasek: I wonder if plymouthd is loading something dynamically maybe?
[16:40] <retoaded> ack
[16:40] <cjwatson> I dunno, it's incredibly hard to debug
[16:40] <slangasek> cjwatson: it loads a number of things dynamically, but I thought all the things had previously been dealt with
[16:41] <cjwatson> Let me see if I can reproduce it in kvm ... although I seem to remember that not being successful in the past
[16:41] <xnox> same. here. this bug is very often easily reproduced in virtual box. As far as I remember we would drop back to tty1, yet the message is displayed in tty7. Switching to that tty1 should show it.
[16:41] <stgraber> I've noticed I have better odds of reproducing it when testing Edubuntu and running ltsp-live, but it's still a 1 every 5 times kind of thing, so it makes adding debug everywhere to track it down quite a bit of a pain
[16:41] <xnox> if we can somehow display the message across all ttys it would help, with like a Wall message.
[16:41] <cjwatson> It's supposed to be displayed in plymouth, though
[16:41] <slangasek> yes
[16:42] <cjwatson> Which is very definitely on one tty :-)
[16:42] <xnox> true.
[16:43] <cjwatson> If I can reproduce it then *maybe* I can instrument it somehow - the problem of course is that your filesystem has just gone away
[16:43] <slangasek> we do have a newer version of plymouth in raring vs. quantal, so it could be a new upstream dependency of some kind, I haven't checked
[16:44] <slangasek> cjwatson: would it be any use to instrument on a running system to find what files are mmapped?  I guess that doesn't catch files that are opened/read/closed
[16:44] <cjwatson> I think the problem is that you have to instrument some ill-defined set of processes
[16:44] <stgraber> cjwatson: yeah, last time I tried debugging that mess I ended up building a custom initrd and booting from that, so I don't need to patch the various files at every single boot
[16:45] <cjwatson> Maybe systemtap would be of use, if anyone knows it ...
[16:45] <slangasek> cjwatson: is it that ill-defined?  I thought it's just plymouthd + plymouth (client) + the shutdown script
[16:46] <cjwatson> What if it ends up waiting for udev or something - but you're probably right
[16:46] <jbicha> ok, the Ubuntu GNOME images didn't have the updated settings so I clicked the Mark for re-build button on the iso tracker
[16:47] <cjwatson> Hm, I don't have my plymouth tree here - what communication channel does plymouth -> plymouthd use?
[16:47] <cjwatson> jbicha: OK, will poke it later
[16:47] <xnox> cjwatson: just a socket as far as i remember.
[16:48] <cjwatson> But a socket where?
[16:48] <slangasek> cjwatson: mm, I thought it was an abstract unix socket
[16:48] <cjwatson> OK, as long as it's not in a directory whose contents might be swapped out
[16:48] <stgraber>     for path in $(which halt) $(which reboot) /etc/rc?.d /etc/default $(which stty) /bin/plymouth; do
[16:48] <cjwatson> Did we start using fontconfig more aggressively?
[16:48] <stgraber>         cache_path "$path"
[16:48] <stgraber>     done
[16:48] <cjwatson> I wonder if it's trying to load a font or some other text rendering thing
[16:49] <stgraber> cache_path doing a find+cat of everything it finds
[16:49] <cjwatson> kvm doesn't show plymouth properly at boot
[16:50] <cjwatson> tail of the output on tty7 is "stty: standard input: unable to perform all requested operations"  "Please remove installation media and close the tray ..."
[16:50] <cjwatson> But probably an invalid test since it's not actually showing plymouth
[16:52] <slangasek> cjwatson: confirmed that the socket is abstract
[16:52] <slangasek> cjwatson: shouldn't be using fontconfig any more aggressively than before
[16:52] <slangasek> it does use fontconfig though
[16:53] <stgraber> slangasek: does it preload the fonts or just loads them the first time it needs them?
[16:53] <slangasek> so maybe that's why it's only been working intermittently?
[16:53] <slangasek> stgraber: it uses fontconfig
[16:53] <slangasek> so $indeterminate
[16:53] <cjwatson> easy for the fonts to be out of cache, perhaps
[16:54] <slangasek> yeah; I had wondered about that previously, but in the absence of bugs coming my direction I had assumed it was dealt with
[16:55] <stgraber> so stupid question, but why can't we just show the message before ejecting the media? we're talking < 1s here so it's unlikely to make any visible difference to the user
[16:56] <stgraber> basically do plymouth message (or echo), then eject, then do the plymouth watch-keystroke (or read)
[16:56] <cjwatson> I was sort of wondering that.  Perhaps
[16:57] <slangasek> yeah, I'd had the same thought
[17:01] <xnox> how does one "eject" usb?
[17:01] <xnox> as that needs removing as well.....
[17:02] <xnox> (or you mean that well, it's not visible to the kernel / not-mounted)
[17:03] <slangasek> xnox: not sure what the question is - one ejects the USB by physically disconnecting the drive
[17:04] <slangasek> which is what the user should do, to make sure they don't get booted back into the installer
[17:05] <cjwatson> Are we putting armhf+omap4 on releases.u.c this cycle?
[17:05] <cjwatson> Adam seems to recall some debate about that
[17:05] <cjwatson> And IS could do with knowing in order to prepare cloudfront rewrites
[17:06] <slangasek> so last cycle we had desktop-armhf+omap4 on releases
[17:07] <slangasek> and this cycle we didn't release it with beta, right?
[17:07] <xnox> see ya =)
[17:08] <cjwatson> But apparently that was because of a bug that's been fixed
[17:08]  * slangasek nods
[17:09] <slangasek> so this information used to be recorded in the release manifest
[17:09] <slangasek> I'm not sure the move to iso.qa gives us that anymore
[17:09] <slangasek> stgraber: ^^ ?
[17:09] <infinity> slangasek: As a data point, we've also removed the omap4/desktop image from the website's download/arm page (on the staging site).
[17:09] <slangasek> stgraber: also, *finding* the release manifest in iso.qa is a huge pain :/
[17:10] <slangasek> infinity: why have we done that?
[17:10] <infinity> slangasek: I'm not sure there's much point in having it on releases given how close we came to dropping the image entirely.
[17:10] <slangasek> or rather, who made that decision?
[17:11] <slangasek> (that's contrary to my last suggestion on the ubuntu-release thread...)
[17:11] <infinity> slangasek: Came about from a conversation with the web team yesterday, and agreement from me, Pete, Rick... There's a mail thread about this too?  Fun.
[17:11] <slangasek> yes, there was a mail thread about this, which Amrit (web team) was Cc:ed on
[17:12] <cjwatson> also do you think we care about pushing dvd/preinstalled to cloudfront?  apparently we did for precise and not for quantal
[17:12] <slangasek> hmm, which dvd, which preinstalled?
[17:12] <cjwatson> https://pastebin.canonical.com/89790/
[17:13] <infinity> Hrm.
[17:13] <slangasek> we don't have dvd anymore, do we?
[17:13] <cjwatson> oh yeah
[17:13] <slangasek> and the only preinstalled we have this cycle is nexus7
[17:13] <cjwatson> So Ubuntu preinstalled desktop armhf+<whatever>, preinstalled server armhf+<whatever>
[17:13] <ogra_> what the heck are these ?
[17:14]  * ogra_ glares at ubuntu-12.04-preinstalled-desktop-armhf+mx5.img.gz
[17:14] <ogra_> we definitely never had such an image
 I don't want to debug precise now, just trying to check :)
[17:15] <slangasek> ogra_: infinity signed off on it ;) https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest
[17:15] <infinity> ogra_: Sure we did.
[17:15] <ogra_> a desktop mx5 ?
[17:15] <infinity> Yes.
[17:15] <cjwatson> http://cdimage.ubuntu.com/releases/precise/release/ubuntu-12.04-preinstalled-desktop-armhf+mx5.img.gz
[17:15] <plars> cjwatson: my understanding was that desktop was no longer going to be released for omap4, we have desktop on nexus7 and netboot/server on omap4 still though
[17:15] <cjwatson> begs to differ
[17:15] <plars> pgraner: ^ unless something changed since then?
[17:15] <cjwatson> plars: yeah, this isn't about "do we release it", it's about whether it's high enough traffic to push to cloudfront
[17:15] <infinity> plars: No, it's still being released, though perhaps deemphasized.
[17:15]  * ogra_ wonders who ever tested that
[17:16] <cjwatson> I'm inclined to say just the things that are on releases.u.c
[17:16] <infinity> ogra_: Jani did.
[17:16] <ogra_> oh
[17:16] <plars> ah, I see
[17:16] <cjwatson> Which would match quantal
[17:16] <cjwatson> Just want to make sure I'm telling IS the right things
[17:17] <slangasek> cjwatson: so I don't see a compelling argument for either of the nexus7 desktop or the omap4 desktop/server being given precedence over the other on releases.u.c; I expect both are going to be lower traffic than e.g. the phablet image
[17:17] <slangasek> is splitting the desktop image publishing between releases and cdimage problematic?
[17:17] <cjwatson> ok, so let's just have cloudfront == releases
[17:17] <cjwatson> slangasek: no
[17:17] <slangasek> ok
[17:17] <infinity> slangasek: No, we always did in the past.
[17:18] <infinity> (And, indeed, powerpc goes to cdimage if it gets tested and released)
[17:18] <slangasek> infinity: right, was asking on account of the armhf beta2 images that wound up in the pool but not published, wanting to make sure that wasn't a tooling problem
[17:18] <infinity> Nah, that was just pre-publishing not taking ready states into account (intentionally).
[17:18] <slangasek> cjwatson: so how would using cloudfront work wrt cdimage anyway?
[17:20] <cjwatson> same way as it did last two releases :-)
[17:20] <cjwatson> er, for precise anyway
[17:20] <cjwatson> rewrites on IS' end
[17:20] <slangasek> ah
[17:22] <slangasek> cjwatson: right, so I don't imagine these will see a huge amount of traffic... if we're trying to minimize the load on cdimage, it would probably make more sense to cloudfront some of the flavors rather than these.  So +1 from me for just doing releases.
[17:24] <stgraber> slangasek: well, the manifest is linked from the frontpage and on the builds page, but yeah, not exactly the most visible link ;) and if you intend to change it, then it's even better hidden.
[17:24] <stgraber> slangasek: http://iso.qa.ubuntu.com/qatracker/milestones/264/builds is what we had in the beta
[17:25] <stgraber> so it looks like we tested desktop armhf for the beta but didn't publish because it wasn't bootable
[17:25] <cjwatson> yeah, from my pov the only once worth this kind of special handling are by definition on releases
[17:25] <infinity> stgraber: Yeah, that's been fixed since.
[17:25] <ogra_> right
[17:26] <dannf> we're seeing a pretty serious kernel bug on calxeda highbank systems, LP: #1171582 - i've tested a workaround in finish-install, patch attached to that bug. is that something that, if approved, could still make the release?
[17:26] <ubot2> Launchpad bug 1171582 in linux (Ubuntu) "[highbank] hvc0 getty causes random hangs" [High,Incomplete] https://launchpad.net/bugs/1171582
[17:26] <stgraber> cjwatson, slangasek: want me to upload a casper with the re-ordering we discussed earlier. I don't think it's worth a respin but may be good to include if we have to respin for some other reason
[17:26] <ogra_> dannf, i saw it mentioned in the kernel team meeting
[17:26] <cjwatson> *ones
[17:27] <ogra_> i think ppisati is actively working on it
[17:27] <cjwatson> stgraber: hmm, we should probably get it into -proposed at least, yeah
[17:28] <dannf> ogra_: yes, i'm working w/ ppisati - but my understanding is that we can't get a kernel in now
[17:28] <infinity> Yeah, a new kernel at this point is definitely not going to happen.
[17:29] <dannf> i tried to find workarounds we could just document, but came up w/ nuthin.. well, nothing that doesn't involve dropping to a shell and typing magic commands
[17:31] <roaksoax> Hi! I was wondeirng that if I were to upload bug fixes that are not critical for release, would they be held in proposed for 0-day or should I file a proper SRU once raring is released?
[17:31] <ogra_> dannf, note that this fix  will likely break server installs on omap (which is also in the generic kernel(
[17:32] <ogra_> not that this is overly important i guess
[17:32] <cjwatson> version should be 2.42ubuntu1
[17:32] <retoaded> cjwatson, the xubuntu image appears to work with all disks connected; I can manage partitions during install.
[17:33] <dannf> ogra_: break?
[17:33] <dannf> or affect?
[17:33] <cjwatson> ogra_: um, do omaps have /dev/hvc*?
[17:33] <infinity> They shouldn't.
[17:33]  * retoaded will be back in about an hour
[17:33] <ogra_> dannf, well, if in a serial install no $serial_tty.conf is created i would say break
[17:33] <cjwatson> ogra_: you've misread
[17:33] <cjwatson> ogra_: the exit 0 is inserted lower than you think :)
[17:34] <ogra_> oh, ok
[17:34] <cjwatson> so with a fixed version number I'm fine with this change
[17:34] <cjwatson> retoaded: yay yay yay
[17:35] <infinity> dannf: I'll go ahead and sponsor that for you with a sane version.
[17:35] <dannf> infinity: ok, thx and to be clear, i've done no testing on omap - i don't have that hardwre
[17:36] <ogra_> dont worry ... a) i misread  and b) omap is a nice to have only
[17:37] <ogra_> supported arches surely take precedence if its an on/off decision
[17:38] <ogra_> (but in case it would have broken it there should have been a note about it somewhere)
[17:39] <dannf> yeah - i don't see how it could negatively impact omap, but i never really see how i'm about to be wrong :)
[17:39] <cjwatson> jbicha: ^- 20130423.2 has the new ubuntu-gnome-default-settings
[17:41] <jbicha> cjwatson: thanks!
[17:44] <cjwatson> finish-install unblocked too
[17:46] <infinity> stgraber: ^-- Didn't like your casper upload?
[17:47] <stgraber> infinity: right. I based that one on what was currently in the archive and not ubuntu:casper where I already had another fix staged.
[17:48] <stgraber> so I'm now preparing a new one which contains two fixes instead of one (the other fix being detection of swap on virtio, simple one line change I noticed while debugging another issue a while back).
[18:46] <dobey> hey all, can I get someone to accept rhythmbox-ubuntuone into quantal-proposed and precise-proposed please?
[18:49] <phillw> can someone please turn back on the kubuntu-ppc iso, it got dropped from 'auto build' but does now have the lubuntu-ppc team agreeable to check it out.
[18:50] <phillw> ScottK: do you still want kubuntu-ppc tested? Sorry, I should have asked you before I made the request :/
[18:53] <infinity> phillw: Already done.
[18:54] <phillw> infinity: thanks, for purely nostalgic reasons, I do care about ppc :)
[18:55] <infinity> phillw: For bonus points, we also shrunk lubuntu/ppc a fair bit.  It might fit on a CD again.
[18:55] <phillw> infinity: that would be a nice present to the guys
[18:55] <infinity> (kubuntu/ppc won't, but none of the kubuntu images fit on CDs)
[18:56] <phillw> thank you, if the lubuntu ones would, that would be amazing. Julien cannot shrink it more because the 'bug' is the number of kernels.
[18:57] <infinity> Yeah, I knocked out the e500* kernels from desktop CDs today.
[18:57] <infinity> Since they're really only wanted on server installs.
[18:58] <infinity> Compare the size of lubuntu/ppc from 20130423 to 20130423.1, you should be pleasantly surprised.
[18:59] <phillw> the old desktop / lapbook macs may be on the floor, but they are not dead  yet. If you make the iso CD sized I'll get the guys to have a whip round to buy those who managed it a beer.
[18:59] <infinity> Hrm.  We might need to do something clever for your alternate CD too.  But at least the desktop one is shrunk.
[19:01] <phillw> To be honest, my view as release manager is that we get ONE of them released. But, the testers never cease to surprise me. if the ac100 gets the nod, on lubunut we are pretty much good to go. :D
[19:03] <ogra_> phillw, did the ac100 not get one ? popey did an install today
[19:03] <ogra_> and afaik it was fine
[19:11] <vanhoof> cjwatson: infinity: ogra_: dannf: verified bug #1171582
[19:11] <ubot2> Launchpad bug 1171582 in linux (Ubuntu) "[highbank] hvc0 getty causes random hangs" [High,Incomplete] https://launchpad.net/bugs/1171582
[19:13] <infinity> vanhoof: Lovely.  We'll keep that open, since it's actually a kernel bug, but good to know the workaround works.
[19:13] <vanhoof> infinity: ack, just figured was worth a sanity check :)
[19:13] <vanhoof> infinity: thanks (dannf you too :))
[19:21] <ogra_> infinity, cjwatson .... so it seems we end up without gksu installed on desktop ... that would need a seed change i guess
[19:22] <Laney> should it be installed?
[19:22] <ogra_> gksu deps were removed from the two apps that had it on the desktop and it seems nobody added a seed entry
[19:22] <dobey> Laney: i'd say no
[19:22] <ogra_> Laney, well, pkexec doesnt really manage to fulfill the purpose
[19:22] <dobey> Laney: or at least, i'd defer to security to answer that
[19:22] <infinity> I assume it's only in the manifest as a ubiquity dependency and thus gets autoremoved at the end of the install?
[19:22] <ogra_> though people can indeed use sudo
[19:22] <Laney> right
[19:22] <ogra_> infinity, xactly
[19:22] <Laney> I don't know why it's a purpose that needs to be fulfilled by default - if you want it, you can install it?
[19:23] <ogra_> yeah
[19:23] <dobey> and that
[19:23] <ogra_> well, its a convenience for scriping
[19:23] <ogra_> *scripting
[19:23] <infinity> But yeah, pretty much any HOWTO that says "run gksu gedit /etc/foo" could s/gksu/sudo/ with the same effect.
[19:23] <dobey> Laney: it's that people are used to telling people to use it on forums and ask ubuntu and whatnot, to edit files that are owned by root. which is a generally bad thing to be doing anyway, if they don't know what they're doing enough to use sudo/vim instead
[19:25] <infinity> Honestly, I'd consider it a ubiquity bug that gksu is on the CD at all, rather than a bug that it doesn't stay installed.
[19:25] <dobey> infinity: that's what i just said in -devel :)
[19:25] <Laney> dobey: They'll get a nice message telling them to sudo apt-get install gksu
[19:25] <ogra_> infinity, yeah
[19:26] <ogra_> the prob is that we have a ton of docs referring to it
[19:26] <dobey> Laney: yeah. i don't really see any problem with it not being there
[19:26] <Laney> Why did this just happen: https://launchpad.net/ubuntu/+source/libgcrypt11/1.5.0-3ubuntu2.1/+build/3970473 ?
[19:26] <dobey> Laney: though if it was up to me, i'd probably just try to get it removed from the archive. :)
[19:26] <infinity> Laney: Magic.
[19:27] <Laney> Doesn't look like very good magic
[19:27] <jbicha> well it would be cool if gedit or nautilus would prompt to elevate privileges when needed
[19:27] <dobey> jbicha: also that
[19:27] <infinity> Laney: (I did a mass give-back and forgot to exclude armel... To avoid the pain of buildd exploding due to a lack of a chroot tarball for armel, I replaced it with a kitten jpeg)
[19:28]  * Laney downloads the chroot
[19:28] <infinity> I've already removed it.
[19:28] <Laney> No fun.
[19:28] <infinity> Oh, but it hasn't been garbage-collected from the librarian yet.
[19:28] <infinity> http://launchpadlibrarian.net/138118029/chroot-ubuntu-raring-armel.tar.bz2
[19:29] <Laney> bee-yoo-tea-fuhl
[19:30]  * Laney just WTFed that tar wouldn't bunzip it for a bit
[19:30] <infinity> Decompressing kittens is hard.
[19:31] <Laney> Time + food
[19:31] <infinity> Ahh, tar -tuna
[19:48] <slangasek> stgraber: I don't see any manifest link on the front page, fwiw
[19:49] <stgraber> slangasek: so you see the list of milestones? look in the table header "Milestones for 'Raring' series (product manifest | testsuites)"
[19:49] <stgraber> product manifest being the magic link you're looking for ;)
[19:49] <slangasek> stgraber: oh man
[19:50] <slangasek> stgraber: right, could that link please be made a link color? :)
[19:50] <stgraber> I'll raise a bug about that for the next time I try to understand Drupal's css ;)
[20:16] <plars> I suspect http://launchpad.net/bugs/1172002 is going to leave me with no swap after I reboot from this reinstall
[20:16] <ubot2> Launchpad bug 1172002 in ubiquity (Ubuntu) "Install doesn't mount encrypted swap for reinstall" [Undecided,New]
[20:19] <dobey> anyone on sru team around?
[20:23] <dobey> also, does anyone know when the EOL announcement will happen for 10.04 (desktop)/11.10?
[20:27] <phillw> dobey: the team do keep https://wiki.ubuntu.com/Releases updated but as we are really at the end of a new release, there may be a lag in asnwering personally.
[20:28] <phillw> *answering*
[20:29] <skellat> dobey: It appears May 9th was announced for both cases you inquire about.
[20:30] <stgraber> utlemming: looks like your script doesn't know about Azure yet ;)
[20:30] <utlemming> stgraber: yeah, it doesn't :) I still have to have get all that plumbed in
[20:40] <dobey> skellat: ah, where is that? i didn't see it
[20:42] <dobey> ah, on that wiki page.
[20:43] <dobey> thanks
[20:44] <dobey> phillw: ah, i wasn't looking for SRU team to answer the EOL question. i have a couple uploads that have been sat in unapproved for 2 weeks now, and want to get them accepted into proposed so i can move forward with testing and the SRU process :)
[20:54] <infinity> dobey: I announced those last month: https://lists.ubuntu.com/archives/ubuntu-announce/2013-March/thread.html
[20:57] <dobey> infinity: ah ok, thanks.
[21:23] <dobey> infinity: can you do the accepting of rhythmbox-ubuntuone into quantal-proposed and precise-proposed btw?
[21:28] <infinity> dobey: Ask me again in the morning?  Those diffs are a bit large for me to review before bed.
[21:28] <dobey> infinity: ok, thanks
[21:46] <sarnold> Hello all, jdstrand; I have prepared mysql updates for our supported releases. How shall I handle the raring package? The raring version was built for 'raring-security' rather than 'raring', in the security ppa. How shall I proceed?
[21:47] <jdstrand> sarnold: we could copy to raring-proposed, but its tuesday before release. let's just use a -2 USN after raring is released
[21:48] <jdstrand> sarnold: you can release all the others using unembargo and sis-changes with the -r option
[21:49] <sarnold> jdstrand: again with anticipating questions :) hehe
[21:51] <jdstrand> sarnold: upgrades went smoothe, right? ie, the new upstream release didn't cause any weird upgrade issues did they?
[21:52] <sarnold> jdstrand: the test failures were consistent from one to the next, and the wordpress test worked well... though I'm just now noticing that I managed to overlook the quantal build in the ppa. :(
[21:53] <jdstrand> sarnold: I was more talking about if a brand new raring server install had a 0-day conffile change or something weird
[21:54] <jdstrand> sarnold: I wasn't expecting it, but it might be a factor
[21:54] <sarnold> jdstrand: hrm, I haven't made a brand-new install of my raring vm in some time, I've just been apt-get dist-upgrading it along the way...
[21:56] <jdstrand> sarnold: right. part of our testing should be upgrade testing though. Ie, use vm-qrt or the install-packages from the QRT tarball with the current packages. then use uvt repo -e, then do 'apt-get upgrade'
[21:56] <sarnold> jdstrand: oh, yes, that worked fine. :)
[21:56] <jdstrand> yeah, then a 0-day security update in raring-security makes sense to me
[23:30] <gilir> is it possible to respin lubuntu alternate powerpc ? I removed some langpacks to make it cd sized
[23:30] <slangasek> gilir: sure.  only powerpc needed?
[23:31] <gilir> slangasek, yes
[23:31] <slangasek> running
[23:32] <gilir> thanks :-)
[23:41] <slangasek> gilir: ^^
[23:43] <ScottK> phillw: Yes.  Thanks.
[23:44] <phillw> slangasek: thanks. gilir Is it now CD  sized?
[23:44] <ScottK> infinity: I don't think there's enough to do about size on kubuntu ppc that it would ever fit on a CD.
[23:45] <phillw> ScottK: we accept that, it is not an issue.
[23:46] <gilir> phillw, lubuntu alternate powerpc is now cd sized
[23:47] <phillw> WOW !! thanks you to all who have done this :)
[23:50] <Noskcaj> is there a chance bug 1172059 will be fixed in time for release?
[23:50] <ubot2> Launchpad bug 1172059 in ubiquity (Ubuntu) "kubuntu ubiquity encryption doesn't check password" [Undecided,New] https://launchpad.net/bugs/1172059
[23:53] <smartboyhw> Noskcaj: We have people fixing, and we have testers:P
[23:53] <ScottK> smartboyhw: Who's fixing?
[23:54] <ScottK> Also a Ubiquity upload would affect all the flavors, so it's not just a Kubuntu decision.
[23:54] <smartboyhw> ScottK: ah damn it is:(
[23:54] <smartboyhw> s/is/would/
[23:55] <ScottK> So if a fix becomes available, we'll have to see.