[01:33] 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] dtchen: It's replaced by ruby-filesystem [02:27] infinity: ah, thanks [02:32] 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] infinity: know if anything more is going to be done on the iso size? [03:13] Accepted pidgin for (probably) an SRU. I'm not unblocking, but it'll be there if there's a respin. [03:15] ScottK: thanks [03:16] dtchen: No problem. I've got the easy part of the job. [03:32] sot [03:32] ScottK: pidging? [03:32] 8 [03:32] 8pidgin [03:32] awa, [03:33] back to hey [03:33] key board [03:36] 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] I meant another one. [03:36] Those respins are already in progress. [03:37] crikey!! I hope we do not have a respin the world after this one... [03:39] thus [03:41] Thursday is not running away. If you guys want to make a week on Friday.. the testers will no complain. :D [03:42] Come one. We've respun on Thursday before and made it. [03:45] 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] You gotta do what you gotta do. [03:45] We aren't going to respin without a good reason. [03:46] That's why I said "if". [04:01] Don't accept jockey yet. [04:25] phillw: given bug 1080701, at least one further respin-world is likely. [04:25] 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] cjwatson: The jockey upload is respin worthy for Kubuntu (all variants) only. No rush though since another one is likely coming. [04:43] ack === rsalveti_ is now known as rsalveti [04:59] You might want to unblock pidgin too, not sure. I'm off to bed. [05:07] 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] 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] ScottK: Done. No ability to tell/guess why it didn't work for you, though. [06:47] good morning [06:47] 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] TheDrums: nope it's not [06:49] 'Tis a pity, think debian is broken again. :P [06:51] TheDrums: well, paste.debian.net seems kinda dead indeed, but that has nothing to do with pastebinit ;) [06:51] Indeed not. :) [06:51] (DDoS provided by pastebinit! ;) ) === brendand_ is now known as brendand [08:19] Release Team: When will the upgrade testcases land in http://iso.qa.ubuntu.com/qatracker/milestones/269/builds ? [08:19] It should be just a matter of copying:) [08:20] I'll do that [08:23] stgraber, thanks \o/ [08:23] * smartboyhw hugs stgraber [08:29] cjwatson: xnox: http://pastebin.ubuntu.com/5594979/ is the failure that i was talking about in #u-installer [08:31] psivaa: which line has the problem? [08:33] gema: error removing libgksu2-0 is the pop up on the installer [08:34] psivaa: ack [08:34] gema: if you look for Removing libgksu2-0 ... in the above paste there after some errors reported [08:37] psivaa: do you still have access to that machine? [08:39] stgraber: yes, that's in the lab [08:39] psivaa: do you have SSH installed on it? (I have a VPN key for the lab) [08:40] stgraber: yes [08:41] ok, let me quickly setup my VPN here (reinstalled my laptop on Sunday) and I'll take a look [08:41] stgraber: utah-7938-raring-amd64 is the machine in aldebaran [08:44] psivaa: do you have the rest of the utah logs? how big is the hard-drive? [08:44] 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] 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] not an installer bug as such, in any case [08:47] ok, so I'm on aldebaran, now to figure out how to connect to that VM :) [08:48] sorry had to reboot [08:49] 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] stgraber: connect to vnc / kvm via virt-manager? [08:51] stgraber: virt-manager -c qemu+ssh://the.machine.ip/system [08:55] xnox: the drive is 5G and i'll give you the rest of the logs in a sec [09:10] 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] /dev/vda1 7.3G 2.7G 4.3G 39% /target [09:12] cjwatson: it's not corrupted pyc files for once... [09:13] I just wiped them all and still get the stacktrace [09:15] oh wow, something went extremely wrong [09:15] have a look at /usr/lib/python2.7/encodings/__init__.py ? [09:15] cjwatson: just did, the file sizes match but the content is full of nothing [09:15] root@utah-7938-raring-amd64:/# hd /usr/lib/python2.7/encodings/__init__.py [09:16] 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [09:16] * [09:16] 00001642 [09:16] root@utah-7938-raring-amd64:/# ls -l /usr/lib/python2.7/encodings/__init__.py [09:16] -rw-r--r-- 1 root root 5698 Apr 19 19:20 /usr/lib/python2.7/encodings/__init__.py [09:16] this isn't xfs is it? :-) [09:16] (to be fair I think that problem is a thing of the distant past) [09:16] nope, good old ext4 ;) [09:17] default data= ? [09:17] /dev/vda1 /target ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 [09:17] data=ordered is the default and IIRC the sane one [09:17] the __init__.py outside of /target looks good (matches the one on my laptop) [09:18] as long as it's not the crazy data=writeback [09:18] and there's no error whatsoever in dmesg [09:19] psivaa: was that the first time you had this issue or did you see it in previous tests too? [09:20] and is it reproducible? [09:21] 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] so you're getting a succession of different random data corruption ... [09:21] I would be inclined to suspect the host hardware [09:22] psivaa, what box is that on? [09:23] aldebaran [09:23] yes [09:23] stgraber: /var/cache/utah/iso is where the is is picked up from [09:23] psivaa, thats the box we replaced the raid controller on a few weeks ago [09:24] pgraner: no that's alderamin [09:24] 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] pgraner: well alderamin was a week ago, not sure about aldebaran [09:24] psivaa, prob should check with retoaded he should be online anytime now [09:25] pgraner: ack [09:25] stgraber, I just ran it in KVM & Virt box and no issues [09:25] psivaa: the .iso looks good to me [09:25] 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] psivaa: so it looks like we're getting data corruption on the VM hdd, not from the source media [09:26] stgraber: ack, strange timing though [09:26] 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] stgraber: ack, would me try and install a vm on the host manually help narrow down? [09:30] 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] 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] stgraber: ack [09:35] 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] maybe? not sure I have good intuition about what that might or might not cause [09:37] if the metadata write was committed properly but the data write was just dropped on the floor then you'd see that [09:37] TheDrums: The machine that paste.debian.net lives on died. It'll live again once the hardware is replaced. [09:37] ScottK: Ah, thank you for the info. [09:38] 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] fsck? =) [09:41] xnox: running [09:42] xnox: nothing, looks clean (just did a standard fsck.ext4 -f -v) [09:45] retoaded: let me know when you're around - would like to get a patch tested === ara is now known as Guest91539 [10:04] * ScottK hopes someone has ping mark for the new name high on their TODO list. [10:06] in progress, so I hear [10:07] I've bumped the size limits for Ubuntu desktop [10:08] (since they were artificial anyway) [10:08] kubuntu/daily-live: raring-desktop-powerpc.iso oversized by 41590784 bytes (1115332608) [10:08] Riddell,ScottK: anything you want to do about that? bump the limit? [10:08] drop it as far as I'm concerned [10:08] the image or the limit? [10:08] ScottK was trying to get testing lined up, I thought [10:09] 23:00 Did we stop making the Kubuntu powerpc image on purpose? [10:09] 23:00 Someone's actually testing it, so it might be nice to have one less than three weeks old. [10:09] 23:00 (or point me to a failure log please) [10:09] he does like to keep those old things going :) [10:09] Riddell: We actually have a tester, so let's see how it goes. [10:09] ok up to you [10:09] bump the limit please. [10:10] Riddell, ScottK and I think I was mentioned yesterday in here about the powerpc image:( [10:10] Not much we can do about size. [10:10] 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] 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] So what can we strip out of the server-ship seed to make amd64 within size? We only need ~6MB [10:44] munin maybe? Would take libdate-manip-perl with it [10:46] Daviey, ^^^^ suggestions? [10:46] * jamespage takes a look [10:47] Or python-svn [10:47] quagga? [10:47] if quagga is useful to you then you have a network :) [10:48] ah, as Adam points out it might be network infrastructure, OK [10:48] I was thinking quagga as well [10:48] No, Adam's right, you might need it to get your network working, and you might need to preseed it [10:48] python-genshi [10:48] hmm [10:49] python-genshi is tiny [10:49] http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.raring/server-ship [10:49] ^- to help prioritise things [10:49] 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] munin might actually be close to sufficient [10:50] if it's something you can drop [10:50] $ GET http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.raring/server-ship | grep munin | cut -d\| -f5 | numsum [10:50] well I'd rather drop backuppc than munin [10:50] 4916980 [10:50] $ GET http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.raring/server-ship | grep backuppc | cut -d\| -f5 | numsum [10:50] 718528 [10:51] 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] python-svn is likely not widely used, given the fact that you don't actually ship subversion. [10:52] nut might be a contender [10:53] python-svn does seem like an obvious win. It's about 1.5MB [10:53] nut's about 1.7MB [10:54] miscfiles? [10:55] I guess we might want the wordlists [10:55] openssh-blacklist*? [10:56] I dropped those to Suggests in openssh a while back - it's been long enough since that vuln [10:56] 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] It's not the most obviously cool package name. [10:57] I'd +1 miscfiles [10:57] and siege as well (but that is tiny) [10:57] python-svn + miscfiles + openssh-blacklist* would be sufficient [10:58] We wouldn't need to strip anything else after that [10:58] 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] No [10:58] openssl-blacklist is pulled in by openssl-blacklist-extra which is seeded independently [10:59] And I think the tradeoffs for installing openssl-blacklist-extra are different [10:59] ah yeah, missed that line [11:00] 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] 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] jamespage: I somehow daubt that every single piece of yui is used. [11:01] xnox, please don't make me cry [11:01] jamespage: well, maybe something for s-series to look into, to bring things back. [11:01] xnox, agreed [11:04] I'll start making the seed changes for the above then [11:04] (python-svn + miscfiles + openssh-blacklist*) === mmrazik is now known as mmrazik|afk [11:16] rejecting live-build for a tweak, Adam will reupload [11:18] cjwatson, I'm around [11:19] pgraner ^^^^ [11:19] retoaded, thanks, cjwatson will be right with ya [11:19] np [11:20] retoaded: great. I'd like to get http://paste.ubuntu.com/5594654/ tested on a machine that fails bug 1080701 [11:20] 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] 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] cjwatson, let me peek [11:21] actually why don't I just give you a mangled version anyway [11:21] retoaded: http://paste.ubuntu.com/5595274/ [11:22] cjwatson, ack [11:22] 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] stgraber: e.g. product (wubi) same as currently in precise daily. [11:23] hrm, could someone reject my lightdm upload, it's missing depends on the new plymouth version [11:23] cjwatson, let me reconnect all drives that were disconnected during testing then I'll give it a go. [11:24] cjwatson: xnox: stgraber: the latest preseeded installation has passed on the same host with amd64 image. [11:24] retoaded: thanks [11:24] psivaa: oh good [11:24] tjaalton: Done. [11:24] infinity: thanks [11:26] tjaalton: Is this plymouth/lightdm thing meant to be an SRU, or are you angling for a last-minute fix? [11:26] infinity: sru [11:26] Kay. [11:26] Then I'll switch hats before I review it. [11:27] it's acked by slangasek already, I've tested it thoroughly here apart from this packaging detail :) [11:27] ScottK: unblocked pidgin [11:27] tjaalton: Check. [11:27] same should be applied to other *dm's too, but I'll probably leave that up to their maintainers [11:27] that's nasty enough that I'd rather take it, and it has confirmations in the bugs [11:27] tjaalton: are there packages anywhere? I'd like to test is on my laptop which is affected by it. [11:27] *bug [11:28] xnox: plymouth is on ubuntu-x/x-staging already, I'll push lightdm too === JackYu_ is now known as JackYu [11:28] cjwatson: you mean my bug? [11:28] tjaalton: please do =) [11:28] tjaalton: no, I mean pidgin [11:28] ah, cool :) [11:28] xnox: hmm, ok. I guess it'll confuse some people though as it'll link to non-existing files. [11:29] 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] xnox: done [11:29] stgraber, thanks [11:30] hmm, what? I added those to daily, not to final... [11:31] stgraber, I did the final by accident, I'll remove [11:31] ah, ok, it got added back to the manifest, so it then got auto-copied to Raring Final [11:31] stgraber, I'll let you fix it [11:31] xnox: ok, uploaded.. should be built soonish [11:32] tjaalton: thanks. [11:32] fixed [11:35] 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. === highvolt1ge is now known as highvoltage === mmrazik|afk is now known as mmrazik [12:17] retoaded: ooooooh === highvolt1ge is now known as highvoltage [13:34] cjwatson: will the upcoming respin include server images as well? [13:37] psivaa: yes [13:37] cjwatson: ack, thanks [13:38] can we have them marked on the iso tracker? [13:39] stgraber: thanks a lot for wubi test cases! we may have found something. [13:48] cjwatson, infinity: just a quick update. I'm working with jodh on the two bugs smoser mentioned yesterday. === jbicha_ is now known as jbicha [14:16] new wubi in place which is actually the correct revision and will pop up the right things, thanks xnox [14:45] respinning world for fix for bug 1070801 [14:45] Launchpad bug 1070801 in OCS Inventory: OCSReports "Can't activate packages with automatic method" [Medium,Confirmed] https://launchpad.net/bugs/1070801 [14:45] er, not that [14:45] bug 1080701 [14:45] 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] (note part of that's in partman-auto, so applies to alternates/servers too) [14:46] hopefully this is the last ... [14:46] cjwatson, all images? [14:47] Yeah [14:48] Unless you like partitioner hangs :) [14:48] We only just figured out the fix this morning === chuck__ is now known as zul [15:03] jbicha: Ouch. [15:03] can we get that u-g-default-settings fix in ^ before we respin ubuntu gnome? [15:03] oh, too late? [15:03] might be lucky [15:03] jbicha: We'll respin again if we missed the current one. :P [15:03] the builds are all racing a lock [15:03] jbicha: So, we'll see. :) [15:04] sorry about that, I was out for 30 minutes [15:04] jbicha: Meh. It happens. At least your spins are quick. === rickspencer3_ is now known as rickspencer3 [15:18] sorry for the bad timing but three different people reported a breakage caused by the recent isc-dhcp update in quantal. [15:18] 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] 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] 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] stgraber: ok, I can push it through when it shows up [15:25] Nobody accept sphinxtrain until sphinxbase publishes on armhf. [15:26] And same for pocketsphinx. [15:42] slangasek: looks like Launchpad's done diffing isc-dhcp if you want to take a look [15:54] stgraber: ok, accepted === doko_ is now known as doko [16:11] 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] cjwatson, sure === Guest92449 is now known as balloons [16:12] thanks [16:38] 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] 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] 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] 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] Depends on how reliably it doesn't work... [16:39] 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] Yeah, I've been hearing reports of that for a long time; it's true that it's fragile [16:39] cjwatson, it might be a little while. my download speeds are horribly slow today. [16:39] retoaded: ok [16:40] let me know at some point so I know when I can hit the pub :) [16:40] slangasek: I wonder if plymouthd is loading something dynamically maybe? [16:40] ack [16:40] I dunno, it's incredibly hard to debug [16:40] cjwatson: it loads a number of things dynamically, but I thought all the things had previously been dealt with [16:41] Let me see if I can reproduce it in kvm ... although I seem to remember that not being successful in the past [16:41] 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] 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] if we can somehow display the message across all ttys it would help, with like a Wall message. [16:41] It's supposed to be displayed in plymouth, though [16:41] yes [16:42] Which is very definitely on one tty :-) [16:42] true. [16:43] 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] 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] 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] I think the problem is that you have to instrument some ill-defined set of processes [16:44] 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] Maybe systemtap would be of use, if anyone knows it ... [16:45] cjwatson: is it that ill-defined? I thought it's just plymouthd + plymouth (client) + the shutdown script [16:46] What if it ends up waiting for udev or something - but you're probably right [16:46] 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] Hm, I don't have my plymouth tree here - what communication channel does plymouth -> plymouthd use? [16:47] jbicha: OK, will poke it later [16:47] cjwatson: just a socket as far as i remember. [16:48] But a socket where? [16:48] cjwatson: mm, I thought it was an abstract unix socket [16:48] OK, as long as it's not in a directory whose contents might be swapped out [16:48] for path in $(which halt) $(which reboot) /etc/rc?.d /etc/default $(which stty) /bin/plymouth; do [16:48] Did we start using fontconfig more aggressively? [16:48] cache_path "$path" [16:48] done [16:48] I wonder if it's trying to load a font or some other text rendering thing [16:49] cache_path doing a find+cat of everything it finds [16:49] kvm doesn't show plymouth properly at boot [16:50] 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] But probably an invalid test since it's not actually showing plymouth [16:52] cjwatson: confirmed that the socket is abstract [16:52] cjwatson: shouldn't be using fontconfig any more aggressively than before [16:52] it does use fontconfig though [16:53] slangasek: does it preload the fonts or just loads them the first time it needs them? [16:53] so maybe that's why it's only been working intermittently? [16:53] stgraber: it uses fontconfig [16:53] so $indeterminate [16:53] easy for the fonts to be out of cache, perhaps [16:54] 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] 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] basically do plymouth message (or echo), then eject, then do the plymouth watch-keystroke (or read) [16:56] I was sort of wondering that. Perhaps [16:57] yeah, I'd had the same thought [17:01] how does one "eject" usb? [17:01] as that needs removing as well..... [17:02] (or you mean that well, it's not visible to the kernel / not-mounted) [17:03] xnox: not sure what the question is - one ejects the USB by physically disconnecting the drive [17:04] which is what the user should do, to make sure they don't get booted back into the installer [17:05] Are we putting armhf+omap4 on releases.u.c this cycle? [17:05] Adam seems to recall some debate about that [17:05] And IS could do with knowing in order to prepare cloudfront rewrites [17:06] so last cycle we had desktop-armhf+omap4 on releases [17:07] and this cycle we didn't release it with beta, right? [17:07] see ya =) [17:08] But apparently that was because of a bug that's been fixed [17:08] * slangasek nods [17:09] so this information used to be recorded in the release manifest [17:09] I'm not sure the move to iso.qa gives us that anymore [17:09] stgraber: ^^ ? [17:09] 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] stgraber: also, *finding* the release manifest in iso.qa is a huge pain :/ [17:10] infinity: why have we done that? [17:10] 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] or rather, who made that decision? [17:11] (that's contrary to my last suggestion on the ubuntu-release thread...) [17:11] 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] yes, there was a mail thread about this, which Amrit (web team) was Cc:ed on [17:12] also do you think we care about pushing dvd/preinstalled to cloudfront? apparently we did for precise and not for quantal [17:12] hmm, which dvd, which preinstalled? [17:12] https://pastebin.canonical.com/89790/ [17:13] Hrm. [17:13] we don't have dvd anymore, do we? [17:13] oh yeah [17:13] and the only preinstalled we have this cycle is nexus7 [17:13] So Ubuntu preinstalled desktop armhf+, preinstalled server armhf+ [17:13] what the heck are these ? [17:14] * ogra_ glares at ubuntu-12.04-preinstalled-desktop-armhf+mx5.img.gz [17:14] we definitely never had such an image [17:14] I don't want to debug precise now, just trying to check :) [17:15] ogra_: infinity signed off on it ;) https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest [17:15] ogra_: Sure we did. [17:15] a desktop mx5 ? [17:15] Yes. [17:15] http://cdimage.ubuntu.com/releases/precise/release/ubuntu-12.04-preinstalled-desktop-armhf+mx5.img.gz [17:15] 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] begs to differ [17:15] pgraner: ^ unless something changed since then? [17:15] 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] plars: No, it's still being released, though perhaps deemphasized. [17:15] * ogra_ wonders who ever tested that [17:16] I'm inclined to say just the things that are on releases.u.c [17:16] ogra_: Jani did. [17:16] oh [17:16] ah, I see [17:16] Which would match quantal [17:16] Just want to make sure I'm telling IS the right things [17:17] 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 === mmrazik is now known as mmrazik|afk [17:17] is splitting the desktop image publishing between releases and cdimage problematic? [17:17] ok, so let's just have cloudfront == releases [17:17]