[06:19] <micahg> 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] <micahg> so, please don't bother kicking off Studio beta 2 images until I get that stuff in
[06:20] <micahg> oops, I meant Xubuntu
[06:24] <micahg> I'll see if someone else has time before the freeze
[11:50] <doko> RAOF, ^^^ now merged as well
[11:56]  * cjwatson builds kubuntu/precise/daily-live again after a cdimage fix
[11:57] <cjwatson> 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] <vibhav> cjwatson: What does " melior malum quod cognoscis" mean? :)
[12:02] <ogra_> it means "use google translate"
[12:03] <xnox> ogra_: that doesn't help though.
[12:03] <stgraber> better the evil you know
[12:04] <vibhav> ogra_: yeah, gogle translate doesn't work
[12:04] <vibhav> stgraber: is it latin?
[12:04] <stgraber> yeah
[12:04] <vibhav> ah okay
[12:04] <ogra_> "Better the evil you know"
[12:04] <ogra_> thats what google translate gets me here
[12:05] <vibhav> Google translate thought its italian, but anyway, thanks
[12:05] <ogra_> you guys dont have latin as your first language set by default ?!?
[12:05]  * ogra_ shakes head
[12:06] <ogra_> where did the world go ...
[12:06] <ogra_> *g*
[12:06] <vibhav> heh
[12:07] <ogra_> oh, wow, unpacking the chromium package source on my chromebook only took 25min ...
[12:08] <stgraber> well, that specific sentence should be easy enough for any french speaker with vague latin knowledge to translate without needing google ;)
[12:08] <stgraber> ogra_: are you planning on building it on there?
[12:08] <ogra_> probably ...
[12:08] <ogra_> for now i just wanted to look why it doesnt find stdio.h
[12:09] <ogra_> and if v8 is probably easy to disable to at least get it building
[12:09] <ogra_> some little easter project :)
[12:09] <davmor2> stgraber: or any private schooled child in the uk who is still taught latin for some reason :)
[12:09] <ogra_> not really planning on anything though ...
[12:11] <ogra_> LOL !
[12:12] <ogra_> libc6-dev-i386 [amd64],
[12:12] <ogra_> so what could probably go wrong trying to build it on armhf here
[12:12] <ogra_> (no, there is no other libv6-dev entry at all in the deps)
[12:13] <cjwatson> "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] <ogra_> i know several people spent hours trying to get it to build
[12:14] <cjwatson> 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] <cjwatson> ogra_: err, libc6-dev is build-essential
[12:15] <ogra_> well
[12:15] <ogra_> v8/src/../include/v8stdint.h:34:19: fatal error: stdio.h: No such file or directory
[12:15] <ogra_> compilation terminated.
[12:15] <ogra_> thats the build error
[12:15] <cjwatson> sure, but the fix is not to add libc6-de
[12:15] <cjwatson> v
[12:15] <cjwatson> that looks more like a broken include path or something
[12:15] <xnox> davmor2: or any average Finish school as per Linus' last g+ rant/blog post =)
[12:15] <ogra_> #include <stddef.h>
[12:15] <ogra_> #include <stdio.h>
[12:16] <stgraber> 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] <cjwatson> 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] <ogra_> not relly redefined ot something
[12:16] <cjwatson> like I say, more likely a busted include path
[12:16] <xnox> stgraber: it was gone a long time ago from typical curriculum.
[12:16] <cjwatson> perhaps it's building for a different target there
[12:16] <ogra_> ah, yeah, the build log shows it being installed
[12:16] <cjwatson> 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] <ogra_> yep
[12:17] <cjwatson> it's already in the base chroot, it's just upgraded in the build log
[12:18] <ogra_> 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] <ogra_> make[1]: *** [Makefile] Error 1
[12:18] <ogra_> aha
[12:18] <stgraber> 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] <xnox> stgraber: true. I never did latin nor greek =(
[12:19] <cjwatson> I wasn't privately-schooled and Latin was still on our default curriculum
[12:19] <cjwatson> I've found it very useful for understanding languages, as stgraber said.  Could do with having Ancient Greek too but ENOTIME
[14:41] <stgraber> 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] <stgraber> Example output is: http://paste.ubuntu.com/5655298/
[14:41] <stgraber> 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] <cjwatson> Yep, would be useful; MP against lp:ubuntu-cdimage? :)
[14:41] <cjwatson> Although cdimage doesn't have root
[14:42] <cjwatson> I don't suppose it can be done with the userspace tools?
[14:42] <cjwatson> I guess not, there's no lssquashfs, you'd have to unsquashfs the whole thing
[14:42] <stgraber> yeah and that'd be pretty bad performance-wise
[14:43] <stgraber> so not something we can easily run on nusakan, but easy to use on our own machines
[15:07] <FourDollars> bdmurray: Could you help me to review https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/1160414 ?
[15:07] <ubot2`> Launchpad bug 1160414 in ibus-chewing "Use shift keypress to switch to English mode." [Undecided,Confirmed]
[15:10] <bdmurray> FourDollars: review as in upload or review as in approve from the SRU queue?
[15:11] <FourDollars> bdmurray: I don't know what is the next step.
[15:11] <bdmurray> FourDollars: it looks like upload and I can probably do both
[15:12] <FourDollars> bdmurray: That will be great. :)
[15:16] <ogra_> cjwatson, http://paste.ubuntu.com/5655397/ does that look ok to you ?
[15:16] <ogra_> ^^^ or infinity
[15:17] <cjwatson> looks mostly plausible
[15:17] <cjwatson> the multiarch setup is wrong though
[15:18] <cjwatson> use 'dpkg --print-foreign-architectures' rather than grepping /etc/dpkg/dpkg.cfg.d/multiarch
[15:18] <ogra_> oh ?
[15:18] <ogra_> ah, right, that fails on my precise test machine :)
[15:18] <cjwatson> $ dpkg --print-foreign-architectures
[15:18] <cjwatson> i386
[15:18] <ogra_> had it for testing
[15:18] <cjwatson> yeah, but dpkg --add-architecture would fail on precise too :)
[15:19] <ogra_> yeah, exept that i have i386 indeed :)
[15:19] <ogra_> in multiarch
[15:19] <cjwatson> IOW you're mixing old and new styles there
[15:19] <ogra_> yup
[15:20] <cjwatson> you also need to edit debian/install
[15:20] <ogra_> uh, oh, thanks !
[15:20] <cjwatson> I think the rest is fine
[15:20] <cjwatson> and of course you'll need an RT to update BuildLivecD
[15:20] <cjwatson> with correct capitalisation
[15:20] <FourDollars> bdmurray: Is there anything else I should do for https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/1160414 ?
[15:20] <ubot2`> Launchpad bug 1160414 in ibus-chewing "Use shift keypress to switch to English mode." [Undecided,Confirmed]
[15:21] <bdmurray> FourDollars: no, I'll handle the rest
[15:21] <ogra_> cjwatson, that can wait until i have the firewalls open ... cant test before anyway
[15:21] <FourDollars> bdmurray: Thanks a lot.
[15:22] <ogra_> (in the real env)
[15:23] <ogra_> cjwatson, http://paste.ubuntu.com/5655424/ updated
[15:24] <cjwatson> yep, looks better
[15:24] <cjwatson> feel free to ask if you want me to do the cdimage side
[15:25] <ogra_> k, committing and merging
[15:25] <cjwatson> since that's all rewritten from what you're likely familiar with
[15:25] <ogra_> well, do you think its a quick job for you ?
[15:26] <ogra_> else i'll try it myself and move the WI to next month
[15:27] <cjwatson> should be pretty quick if I know what all the filenames are and what the expected output is
[15:27] <ogra_> at some point i have to get familiar with the new code ... not sure thats the right moment though
[15:30] <ogra_> cjwatson, the output files will be cm-10.1-${iso_date}-UNOFFICIAL-${subarch}.zip
[15:30] <cjwatson> 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] <ogra_> i.e. cm-10.1-20130328-UNOFFICIAL-mako.zip
[15:30] <ogra_> ok
[16:39] <ogra_> 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] <plars> ogra_: ah, it had the wrong lp id so I haven't even seen this one
[16:47] <plars> ogra_: I've actually got that all covered in another BP
[16:47] <ogra_> well, not sure who added it there :) should i rip it out ?
[16:48] <plars> 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] <plars> 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] <plars> ogra_: and I don't think the desktop stuff fits in a bp for android builds :)
[16:49] <ogra_> next week is next month ;)
[16:49] <ogra_> plars, we wont buuild on jenkins anymore once that BP is implemented
[16:50] <ogra_> -u
[16:52] <ogra_> (thats the whole point of it)
[16:52] <plars> ogra_: yes, but the tests run out of jenkins
[16:52] <plars> ogra_: and that's what will trigger the transition
[16:52] <plars> ogra_: the ones I have are in https://blueprints.launchpad.net/ubuntu/+spec/qa-r-staging-iso-testing
[16:53] <ogra_> i'm not so sure we can even test the android images in jenkins ...
[16:53] <plars> ogra_: it will just cover a few images at first, and move on to more as we have smoke coverage for them
[16:53] <ogra_> do you have any automated tests runing on the HW ?
[16:53] <plars> ogra_: we have automated tests running on the ubuntu touch images right now if that's what you mean
[16:53] <ogra_> for the android side ? or just for the ubuntu container content ?
[16:54] <plars> ogra_: I don't think anything specifically targets the android specific bits - sergiusens might have something but we don't
[16:54] <ogra_> right ... we should work something out for this ...
[16:54] <plars> indeed
[16:54] <ogra_> since i belive the android side is totally uncovered atm
[16:55] <ogra_> dropped the desktop item from the WI list for now
[16:55] <ogra_> fo android testing i think we need a separate spec for later (not right now though)
[16:56] <cjwatson> 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] <ogra_> cjwatson, yes, but it needs HW backing
[16:56] <ogra_> and i doubt there is anything set  up
[16:56] <ogra_> the specific WI above was clearly stating desktop isos thogh
[16:57] <ogra_> which is why i removed it from that spec ... (and plars seems to cover it in his other spec already)
[16:58] <cjwatson> well, uh
[16:58] <cjwatson> the *original* WI was for touch
[16:58] <ogra_> oh
[16:58] <cjwatson> we embraced and extended it for desktop because that could be done first
[16:59] <plars> cjwatson: it still includes a WI for the touch image, assigned to sergiusens
[16:59] <ogra_> let me put it back then and rephrase a bit
[16:59] <plars> [sergiusens] Update PS Jenkins to poll cdimage and trigger /pending update on Touch images once smoke tests pass: TODO
[16:59] <ogra_> yep
[17:00] <cjwatson> ah, yes, that way round.  the desktop WI is fine in the qa spec
[17:00] <ogra_> oh, and its exactly the same text
[17:00] <ogra_> 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] <ogra_> sorry for all the mail spam ... i wish we could restrict that to WI owners and the approver or so
[17:02] <cjwatson> ogra_: any luck with cdimage or would you like me to look?
[17:02] <ogra_> cjwatson, had a little cat emergency here, didnt even get to look at it yet
[17:02] <ogra_> so yes, if you dont mind ... else i'll make it my easter task (have nothing palanned there anyway)
[17:02] <ogra_> *planned
[17:03] <ogra_> 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] <cjwatson> s'what the test suite is for :)
[17:04] <cjwatson> in "cm-10.1-20130328-UNOFFICIAL-mako.zip", which bits are variable and based on what?
[17:04] <cjwatson> also can you make there be symlinks so I don't have to guess the livefs-side build id?
[17:04] <ogra_> makoi is the subarch ... (at least thats how i planned it)
[17:04] <ogra_> *mako ...
[17:05] <cjwatson> so there's one livefs build for each subarch?
[17:05] <ogra_> yeah
[17:05] <cjwatson> (mentally substitute something more appropriate for "livefs")
[17:05] <ogra_> maguro mako grouper manta
[17:06] <ogra_> 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] <ogra_> plars, well, yeah, it kind of is a hwpack
[17:07] <ogra_> theoretically they are "targets" ... not even arches ...
[17:07] <ogra_> and practically they are armel+$subarch ... as android builds arent armhf
[17:07] <ogra_> very chaotic ...
[17:08] <ogra_> plars, hmm, not even "kind of" ... it *is* a hwpack
[17:08] <cjwatson> it'll be much less painful to refer to them as subarches within cdimage
[17:09] <plars> 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] <ogra_> since the rootfs we use on top is totally HW independent
[17:09] <plars> ogra_: but yeah
[17:09] <ogra_> cjwatson, right, thats why i used that term :)
[17:09] <cjwatson> since that already has the right arch+subarch representation
[17:09] <ogra_> well ...
[17:09] <ogra_> we dont really have armel
[17:10] <ogra_> (anymore ... officially ... blah blah ... )
[17:10] <cjwatson> cdimage doesn't care about that :)
[17:11] <cjwatson> it's certainly a little exciting that this is armhf on top of armel+blah, but I'm sure we can cope
[17:11] <ogra_> yup, i know ... but i know i'll have to answer silly questions about it :)
[17:11] <ogra_> (already had)
[17:13] <ogra_> the rootfs build will be intresting though ... i think its the first time we build armhf without any subarch
[17:14] <ogra_> will show us all the corner cases in teh code where we assumed there will always be a subarch
[17:14] <ogra_> (though i guess these are rather in debian-cd than in cdimage)
[17:17] <infinity> ogra_: It's not the first amrhf without subarch, there's core.
[17:17] <ogra_> oh !
[17:17] <ogra_> totally forgot that one
[17:20] <ogra_> 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] <davmor2> hey guys is the latest iso missing the secureboot stuff?
[17:28] <cjwatson> davmor2: not that I know of, --verbose
[17:30] <davmor2> 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] <cjwatson> would need to see installation logs to see if it remembered to install the right things
[17:31] <davmor2> cjwatson: can I get those from a live cd or not?
[17:32] <cjwatson> sure, mount your installed system and look in /var/log/installer/ within it
[17:33] <davmor2> cjwatson: that's fine then give me a few minutes
[17:34] <davmor2> xnox: was the webcam page removed from the install process too out of interest?
[17:34] <cjwatson> ogra_: is "cm-10.1" a constant string?  what does it mean?
[17:34] <cjwatson> davmor2,xnox: yes, intentionally
[17:34] <ogra_> cjwatson, cyanogenmod 10.1
[17:34] <davmor2> cjwatson: ah that's fine
[17:34] <cjwatson> ogra_: presumably that might change at some point in the future?
[17:34] <cjwatson> should it be tied to Ubuntu series or something?
[17:34] <ogra_> cjwatson, if we bump to a newer cyanogenmod, yeah
[17:35] <ogra_> http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/current/
[17:35] <ogra_> thats how we call them in the end
[17:35] <ogra_> quantal-preinstalled-armel+$subarch.zip
[17:35] <cjwatson> Right.  I wonder if it would be smarter to create symlinks on the livecd-rootfs side then?
[17:36] <ogra_> yeah ...
[17:36] <cjwatson> Since we need symlinks to avoid cdimage needing to guess the build ID anyway
[17:36] <ogra_> oh hmm, might be that i will have to extend livecd-rootfs later anyway ...
[17:36] <ogra_> i currently dont take "boot", "system" and "recovery" into account
[17:36] <davmor2> cjwatson: it's been a while /var/log/installer/syslog anything else you need
[17:37] <ogra_> not that they are overly important atm
[17:37] <cjwatson> 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] <cjwatson> ogra_: doesn't phablet-flash use them?
[17:38] <davmor2> 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] <cjwatson> But yeah, it would be nice if livecd-rootfs could just create "quantal-preinstalled-armel+*.zip" symlinks
[17:38] <cjwatson> or raring- of course
[17:39] <ogra_> cjwatson, phablet-flash only uses quantal-preinstalled-armel+$subarch.zip and the rootfs zip
[17:39] <ogra_> the others are for use with fastboot directly
[17:39] <ogra_> if you tinker manually with the device ...
[17:40] <ogra_> (phablet-flash works on the adb level, doesnt touch fastboot/bootloader mode)
[17:44] <ogra_> i'll fix my script to provide them from livecd-rootfs but dont bother with them yet
[17:46] <davmor2> cjwatson: http://ubuntuone.com/7AYGMhTAuDswfLCCn9y8W5
[17:50] <ogra_> done ...
[18:02] <cjwatson> 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] <cjwatson> Mar 28 17:12:54 ubuntu kernel: [  716.795993] efivars: set_variable() failed: status=8000000000000009
[18:02] <cjwatson> then a couple more of those and then
[18:02] <cjwatson> Mar 28 17:12:57 ubuntu ubiquity: Can't access efivars filesystem at /sys/firmware/efi/efivars, aborting
[18:03] <cjwatson> So I think that probably confused the installer into not installing SB pieces
[18:03] <cjwatson> It just installed the right *debs*
[18:04] <cjwatson> I *think*.  It's a little hard to tell
[18:04] <davmor2> cjwatson: I'm assuming a trip to #ubuntu-kernel is possibly in my near future then :)
[18:09] <cjwatson> livecd-rootfs actually calls its symlinks livecd.ubuntu.squashfs and that kind of thing
[18:09] <cjwatson> Or things like livecd.ubuntu.kernel-generic when it needs additional information
[18:10] <cjwatson> It might not be a terrible idea to try to line up with it, although it's not required
[18:10] <ogra_> cjwatson, well, i dont want to keep the 20G build tree around ...
[18:10] <cjwatson> I don't see how the build tree is relevant ...
[18:10] <ogra_> i need to copy them out there
[18:10] <ogra_> before wiping it
[18:11] <cjwatson> I meant symlinks to cm-10.1-20130328-UNOFFICIAL-mako.zip
[18:11] <cjwatson> Naturally you need to copy out to that
[18:11] <cjwatson> However, please do make sure that at least your output directories and log files line up with how livecd-rootfs does things
[18:11] <ogra_> right
[18:20] <ogra_> livecd.ubuntu-touch-$timestamp-armel.$image-$subarch then ...
[18:20] <ogra_> (for system, recovery and boot)
[18:20] <ogra_> i'm not really sure how to call the actual zip though ...
[18:21] <ogra_> just .zip ?
[18:22] <cjwatson> Putting $subarch at the end wouldn't be uniform
[18:22] <cjwatson> Well, sort of, I suppose
[18:22] <cjwatson> Have a look at e.g. how cadejo is laid out
[18:22] <ogra_> well, thats what i see on the other armhf builds
[18:23] <ogra_> looking at nexus7 output atm
[18:23] <cjwatson> They have livecd.ubuntu-$subarch.$image[-$kernel_flavour]
[18:23] <cjwatson> Generally
[18:23] <ogra_> oh, crap ... nexus7 is special ... the flavour name has the subarch in it
[18:24] <cjwatson> 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] <cjwatson> Which you want here as well
[18:25] <cjwatson> So the full path would be something like /~buildd/LiveCD/raring/ubuntu-touch-mako/livecd.ubuntu-touch-mako.zip ?
[18:25] <ogra_> yep
[18:26] <cjwatson> 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] <cjwatson> for system etc., I suppose you get to make something up
[18:27] <cjwatson> Wouldn't be too unreasonable for it to be .system.zip or -system.zip
[18:27] <cjwatson> Er, except it's .img, YKWIM
[18:28] <ogra_> 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] <ogra_> livecd.ubuntu-touch-$codename.$image.img
[18:29] <ogra_> thats what i have now
[18:29] <ogra_> and livecd.ubuntu-touch-$codename.zip for the zip#
[18:30] <ogra_> -#
[18:30] <cjwatson> Yeah, I don't think this is really analogous to a kernel flavour, so best not at the end
[18:30] <cjwatson> OK, sounds good
[18:31]  * ogra_ commits and uploads new livecd-rootfs
[18:31] <ogra_> i didnt make them links btw ... just changed the cp commands
[18:32] <ogra_> or is there any reason to artificially have links for them ?
[18:33] <ogra_> ah, BuildLiveCD creates them anyway, for the timestamps
[18:35] <cjwatson> It might be useful to know the underlying cm-10.1- naming, but your choice
[18:35] <ogra_> if its needed i can just add a link with the original name easily later
[18:35] <cjwatson> Sure
[18:35] <ogra_> i doubt there is any need for it ever though
[18:37] <ogra_> and uploaded
[20:12] <cyphermox> ScottK: re bug 1126205 ; just about done reviewing and getting everything to build and rebuild
[20:12] <ubot2`> 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] <cyphermox> 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] <cyphermox> hopefully not long
[20:46] <cyphermox> 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] <infinity> (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] <seb128> infinity, you could score them between ordinary builds and security
[20:49] <seb128> infinity, or you could just stop doing IRC during your days off ;-)
[20:49] <infinity> They'll be fine.
[20:49] <xnox> cyphermox: which qtbase-opensourse-src are you uploading? as staged in the lp:~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src ?
[20:49] <xnox> hmm... that looks released already.
[20:50] <xnox> cyphermox: https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.0.1+dfsg-0ubuntu4 it's building already with appmenu support.....
[20:51] <xnox> bah, that is your upload. and me fail to look at the clock =)
[20:52] <cyphermox> yeah, that's my upload, and yes it comes from that branch precisely
[20:52] <cyphermox> it was already in the branch and checked by didrocks, tested by sil as well
[20:55] <xnox> and tested by me =) Yeah for GtkStyle fixes, to make qt5 apps non-ugly ;-)
[21:29] <marrusl> 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] <infinity> marrusl: Sec.
[21:39] <infinity> marrusl: Why the different CaSe sEnSiTivItY between precise and quantal?
[21:40] <infinity> 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] <marrusl> infinity, weird and good catch.  I was always trying to be consistent before.  apparently not.  I don't mind resubmitting.
[21:42] <infinity> marrusl: I'll commit the fix to bzr, forcefully mangle the tag, and reupload for you.
[21:42] <marrusl> infinity, dpkg-gencontrol is something I would run manually?
[21:42] <infinity> 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] <marrusl> infinity, ah.  thanks.  i see now.  still, no reason to have inconsistent source packages.
[21:46] <infinity> Yup, already fixed.
[21:48] <infinity> http://bazaar.launchpad.net/~ubuntu-audio-dev/alsa-utils/ubuntu.precise/revision/122
[21:48] <infinity> And uploaded.  And will accept shortly.