=== doko_ is now known as doko [06:19] FYI, whoever is driving Beta 2, I've got a few uploads that I won't be able to finish until after work tomorrow which will be a few hours past the freeze, it's either Xubuntu specific stuff (xubuntu-docs, gtk-theme-config) or catfish which Studio can pick up on a respin if it happens [06:20] so, please don't bother kicking off Studio beta 2 images until I get that stuff in [06:20] oops, I meant Xubuntu [06:24] I'll see if someone else has time before the freeze === balloons_ is now known as balloons === balloons is now known as Guest41934 [11:50] RAOF, ^^^ now merged as well [11:56] * cjwatson builds kubuntu/precise/daily-live again after a cdimage fix [11:57] cdimage is now entirely in Python (apart from some remaining horribleness in etc/config), so hopefully that's the end of the upheavals [12:01] cjwatson: What does " melior malum quod cognoscis" mean? :) [12:02] it means "use google translate" [12:03] ogra_: that doesn't help though. [12:03] better the evil you know [12:04] ogra_: yeah, gogle translate doesn't work [12:04] stgraber: is it latin? [12:04] yeah [12:04] ah okay [12:04] "Better the evil you know" [12:04] thats what google translate gets me here [12:05] Google translate thought its italian, but anyway, thanks [12:05] you guys dont have latin as your first language set by default ?!? [12:05] * ogra_ shakes head [12:06] where did the world go ... [12:06] *g* [12:06] heh [12:07] oh, wow, unpacking the chromium package source on my chromebook only took 25min ... [12:08] well, that specific sentence should be easy enough for any french speaker with vague latin knowledge to translate without needing google ;) [12:08] ogra_: are you planning on building it on there? [12:08] probably ... [12:08] for now i just wanted to look why it doesnt find stdio.h [12:09] and if v8 is probably easy to disable to at least get it building [12:09] some little easter project :) [12:09] stgraber: or any private schooled child in the uk who is still taught latin for some reason :) [12:09] not really planning on anything though ... [12:11] LOL ! [12:12] libc6-dev-i386 [amd64], [12:12] so what could probably go wrong trying to build it on armhf here [12:12] (no, there is no other libv6-dev entry at all in the deps) [12:13] "better the devil you know" is a more idiomatic English translation [12:14] * ogra_ cant belive that nobody who looked at chromium hasnt catched that before [12:14] i know several people spent hours trying to get it to build [12:14] it's a comment on risk management: given a current known state with problems, and a possible future state with unknown problems, the current state may be better despite the problems [12:14] ogra_: err, libc6-dev is build-essential [12:15] well [12:15] v8/src/../include/v8stdint.h:34:19: fatal error: stdio.h: No such file or directory [12:15] compilation terminated. [12:15] thats the build error [12:15] sure, but the fix is not to add libc6-de [12:15] v [12:15] that looks more like a broken include path or something [12:15] davmor2: or any average Finish school as per Linus' last g+ rant/blog post =) [12:15] #include [12:15] #include [12:16] davmor2: oh, they stopped teaching it in public school over there? I still had Latin and Ancient Greek as part of the standard classes in Switzerland (public school) [12:16] we need to explicitly build-depend on libc6-dev-i386 since it isn't build-essential, but it is strictly wrong to explicitly build-dep on libc6-dev [12:16] not relly redefined ot something [12:16] like I say, more likely a busted include path [12:16] stgraber: it was gone a long time ago from typical curriculum. [12:16] perhaps it's building for a different target there [12:16] ah, yeah, the build log shows it being installed [12:16] in any case you can see at the top of the build log that libc6-dev is installed, along with libc6-dev-armel [12:17] yep [12:17] it's already in the base chroot, it's just upgraded in the build log [12:18] gyp: /var/tmp/builddeb-get-source-nCb6ts/export/chromium-browser-6169/src/build/common.gypi not found (cwd: /build/buildd/chromium-browser-25.0.1364.160/src) while reading includes of build/all.gyp while trying to load build/all.gyp [12:18] make[1]: *** [Makefile] Error 1 [12:18] aha [12:18] xnox: that's unfortunate. The combination of Latin and Ancien Greek is very useful when learning additional languages and to understand a few works of languages you've never seen before. [12:18] stgraber: true. I never did latin nor greek =( [12:19] I wasn't privately-schooled and Latin was still on our default curriculum [12:19] I've found it very useful for understanding languages, as stgraber said. Could do with having Ancient Greek too but ENOTIME [14:41] cdimage people, while working on the image based upgrades I've written a simple python tool that diffs squashfs images. I guess this may come up handy when we're wondering what changed between images. [14:41] Example output is: http://paste.ubuntu.com/5655298/ [14:41] the tool simply takes a source and target squashfs, mounts them both and walks the whole tree doing a sha1sum of everything it sees, then gives the list of additions/changes/removals [14:41] Yep, would be useful; MP against lp:ubuntu-cdimage? :) [14:41] Although cdimage doesn't have root [14:42] I don't suppose it can be done with the userspace tools? [14:42] I guess not, there's no lssquashfs, you'd have to unsquashfs the whole thing [14:42] yeah and that'd be pretty bad performance-wise [14:43] so not something we can easily run on nusakan, but easy to use on our own machines === Guest41934 is now known as balloons [15:07] bdmurray: Could you help me to review https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/1160414 ? [15:07] Launchpad bug 1160414 in ibus-chewing "Use shift keypress to switch to English mode." [Undecided,Confirmed] [15:10] FourDollars: review as in upload or review as in approve from the SRU queue? [15:11] bdmurray: I don't know what is the next step. [15:11] FourDollars: it looks like upload and I can probably do both [15:12] bdmurray: That will be great. :) [15:16] cjwatson, http://paste.ubuntu.com/5655397/ does that look ok to you ? [15:16] ^^^ or infinity [15:17] looks mostly plausible [15:17] the multiarch setup is wrong though [15:18] use 'dpkg --print-foreign-architectures' rather than grepping /etc/dpkg/dpkg.cfg.d/multiarch [15:18] oh ? [15:18] ah, right, that fails on my precise test machine :) [15:18] $ dpkg --print-foreign-architectures [15:18] i386 [15:18] had it for testing [15:18] yeah, but dpkg --add-architecture would fail on precise too :) [15:19] yeah, exept that i have i386 indeed :) [15:19] in multiarch [15:19] IOW you're mixing old and new styles there [15:19] yup [15:20] you also need to edit debian/install [15:20] uh, oh, thanks ! [15:20] I think the rest is fine [15:20] and of course you'll need an RT to update BuildLivecD [15:20] with correct capitalisation [15:20] bdmurray: Is there anything else I should do for https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/1160414 ? [15:20] Launchpad bug 1160414 in ibus-chewing "Use shift keypress to switch to English mode." [Undecided,Confirmed] [15:21] FourDollars: no, I'll handle the rest [15:21] cjwatson, that can wait until i have the firewalls open ... cant test before anyway [15:21] bdmurray: Thanks a lot. [15:22] (in the real env) [15:23] cjwatson, http://paste.ubuntu.com/5655424/ updated [15:24] yep, looks better [15:24] feel free to ask if you want me to do the cdimage side [15:25] k, committing and merging [15:25] since that's all rewritten from what you're likely familiar with [15:25] well, do you think its a quick job for you ? [15:26] else i'll try it myself and move the WI to next month [15:27] should be pretty quick if I know what all the filenames are and what the expected output is [15:27] at some point i have to get familiar with the new code ... not sure thats the right moment though [15:30] cjwatson, the output files will be cm-10.1-${iso_date}-UNOFFICIAL-${subarch}.zip [15:30] back in ~30mins, picking bike up from shop. live filesystem downloading is in lib/cdimage/livefs.py, depending on what you're doing you may also need to adjust lib/cdimage/build.py, and publication is in lib/cdimage/tree.py; test code in lib/cdimage/tests/ and ./run-tests. if you want to look in that half an hour then feel free, otherwise I'll look when I get back [15:30] i.e. cm-10.1-20130328-UNOFFICIAL-mako.zip [15:30] ok [16:39] plars, looking at https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-cdimage-android-builds i assume your WI is for next month ? (just miving mine around, happy to do that for yours too) [16:47] ogra_: ah, it had the wrong lp id so I haven't even seen this one [16:47] ogra_: I've actually got that all covered in another BP [16:47] well, not sure who added it there :) should i rip it out ? [16:48] ogra_: I think so, it's already covered elsewhere for desktop, and I'm getting IS to fix the firewall rules at the moment [16:49] ogra_: probably it will happen next week. For touch I'd still like to sync up with sergiusens a bit on it, but he's going to be doing basically the same thing from a different jenkins for that image [16:49] ogra_: and I don't think the desktop stuff fits in a bp for android builds :) [16:49] next week is next month ;) [16:49] plars, we wont buuild on jenkins anymore once that BP is implemented [16:50] -u [16:52] (thats the whole point of it) [16:52] ogra_: yes, but the tests run out of jenkins [16:52] ogra_: and that's what will trigger the transition [16:52] ogra_: the ones I have are in https://blueprints.launchpad.net/ubuntu/+spec/qa-r-staging-iso-testing [16:53] i'm not so sure we can even test the android images in jenkins ... [16:53] ogra_: it will just cover a few images at first, and move on to more as we have smoke coverage for them [16:53] do you have any automated tests runing on the HW ? [16:53] ogra_: we have automated tests running on the ubuntu touch images right now if that's what you mean [16:53] for the android side ? or just for the ubuntu container content ? [16:54] ogra_: I don't think anything specifically targets the android specific bits - sergiusens might have something but we don't [16:54] right ... we should work something out for this ... [16:54] indeed [16:54] since i belive the android side is totally uncovered atm [16:55] dropped the desktop item from the WI list for now [16:55] fo android testing i think we need a separate spec for later (not right now though) [16:56] ogra_: if we can automatically test them anywhere, we can test them in jenkins - since jenkins typically just farms out tests to slaves [16:56] cjwatson, yes, but it needs HW backing [16:56] and i doubt there is anything set up [16:56] the specific WI above was clearly stating desktop isos thogh [16:57] which is why i removed it from that spec ... (and plars seems to cover it in his other spec already) [16:58] well, uh [16:58] the *original* WI was for touch [16:58] oh [16:58] we embraced and extended it for desktop because that could be done first [16:59] cjwatson: it still includes a WI for the touch image, assigned to sergiusens [16:59] let me put it back then and rephrase a bit [16:59] [sergiusens] Update PS Jenkins to poll cdimage and trigger /pending update on Touch images once smoke tests pass: TODO [16:59] yep [17:00] ah, yes, that way round. the desktop WI is fine in the qa spec [17:00] oh, and its exactly the same text [17:00] with s/Touch/Desktop/ [17:01] * ogra_ leaves it as is then ... waiting for feedback from sergio to move his WI to month-6 too [17:01] sorry for all the mail spam ... i wish we could restrict that to WI owners and the approver or so [17:02] ogra_: any luck with cdimage or would you like me to look? [17:02] cjwatson, had a little cat emergency here, didnt even get to look at it yet [17:02] so yes, if you dont mind ... else i'll make it my easter task (have nothing palanned there anyway) [17:02] *planned [17:03] we cant really test it in production yet ... until the IS bits are done, so if you have something more urgent to do, dont bother [17:04] s'what the test suite is for :) [17:04] in "cm-10.1-20130328-UNOFFICIAL-mako.zip", which bits are variable and based on what? [17:04] also can you make there be symlinks so I don't have to guess the livefs-side build id? [17:04] makoi is the subarch ... (at least thats how i planned it) [17:04] *mako ... [17:05] so there's one livefs build for each subarch? [17:05] yeah [17:05] (mentally substitute something more appropriate for "livefs") [17:05] maguro mako grouper manta [17:06] thats the list of subarches we'll build for now [17:06] * plars can't help but apply the linaro concept of hwpack here [17:06] plars, well, yeah, it kind of is a hwpack [17:07] theoretically they are "targets" ... not even arches ... [17:07] and practically they are armel+$subarch ... as android builds arent armhf [17:07] very chaotic ... [17:08] plars, hmm, not even "kind of" ... it *is* a hwpack [17:08] it'll be much less painful to refer to them as subarches within cdimage [17:09] ogra_: yeah, but it's hard to make that shift given that hwpacks were something we did for the ubuntu images, not android [17:09] since the rootfs we use on top is totally HW independent [17:09] ogra_: but yeah [17:09] cjwatson, right, thats why i used that term :) [17:09] since that already has the right arch+subarch representation [17:09] well ... [17:09] we dont really have armel [17:10] (anymore ... officially ... blah blah ... ) [17:10] cdimage doesn't care about that :) [17:11] it's certainly a little exciting that this is armhf on top of armel+blah, but I'm sure we can cope [17:11] yup, i know ... but i know i'll have to answer silly questions about it :) [17:11] (already had) [17:13] the rootfs build will be intresting though ... i think its the first time we build armhf without any subarch [17:14] will show us all the corner cases in teh code where we assumed there will always be a subarch [17:14] (though i guess these are rather in debian-cd than in cdimage) [17:17] ogra_: It's not the first amrhf without subarch, there's core. [17:17] oh ! [17:17] totally forgot that one [17:20] and we should actually be able to re-use all its code for touch rootfses ... since they dont need any post processing for bootability [17:22] hey guys is the latest iso missing the secureboot stuff? [17:28] davmor2: not that I know of, --verbose [17:30] cjwatson: I've just tried an install on my ideapad Y580. I get the EFI boot menu from the cd, the install went fine on reboot it says "Ubuntu has been blocked by the current security policy." [17:31] would need to see installation logs to see if it remembered to install the right things [17:31] cjwatson: can I get those from a live cd or not? [17:32] sure, mount your installed system and look in /var/log/installer/ within it [17:33] cjwatson: that's fine then give me a few minutes [17:34] xnox: was the webcam page removed from the install process too out of interest? [17:34] ogra_: is "cm-10.1" a constant string? what does it mean? [17:34] davmor2,xnox: yes, intentionally [17:34] cjwatson, cyanogenmod 10.1 [17:34] cjwatson: ah that's fine [17:34] ogra_: presumably that might change at some point in the future? [17:34] should it be tied to Ubuntu series or something? [17:34] cjwatson, if we bump to a newer cyanogenmod, yeah [17:35] http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/current/ [17:35] thats how we call them in the end [17:35] quantal-preinstalled-armel+$subarch.zip [17:35] Right. I wonder if it would be smarter to create symlinks on the livecd-rootfs side then? [17:36] yeah ... [17:36] Since we need symlinks to avoid cdimage needing to guess the build ID anyway [17:36] oh hmm, might be that i will have to extend livecd-rootfs later anyway ... [17:36] i currently dont take "boot", "system" and "recovery" into account [17:36] cjwatson: it's been a while /var/log/installer/syslog anything else you need [17:37] not that they are overly important atm [17:37] davmor2: that'll do for starters. (note I'm about to finish for Easter, it may not be a good idea to assume I'll be able to deal with it right now) [17:37] ogra_: doesn't phablet-flash use them? [17:38] cjwatson: I'll be happy with a debug for now :) I can use my non-uefi system without issue till it is fixed :) [17:38] But yeah, it would be nice if livecd-rootfs could just create "quantal-preinstalled-armel+*.zip" symlinks [17:38] or raring- of course [17:39] cjwatson, phablet-flash only uses quantal-preinstalled-armel+$subarch.zip and the rootfs zip [17:39] the others are for use with fastboot directly [17:39] if you tinker manually with the device ... [17:40] (phablet-flash works on the adb level, doesnt touch fastboot/bootloader mode) [17:44] i'll fix my script to provide them from livecd-rootfs but dont bother with them yet [17:46] cjwatson: http://ubuntuone.com/7AYGMhTAuDswfLCCn9y8W5 [17:50] done ... [18:02] davmor2: Well, it installed the right pieces, but looks as though there's something wrong with either the kernel or your firmware, perhaps? [18:02] Mar 28 17:12:54 ubuntu kernel: [ 716.795993] efivars: set_variable() failed: status=8000000000000009 [18:02] then a couple more of those and then [18:02] Mar 28 17:12:57 ubuntu ubiquity: Can't access efivars filesystem at /sys/firmware/efi/efivars, aborting [18:03] So I think that probably confused the installer into not installing SB pieces [18:03] It just installed the right *debs* [18:04] I *think*. It's a little hard to tell [18:04] cjwatson: I'm assuming a trip to #ubuntu-kernel is possibly in my near future then :) [18:09] livecd-rootfs actually calls its symlinks livecd.ubuntu.squashfs and that kind of thing [18:09] Or things like livecd.ubuntu.kernel-generic when it needs additional information [18:10] It might not be a terrible idea to try to line up with it, although it's not required [18:10] cjwatson, well, i dont want to keep the 20G build tree around ... [18:10] I don't see how the build tree is relevant ... [18:10] i need to copy them out there [18:10] before wiping it [18:11] I meant symlinks to cm-10.1-20130328-UNOFFICIAL-mako.zip [18:11] Naturally you need to copy out to that [18:11] However, please do make sure that at least your output directories and log files line up with how livecd-rootfs does things [18:11] right [18:20] livecd.ubuntu-touch-$timestamp-armel.$image-$subarch then ... [18:20] (for system, recovery and boot) [18:20] i'm not really sure how to call the actual zip though ... [18:21] just .zip ? [18:22] Putting $subarch at the end wouldn't be uniform [18:22] Well, sort of, I suppose [18:22] Have a look at e.g. how cadejo is laid out [18:22] well, thats what i see on the other armhf builds [18:23] looking at nexus7 output atm [18:23] They have livecd.ubuntu-$subarch.$image[-$kernel_flavour] [18:23] Generally [18:23] oh, crap ... nexus7 is special ... the flavour name has the subarch in it [18:24] The weird bit is that livefs subarch builds get the subarch tacked onto the project name; that's really for being able to build multiple subarches independently [18:24] Which you want here as well [18:25] So the full path would be something like /~buildd/LiveCD/raring/ubuntu-touch-mako/livecd.ubuntu-touch-mako.zip ? [18:25] yep [18:26] The naming is a bit mad; it depends where you think it's better to put the extra complexity due to differences, really [18:26] for system etc., I suppose you get to make something up [18:27] Wouldn't be too unreasonable for it to be .system.zip or -system.zip [18:27] Er, except it's .img, YKWIM [18:28] yeah, i had looked at n7 and made it -system.img-$subarch ... i'll flip that around so it ends in system.img [18:29] livecd.ubuntu-touch-$codename.$image.img [18:29] thats what i have now [18:29] and livecd.ubuntu-touch-$codename.zip for the zip# [18:30] -# [18:30] Yeah, I don't think this is really analogous to a kernel flavour, so best not at the end [18:30] OK, sounds good [18:31] * ogra_ commits and uploads new livecd-rootfs [18:31] i didnt make them links btw ... just changed the cp commands [18:32] or is there any reason to artificially have links for them ? [18:33] ah, BuildLiveCD creates them anyway, for the timestamps [18:35] It might be useful to know the underlying cm-10.1- naming, but your choice [18:35] if its needed i can just add a link with the original name easily later [18:35] Sure [18:35] i doubt there is any need for it ever though [18:37] and uploaded [20:12] ScottK: re bug 1126205 ; just about done reviewing and getting everything to build and rebuild [20:12] Launchpad bug 1126205 in indicator-appmenu (Ubuntu) "[FFe] Bring Unity appmenu / HUD integration to Qt5" [Undecided,In progress] https://launchpad.net/bugs/1126205 [20:13] I'll upload qtbase-opensource-src in a minute, and then I'll start the builds for appmenu-qt and libdbusmenu-qt in didrocks' daily release jenkisn jobs... I'm just not sure how long that's goingto take exactly to build [20:13] hopefully not long [20:46] FYI, I'm waiting after jenkins / cu2d/ builds in the ubuntu-unity/daily-build PPA to complete to auto-release appmenu-qt and libdbusmenu-qt (to go with the bug above), those might be a little bit late [20:47] (And before anyone suggests scoring them up, I already said I wouldn't do that, because security builds trump random attempts to beat arbitrary freeze deadlines, but I'm fine with those PPA copies coming a bit late) [20:49] infinity, you could score them between ordinary builds and security [20:49] infinity, or you could just stop doing IRC during your days off ;-) [20:49] They'll be fine. [20:49] cyphermox: which qtbase-opensourse-src are you uploading? as staged in the lp:~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src ? [20:49] hmm... that looks released already. [20:50] cyphermox: https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.0.1+dfsg-0ubuntu4 it's building already with appmenu support..... [20:51] bah, that is your upload. and me fail to look at the clock =) [20:52] yeah, that's my upload, and yes it comes from that branch precisely [20:52] it was already in the branch and checked by didrocks, tested by sil as well [20:55] and tested by me =) Yeah for GtkStyle fixes, to make qt5 apps non-ugly ;-) === Ursinha-afk is now known as Ursula === pgraner is now known as pgraner-afk [21:29] me again... hat in hand.... would any SRU folks mind looking at the unapproved alsa-utils uploads in the precise and quantal queues for me? They're really trivial changes, I know, but it's blocking for some people. [21:36] marrusl: Sec. [21:39] marrusl: Why the different CaSe sEnSiTivItY between precise and quantal? [21:40] marrusl: Fairly sure that dpkg-gencontrol fixes that on the fly to be correct, but not positive. Would be better to have it correct in the packaging. [21:41] infinity, weird and good catch. I was always trying to be consistent before. apparently not. I don't mind resubmitting. [21:42] marrusl: I'll commit the fix to bzr, forcefully mangle the tag, and reupload for you. [21:42] infinity, dpkg-gencontrol is something I would run manually? [21:42] marrusl: No, dpkg-gencontrol being the thing run by dh_gencontrol that turns debian/control into package/DEBIAN/control in the binary packages. [21:46] infinity, ah. thanks. i see now. still, no reason to have inconsistent source packages. [21:46] Yup, already fixed. [21:48] http://bazaar.launchpad.net/~ubuntu-audio-dev/alsa-utils/ubuntu.precise/revision/122 [21:48] And uploaded. And will accept shortly.