=== willcooke is now known as willcooke|meetin === willcooke|meetin is now known as willcooke [12:39] infinity, are you coordinating the release of 14.04.1? Can you add it to the tracker? [15:15] infinity, I think that I have most of the proposed docker SRU prepared and ready for upload - care to review bug 1338768? [15:15] bug 1338768 in golang-pty-dev "[SRU] Update to 1.0.0 release" [High,New] https://launchpad.net/bugs/1338768 [15:16] jamespage: Not just now, but soon, yeah. [15:16] infinity, ta [15:32] jibel: Should be added. [15:41] infinity, thanks. There is no build, is 20140722 the first candidate or you'll do a new build? [15:59] infinity: well, I was hoping to have bug #1275162 published for point release, but bug #1314134 is not verified yet. Both bugs affect the installation itself. [15:59] bug 1275162 in grub2 "incorrect efibootmgr command is set by update-grub under OVMF" [High,Fix committed] https://launchpad.net/bugs/1275162 [15:59] bug 1314134 in grub2 "network stack never yields control on busy networks" [High,Fix committed] https://launchpad.net/bugs/1314134 [16:03] xnox, I can do the verification of 1275162 [16:04] ah, nm, it's verified. [16:04] jibel: that one is verified, the haevy traffic needs verification. [16:04] jibel: yeap. [16:05] cjwatson: stgraber: any clue how to simulate / test bug #1314134 ? [16:05] bug 1314134 in grub2 "network stack never yields control on busy networks" [High,Fix committed] https://launchpad.net/bugs/1314134 [16:06] jibel: There will be new builds soon(ish) [16:07] xnox: honestly, if grub works at all, I'd just go for it ... [16:08] Quality advice on quality, right here folks. ;) [16:08] \o/ [16:08] unless you happen to have a netboot setup already [16:08] But since the last d-i build would have been with that grub, we're vaguely committed anyway. [16:09] And it's been in proposed for eons, with no complaints. [16:09] So, let's do it. [16:11] Hrm, I guess I should turn off cron. [16:14] cjwatson: daily isos are netbooted in the test infrastructure, on jenkins. so that works, and our network should be busi-ish? or is this some kind of special busy? [16:15] trusty is 100% both on desktop-netboot and server images. [16:15] xnox: I doubt the netbooting goes through grub [16:17] cjwatson: oh. ok. so it's grub networking =/ no idea about that. [18:24] jibel: The RC builds should start spitting out soon now, if you want to remind flavour testers that they're all LTS this time around. :P [18:25] jibel: (especially mythbuntu, who completely forgot at release time...) [18:44] infinity: I don't suppose this will include our sru packages still in the queue [20:28] I'm seeing an update for base-files to 7.2ubuntu5.1 in trusty-updates.. which just caused some confusion in #ubuntu. Is this intended? [20:29] Pici: What confusion did it cause? [20:30] Pici: And yes, it's intended. We're releasing 14.04.1 on Thursday, which means needing to update base-files a bit in advance so we can spin and test images. [20:30] infinity: Well, we sometimes ask people to post the contents of /etc/issue to determine which version of Ubuntu they are running. Seeing 14.04.1 just threw us for a loop. [20:30] infinity: okay. [20:30] Pici: This happened 4 times in 12.04, you'd think people would be used to it by now. :) [20:31] Pici: If you want a number that never changes, you want 'lsb_release -rs' [20:31] Pici: /etc/issue is purely cosmetic. [20:31] infinity: Yeah, but thats a lot of typing for people who can barely use the terminal. But thanks :) [20:37] cjwatson: Argh, why didn't we fix the linux-signed-in-live-seed issue? :( [20:44] damn, I thought I had [20:45] I'm going to see if there's something I can do that's less painful than the "stop using tasks" thing. [20:45] Though, I guess we need that change for 14.04.2 anyway. [20:45] hi, what's the diff between 20140722.1 and 20140722 in daily? [20:45] pfsmorigo: The former is newer. [20:47] infinity: you mean 20140722.1, right? why there isn't ppc64el in it? [20:48] pfsmorigo: For which image? [20:48] pfsmorigo: trusty server? [20:49] Actually, that's a good question. [20:49] infinity: yep... http://cdimage.ubuntu.com/ubuntu-server/trusty/daily/20140722.1/ [20:49] infinity: I need to check a bug fix. Can I use 20140722? [20:50] pfsmorigo: Depends on which bug. [20:51] infinity: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1334649/comments/2 [20:51] Launchpad bug 1334649 in debian-installer "ppc64el/cdrom: ieee1275/cdrom devalias doesn't work on all machines" [High,Fix released] [20:51] pfsmorigo: You can test that with a d-i mini.iso [20:52] infinity: nice! [20:52] pfsmorigo: http://ports.ubuntu.com/ubuntu-ports/dists/trusty-proposed/main/installer-ppc64el/20101020ubuntu318.3/images/netboot/ [20:52] infinity: let me check.. tls [20:52] s/tls/tks/ [20:54] genisoimage: Volume ID string too long [20:54] FFS. [20:55] Indeed, I bet this is why the powerpc ISOs are "ppc" instead of "powerpc". [20:56] cjwatson: Preference on how to cheat here? s/ppc64el/ppc64/? s/ppc64el/POWER/? [20:56] cjwatson: Adding ".1" to the string sent it over the edge. :P [20:56] slangasek: ^-- You like to have opinions about this sort of thing. [21:06] * infinity will probably just go with ppc64, not terribly confusing on Ubuntu, where we don't have that dpkg arch. [21:20] Well, that's helpful, apt. [21:20] (trusty-amd64)root@cthulhu:~# apt-get install ubuntu-live^ linux-image-3.13.0-24-generic- linux-signed-image-3.13.0-24-generic- linux-image-extra-3.13.0-24-generic- linux-headers-3.13.0-24-generic- linux-headers-3.13.0-24- [21:20] [...] [21:20] The following held packages will be changed: [21:20] linux-headers-3.13.0-24 linux-headers-3.13.0-24-generic linux-image-3.13.0-24-generic [21:20] linux-image-extra-3.13.0-24-generic linux-signed-image-3.13.0-24-generic [21:20] In other words, "I heard you, and I'm going to install them anyway, nyah nyah." [21:26] cjwatson: Huh, the plot thickens. These builds were working in -proposed (ie: not pulling in two kernels), but don't work with proposed turned off. [21:27] That doesn't even make sense... [21:38] infinity: opinions> I don't know that I'd say I like to have them; they're a cross I bear [21:39] infinity: if this is for genisoimage volume ID, I'm not sure I really care :) what's the actual limit? [21:40] ppc64 would be fine; we use ppc for powerpc [21:41] the limit is documented next to the code that does that [21:41] I think [21:42] oh, it's documented in cdimage/lib/cdimage/project.py [21:42] see r1406 [21:43] infinity: dodgy tasks or something? [21:44] cjwatson: I can't sort out how to reproduce the issue by pulling add_task out of livecd-rootfs and abusing manually. :/ [21:44] cjwatson: Then again, the quoting on this makes my head hurt. [21:46] I think it amounts to this, though: [21:46] apt-cache dumpavail | grep-dctrl -nsPackage \( -XFArchitecture amd64 -o -XFArchitecture all \) -a -wFTask ubuntu-live -a --not -Pe "^linux-(headers|image|signed)" [21:46] And I can't get that to give me a kernel with or without proposed enabled. [21:46] Which it shouldn't. [21:46] So, WTF. [21:47] if you can wait an hour or two I can look properly [21:48] cjwatson: I'd appreciate it. It sure looks like you fixed this, so why it's unfixing itself is a mystery to me. [21:48] I might have some breakfast. [21:48] infinity: link me the failure while you have it? [21:48] At least ppc64el is fixed. [21:48] cjwatson: https://launchpadlibrarian.net/180527763/buildlog_ubuntu_trusty_amd64_ubuntu_FAILEDTOBUILD.txt.gz [21:49] cjwatson: Compare to success at https://launchpadlibrarian.net/180455287/buildlog_ubuntu_trusty_amd64_ubuntu_UPLOADING.txt.gz [21:49] cjwatson: Or, you know, your stellar UI at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/trusty/ubuntu ;) [21:49] shush you [21:49] I'll fix it at some point :) [21:49] Hey, it works. [21:49] It's just impossible to find. [21:50] needs an index of livefses [21:50] cjwatson: The log is twice the size because, unshockingly, linux-headers is all dupe files. Othwerwise, they're pretty much identical, save proposed/!proposed, and one getting two kernels for no discernable reason. [21:51] infinity: it's using the wrong livecd-rootfs version ... [21:51] Well, more than two kernels, two kernels, headers, etc. So, it really looks like the task filter is failing to filter. [21:51] so um argh how do we fix that in time [21:51] 2.208 vs. 2.208.1 [21:51] Err, so it is. [21:51] Not pulling from -updates. :( [21:51] I think I know [21:51] It should work if we give it pocket="Updates" [21:52] Mostly it doesn't matter, but it does for livecd-rootfs [21:52] It matters in general, IMO, since we want to be able to update our build tools. [21:52] But, in practice, that's usually just livecd-rootfs and live-build, sure. [21:53] So, this bit here: [21:53] Right, I mean it doesn't matter for the inside of the livefs [21:53] if config["PROPOSED"]: [21:53] kwargs["pocket"] = "Proposed" [21:53] metadata_override["proposed"] = True [21:53] else: [21:53] kwargs["pocket"] = "Release" [21:53] Right, I'm just fixing that [21:54] config["DIST"].is_latest is the relevant thing, so it stays Release for utopic but goes to Updates for Mangling it to just hardcode precise, trusty for now? [21:54] Ahh, or that. [21:54] Much cleaner. [21:54] infinity: try now [21:54] * infinity retries ubuntu-desktop [21:55] Will do the rest when this appears good. [21:55] re dupe files, I canned that in utopic, just not in trusty [21:55] because we haven't cared for years [21:55] It's an interesting metric, but only if someone actually reads it. [21:55] It's just useless data in the wind otherwise, and a waste of CPU time. [21:55] More to the point, it can be computed latr. [21:56] *later [21:56] True, that too. Could be a QA test. [21:56] Yeah, we could stick it on ci.ubuntu.com if we felt like it. [21:56] I don't think anyone cares enough though [21:57] Well, it was an interesting metric that led to things like pkgbinarymangler deduping copyright/changelog, etc. [21:57] Though, not sure if the livefs builds were directly responsible, or just someone saying "look, that's pointless duplication". [21:57] But a QA/CI read on pointless duplication wouldn't go amiss. [21:58] Both exact duplication (identical files, like fdupes was telling us), and suspicious possible duplication (multiple versions of libfoo[0-9] installed, for instance) would be interesting. [22:15] tgm4883: Sorry, missed your question in the dramatic backscroll there. [22:15] tgm4883: Which packages were you curious about? [22:18] infinity: we've been trying to SRU the mythtv packages, but haven't had any comments in about a month now https://bugs.launchpad.net/ubuntu/trusty/+source/mythtv/+bug/1323391 [22:18] Launchpad bug 1323391 in mythtv "Update to 0.27.1 point release" [Undecided,In progress] [22:19] I don't want to just ping this room every day, but I don't know what else to do [22:20] tgm4883: Hrm, the last comment there implies that there's a 0.27.2 around the corner. [22:21] hi, could some make the builds for the rest of lubuntu builds? This will be .2 builds?... [22:21] infinity: While that is true, since we weren't getting any comments on that we didn't want to have to start the process over by uploading a new one [22:21] tgm4883: Anyhow, short answer, no that won't be able to make the point release ISO, even if I review and accept it today. But yes, we should push forward with this, and users can upgrade post-install. [22:21] infinity: ok, should I upload the latest point release then? [22:22] phillw: I'll rebuild lubuntu in a second after we verify our amd64 fix is happy. [22:22] I mean, we really only planned on doing this (SRU's) for point releases, but yes we should give them something they can upgrade to [22:23] tgm4883: I think moving to the latest point release is smart, but we also need to review this fairly extensively (though, I think ideally, we'll want to get you guys to apply for an MRE for this). [22:23] tgm4883: "For point releases" is somewhat meaningless anyway, a package upgrade is an upgrade, if it's on an ISO only really matters if it affects the installation. [22:23] infinity: I thought MRE's were only needed for packages with new features? [22:23] infinity: thanks.. sorry to be the person here... our TL is just back from a meeting and our other Release manager is at osscon [22:24] tgm4883: No, the point of an MRE is to say "there's extensive upstream QA on this, and lots of changes and we're not going to test every single commit/fix in Ubuntu to verify it". [22:24] infinity: that is true, but many of our users treat our distro as an appliance. Which means install it and forget it (for better or worse) [22:24] tgm4883: Without an MRE, you need to enumerate every single upstream change and validate each one. [22:24] infinity: ah ok. Is there documentation for doing an MRE, I'm only aware of what superm1 gave me, which is the SRU documentation [22:24] https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions [22:24] (I can go looking for it too) [22:25] ^ [22:25] reading it now [22:25] tgm4883: Cause, yeah, this 480K diff isn't something any of us can realistically review properly, not something you guys can realistically QA properly. So, we need to rely on assurances that it's already sane before uploading (hence the MRE concept). [22:26] s/not something/nor something/ [22:26] infinity: that makes sense. [22:27] infinity: do you if jluien got his SRU's in, in time for our bugs on lubuntu? [22:27] *do you know* [22:27] phillw: No idea, since I don't know which those were. [22:29] infinity: bug 1326740 and bug 1308348 [22:29] bug 1326740 in xfce4-power-manager "[SRU] Please backport xfce4-power-manager 1.2.0-3ubuntu6 to trusty" [Critical,Fix released] https://launchpad.net/bugs/1326740 [22:29] bug 1308348 in lxsession "network settings indicator missing from panel" [High,Fix released] https://launchpad.net/bugs/1308348 [22:29] if you have the bug numbers, you can look at the bug states [22:30] cjwatson: both say fix released... will they be in the .1 release? [22:30] that would imply yes [22:30] phillw: If they were Fix Released before, uhm, now, then yes. [22:31] phillw: Since I already pointed out that I was going to respin everything. :) [22:32] infinity: it was close to time called, julien is busy after a conference, so I'm a bit stuck on witing up a set of release notes... any crumbs would be apprreciated :D [22:32] infinity: Ahh, but are they in the list :P [22:33] The List? [22:34] the list of SRU's / bug fixes approved? [22:34] phillw: If it's Fix Release, it's in The List. We build from -updates, we don't hand pick packages to update. [22:36] infinity: thanks... was not too sure how the diffeence between 'fix relased' and 'SRU' [22:36] We had 'fix released' but were told it then needed an SRU [22:37] phillw: It's Fix Released *in trusty* that's the important bit here. Which both of those bugs are. [22:38] infinity: that's good news, they were really annoying bugs [22:38] bad press of people complaining is never good :) [22:39] I will let you good people get on. thankyou for not kick-banning me. I still do care :) [22:40] infinity: \o/ [22:44] infinity: have you respun the world now? [22:45] phillw: That was just Ubuntu, not the world, but the world will now follow. ;) [22:45] when can the lubunteers expect images (we have alt and desktop) [22:46] And they're off. [22:46] oh, and as you know, when we've done ours, we always help out other flavours :) [22:47] phillw: Probably 1-2h for everything to be done. [22:47] I'll try to hang on for at alts.... they will hopefully be a quick zsync unless you guys have done some thing major? [22:48] And once these are all happy, I'll re-enable the flavour self-service stuff. [22:48] infinity: both of who are afk.... c'est la vie :) [23:50] infinity: lubuntu builds done, or still queued? [23:51] phillw: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/trusty/lubuntu/+build/2646 [23:51] it got a slower builder on powerpc, but making progress [23:52] phillw: Alternates are done, desktop are in progress, as cjwatson points out. [23:52] Ill start off with alternates :) [23:52] thanks