[00:40] <siretart> infinity: is libav9 good to upload now? If not, what kind of coordination do you think would be best for this package? note that the transition has been completed in debian, but in ubuntu, we may have some additional undermaintained packages that break.
[00:42] <infinity> siretart: I'm ready for it whenever, yeah.  I assume Ubuntu carries a delta that needs to be addressed.
[00:43] <infinity> In fact, looks like the last uploader was me, for wgrant.
[00:43] <infinity> siretart: Do you have Ubuntu sources ready for it?  I wouldn't mind giving it a once-over, and then letting it go.
[00:45] <siretart> infinity: no, in ubuntu, we do have a delta because we need to handle libav-extra specially
[00:45] <infinity> siretart: Right, the -extra thing, plus some aarch64 patches (though, we'd want those in Debian too)
[00:45] <siretart> infinity: in debian, all dependencies are in main, ubnutu, libx264, xvid, lame, and many others are only in multiverse. that's why we need libav-extra
[00:46] <wgrant> (they're in universe now, but close enough)
[00:46] <siretart> aarch64 patches? send them upstream, I may even roll  them in a point release :-)
[00:46] <infinity> They're from upstream.
[00:46] <siretart> yeah, same problem.
[00:46] <siretart> even better!
[00:48] <infinity> none /dev/pts devpts rw,nosuid,noexec,relatime,mode=600 0 0
[00:49]  * infinity looks suspiciously at that, and wonders who to blame.
[01:01] <infinity> Oh, look, it's upstart's fault.
[01:01] <infinity> xnox: upstart is mounting devpts wrong, plz fix.
[01:02]  * xnox thinks it's time for me to go to sleep.
[01:03] <infinity> Convenient. :P
[02:15] <slangasek> infinity: what's wrong about it?
[02:15] <slangasek> infinity: ah, missing gid=tty and wrong mode?
[02:15] <infinity> slangasek: Just mounts with defaults, no gid or mode.
[02:16] <slangasek> yeah
[02:16] <slangasek> really love that upstart and mountall both have to deal with mounting
[02:16] <slangasek> really want to merge those :P
[02:17] <infinity> Why aren't they?  The misguided assumption that mountall might be used from another init system?
[02:17] <slangasek> no, it was a practical consideration at the time Keybuk was developing it
[02:17] <slangasek> and no one's had the time since then to go back and merge them
[02:18] <infinity> I'm puzzled as to which circumstances lead me to a mountall-mounted devpts and which lead to an upstart-mounted one.
[02:19] <infinity> My laptop gets the gid/mode from /lib/init/fstab (so, I assume, mountall), but this dev board I just set up gets no gid/mode, so I assume it's from upstart.
[02:19] <infinity> In neither case is there anything going on in /etc/fstab or other such oddities.
[02:20] <infinity> The dev board has no initrd, which I assume confuses matters a bit.  Maybe that's the big difference.
[02:21] <infinity> Oh, in fact, wasn't "no initrd" the use-case that led to upstart leaning to mount some kernel filesystems on its own?  This is coming back to me...
[02:21] <infinity> s/lean/learn/
[02:22] <slangasek> infinity: do you have an initramfs?
[02:22] <infinity> In fact, maybe mountall never gets around to touching devpts at all, but on my laptop, we're carrying over the mount that initramfs-tools (correctly) set up in early boot.
[02:22] <slangasek> yep
[02:22] <slangasek> in practice mountall "can" mount these but never gets a chance because they're pre-mounted by the initramfs for most people
[02:23] <slangasek> but in the initramfsless case, upstart has to mount them; this path is not well-exercised
[02:23] <infinity> Well, I've been exercising it a bit in the last month. :)
[02:23] <infinity> And other than the above gid/mode oops, it seems to largely work as expected.
[02:24] <slangasek> heh, ok then. :)
[02:24] <slangasek> maybe you want to just fix bug #1039887
[02:26] <infinity> slangasek: Fix, as in have mountall 'mount -o remount' everything in fstab?
[02:27] <slangasek> infinity: maybe?  I haven't thought through what the right fix would be :)
[02:27] <slangasek> but if mount options are missing, I don't think it should ignore that
[02:27] <infinity> slangasek: Well, one could pull fstab into the initramfs, but that makes it much more system-specific than they usually are, plus every time we have one more "if you update this conffile, you need to re-run update-initramfs", it gets 5% less intuitive.
[02:28] <slangasek> yes
[02:28] <slangasek> also, that doesn't get you a free fix for the initramfsless, upstart-had-its-own-idea problem
[02:28] <infinity> Indeed.
[02:29] <infinity> Well, upstart's idea about devpts should be fixed regardless.
[02:29] <infinity> But agreed that /lib/init/fstab and /etc/fstab should probably be reparsed by mountall even for already-mounted filesystem to fill in the blanks on sysadmin preferences.
[02:30] <slangasek> yeah - fix upstart, but also make it less of a problem in the future for upstart's mount model to be out of sync
[03:17] <ntzrmtthihu777> heyo. how hard, if possible, would it be to create an ubuntu iso that can boot live or install k/l/x/ubuntu?
[03:20] <vimpulse> ntzrmtthihu777:  one ISO which gives you a choice of four Ubuntu flavors?
[03:21] <ntzrmtthihu777> vimpulse: yep
[03:25] <vimpulse> (followup:  in #ubuntu-offtopic, ntzrmtthihu777 mentioned that s/he wants this only for fun.  Flannel added that such a thing already exists, though s/he didn't recall where it's downloadable from.)
[03:26] <ntzrmtthihu777> also, since the ubuntu iso has already broken the cd size limit, any thought given to bundling x86_64 and i386 versions into one iso, like arch linux?
[03:27] <Flannel> vimpulse, ntzrmtthihu777: http://rww.name/grub2iso.html  talks about it (or its functional equivalent) (at the bottom)
[03:29] <ntzrmtthihu777> Flannel: I know of this method, and have dones so before, but, since the differences are negligable between flavours there seems to be no reason to have multiple squasfs files and bloat up the iso image/usb stick
[03:31] <vimpulse> ntzrmtthihu777:  This matter is probably offtopic here.  Please see my reply in #ubuntu-offtopic.
[05:48] <Noskcaj> What happened to perl 5.14? I've just lost a stack of packages since it isn't working
[05:50] <pitti> Noskcaj: it's spelled "5.18" now
[05:50] <Noskcaj> Then i really need to fix some packages
[05:51] <infinity> Noskcaj: There's a transition in progress.  If your packages are failing to build because build-deps aren't installing, just wait a bit and retry in a day or two.
[05:52] <Noskcaj> No, i've lost a heap of installed packages
[05:52] <infinity> ...
[05:52] <Noskcaj> xchat and yarssr are my main issues
[05:52] <infinity> You're running -proposed?
[05:52] <infinity> I feel like perhaps we've told you a few dozen times that that's a very bad idea.
[05:53] <Noskcaj> infinity: Unfortunately, i hear bad idea as "do this". I'll see what i can do with the (few) packages broken that i access
[06:29] <ScottK> Noskcaj: We can't save you from yourself.  If you break stuff against explicit advice, you should really not bug the people who told you not to do it to help you fix it.
[06:29] <Noskcaj> ScottK: of course, i just hadn't realised the break was because i had -proposed on
[06:30] <ScottK> Noskcaj: If you've got proposed on, assume any break is because that.
[06:31] <Noskcaj> ok
[06:31] <ScottK> Seriously.  You're running a configuration that is completely and utterly unsupported that NO ONE is ever supposed to run.
[06:31] <ScottK> Is that sufficiently clear or are you still thinking "I think he means I should do it"?
[06:33] <Noskcaj> ScottK: Very clear. i hadn't realised proposed was on
[06:35] <Noskcaj> You don't  need to get angry because of that
[07:03] <zyga> good morning
[07:13] <AtuM> can anyone tell me if the package openvswitch-brcompat will be available in 13.10 ? All I find is an outdated one.
[07:16] <AtuM> I have openvswitch 1.10.2-0ubuntu2 installed.. I found openvswitch-brcompat version 1.9 for saucy..  brcompat is getting obsolete fast, but virt-manager still can't do without.
[07:25] <halfie> hi
[07:26] <halfie> is "-Werror=format-security" turned on for all packages by default?
[07:27] <halfie> or is it ON only for packages built with DEB_BUILD_HARDENING=1 ? .. and how are packages made PIE *selectively* then?
[07:28] <debfx> halfie: yes, if they use dpkg-buildflags (directly or through debhelper compat level 9)
[07:30] <halfie> oh, can you please break that down for me?
[07:30] <halfie> "-Werror=format-security" is ON for all packages, right?
[07:30] <halfie> 2. how do I make a package PIE in Ubuntu
[07:31] <debfx> export DEB_BUILD_MAINT_OPTIONS=hardening=+pie
[07:31] <halfie> ah I see now, there are options besides DEB_BUILD_HARDENING=1
[07:31] <halfie> it seems DEB_BUILD_HARDENING=1 is the default when building any package, correct?
[07:31] <debfx> afaik DEB_BUILD_HARDENING is a hardening-wrapper thing
[07:32] <halfie> debfx, yes, it is part of that wrapper.
[07:32] <halfie> do you have this wrapper activated on official Ubuntu build machines?
[07:33] <halfie> essentially, I want to understand if it is "safe" to turn on "-Werror=format-security" by default and system-wide?
[07:41] <AtuM> How come udev rules are written so that /dev/disk/by-path/* drives include serial/model number? that beats the whole meaning of using by-path link
[07:42] <AtuM> nevermin.. I'll ask on #udev
[07:55] <mantiena-baltix> james_w: hi are you online?
[07:56] <mantiena-baltix> hi all
[07:56] <mantiena-baltix> could someone tell me when package sources import from debian will be enabled?
[07:57] <mantiena-baltix> I need packaging folder from latest Debian package to build new release of gnome-shell-extension-weather, see https://answers.launchpad.net/udd/+question/237721
[07:57] <ogra_> mantiena-baltix, i think it already is
[07:58] <ogra_> ..."Trusty is now open for development, with syncs from unstable currently running." ...
[07:58] <ogra_> from the ubuntu-devel ML
[08:00] <mantiena-baltix> ogra_: but why William Grant (wgrant) said yesterday: package importer has been disabled since Friday in preparation for Ubuntu Trusty.
[08:00] <mantiena-baltix> ogra_:  see https://answers.launchpad.net/udd/+question/237721
[08:01] <StevenK> Package importer has nothing to do with syncs
[08:01] <wgrant> mantiena-baltix: I reenabled package-import a few hours ago, but it will take a little while to catch up.
[08:01] <wgrant> And it's separate from the sync mechanism.
[08:02] <mantiena-baltix> wgrant: thanks, it seems I can expect today to see up to date lp:debian/gnome-shell-extension-weather , right?
[08:04] <wgrant> mantiena-baltix: It could take 2-3 days.
[08:09] <mantiena-baltix> wgrant: oh, maybe I can see the progress somewhere?
[08:09] <wgrant> http://package-import.ubuntu.com/status/
[08:09] <mantiena-baltix> thanks
[08:09] <mantiena-baltix> bye
[08:29] <smartboyhw> xnox: Bug 1242417
[08:30] <xnox> smartboyhw: yes?!
[08:30] <smartboyhw_> I'x
[08:31] <xnox> smartboyhw_: ubuntu studio needs to revert that change, because grub* maintainer scripts do not consider Studio as an alias for ubuntu and restults in a non-booting Studio.
[08:31] <smartboyhw_> xnox: Not sure if the
[08:31] <smartboyhw_> linux-lowlatency kernel supports UEFI
[08:31] <mlankhorst> probably does, why wouldn't it?
[08:31] <xnox> smartboyhw_: thus studio-default-settings should revert in saucy & trusty, until grub2 supports multiple distributions.
[08:32] <smartboyhw_> xnox: OK, I will tell OvenWerks
[08:32] <xnox> smartboyhw_: kernel doesn't have much to do with UEFI, apart from optional modules to provide EFIvars via sysfs. But it does boot with UEFI fine.
[08:32] <Laney> pitti: looks like ddebs needs to learn about trusty?
[08:32] <Laney> also, hello!
[08:34] <smartboyhw_> xnox: OK.
[10:44] <mlankhorst> wow.. why does /var/cache/apt/archives/linux-image-3.11.0-12-generic_3.11.0-12.19_amd64.deb check on AMD64 whether the cpu is pae capable or not
[11:46] <tkamppeter> HP wants to start testing HPLIP on ARM systems, can someone tell me where I find instructions to get started with Ubuntu development on ARM and also about recommended hardware?
[11:52] <mlankhorst> https://wiki.ubuntu.com/ARM/Server
[11:59] <tkamppeter> mlankhorst, thanks. Is there also something about the Ubuntu Desktop on ARM?
[12:03] <mlankhorst> nah since that's reliant on hardware support
[12:03] <mlankhorst> binary drivers
[12:04] <mlankhorst> graphics on arm is a mess
[12:13] <tkamppeter> mlankhorst, thank you very much.
[12:37] <xnox> tkamppeter: for bringing up new ARM development boards, it's best to use https://wiki.ubuntu.com/Core
[12:38] <xnox> tkamppeter: take ubuntu armhf rootfs + bring your own kernel + bring your own bootloader (usually part of the board anyway)
[12:43] <pitti> infinity: FTR, I added trusty-ness to http://ddebs.ubuntu.com/dists/
[12:48] <Laney> woot
[12:54] <doko> jamespage, testng is another maven conversion
[12:54] <brainwash> pitti: hey, any more ideas on how to debug bug 1184262? running logind in foreground doesn't reveal any useful information, and I'm not sure if the guys of in #systemd will help me with ubuntu's systemd/logind implementation
[12:55] <doko> jamespage, testng is another maven conversion (and it's b-d's too, guice and jcommander)
[12:56] <doko> barry, could you look at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg and handle webtest and python dependencies?
[12:57] <pitti> brainwash: #systemd> right, it's most certainly something in between our patches and systemd-shim, so upstream can't/won't help
[12:58] <doko> barry, the question being, if we want pypy in main ...
[12:59] <pitti> brainwash: I guess next up would be debugging the exchanged messages/signals (https://wiki.ubuntu.com/DebuggingDBus) and see whether there is anything weird there
[13:00] <pitti> brainwash: running /usr/lib/x86_64-linux-gnu/systemd-shim in the foreground might also reveal something
[13:00] <pitti> brainwash: FTR, I ran my session for four days with two dozen suspends now, without any hitch..
[13:01] <brainwash> pitti: so it's some sort of race condition or timeout occurring
[13:01] <brainwash> because it does happen randomly
[13:01] <pitti> presumably
[13:01] <barry> doko: sure, i'll take a look
[13:02] <brainwash> pitti: alright, I'll start to monitor everything from now on and report back, thanks :)
[13:03] <pitti> brainwash: if that doesn't reveal anything either, the next step would be gdb, I guess..
[13:03] <pitti> brainwash: but at that point I'd need access to an affected system, or some recipe how to reproduce it
[13:13] <cjwatson> stgraber: FYI your lxc merge broke touch due to overly-strict parsing in lxc-android-config; fixed now in l-a-c but you may want to test merges to critical touch infra :)
[13:17] <stgraber> cjwatson: doh, well, my pre-upload tests here do include touch, just not that particular init script... I guess I should include a full reboot test
[13:20] <stgraber> that really should be: lxc-info -n android-dev -p|awk '{print $2}'
[13:20] <stgraber> s/android-dev/android/ (android-dev is the one on my laptop)
[13:29] <ogra_> stgraber, except that i hate awk with passion ...
[13:29] <ogra_> :)
[13:29] <ogra_> stgraber, fixed with a [[:space:]] now
[13:29] <seb128> ogra_, you hater!
[13:29] <ogra_> haha
[13:29] <seb128> ogra_, wie gehts? ;-)
[13:30] <ogra_> seb128, super !
[13:30] <stgraber> ogra_: [[:space:]] should be good enough indeed. I'd still recommend using -p instead of the silly | grep pid
[13:30] <ogra_> fixing the framework around the webapps atm :)
[13:30] <ogra_> stgraber,  oh is that new ?
[13:30] <stgraber> ogra_: nope, been there forever
[13:31] <stgraber> without -p, lxc-info will attempt to get ip addresses and a bunch more info from the container which you don't use, so -p should make it more lightweight
[13:31] <ogra_> stgraber, how about a --raw switch too that removes the silly header :)
[13:31] <ogra_> (i.e. just returns the pid)
[13:31] <stgraber> ogra_: we already have a feature request for that on github or LP, just need someone to write a patch for it ;)
[13:31] <ogra_> stgraber, ok, will add that to the next upload
[14:01] <ogra_> stgraber, i was wondering yesterday ... if someone has /usredata/.writable_image and flashes without --no-backup, will he get a writable image automatically ? (we should probably remove the file during flashing if thats the case)
[14:18] <stgraber> ogra_: that's more of a question for sergiusens I think. At least the upgrader doesn't remove the flag, so if phablet-flash doesn't, then nothing does
[14:18] <ogra_> yeah
[14:18] <ogra_> i think as soon as i use phablet-flash you can assume i want it ro again
[14:18] <ogra_> but i guess thats a philosophical question :)
[14:21] <pitti> mvo_, cjwatson: is anyone already looking at the python-apt merge? I'd like to do it now to get "trusty" info into it (this breaks several things ATM)
[14:21] <cjwatson> I'm not
[14:21]  * cjwatson files an RT for trusty chroots on porter boxes
[14:21] <mvo_> pitti: its hopfully just a merge, no? i.e. is there anything left that is ubuntu specific?
[14:22] <pitti> mvo_: right; in the best case it's a sync
[14:22] <mvo_> pitti: i mean, I'm happy to add trusty and do a debian upload :)
[14:22] <pitti> mvo_: trusty already went into 0.9.0
[14:22] <pitti> mvo_: our current delta is to add saucy and add "Multi-Arch: allowed" (both of which should go into Debian)
[14:22] <mvo_> great
[14:23] <mvo_> yeap
[14:23] <Laney> I think they both did in 0.9.0
[14:23]  * pitti verifies
[14:23] <mvo_> apt should be the same btw, that is hopefully just a sync too
[14:23] <pitti> yep, all in, nice!
[14:24]  * pitti syncs
[14:24] <pitti> jibel: ^ FYI
[14:25] <mvo_> pitti: cool
[14:26] <pitti> mvo_: I think apt still has some delta, e. g. 0.9.9.1~ubuntu3 sounds rather ubuntu specific
[14:26] <pitti> (whereever that strange version came from)
[14:28] <mvo_> pitti: ok, let me check
[14:29] <brainwash> pitti: just a quick question, is systemd-shim supposed to run all the time?
[14:29] <pitti> brainwash: no, it's dbus-activated and times out after some minutes
[14:29] <brainwash> pitti: ah ok, thanks
[14:30] <pitti> mvo_: oh, so looking at https://launchpad.net/ubuntu/saucy/+source/apt/+changelog it's probably not that bad
[14:30] <pitti> mvo_: 0.9.9.1~ubuntu1 was just a merge from Debian anyway, so we mostly just need to look for the delta of the last two versions?
[14:30] <mvo_> pitti: looks like it, I will merge the latest upload from infinity into the ubuntu branch now
[14:31] <mvo_> pitti: there is a ubuntu/master branch in the git tree for the merging and I was utterly wrong about sync :) still a bit of a delta
[14:31] <pitti> mvo_: so http://launchpadlibrarian.net/146396279/apt_0.9.9.1~ubuntu1_0.9.9.1~ubuntu2.diff.gz is in sid
[14:32] <mvo_> pitti: great
[14:32] <pitti> mvo_: http://launchpadlibrarian.net/149979633/apt_0.9.9.1~ubuntu2_0.9.9.1~ubuntu3.diff.gz isn't; perhaps/hopefully that's the only delta
[14:32] <pitti> mvo_: oh, ubuntu/master has stuff which isn't uploaded?
[14:33] <mvo_> pitti: its all uploaded, its just in there to make the merge easier
[14:34] <pitti> mvo_: given that linux-tools is in Debian as well, that might be something for Debian, too?
[14:35] <pitti> ah no, not with the full abi
[14:37] <mdeslaur> siretart: could you please comment on bug 1243235?
[14:38] <mvo_> pitti: yeah, looks like it might not be a perfect fit. I just did a git merge debian/sid in the ubuntu tree and it does not look too horrible should be a matter of some minutes to resolve the conflicts
[14:39] <pitti> mvo_: splendid, thanks; I'm currently walking through https://merges.ubuntu.com/a/apt/REPORT and there's some more apparently
[14:39] <pitti> mvo_: like cmdline/apt-key debian->ubuntu servers, etc.
[14:40] <pitti> ah, and the dependency: debian-archive-keyring -> ubuntu-keyring
[14:40] <pitti> mvo_: but that's pretty much it, so yes, the delta should be rather small
[15:13] <mvo_> pitti: just fyi http://anonscm.debian.org/gitweb/?p=apt/apt.git;a=shortlog;h=refs/heads/ubuntu/master should be good now
[15:13] <mvo_> pitti: I gtg, can do a bit more testing/upload later tonight
[15:14] <smartboyhw> cjwatson, xnox: To confirm, for Studio we should be reverting the changes in http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/ubuntustudio-default-settings/saucy/revision/48 (file etc/default/grub.d/50_ubuntustudio.cfg)?
[15:14] <cjwatson> smartboyhw: For the moment, yes
[15:15] <smartboyhw> cjwatson, OK, so I shall do the changes?
[15:15] <cjwatson> smartboyhw: Please
[15:16] <xnox> smartboyhw: note, it's a conffline, hence rm_conffile with .maintscript snippet will be needed $ man dh_installdeb
[15:16] <smartboyhw> xnox, OK
[15:22] <smartboyhw> cjwatson, xnox: Rarely have experience with .maintscript, is http://paste.ubuntu.com/6283517/ correct?
[15:22] <xnox> smartboyhw: test it, upgrading from previous package to that one should remove the file on disk.
[15:23] <cjwatson> smartboyhw: needs a version
[15:23] <cjwatson> Probably 0.50~ (note tilde)
[15:24] <smartboyhw> cjwatson, the version = the version before the one I'll be uploading? (i.e. 0.49?)
[15:24] <smartboyhw> oh
[15:24] <cjwatson> read the dpkg-maintscript-helper man page.
[15:35] <smartboyhw> xnox, cjwatson the fix works:)
[15:42] <smartboyhw> cjwatson, https://code.launchpad.net/~smartboyhw/ubuntu/trusty/ubuntustudio-default-settings/fix-bug-1242417/+merge/192179 for you
[15:45] <smartboyhw> Uh, wait
[15:47] <zequence> cjwatson: Let me have a look first as well..
[15:55] <zequence> cjwatson: smartboyhw is operating on his own behalf. He hasn't discussed any changed with ubuntu studio devs, Oven in particular who made those changes, so I'd rather we have some internal communications first, unless there's a really apparent solution
[16:10] <xnox> zequence: point is that that change should have been cordinated with grub maintainer first, as simply setting that variable results in broken installs that cannot boot (at least on uefi). As matching changes are required in the grub package (some of which were in-place for kubuntu).
[16:11] <seb128> ev, hey, did you see my ping about that activity log manager bug?
[16:11] <xnox> zequence: thus it must be reverted in saucy & trusty, until more generic facility for menu-item branding is provided by the grub package.
[16:12] <xnox> seb128: he is away on sprints and stuff =/
[16:12] <seb128> xnox, yeah, but still online
[16:12] <xnox> seb128: he uses irc bouncer/proxy.
[16:12] <seb128> xnox, well, he wrote on IRC since
[16:12] <xnox> ah.
[16:12]  * seb128 needs to go for lunch
[16:12] <seb128> bbl
[16:17] <cjwatson> zequence: What xnox said.  The Ubuntu Studio developers who made this change didn't discuss it with me as grub2 maintainer.
[16:17] <cjwatson> zequence: And as a result it is broken.
[16:17] <cjwatson> zequence: smartboyhw is operating on my request, not on his own behalf.
[16:23] <bdmurray> ev: have you and mpt talked about colors for 14.04?  I'm working on adding it to errors
[16:23] <ev> I have no preference :)
[16:28] <zequence> cjwatson: Well, no one is talking to the one who made the change, and changes were not made to our source
[16:28] <zequence> I asked smartboyhw to remove the merge request, as it was towards the ubuntu source, and not the ubuntustudio source
[16:29] <zequence> we have to have some kind of order in how we do things
[16:29] <cjwatson> zequence: That order should have involved talking to the grub2 maintainer before doing weird things in /etc/default/grub.d/ :-P
[16:29] <cjwatson> IOW creating support headache for me
[16:29] <cjwatson> Please land smartboyhw's change
[16:30] <cjwatson> (Even if to a different branch or whatever)
[16:31] <ogra_> ev, huh ? not pink anymore ?
[16:31] <ev> pink is best
[16:31] <ev> best. best. best.
[16:31] <ogra_> :)
[16:31] <ev> (http://www.youtube.com/watch?v=n7-RetY7fGo)
[16:32] <ogra_> haha
[16:32] <zequence> cjwatson: I'm not against reverting the change itself. I'm being happily ignorant about the problems around it - allthough I'd rather see as many changes done upstream as possible, which I always tell the Ubuntu Studio devs (Oven I believe went forward following Kubuntu's example, and probably did not realize the full impact of it).
[16:33] <zequence> cjwatson: Just that, this is the second time a change to ubuntu studio source is submitted, bypassing ubuntu studio branches
[16:33] <saiarcot895> If there is a package that has a CVE that affects all supported versions, and that was fixed in Saucy (well, from Debian), can it go in as an SRU?
[16:34] <zequence> cjwatson: And also, bypassing the devs themselves. That's all I'm worried about
[16:35] <cjwatson> zequence: Sure, I expect Howard just didn't realise the right branch to target; happens with installer branches all the time
[16:37] <xnox> saiarcot895: it maybe should go in as a security update, check with #ubuntu-hardened (ubuntu security team channel)
[16:38] <saiarcot895> xnox: thank you
[16:47] <tkamppeter> Anyone working with emacs here?
[18:11] <esing> hi, I want to report a bug for ubuntu on launchpad, but I get this bug message when trying to report the bug  "Invalid OpenID transaction"
[18:11] <Pici> esing: #launchpad would be a better place to ask
[18:12] <esing> thanks for the hint
[19:51] <infinity> siretart: So, when do you want to get started on this libav9 transition?  I'm ready whenever, as soon as you have libav/libav-extra ready to upload.
[20:04] <arges> so i'm looking at bug 1121874, would it make sense to upload a trusty update even though the merge from debian hasn't happened yet?
[20:07] <infinity> arges: I'd just do it as part of the merge, IMO.  We're hammering the builders enough as it is.
[20:08] <arges> infinity: ack. also the fix needs to be SRUed for P/Q/R/S, that will need to wait until its in Trusty right?
[20:09] <infinity> Not strictly speaking, no.  As long as I know the fix is in progress for T, it doesn't HAVE to be first.  We just need to know it's going to not get forgotten.
[20:09] <infinity> Ideally, this should be forwarded to Debian (has it been?), so we don't accidentally lose it along the way.
[20:10] <arges> infinity: it hasn't been yet. Its an upstart fix, so I'm guessing its something that could be forwarded
[20:10] <arges> I wasn't sure if debian was using upstart of this was an ubuntu specific delta (i need to check)
[20:10] <infinity> arges: Also, unless it's tied up in a transition, if you SRU to S, I could copy it forward to T.
[20:11] <infinity> arges: The upstart job might be ubuntu-specific but, if it is, we should fix that and forward it too.
[20:11] <infinity> rbasak: Are you going to be doing the mysql-5.5 merge?
[20:11] <arges> infinity: ok great, I'll check that out. As for the copy forward that's fine but there isn't a hurry, just want to do the Right Thing
[20:12] <infinity> arges: The Right Thing is to make sure the fix doesn't get lost and cause a regression.  There are many ways to skin that particular small mammal.
[20:12] <mdeslaur> arges: I'd wait a bit before doing any mysql srus, I'm preparing security updates for the stable releases
[20:13] <infinity> Oh, right, I forgot that he can't see those in the build queues. :P
[20:13] <infinity> arges: PS: mysql security updates are hammering the builders right now.
[20:13] <arges> mdeslaur: ok i'll wait
[20:13] <arges> infinity: yea mysql is a beast to build
[20:13] <infinity> The building is fine, the testsuite is... Extensive.
[20:13] <arges> yea that's what i meant : )
[20:27] <rbasak> infinity: I'm not sure. We know we need to catch up on it. I'll look at all the merges when I'm back after Linaro Connect
[20:28] <infinity> rbasak: Kay.  mdeslaur is in the process of doing security updates, which will bump the upstream version, and I'll copy that from S to T when he's done.
[20:28] <infinity> rbasak: But we may be behind on packaging changes.
[20:29] <rbasak> OK
[20:29] <infinity> mdeslaur: Well, assuming you do a saucy upload. :P
[20:29] <mdeslaur> infinity: yes
[20:31] <infinity> mdeslaur: Oh, also, while we're dealing with potentially sketchy hardware, if you have weird arm64 FTBFSes in the security PPA, let me know, and I'll sort them.
[20:31] <infinity> mdeslaur: (Poking the one in there right now)
[20:49] <mdeslaur> infinity: cool, thanks
[20:54] <doko> mterry, it does effect testng because it uses maven ...
[20:54] <mterry> doko, testng was already in main, but you mean the question of whether to promote maven or drop dep on maven?
[20:55] <doko> the latter
[20:55] <mterry> doko, I see
[20:55] <mterry> doko, OK, will add back, sorry
[20:55] <doko> unless jamespage wants to write hunders of MIRs ,p
[20:55] <doko> hundreds even
[20:56] <mterry> doko, I didn't look at maven yet
[20:56] <mterry> I don't like the sound of that, no
[20:56] <doko> mterry, see the dependency graph: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[21:01] <doko> Source: cracklib2
[21:01] <doko> Uploaders: Martin Pitt <mpitt@debian.org>
[21:02] <doko> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724842
[21:02] <doko> https://launchpad.net/ubuntu/+source/cracklib2/2.9.0-1
[21:02] <doko> pitti, ^^^
[21:02] <roaksoax> /w/win 3
[21:03] <stgraber> mdeslaur: mind if I steal that sudo merge from you?
[21:07] <cyphermox> xnox: around?
[21:15] <mdeslaur> stgraber: go right ahead :)
[22:54] <doko> slangasek, would you mind if I merge pango1.0? librsvg waits on it
[23:32] <mdeslaur> infinity: and...arm64 build failed in the secppa
[23:35] <doko> mdeslaur, can't see what did fail and why. so you are on your own ...
[23:35] <mdeslaur> doko: infinity can, and offered
[23:35] <mdeslaur> doko: thanks
[23:45] <infinity> mdeslaur: On it.
[23:49] <mdeslaur> infinity: awesome, thanks