[09:36] cjwatson: xnox: http://pastebin.ubuntu.com/5721076/ is seen with the default raring server installations today. [09:37] psivaa: is that on all server jobs?! [09:37] * xnox ponders how to subscribe to failures on those. [09:38] xnox: both i386 and amd64 [09:40] hmmmm [09:40] xnox: public jenkins is taking too long to load, but we have not set up email notifications for the smoke tests yet, we could do that [09:41] psivaa: new today? [09:41] cjwatson: yes this failure is new and only with today's images [09:41] oh, d-i updated without seeds again [09:42] It sure didn't. [09:42] hmm [09:42] maybe just really unlucky timing [09:42] Unless something's trying to pull d-i from proposed. [09:42] * cjwatson grabs the image to look in more detail [09:42] But I did the seed change at more or less the optimal time (sure, there's a window for a publisher cycle there, or so) [09:43] the build is around the time when you *might* have got unlucky, but I'll check [09:43] there seems to be a new kernel yesterday 3.8.0-19 [09:43] yeah, I know [09:43] I'll look into it [09:44] cjwatson: ok thank you [09:44] psivaa: can I have a link to the full log? [09:45] cjwatson: i'm trying to load that in the public instance which has not still loaded, ill copy and paste the full log from the private jenkins [09:45] Maybe if we mangle when cdimage dailies build, we can just disallow migration of d-i/linux during suboptimal windows. :P [09:45] I have lab access, so a private jenkins link would be fine [09:46] Or maybe my hackish solution to get kernel ABIs completely out of the seeds would solve all of this. [09:46] cjwatson: http://pastebin.ubuntu.com/5721108/ [09:46] I'll have to look at landing that early in S. [09:47] hmm, that's d-i with -18 and -18 is on the images. [09:47] Apr 19 08:19:23 main-menu[1734]: (process:13782): libkmod: kmod_lookup_alias_from_builtin_file: [09:47] Apr 19 08:19:23 main-menu[1734]: (process:13782): could not open builtin file '/lib/modules/3.8.0-18-generic/modules.builtin.bin' [09:47] is that a recent kmod change? [09:48] I did upload a new kmod, but that seems to be a red herring, no? [09:48] * xnox thought i was fixing builtin file opening.... and it was mostly harmless before?! [09:48] Apr 19 08:19:23 main-menu[1734]: (process:13782): unknown udeb squashfs-modules [09:48] Apr 19 08:19:23 main-menu[1734]: (process:13782): FATAL: Module squashfs not found. [09:48] Those seem to be the more interesting lines. [09:49] ah, yeah, that's package-level of course [09:49] ok, I'll have to actually try the image and see what's going on there [09:50] Could this just be that the test was run after I NBSed out squashfs-modules-18? [09:50] Though, I assume that should be on the CD, so nevermind. [09:50] it may well have been, because squashfs-modules sure isn't on the image [09:51] this is odd because various other -modules are [09:51] (which means that the sanity check in debian-cd didn't fire) [09:52] Seems like a bunch of them aren't on the image. [09:52] aha, and the image build postdated the seed change [09:52] ! Allowing d-i kernel versions: ['3.8.0-19-generic'] [09:52] cjwatson: I am only a bot, please don't think I'm intelligent :) [09:52] ! Pruned squashfs-modules-3.8.0-18-generic-di from installer [09:52] cjwatson: I am only a bot, please don't think I'm intelligent :) [09:52] oh shut up ubot2 [09:52] So, just poor timing. [09:53] Mystery solved. [09:53] but then things like [09:53] * Chose crypto-modules-3.8.0-18-generic-di out of crypto-modules to satisfy netcfg [09:53] and indeed this is probably why: [09:53] ===== Parallel build; waiting for Ubuntu-Server mirror to sync ===== [09:53] Fri Apr 19 07:07:54 UTC 2013 [09:53] Right, so all the modules that made it are there because of transient deps, not direct seeds. [09:53] so it was building alongside something else and hence the mirror was a bit staler than it should have been [09:54] cdimage's parallel build support isn't perhaps as absolutely perfect as it should be for this (though it's not clear that it can be) [09:54] So the fix is just to respin the ISO part. I'll do that now [09:54] Is there no kernel in the squashfs for server? [09:55] Ahh, guess not. [09:55] nope [11:05] psivaa: should be better now? [11:09] cjwatson: our cron jobs have not yet picked up the new set. Will let you know once they run. [11:10] cjwatson: thanks for the quick fix though :) [11:12] cjwatson: The desktop media-info files still say Alpha. I know that does not have any user impact, but is there a plan to change it? Or Is it that todays desktop images wont be the RC? [11:13] psivaa: I already changed that earlier today in the code [11:13] those desktop images can't be RC [11:13] cjwatson: ack [13:45] ev: well does it matter who files the RT for signing wubi? =) my RTs usually get stuck forever.... Yours are getting done quicker ;-) [13:46] :) you just need to make friends with people in IS/webops [13:46] on it [13:47] ev: thanks. [13:47] * xnox just makes friends with you ;-) [13:48] xnox: ha! :) I don't think the transitive property applies to RT [13:48] oh wait, it just did [13:48] * xnox hides [13:51] RT 60951 [13:56] ev: No permission to view ticket =( [13:56] strange [13:56] maybe after it's trianged in correct queues?! [13:56] yeah, probs [13:57] anyway added to my short list of RTs I am waiting on. [14:02] xnox: if you're blocked on RTs, Steve can raise the priority of them and mention them in his catch up call with IS [14:02] yeah, doit, he wants to have something to talk about there :) [14:02] xnox: it also helps to know whats in front of you: https://portal.admin.canonical.com/ruins?team=losa [14:03] ev: well, _I_ am not blocked on them. They are just fixes that affect the users of our services: manpages.ubuntu.com, geoip-lookup.ubuntu.com, wubi release. [14:04] geoip-lookup is relatively important, I would think [14:04] definitely worth mentioning to Steve [14:05] well geoip is #15 with size estimate XS =) (i hope that's ExtraSmall and not ExtrodinarySophisticated) [14:06] and manpages got reopened and are not up on the board yet. [14:07] any opinions on bug 1170150 [14:07] Launchpad bug 1170150 in grub2 (Ubuntu) "vmlinuz/initrd.img symlinks do not point to signed versions on kernel updates of secure boot UEFI machines" [Medium,Confirmed] https://launchpad.net/bugs/1170150 [14:07] ? [14:11] how is that a grub2 bug? [14:11] it doesn't manage the symlinks [14:11] cjwatson: what does manage symlinks? linux-kernel? [14:11] * cjwatson reassigns to linux [14:12] -> not our problem :) [14:12] love it =) [14:12] (also not a release-critical problem or anything since the symlinks are only ever used for the sort of manual use case the reporter suggests) [14:19] ev: when you will be state side would be able to poke Keybuk about doing a libnih release? or e.g. handing the project over to ~upstart-devel team? https://code.launchpad.net/libnih/+activereviews shows the amount of fixes that are in ubuntu but not upstream, and there hasn't been a bugfix release with those. [14:19] we have a few people on RPM-based distros asking for a tarball release with all of those fixes. [14:20] ev: or is it something you don't talk with Keybuk about? =)))) [14:21] texted him what you said [14:23] ev: thanks. [14:24] fingers crossed that it's just something he can quickly cover off on the google bus [14:24] haha. [14:48] xnox, what do you think of the jumpy "Keyboard layout" step? [14:49] http://goo.gl/YwIcT [14:51] mpt: I am currently staring at the spinning logo around the image. [14:51] =)))) one moment please. [14:55] mpt: description sounds ok. But how does one /change/ layouts any any step? (or are we simply not support that like we currently do). E.g. what if I want English(US) everywhere but at the Name field I got a feeling to type "Дмитрий Ледков"? aka setting up a secondary layout? [14:55] or should we always setup english as a secondary layout and say " you can change layout above, or by pressing Control-x Alt-c Alt-butterfly [14:56] If you set up a non-Latin layout in console-setup then it is always true that you can press Alt+Shift to toggle to English [14:56] xnox, same as normal, using the text entry menu in the menu bar [14:56] (IIRC) [14:57] mpt: ack. [14:57] Which ... actually isn't mentioned at the moment [14:57] cjwatson: I had no idea, and I don't think we tell users that at the keyboard step do we? [14:57] I don't think we do [14:57] fixed [14:57] But we might as well tell people rather than inventing another set of keys :) [14:58] I think we may have told people at one point and it got lost in a redesign [14:58] mpt: is your google doc meant to have a spinner animation as the first figure under Keyboard layout? cause that's what I see here. [14:58] xnox, that happened when I moved it from one part of the document to another. I'm trying to pluck the image out of an older revision. [14:58] * xnox thinks "interation" is a better word than "redesign" as really everything is constantly "redesigned" =))))) [14:59] s/interation/iteration/ [15:00] Fixed! [15:00] Well, I was specifically thinking about before the maverick-redesign branch, but I may well be mistaken [15:01] I've been doing more or less of the design since Ubiquity started, and this is the first I've heard of Alt Shift :-) [15:03] cjwatson: Alt Shift launches Unity HUD for me to search/execute global-menu items [15:03] or if done too quick, does nothing. [15:05] right - I reset to default readd Russian layout and the "key combination to change layouts" has nothing selected. [15:06] * xnox goes to file a bug. [15:07] Bah, I guess the Unity folks didn't know about it either ... [15:08] cjwatson: askubuntu brings up 2 year old questions with total of 20 000 views on approx. "why alt+shift doesn't change keyboard layout" [15:09] enabling alt-shift does work well enough with HUD/Dash/Apps [15:09] so it's just that shortcut is not enabled by default at all. [15:12] It's only enabled by default if you installed with a non-Latin layout [15:12] Or used to be anyway ... [15:20] Русский is non-latin =) i will do a test install at the weekend to test this. [15:21] Should be, yeah ... [15:51] xnox: jacekn is signing wubi now [16:29] xnox: signed wubi is in place [16:41] ev: awesome, what's next to "release it" ? I guess next raring image build will simply pick it up? [16:41] and precise daily as well? [16:41] correct [16:41] what about just wubi.exe downloads from ubuntu.com? [16:42] would those just work after the image build? [16:42] The web team usually make that be a redirect to the one we publish on releases.ubuntu.com [16:42] Or a mirror of it [16:43] cjwatson: yeahp, link from ubuntu.com for precise wubi goes to: http://www.mirrorservice.org/sites/releases.ubuntu.com//precise/wubi.exe [16:43] cjwatson: so would you just republish precise wubi there? or do you want me to test the know signed wubi.exe first? [16:44] Usually done at the next point release [16:44] But if it's a fix for 12.04.2 then we could republish [16:44] Rather have it tested first though [16:45] cjwatson: it's a fix for 12.04.2, so we didn't release any wubi with 12.04.2 but we should have, due to kernel name change to -> *.efi [16:45] cjwatson: ok will test as per precise-daily iso tracker wubi test cases & will report results there, such that it's documented. [16:48] ah yes, that [21:32] hi, during installation it says it will take 53 min to download language packs. i see they are downloading at ~30KB/s not so fast. ive noticed this a couple times recently [21:35] this is for 12.04.2 desktop [21:36] wondering if anybody else has noticed that downloading the language packs is slow [22:29] mattrae_: not something we can really do much about here, I'm afraid ... [22:29] I guess the mirror for your country is suboptimal for you or something