[01:18] sarnold: I wouldn't expect that, but I don't really know for sure; that's really a question for the kernel team [01:19] slangasek: thanks [01:19] but I see this here: [01:19] [ 1.593369] video: module verification failed: signature and/or required key missing - tainting kernel [01:20] and that's definitely the stock video.ko from the linux-image package [01:20] so I guess module verification is working not quite as expected [07:06] usual quick visit.. please review http://pastebin.com/s0e0bPzS It's not my problem.. [08:58] NoNameYet™ [09:00] weirdos [09:01] .com [09:04] just googled it and found https://blogs.kde.org/2004/08/28/canonical-software-no-name-yet-warthogs-and-ubuntu [09:04] :-) [09:12] yeah === sil2100_ is now known as sil2100 === doko_ is now known as doko [14:04] doko: ^ shouldn't that be in the PPA? [14:05] cjwatson, already rejected [14:05] ok [14:05] Hello everyone! Can I get some SRU-team eyeballs on a Unity/Nux bug that we want to SRU for precise? Would be nice to know if we can have it released: https://bugs.launchpad.net/unity/+bug/1043627 [14:05] Launchpad bug 1043627 in nux (Ubuntu Raring) "[SRU] Add XIM Support to Nux" [Undecided,Confirmed] [14:22] Would whoever is setting up "Trusty" in LP also add the traditional Alpha/Beta milestones. Many flavors still use those. [14:23] Grr, I can't any more [14:24] Let me put together a list for webops [14:27] Thanks. [14:33] FYI: although trusty is initialising, please don't accept anything until we've got the -changes list in place [14:57] OK, we have the list in place now, initial bits are publishing [15:40] Are we ok to be doing saucy SRU's now, without the fix yet in Trusty (task is open)? [15:42] Daviey: Yeah. For some things, we can even copy forward. [15:43] infinity: Right, yeah - just checking that hadn't changed. [15:45] ISTR that cjwatson ran a cron measuring stuff that needed to be copy forward? [15:45] Manual [15:45] Generally run it every now and again for a few weeks [15:46] cjwatson: Does that mean that I don't need to keep this on my todo? [15:46] Daviey: well, it's easier to upload to trusty at the same time. I really despise having things installing from "previous-updates" 2-3 months into the development cycle. [15:47] xnox: well yes.. I'm talking purely about the opening window.. ie, this week. [15:47] Daviey: sure a week is ~okish, anything << 30 days. [15:48] you noticed that it is friday ? [15:48] this week doesnt have much left anymore :) [15:48] old ogra_, and his 5 day weeks :) [15:48] * ogra_ shakes his cane [15:55] Daviey: you don't [15:57] ta === seb128_ is now known as seb128 [17:14] infinity, please promote precise linux-firmware to -updates. the fix has been confirmed. https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1239414/comments/6 [17:14] Launchpad bug 1239414 in linux-firmware (Ubuntu Precise) "rtl8192ce fails to load firmware" [Medium,Fix committed] [17:15] rtg_: updates and security, I assume, to match SRU kernels? [17:16] infinity, yep [17:16] rtg_: Also, if someone had set the verification-done tag on that, you might not have to nag me. :) [17:16] infinity, ah, could have done that myself. [17:16] rtg_: Released. [17:17] infinity, also, at your convenience, it would be good to get the saucy LTS kernel pocket copied. [17:18] rtg_: I'll look at that on Monday, if you don't mind. [17:18] thats soon enough [17:19] rtg_: Why no tools on armhf? [17:19] Oh, do_tools_x86. [17:19] I can't read. [17:20] infinity, go away and do this Monday :) [17:20] Yes dear. Nag me on Monday, please? I'll lose context. [17:20] can do [17:23] * maxb is terribly disappointed that the t-series name in the topic is just a joke :-) === infinity changed the topic of #ubuntu-release to: Released: 13.10, and 12.04.3 | Archive: Closed | Trusty Tahr Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis [17:28] would anyone be unhappy if I sru-released systemd for the maguro uevent spam fix today? [17:35] slangasek, not at all !!! [17:37] if some SRU team member could review the libindicator's saucy SRU today that would be nice [17:38] I'll be able to look in a bit [17:39] slangasek, thanks [17:51] slangasek: Let me give it an eyeball for impact before I give you a second SRU +1 on that. [17:53] slangasek: Okay, vomitous and somewhat hard to judge without a bit more testing or deep knowledge, but impacts only ARM, so go for it. [17:53] * slangasek nods [17:54] bdmurray: looks like phased-updater also has a hard-coded reference to raring? [18:00] slangasek: fixing [18:02] slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phase-saucy/+merge/191848 [18:03] bdmurray: merged [18:25] slangasek: wrt to libunity we could verify it using apt-get to upgrade correct? [18:25] bdmurray: yes, that's what I put in the test case on the bug [18:25] I assumed using u-r-u would work less well because it might not be happy with -proposed [18:30] slangasek: I'll review the upload and verify it [18:31] bdmurray: cheers [18:32] thanks for the help sorting it out [18:59] infinity: did you see this mail from phillw? how did lubuntu armhf+ac100 get released if it has no tests on the iso tracker? [19:00] yeah, thats intresting [19:00] especially since wlan seems to not work at all for wahtever reason [19:01] * ogra_ just triaged a bug for that today [19:01] right; though not releasing the image wouldn't prevent users from upgrading, we still shouldn't release images that weren't tested [19:02] hm it's in the product manifest, but was not marked as ready on the tracker, not sure how did it manage to get released. [19:04] slangasek: We had to publish before all tests were in on all flavours/arches. We can certainly unpublish that one, if they don't want it out there. [19:04] infinity, well, it seems to work apart from the NM issues [19:05] (which actually surprised me) [19:05] infinity: will trusty be unfrozen over the weekend, or no? [19:06] slangasek: verification done if you could release it and set the p-u-p to 100 that'd be great [19:06] xnox: That depends on Colin's perl transition and getting proposed-migration going and a few other things. [19:06] xnox: So, "maybe". [19:06] infinity: why "had to publish"? This is a significant departure from the standard practice of "don't publish anything that's not tested" [19:06] infinity: so i can upload/sync bits for perl then. [19:06] infinity: into unapproved. ok then. [19:06] infinity: anyway, I'll unpublish it now [19:07] bug 1231778 btw [19:07] Launchpad bug 1231778 in network-manager (Ubuntu) "wifi not working on Saucy Salamander" [Medium,Confirmed] https://launchpad.net/bugs/1231778 [19:07] so i guess we should call that a semi successful image test :) [19:07] infinity: btw (and don't let this get in the way of your pint), it looks like there's some cleanup to be done of previous saucy milestones on cdimage... beta-1 and beta2 are still hanging around [19:07] s/should/could [19:07] slangasek: As in, plenty of tests were still rolling in, and we needed to get the tree ready and pushed several hours before the announce. To be fair, no one actually told any of us doing the release not to publish said image. [19:08] slangasek: Yeah, the cleanup will come $later. [19:08] slangasek, let it stay and i'll care to get the NM bug tested [19:08] infinity: since when does cdimage need to be done several hours before announcing? [19:08] slangasek, that way we have at least *some* non touch users on armhf [19:08] cdimage never needed more than 10 minutes lead time in the past [19:08] with the chance to get some bugs [19:09] s/tested/fixed [19:09] slangasek: releases needs lead time, or so I was led to believe. I could have just synced to the releases mirrors, I guess, and held off on cdimage. [19:10] infinity: right, I believe that's what we always did in the past [19:10] slangasek: 10 minutes is very optimistic though ;) 2-3 hours is usually a better bet for cdimage as rsync takes quite a while now (multiple targets) and bittorrent is still slow as hell [19:10] ogra_: Fixing the NM issue in -updates won't get you a working image, since there's a chicken and egg problem that the only convenient way to get the fixed package is via wireless. [19:10] slangasek, just let it stay [19:10] infinity: pre-publishing n hours before; then update the symlinks on release and publish to cdimage at the last minute [19:10] infinity, oh, indeed ... crap [19:11] stgraber: erm, that's not reasonable and leads to this kind of issue [19:11] slangasek: The symlink propagation is what I was told still takes hours. [19:11] stgraber: if rsync is now taking 2-3 hours internally, we should talk to IS about this [19:11] * ogra_ would hav ereally liked to have some "normal" armhf desktop users [19:11] infinity: um [19:11] *really [19:11] It doesn't take hours internally, it takes hours externally. (this is just for releases, we don't care about cdimage mirrors) [19:12] ogra_: I'm deleting the images from the releases/ dir, they failed verification and are unreleasable [19:12] infinity: then that's also a serious regression [19:13] slangasek: I've seen rsync take up to 30-45min depending on what we publish but it may have been due to network issues (we had some of that a while back). Bittorrent is just horribly slow and it usually takes hours to get the server to hash everything and start seeding. Not something we care about for non-final milestones (we didn't wait the past few times) but it's probably worth waiting for for final. [19:13] slangasek, yes, understood [19:24] so, saucy daily build of ubuntu-touch is done now, picking up the new udev [19:25] stgraber: do you trust import-images to DTRT here? :) [19:25] slangasek: if it published to ubuntu-touch/saucy/daily-proposed, yes [19:26] stgraber: I hope you mean ubuntu-touch/saucy/daily-preinstalled/pending [19:26] import-images ignores /pending, but yeah, anywhere below ubuntu-touch/saucy/daily-proposed will work [19:26] ? [19:26] s/proposed/preinstalled/? [19:26] heh, yeah, that [19:27] anyway, looks like it's fine, it's eating most of the CPU on nusakan at the moment which usually means delta generation [19:27] ok [19:28] and you're not worried about it ending up in the wrong channel :) [19:29] nope, only saucy-proposed has ubuntu-touch/saucy/daily-preinstalled set as its source, so it'll either import it there or skip it. Looking at the CPU usage, it looks like it's importing it. [19:29] * ogra_ would be more worried about it killing the in progress rework of the QA infra [19:29] not sure where that stands atm [19:30] slangasek: each channel importing from cdimage also has the file prefix defined in the config, so saucy-proposed will only accept files starting with saucy- and trusty-proposed only those starting with trusty- [19:30] that's the main safeguard for when we start building a new series in the same path and forget to change the system-image config first [19:31] bdmurray: libunity released and PUPed to 100 [19:34] trusty touch build running now [19:37] slangasek: image published [19:41] stgraber: cool. So people with galaxy nexus can switch to the saucy-proposed channel to test now? [19:41] stgraber: oh... the image appears to also have shown up in the devel-proposed channel, is that expected? [19:42] slangasek: devel-* is still aliases to saucy-* for now since we don't have any image in trusty [19:42] so yeah, that's normal [19:42] but will likely change very soon (once ogra_'s build is done and confirmed not to be a disaster ;)) [19:43] stgraber: well, so people currently on devel-proposed will see this image and shouldn't [19:43] AIUI [19:44] slangasek: That seems like reasonable behaviour until the s/saucy/trusty/ switch flips, doesn't it? [19:45] (Though, ideally, that would flip on release day) [19:45] infinity: not if it means that people who are tracking devel-proposed see a discontinuity in the channel's contents [19:45] I think anyone in devel-proposed wants the latest image available, short of having a trusty image, the shiniest thing you can have is saucy-proposed [19:45] ok, so that means this saucy-proposed image will remain in the devel-proposed channel, and the next trusty devel-proposed delta will be built against that [19:46] stgraber: I'm not concerned here with what the users of devel-proposed want, but with whether the resulting channels remain sane :) [19:46] slangasek: no. devel-proposed is an alias, currently it points to saucy-proposed with the latest image being 101 (the one you just built) [19:46] once I flip the switch, it'll instead alias to trusty-proposed with the latest image being 1 [19:47] so, how will users upgrade when that switch is flipped? [19:47] the system-image client tracks the alias, when the target changes it does one full image update (by assuming its internal version is 0) [19:47] and after that you're back to standard deltas from that point on [19:47] ok [19:48] A full upgrade for something with essentially zero actual delta seems vicious. [19:48] infinity: it nevertheless ensures correctness, which should be the top priority [19:48] (and it seems that it is :) [19:49] * infinity nods. [19:49] I guess it only really hurts for devel-type people. [19:49] Which, eventually, we would expect very few users to be. [19:51] full update means re-creating the filesystem, so forcing all phones to be perfectly clean once per cycle seems like a good feature (it'll also get the few remaining phones converted to a 2GB / instead of 1.2GB) [19:51] but yeah, that means a 300MB+ download so a bit annoying for what's technically a minimal change [19:53] * stgraber copies procps from saucy-updates to trusty so we open with a working LXC === infinity changed the topic of #ubuntu-release to: Released: 13.10, and 12.04.3 | Archive: Frozen for Opening | Trusty Tahr Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis [19:54] * infinity heads out to find a drink. [19:54] infinity: do we have britney yet or is it better I copy straight to release pocket for that one? [19:54] Back late tonight before I fly home. [19:54] stgraber: britney's off currently. slangasek's been copying to release, which I was about to chastise him for. [19:55] (But, in this copying forward SRUs case, it should be harmless) [19:56] I imagine Colin will get proposed-migration running tomorrowish. [19:56] ok. I'll do a straight copy then for that one (as I really don't want to have to deal with it again after we open). [19:56] infinity: if we prefer these being copied to -proposed I can do that, though I don't see how it matters for these SRUs [19:57] slangasek: We prefer everything being copied to proposed, for paranoia's sake. We're about to land changes to copy-package attempting to enforce that for those of us with the power to copy to release. :P [19:57] hmm, I suppose in theory there could be some adt interactions [19:57] ok [19:58] the build didnt fail yet btw [19:58] still running [19:58] "Didn't fail yet" is high praise. [19:58] yeah [19:59] in fact it should be done soon [20:10] ogra_: looks like the rootfs built fine, it's doing the android bits now [20:10] yeah [20:10] should just finish fine then [20:12] and done [20:12] \o/ [20:12] awesome, we have a trusty image [20:12] cp: cannot stat 'chroot/usr/share/android/product/trusty-preinstalled-system-armel+maguro.img': No such file or directory [20:13] (from the log file on the buildd) [20:13] gah [20:14] i guess i'll hardcode that to saucy for a few builds until we want to actually try to rebuild android [20:15] hmm, why do we even store the series name in the binary package? [20:15] seems to me we could have that one called ubuntu-preinstalled-... and just have cdimage care about the series [20:16] anyway, you'll need trusty to be open to fix any of that so I guess we'll be stuck on saucy for a tiny while longer [20:16] yeah, but i definitely dont want to rebuild android right now [20:16] not unlesswe have a workign image [20:17] oh, right, proposed is still locked donw [20:17] *down [20:17] colin mentioned that [20:17] yep [20:21] * ogra_ calls it a day then [21:40] i guess it makes sense to wait for arm64 to catch up before doing transitions... [23:04] slangasek: I've uploaded u-r-u to the saucy-proposed queue