[01:14] uh? [01:14] you're just assuming they won't work, infinity ? [01:35] wxl: I know they don't work. :P [01:35] i figured as such [01:35] wxl: I fiddled with amd64 a bit to see if I could sort it out, tested, still broken, and don't have the time to fix it before tomorrow. [01:37] wxl: But, like I said, the target audience for alternate ISOs and HWE stacks are almost at polar opposites, so I don't think it's a huge loss, just a bit of a personal annoyance that I didn't have the time to figure out how to make it go. [01:38] it's all good infinity [01:38] infinity: if you want to look at why maybe check out bug 1417918 [01:38] bug 1417918 in debian-installer (Ubuntu) "installation step failed - Select and install software" [Undecided,Confirmed] https://launchpad.net/bugs/1417918 [01:38] oh, shiny, a d-i bug just for me ;) [01:39] hahahah have fun cyphermox :) [01:39] ahaha [01:39] check out the syslog [01:39] It's not a d-i bug. [01:39] * cyphermox is still high on adrenaline. [01:39] it's clearly an issue with dpkg [01:39] wxl: Dude, I was testing locally, I've seen the issue first hand. [01:39] It's not a dpkg or apt issue either. [01:39] well i don't mean a bug in dpkg [01:39] but a bug with the installation [01:40] so it's an issue with tasks or seeds or some other bs :) [01:40] There seems to be an issue with non-HWE stuff being installed before the desktop task is selected. [01:40] oh my [01:40] But I don't have the time to try to unwind what's going on there. [01:40] But yes, it's ultimately going to be a seed/task issue, and maybe also a preseed issue. [01:41] infinity: do you have syslog too, or is the one on the bug good enough? [01:41] cyphermox: I didn't save mine. [01:42] ok [01:42] infinity: i owe you a beer. thanks for the hard work. [01:42] heh, it looks like fun. [01:42] cyphermox: Mine looks a lot like that one, though. [01:44] cyphermox: The curious bit is that if you chroot into /target/, some *mesa* packages (non-HWE) are already installed, though I don't see them getting installed in syslog. [01:44] cyphermox: So, a bit hard to track down why they're there before the desktop install happens (and fails) [01:45] copied from the live filesystem? [01:45] (just guessing) [01:45] What live filesystem? [01:45] This is d-i. [01:45] oh, of course [01:45] but as I recall there is still a live fs now no? [01:46] Though, I was tired and grumpy, maybe they were ^i., not ^ii... [01:46] As in, selected for install, but not installed. [01:46] that's why base-installer has some weird live fs image preseed [01:46] cyphermox: Only the server CD uses live-installer, other alternates (of which lubuntu is the only one left) use base-installer. [01:46] what iso was this? [01:47] lubuntu-alternate-trusty-amd64 was my guinea pig. [01:47] ok [01:47] are you already looking into it, or can I start looking to let you worry about other things? [01:47] Honestly, I really want to talk lubuntu out of shipping the alternates. It's not a codepath we maintain well anymore, and they don't maintain it for us either. [01:48] cyphermox: I'm giving up and telling them they can't have alternates for the point release. If you really want to waste an evening figuring out how to fix it, be my guest, but don't make anyone any promises. [01:48] I wasn't going to make promises, I know better [01:48] i don't think we can avoid not having alternates [01:49] lubuntu is a strange case, as the targets are often old computers [01:49] there are other issues with netboot/mini.iso i hadn't really considered [01:49] wxl: I think the better option is a text-based ubiquity that doesn't involve the X overhead. [01:49] our only hope is a text-only frontend to ubiquity [01:49] great minds think alike :) [01:49] infinity: unfortunately, i don't know if i can implement that myself [01:50] i've asked the server team for some help [01:50] no response yet :/ [01:50] wxl: Though, the boot-to-ubiquity option solves most concerns. Maybe only the ubuntu images have that? [01:50] whatcha mean boot-to-ubiquity? [01:50] like don't go live before installing? [01:50] Install, rather than Try and [01:50] wxl: Cause if you can't run a minimal X and just ubiquity (no desktop, etc), then you can't run LXDE either, let's be honest. [01:50] wxl: Yes, boot to install, instead of try-then-install. [01:51] infinity: yeah we have that [01:51] wxl: That should boot to a minimal X environment with just ubiquity running. [01:51] infinity: but even still it seems to require more memory than lxde does [01:51] wxl: And really, if you can't run JUST ubiquity and X, how can you run a full desktop (even a lightweight one) and, say, a web browser? [01:51] we only need like 128-256mb to run lxde [01:52] you can run a browser [01:52] it's just stupid slow :) [01:52] ubiquity outright freezes if you don't meet its memory requirements [01:52] wxl: just ubiquity and ubiquity-dm takes more memory than lxde? [01:52] Anyhow, I think the right path is to explore slimming down the installer if we can. [01:52] cyphermox: seems to [01:53] ubiquity-dm could be a bit of a hog. An lxde variant could solve that. [01:53] infinity: i agree. we just need (at minimum) some stakeholders, if not people to DO the work :) [01:53] wxl: that ought to be fixable by editing ubiquity-dm. maybe it's not doing quite the right thing to bring up the session for lubuntu [01:53] cyphermox: infinity: i still think text only would be ideal. then we could get server away from d-i, too [01:53] that way ALL of us would share the same problems [01:53] heh.. [01:53] well [01:54] with the installer, cyphermox :) [01:54] d-i tends to work ;) [01:54] mmmmm [01:54] i don't know if that's 100% been my experience :) [01:54] wxl: Server is fine with what it has, really. It's d-i in conjunction with complex and weird desktop use-cases that explodes a bit oddly at times. [01:54] wxl: but hey, if you want to implement a text-only frontend for ubiquity, you're free to play with it. There's already a debconf frontend so it can't be missing all that much [01:54] And, to be honest, "real" server admins never use the CD. [01:55] heheh [01:55] so what's ubiquity-dm [01:55] ? [01:55] !info ubiquity-dm [01:55] derp [01:55] Package ubiquity-dm does not exist in utopic [01:55] mostly a script that starts key parts of the session apps for whatever release [01:55] cyphermox: I think what the debconf frontend is missing is a sane UI (or any UI?) for the partitioner, last I looked. [01:55] cyphermox: Which is, of course, the hardest part to get right. [01:56] infinity: right [01:56] well i guess i could look deeper and see what i might be able to figure out [01:56] !find ubiquity-dm [01:56] or just preseed it ;) [01:56] File ubiquity-dm found in ubiquity [01:56] wxl: ubiquity-dm is a script in ubiquity\ [01:56] under bin/ IIRC [01:58] alrighty [01:58] hey cjwatson is the maintainer. i'll just tell him to fix it XD [01:59] wxl: Not anymore. [01:59] you might be surprised at the result... or I'll be [01:59] infinity: i know, i was kidding. [01:59] ubiquity-dm appears to be trying to do lxde-ish things correctly already. [02:00] It may well just be that ubiquity itself is a bit too chubby. [02:00] Writing installers in python is handy, but not exactly memory-efficient. [02:00] But there could also be obvious bits that could be slimmed down with some effort. [02:00] i'll play with this and see what i can figure out [02:00] Profiling python isn't my forte though, just complaining about it. [02:01] that's usually the case, infinity :) [02:01] I'd rewrite it in C if everyone involved wouldn't shoot me for doing it. [02:01] oh man [02:01] that would be like nuclear [02:05] Thanks everyone for bringing us 14.04.2 :-) I've installed the HWE bits already and Tropico 5 finally works on my older AMD card. I should probably check if they have fixed ETS2 as well, that was an issue when I uninstalled catalyst some time ago. :-) Anyway, thanks & good night! [02:11] Ah? Seems to me like ubiquity in c could be nice, just a time-consuming endeavor [02:11] * wxl starts rewriting ubiquity in common lisp [02:11] Redoing or dropping all these hacks [02:12] cyphermox: It doesn't lend well to rapid fixes or new features, which is obviously why it wasn't done in C, but it sure would be quicker and smaller. :/ [02:12] wxl: there is definitely some room for improvement though already, so if you have any branches to review I'll be happy to help [02:12] seriously, though, i'll see what i can do [02:14] And otherwise I'll see about making some large cleanups as well, but I suspect it won't be for vivid, it's already busy enough for me to get into the hang of things with the bugs right now, and FF being right around the corner [02:14] ypwong: Not sure if you noticed, but we had to respin all the trusty ISOs for another couple of bugs. If you guys could re-test kylin (quick smoketesting to make sure the images are still sane), that would be lovely. [02:16] * infinity goes to take a beer and video game break. [02:20] * elfy will one day be in the same place as infinity and will slide him a beer ... [02:20] Riddell: ping :) [02:41] we have reached the age of a the omni-tz elfy [02:41] yea ... [02:41] holiday week and what did I do? [02:42] really late image tests for someone else ... [02:45] dedicated individual [02:48] read that as maniac ... [02:48] :D [04:32] infinity: FYI due to sucky Internet here, I'm about 10 hours away from getting the Edubuntu candidate images downloaded on my laptop, so unless highvoltage can spend some time doing the testing, Edubuntu will only get test results pretty late tomorrow (due to me being on the west coast at the moment) [05:12] stgraber: hmm, I tested Tuesday night's one and marked it as ready, but it seems cleared out on the tracker [05:14] hi all, I see the qtcreator-plugin-ubuntu and the phablet-tools being blocked like this -> https://jenkins.qa.ubuntu.com/job/vivid-adt-qtcreator-plugin-ubuntu/lastBuild/ARCH=amd64,label=adt/console looks like an infrastructure issue [05:14] Could anybody here help me? [05:40] highvoltage: I had to respin for a couple of bugs. Re-testing should really just be a boot/install/reboot smoketest to make sure the image didn't somehow implode. [05:41] bzoltan_: That's not an infrastructure issue, it's a broken package. [05:41] infinity: I see, and how can I see what is broken there? [05:41] bzoltan_: Oh, a broken package that was deleted from proposed for being so broken. [05:42] bzoltan_: So, someone just needs to retry those tests for you. [05:42] infinity: who could do that? [05:43] bzoltan_: I could if I was home. pitti or jibel certainly can, when they're around. [05:43] infinity: Thank you, I will check with them. Enjoy not being at home :) [07:07] well 2/3 lubuntus done [07:07] now to start a fire under ppc folks grr [07:07] server need help? [07:09] infinity, Ubuntu GNOME images seem ready, won't mark them us such, so people keep testing [07:09] so just go ahead, since I won't likely be awake when you are doing the releases! [07:10] congrats darkxst :) [07:11] wxl, what for? think we got lucky with this one [07:12] that's what i mean! [07:12] wxl, right [07:14] darkxst, I'll be around so no worries [07:14] don't mark them as ready yet please, darkxst so we get more testing :) [07:16] darkxst, I have bad night so in case I will sleep early, I will try to wake up early and do the needful so no worries about the release, etc etc [07:20] amjjawad, isnt that what I just said! [07:20] darkxst, and I was confirming it! === \b is now known as benonsoftware [08:20] darkxst: Good to hear. I won't be releasing until tomorrow afternoon (my time), so plenty of time for testing, but I'm also not going to respin or retract images for anything but dire bugs, so pretty sure this is what we're shipping. [08:21] infinity, thanks for all your hard work, you and everyone else :) but may I know what is your time zone, please? so I can get things ready on time :) [08:22] amjjawad: -0700 ... You have plenty of time. [08:22] amjjawad: It's 1:22am now, and I'm heading to bed. [08:23] I'm from the future (+11GMT) so indeed, that's plenty of time :) good night and thanks for everything :) [08:23] amjjawad: Please send me winning lottery numbers, thx. [08:23] infinity, will sure do :P [08:40] infinity, thanks, was just saying so you know they ready, though sounds like amjjawad will stay up anyway [08:43] infinity, I'm not very good at responding to are your images ready yet pings when I am asleep ;) [09:47] elfy: you pung? [09:57] davmor2, if you find 10 min, can you try an OEM installation. The session didn't start on first boot, immediately after the end user setup. [09:58] jibel: will do [10:36] Riddell: I did :) do you have a moment to spare me in PM ? [10:43] davmor2, and again, this time on i386, on first boot to prepare for end user, unity session fails to start [10:43] no compiz [10:43] jibel: I have i386 install for the oem bit now will reboot it in a second [10:52] jibel: I'm still not getting the password box on hw till I reboot again, I do have a desktop but I did have to reboot to get the password box [10:52] davmor2, actually the live session doesn't even start on i386 [10:52] davmor2, it's on qemu, can you try on HW? [10:52] elfy: ok [10:52] jibel: let me check I have the right iso [10:53] amd64 is OK [10:56] jibel: this is i386 [10:56] jibel: I'll try a live session 1 second [11:00] jibel: I have the live cd up and the iso image md5sum matches the one in current [11:00] live session even [11:00] davmor2, yeah, it seems to be a qemu only problem [11:01] jibel: I did have a crash file for the greeter though so I might see if I can add that to the bug report [11:26] Edubuntu 14.04.2 LTS marked as ready [11:38] hmm non english installs are broken in kubuntu for bug 1182784 [11:39] bug 1182784 in ubiquity (Ubuntu Utopic) "Install with non English language fails on Keyboard: "ubi-console-setup failed with exit code 141" or "Installer Crashed"" [Critical,Fix released] https://launchpad.net/bugs/1182784 [11:39] I wonder if I have time for a fix and respin [12:41] didrocks: would you have time for bin-preNEW review of compiz(-mate) since it's FF today? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-021 / https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.1+15.04.20150213-0ubuntu1.diff === Guest20952 is now known as rcj === rcj is now known as Guest66629 [13:51] Mirv: why is there this remove unity script on upgrade? [13:52] Mirv: the default profile plugin doesn't use unity for mate [13:52] (see debian/mate.ini) [13:53] Mirv: all the rest is good, but this part should be clarified [13:55] bregma: ^ [13:56] didrocks, hmm, I'll check [13:58] bregma: yeah, I see it's a copy of my own migration script a while ago, but this was to transition from "default" to "ubuntu" session (and so, leave the default session with compiz without unityshell) [13:58] bregma: If I'm right and can still read my code, no promise :p [13:59] thanks didier for helping bregma [13:59] yw! [13:59] it's a dark moist area of the code I haven't looked at before, I'l trying to grok it now [14:00] bregma: yeah, it's not really a biggy but I feel it's not of use (and will just create a delay at startup), so better to check [14:00] bregma: maybe you can even clear my old migration script, the LTS has passed :) [14:00] maybe [14:04] didrocks, would it be acceptable to promote the current MATE changes as-is and open a bug to remove all the migration stuff before Vivid release? [14:05] bregma: fine by me if you ensure me it doesn't fall off track :) [14:06] I shall open a bug and get an MP up today, as soon as I get a troubled Unity landing off my plate [14:06] bregma: let me open the bug for you [14:06] Mirv: +1 then ^ [14:06] didrocks: bregma \o/ huge thanks! [14:08] bregma: bug #1423566 [14:08] bug 1423566 in compiz (Ubuntu) "Removal of migration scripts (both MATE and ubuntu one)" [High,New] https://launchpad.net/bugs/1423566 [14:09] super [14:47] * pitti waves [14:47] so GunnarHj asked me to build fresh trusty langpacks (with new -base), as we got updated ubuntu-docs this week [14:48] I realize the timing of this might be a bit unfortunate with 14.04.2, though [14:48] so what is the best course of action now: [14:48] - wait a week [14:48] - build/test them and upload them to -proposed, so that they can be tested, and we only release them next week [14:48] pitti: 14.04.2 is out today. vivid beta 2 is out next thursday. so act now! :) [14:48] or [14:49] - upload them, but don't accept them from the trusty-proposed queue? [14:49] wxl: this is about trusty :) [14:49] infinity: ^ [14:50] pitti: oh. then you're either screwed or infinity is going to be peeved. XD [14:50] I'm not saying that these langpacks must go into 14.04.2 :) [14:51] just making sure that uploading them to trusty-proposed now won't cause any difficulties [14:51] I don't see any as trusty-proposed has lots of stuff which isn't going into 14.04.2 [14:51] but better safe than sorry [14:51] afaik we made sure -proposed wasn't enabled by default in trusty [14:52] that *was* a problem at one point :/ [14:53] urgh :) [14:54] sorry i can't otherwise be of help [14:54] unfortunately my only relation to the release team is being the release manager for lubuntu [14:55] infinity and i are on similar time zones and i'm up early, so, you might give him a couple hrs [14:55] also he's pulled a couple all nighters this week for trusty :( [14:56] I'll just prepare them for now, but not upload them yet [14:56] i'd say that's a good idea [15:00] highvoltage: thanks for testing! I just woke up here and noticed that the hotel disconnected me halfway through the night so it'd still take me another 4 hours or so to grab the Edubuntu images... [15:00] afternoon - please could an archive admin do the honours and promote python-pint? - https://bugs.launchpad.net/ubuntu/+source/python-pint/+bug/1407970 [15:01] Launchpad bug 1407970 in python-pint (Ubuntu) "[MIR] python-pint" [High,Fix committed] [15:01] that unsticks one of my teams openstack uploads === Guest66629 is now known as rcj === rcj is now known as Guest35307 [15:13] * Riddell rebuilds kubuntu for new ubiquity [15:14] jamespage: done [15:14] Daviey, thanks! [15:42] Riddell: Err, what? You got a rebuild for ubiquity already... Or did you upload a new one when I wasn't looking? [15:42] infinity: yes I uploaded a new one [15:46] Riddell: Ugh. [15:46] Riddell: And thi crash only happens in the KDE frontend, despite being in common code? [15:47] Daviey: Hey, weren't you involved with mythbuntu at some point? :P [15:48] infinity: Sort of still am.. but not claiming to be. :) [15:49] Daviey: No one's smoketested the 14.04.2 images. Could I talk you into spinning them up for a quick boot/install/reboot cycle to make sure they're not completely buggered? [15:49] infinity: yes, it's in a PageFooKDE class [15:49] Riddell: Mmkay. Technically, I should respin the world for the change, but I'll let it slide in that case. [15:50] pitti: Please no langpacks today. :P [15:50] infinity: Would you believe me if i said i only had access to armv7 machine today? [15:50] pitti: Would have been nice to have them a week ago, but oh well. [15:50] Daviey: Probably not. [15:50] infinity: yeah, certainly not for 14.04.2; it's mostly the question whether uploading them to -proposed would disturb anything on yours ide [15:51] pitti: No, I'm blissfully ignoring proposed right now. [15:53] infinity: I can do that today [15:53] let me pull the images now [15:53] Riddell: Argh. I'm going to have to respin those again for you. [15:53] Riddell: The cdimage ftp mirror got skewed, your ubiquity and oem-config are mismatched. [15:53] tgm4883: Thanks. [15:54] * infinity really needs to hunt and fix that bug. [15:54] infinity: 20150218.1 images? [15:54] tgm4883: Yep. [15:54] ok, pulling them now [15:55] Riddell: Fixing the mirror skew issue, will respin for you as soon as it's not broken. :/ [15:55] infinity: i. e. I can upload those and translators can test them? they'd be released to -updates in two weeks [15:55] :( sorry [15:56] pitti: Sure, go nuts. [15:57] Riddell: Not your fault, the local mirror thing is a bit fragile. [15:57] * infinity taps his foot, waiting for rsync. [16:02] Laney,infinity: could use reviews/merges of my stack of britney MPs if you get a chance. They're mostly cowboyed live but it'd be best to squash the cowboys ASAP [16:03] Riddell: Okay, respinning again. [16:03] also should mostly be fairly obvious [16:03] cjwatson: After I point release. Tomorrow seems more likely. [16:03] k [16:03] the remaining piece is to work out what to do with the "old binaries" bits on http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html for linux [16:04] I think I'm going to add a switch to britney.py to ignore those for stables, TBH [16:05] cjwatson: Oh, whee. Didn't think about that ugliness. [16:05] because even discounting the debatable bit about whether to clean up old ABIs, there are always going to be binaries in trusty release that we can't get rid of [16:05] and honestly I really don't want to get into having to teach britney.py to tell the difference between release and updates and suchlike ... [16:05] cjwatson: Well, and even if I won the debate with "screw every old ABI except the ones on currently published installation media", there would still be *some* old ones. [16:06] yeah exactly [16:06] I think we just have to ignore those, maybe keep the excuse but not make it block [16:07] cjwatson: Can you special case the ignore to just linux* source packages? [16:07] cjwatson: Not that I anticipate others having NBS, but I suppose it could happen in the case of agressive-backports-as-SRUs (firefox locales, for instance), and the cruft should actually be noticed and cleaned. [16:07] I can think of other cases where it matters [16:07] and where we can't clear it [16:08] Hrm. Okay, then you've thought about it more than I have. :P [16:08] consider a library upload for a new HWE stack that changes the library package name, and we've decided to accept that and rebuild everything for it [16:08] I guess it's not killing us to carry other cruft anyway, linux is by far the worst offender. [16:08] that could well be fine (if nasty), but we can never get rid of the original binary in trusty release [16:08] cjwatson: new HWE stack libraries have new source names. [16:08] s/for a new HWE stack // [16:09] it was an example :) [16:09] my point is there are situations where there's uncleanable cruft [16:09] But yeah, right, I hadn't thought about the part where you're smooshing release and updates into a single "testing". [16:09] Cause we can't do a thing about "cruft" (which isn't) in release. [16:09] now it's sort of theoretically possible to fix that by making the merge be source-aware [16:10] actually, hmm, maybe it already is [16:10] I think the "just ignore it" solution is fine for now. [16:10] ok, I can start by "just ignore it" but limited to .startswith("linux") [16:10] and we can see how that goes [16:11] though I'll need to think about how to handle that on the command line, or whether to just do it by default, or what [16:11] I don't want to have to hardcode "dev series is vivid, treat it differently" in too many places [16:16] cjwatson: Wait, other than the ugly output on excuses, what's the actual problem? In the dev series, the "testing" target always has old binaries, since we don't clean them until after the migration. [16:16] cjwatson: Or is this check for "old binaries that don't belong to the target's source version"? ie: really old binaries. [16:17] infinity: testing done. Sorry about the wait on that, with the US holiday this week, and conducting interviews I've been pretty busy [16:17] tgm4883: All good. Thanks for the turnaround. [16:18] infinity: this all ties into the complex way we mangled britney to handle partial unstable, but normally speaking that gets handled [16:19] infinity: but in this case it doesn't, haven't quite worked out exactly why, but it stops autopkgtests from being dispatched which was kind of the whole point of this exercise === med_` is now known as medberry === medberry is now known as medberry2 [16:55] Riddell: ^-- Finally. [16:56] infinity: thanks, I'll get some people on it, I'm going out shortly for about 3 hours, does that screw with your plans? [16:56] Riddell: Nope, I have a ton of prep to do before I can release. [16:56] sounds fun [16:57] infinity: are we there yet? :p [16:57] have fun :) [16:58] * infinity throws things at elfy. [16:59] :) [16:59] elfy: If you're feeling all helpful again, I have paperwork you could do! [16:59] * infinity watches as the channel goes silent. [16:59] I couldn't possibly do any writing ... [17:00] and I've got a bone in my leg [17:02] infinity: linux> ah, the problem is that the NBS binaries have never been removed from *-propo* [17:02] *-proposed* [17:02] cjwatson: Oh. See, I can do that. [17:02] we don't need to do anything about -updates here, but NBS-cleaning -proposed would sort it out. I think I'd rather do that than hack britney. [17:02] cjwatson: No code changes required, I can just fix that in my process. [17:02] Want to leave that to me for this round since you're busy atm? [17:03] cjwatson: If it's blocking you testing this more, go forth and be cleany. [17:03] It is, and will do. [17:03] cjwatson: Just don't clean any of the current ones by accident. :) [17:04] I will be careful :) [17:05] Grumble, why doesn't rmadison -r work [17:05] infinity: seriously - in a bit if there's anything I can do to help you - I will [17:05] oh, because the CGI inhibits it, hmm. [17:05] probably vaguely reasonable. [17:07] elfy: Well, there's my least favourite part of point releases still to do, running Colin's evil bug-scraping script to put together the "all the crap we fixed since the last point release" part of the release notes. === ralsina is now known as jamestiberiuskir [17:10] note on vivid binary new queue - simgear armhf ftbfs is not a regression, the current version doesn't build as well === jamestiberiuskir is now known as ralsina === ralsina is now known as bonesmcoy === bonesmcoy is now known as ralsina [17:15] infinity: doing the removal pass for -proposed. will presumably take hours [17:16] for trusty-proposed, that is [17:16] I want to see that this fixes p-m before doing others [17:44] infinity: Looking at the trusty SRU queue won't affect the point release right? [17:45] bdmurray: Accepting to proposed won't, no. Just don't release anything to updates today. [17:46] infinity: just wanted to check in on 14.04.2... do you expect to spin another round of ubuntu desktop iso? [17:46] jderose: Nope. [17:46] sweet :) [17:46] jderose: Don't tell me you found a critically awful bug. :P [17:46] nope, it's all good from where i sit :) [17:46] jderose: Because then we won't be on speaking terms. [17:47] jderose: Oh, good. All good sounds nice. [17:47] * infinity tests powerpc and ppc64el server ISOs quick-like. [18:02] infinity: kind of about now, so I could look at that if you wanted and it didn't waste more of your time explaining things than just doing it yourself [18:04] infinity: just to make your day https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1423643 [18:04] Launchpad bug 1423643 in bcmwl (Ubuntu) "Trusty.2 bcmwl-kernel-source is not installing on hwe kernel on macs" [Critical,New] [18:05] elfy: See the "Prepare change summary" bit of https://wiki.ubuntu.com/PointReleaseProcess [18:06] infinity: ok [18:06] elfy: If you want to help by doing that, I'll owe you a large number of bubbly beverages. [18:06] any images still need testing? [18:06] infinity: Oh, should I switch auto-sync into dry-run mode after the 23:00 run? [18:07] cjwatson: Sounds like a plan. [18:07] davmor2: Ugh. [18:07] cyphermox, I just finished desktop but didn't run screenreader and vmware tests [18:07] That just requires me to remember after I get back from the pub, which is probably reasonable-ish. [18:07] It's just adding --dry-run to that crontab line. [18:07] davmor2: I'm not sure that we can investigate and fix that one before release and force everyone to re-test. :/ [18:08] jibel: ok, I can try to run the screenreader while vmware downloads. Having that can't hurt in the future [18:08] davmor2: I thought that driver was meant to be replaced by one that shipped with the kernel for 3.16. [18:08] apw: What do you know of bcmwl? [18:08] infinity: it's only mac who uses those ;) and there is no oem involvement, personally I blame the sales team for that though I just don't think they are trying hard enough ;) [18:09] davmor2: Hah. Good luck squeezing money from Apple to support a competitor's OS. [18:10] infinity: I have a feeling that utopic switch to some other driver for bcm but taht doesn't support mac iirc [18:10] jamespage, do you have anyone to review iSCSI on server images for 14.04.2? [18:10] davmor2: Can we just tell people with Macs to go buy better laptops? [18:10] infinity: looking [18:14] infinity: I note this is in Release minus 14 days and not Release minus a couple of hours ;) [18:14] elfy: Picky, picky. [18:14] :D [18:15] anyway - script running now [18:17] Any idea about 14.04.2? Is it ready for primetime yet ? [18:21] Guest15179: Patience. [18:21] :) [18:23] * infinity runs downstairs to grab a shawarma for fuel. [18:24] oooh - grab 2 :) [18:24] Sure, I'll email you yours. [18:24] mmm - etherfood [18:25] infinity, Ubuntu Desktop i386 and amd64 are OK. vmware easy install is not tested. [18:26] infinity, on server, iSCSI is not tested and I don't have a setup to test it. [18:26] infinity: interesting idea. I just received my shish taouk plate I ordered. [18:28] .. which means I'll need to spend a half-hour shoveling snow later [18:35] infinity: could you ping me when you have main release notes done? [18:45] infinity: umm .... [18:46] so now I have a look at the output - should I maybe have changed line in the script which says "distro_series=precise, pocket='Updates', created_since_date='2012-08-23' [18:47] possibly explains why it's still going and is at line 6000 [18:49] Yeah, that wants to be trusty and the date set to whenever the last SRU was accepted for the previous point release [18:49] Though the output is usually still very long [18:51] cjwatson: and where would I get that date? [18:52] stgraber: ah that sucks. np though. everything was fine. I have the draft announcement too, but it needs the links fixed for the final links [18:53] elfy: I'm overcomplicating things. SRUs aren't accepted between end of prep and the actual release, so just find the date of the last point release from the announcement lists and use that [18:53]