[00:02] <jrwren> dist-upgrade?
[00:58] <kirkland> doko_: probably;  I don't know of any particular interest in it anymore
[02:32] <hyperair> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1293081 <-- is it just my machine, or is there really nobody else facing this issue in trusty?
[02:34]  * hyperair finds it ridiculous that we're going to release with unity having issues switching between single-head and multihead on an IVB-equipped thinkpad
[03:01] <RAOF> hyperair: Is there some reason you're overriding the i915's RC6 defaults? Deep RC6 states have been a fairly rich source of bugs.
[03:02] <RAOF> hyperair: Likewise, semaphores, etc? Do you still get the same hang without all your i915 tweaks? (I ask this because *my* HSW machine is quite happy to enable or disable monitors)
[03:03] <RAOF> That might also suggest an answer to ‘is it just my machine’ ☺
[03:14] <hyperair> RAOF: hmm, it's been like that since the previousd ubuntu release.
[03:14] <hyperair> RAOF: as in i had no issues until upgrading to ubuntu 14.04
[03:14] <hyperair> considering i use the same custom kernel that i used in 13.10, i'm more inclined to believe this is a unity issue.
[03:14] <hyperair> but yeah i'll try disabling my tweaks and seeing if that helps
[03:15] <RAOF> Mesa's also changed, which could be hitting new codepaths.
[03:20] <hyperair> hmm
[03:20] <hyperair> somehow rc6 doesn't sound like the kind of thing that would affect multihead transitions.
[03:21] <hyperair> i mean rc6 is basically super deep sleep for the GPU isn't it?
[03:21] <hyperair> i'm sure the transition stage is when it's not sleeping.
[03:21] <hyperair> is there a way to disable rc6 temporarily without rebooting?
[03:46] <RAOF> hyperair: You can *probably* tweak those things at runtime by writing things to /sys/module/i915/parameters/*
[03:50] <hyperair> hmm
[03:50] <hyperair> come to think of it, i'm not sure what the defaults for this gpu is
[03:50] <hyperair> *are
[04:19] <RAOF> hyperair: You can write -1 into most of them to get default behaviour; I don't know if that'll work post-startup, though.
[04:19] <hyperair> don't think so
[04:19] <hyperair> at least rc6 didn't work some time ago
[05:01] <pitti> Good morning
[05:03] <pitti> infinity: at least they seem happy for now (almost 2 days uptime)
[05:43] <infinity> pitti: I'm not sure that "surviving for two days" is a good indication of stability, but it's better than nothing. :P
[07:12] <dholbach> good morning
[07:37] <RAOF> dholbach: Sorry about the delay; I've tested libxkbcommon 0.4.1, and everything seems hunky-dory. Go about your FFe-ing business!
[07:39] <dholbach> tjaalton, mlankhorst: ^ does that look all right to you?
[07:39] <dholbach> thanks RAOF
[07:39] <tjaalton> dholbach: yep
[07:40] <dholbach> fantastico!
[07:48] <dholbach> pitti, jibel, didrocks: salut mes amis.... do you know who could reply to https://bugs.kde.org/show_bug.cgi?id=333041 ?  comment 1 in particular
[07:48] <RAOF> Dear lord the Debian BTS is a fractal of annoyance.
[07:49] <didrocks> dholbach: hey my friend! I'm not part at all of the QA team nor I'm particularly skilled in those tests. Not sure how I can help :)
[07:50] <dholbach> didrocks, I just wasn't sure who might know the answer to these questions
[07:50] <dholbach> didrocks, I thought you might have a pointer for me :)
[07:51] <didrocks> dholbach: not really knowledgeable on that, sorry!
[07:51] <RAOF> Oh, I don't think xvfb is going to do EGL.
[07:51] <didrocks> RAOF: even with lvmpipe?
[07:52] <didrocks> llvmpipe*
[07:52] <RAOF> Even with llvmpipe; I'm not sure our EGL handles swrast at all.
[07:53] <RAOF> Hm, no. That's not true; the dri2 provider should support swrast.
[07:53] <pitti> mvo: nice changes in apt 1.0! (not a joke, I hope)
[07:54] <pitti> mvo_: what's the difference between "apt upgrade" and "apt full-upgrade" now? Or is upgrade what it always used to be, and that's a typo in your blog?
[07:55] <mvo_> pitti: apt upgrade will never remove a package, full-upgrade will also remove packages
[07:55] <mvo_> pitti: 1.0 is for real :)
[07:55] <pitti> aah
[07:55] <pitti> mvo_: so it's more than upgrade (also installs new packages), but less than dist-upgrade
[07:55] <mvo_> (it used to be that apt upgrade would not install/rmeove anything, but the restriction on install is bad for e.g. the kernel etc)
[07:55] <mvo_> yeah
[07:56] <pitti> mvo_: so this still would stop on package transitions, right?
[07:56] <pitti> or does it take explicit conflicts:/replaces: into account?
[07:56] <pitti> (but that would be the full dist-upgrade
[07:56] <mvo_> pitti: if the transition implies removes it will stop there, but that is actually a good idea to make it smarter
[07:57] <mlankhorst> dholbach: sounds about right
[07:57] <dholbach> mlankhorst, cool
[07:57] <pitti> mvo_: anyway, nice work! I like the easier CLI
[07:57] <pitti> haha, 10000b years in the making :)
[07:57] <seb128> what changed?
[07:57] <mvo_> pitti: thanks :)
[07:58]  * seb128 uses update-manager nowadays ;-)
[07:58] <mvo_> seb128: a simpler CLI with the new "apt" command
[07:58] <pitti> I use apt-cache all the time, and have aliases for that
[07:58] <pitti> alias acs='apt-cache search'
[07:58] <pitti> alias acsh='apt-cache show'
[07:58] <pitti> alias asrc='apt-cache showsrc'
[07:59] <pitti> I type these all the time, so I got lazy :)
[07:59] <mvo_> hehe
[08:00] <seb128> yeah, I used those often as well, just not upgrade/dist-upgrade
[08:00] <dholbach> seb128, one day you'll use image-based updates ;-)
[08:00] <seb128> dholbach, stop making mvo sad
[08:00] <dholbach> seb128, I don't think he'll be sad :)
[08:00] <seb128> hum, no "apt" here
[08:01] <seb128> ignore that, wrong prompt :p
[08:02] <mvo_> seb128: upgrade to trusty ;)
[08:02] <seb128> mvo_, but, precise is the LTS!
[08:02] <seb128> ;-)
[08:02] <mvo_> seb128: ;) and window maker is the WM ;)
[08:02] <seb128> indeed!
[08:02] <mvo_> seb128: :-D
[08:02] <seb128> glad you arrived to this conclusion as well ;-)
[08:02] <dholbach> hippies!
[08:03] <pitti> mvo: oh wow, I completely ignored the presence of "apt" in trusty; I thought it was new in 1.0
[08:03] <mvo> pitti: the 1.0 has a slight improved text progress bar, but the functionality is all there
[08:04] <pitti> now, how long will it take to adjust my finger muscle memory to that, after umpteen years of typing apt-get every morning..
[08:04] <mvo> lol
[08:04] <seb128> pitti, alias apt-get='apt' :p
[08:04] <mvo> I know the feeling, I type apt-g^W^W
[08:05] <Laney> @pilot in
[08:05] <pitti> mvo: not much manpage yet, and apt remove --help doesn't really work: is there a couterpart for "clean up my system", i. e. apt-get --purge autoremove?
[08:05] <seb128> Laney, happy piloting!
[08:06] <pitti> Laney: don't get lost!
[08:06] <mvo> pitti: yeah, the manpage is sadly not in ubuntu yet, the 1.0 one is better
[08:06] <mvo> pitti: and no autoclean, I guess adding that is a really good idea, maybe combined with some way to make it easy to idenitfy "local" packages that are no longer downloadable
[08:08] <pitti> and of course the most important command of all works! apt moo
[08:08]  * pitti hugs mvo
[08:08] <mvo> :P
[08:08]  * mvo hugs pitti
[08:22] <cking> cjwatson_, is xnox around this week?
[08:22] <xnox> cking: yeap =)
[08:22] <Laney> haha
[08:22] <cking> ah, i didn't see you xnox doh
[08:23] <cking> xnox, i still have some installer issues with my special SSD device
[08:23] <xnox> cking: =( right.
[08:23] <cking> sorry to make you life so bad :-/
[08:26] <xnox> no worries. we need it working for 14.04....
[08:26] <dholbach> pitti, hast Du 'ne Ahnung, wer mir Informationen für https://bugs.kde.org/show_bug.cgi?id=333041 geben könnte?
[08:26]  * dholbach hugs Laney
[08:27]  * Laney hugs dholbach 
[08:28] <xnox> warum alles sprechen Deutsch? wir sind kein Suse =)))))
[08:28] <mvo> lol
[08:28] <xnox> mvo: Guten Morgen! =)
[08:31] <mvo> guten morgen xnox!
[08:32] <seb128> mvo, we need tab completion for apt commands ;-)
[08:32] <seb128> mvo, like "sudo apt dis<tab>" ;-)
[08:33] <infinity> seb128: Inclding rewriting dis to ful?
[08:33] <mvo> seb128: oh, indeed
[08:35] <StevenK> seb128: zsh can already do that
[08:35] <StevenK> % sudo apt-get install
[08:35] <StevenK> zsh: do you wish to see all 43092 possibilities (43092 lines)?
[08:35] <seb128> StevenK, what, tab completion? apt-get as well
[08:35] <infinity> StevenK: apt, not apt-get.
[08:35] <seb128> just not the name "apt"
[08:35] <seb128> new name*
[08:35] <infinity> bash does apt-get fine.
[08:35] <StevenK> steven@undermined:~% sudo apt-get install language-pack-e
[08:35] <StevenK> language-pack-el       language-pack-eo       language-pack-et
[08:35] <StevenK> Including stuff like that?
[08:35] <seb128> right, sorry, I misread what StevenK wrote
[08:35] <infinity> And with a less ugly interface. :P
[08:36] <infinity> (base)adconrad@cthulhu:~$ apt-get install
[08:36] <infinity> Display all 45235 possibilities? (y or n)
[08:36] <seb128> StevenK, read :p
[08:36] <StevenK> seb128: Pft, reading is totally overrated
[08:36] <seb128> StevenK, that's "apt-get" you are using, not "apt"
[08:36] <seb128> yeah, I see that
[08:36] <seb128> infinity, since you are up, any chance you could review some of trusty queued items? ;-) some are waiting since thursday, would be nice to get things moving before the trusty freeze
[08:37] <infinity> seb128: I'm not actually here.  Just a bit of insomnia and then back to bed to try harder.
[08:37] <seb128> k
[08:37] <seb128> infinity, I guess you people are going to be angry if I just accept stuff, right? ;-)
[08:37] <infinity> possibly.
[08:38] <infinity> I'll poke mozjs quickly.
[08:38] <infinity> Under the assumption that that sync better be a no-change upload.
[08:39] <StevenK> No compdef for apt :-(
[08:39] <StevenK> Guess I'll have to write one when I'm bored
[08:43] <juliank> mvo: I had the same idea for bug 1302736 tonight, but I had versioned the breaks using (>> 0). This should take care of detecting custom-build packages as well (IIRC, people continued maintaining the official packaging scripts for some time on github, and build personal packages).
[08:47] <juliank> It's a bit uncommon to have >> Breaks and Provides, but hey, it works with stuff like https://github.com/rraptorr/sun-java6 as well
[08:48] <mvo> juliank: aha, nice idea. I was wondering about what to do with all the custom builds and that looks like a neat hack to get rid of them as well. but the downside would be that we would also include "sun-java6-jdk" from precise which is free of the apt binary. or am I missing something in your idea?
[08:52] <juliank> mvo: Was there a version of sun-java6-jdk that had no apt binary? I think only openjdk-6-jdk was changed, but sun-java6-jdk always shipped apt.
[08:52] <mvo> juliank: oh, indeed, I mixed them up - you are right
[08:53] <mvo> juliank: so +1 for your idea, if you haven't commited it to git already I can do that now and cherry pick for ubuntu
[08:53] <juliank> It would still break things if someone created an oracle-java6-jdk package that provides sun-java6-jdk; but I don't think anyone did.
[08:56] <juliank> Let me do a test build, I'm sure lintian complains about it.
[08:57] <infinity> mvo: What is the "apt" binary in the sun jdk, and has anyone whined to them about the namespace collision, so we can have a proper versioned breaks/replaces?
[08:57] <mvo> infinity: its deprecated since java5(? or 6?) (or even before)
[08:58] <mvo> infinity: so its not a issue with all recent jdks
[08:58] <mvo> juliank: ok
[08:58] <infinity> mvo: Ahh, kay.
[08:58] <mvo> infinity: its mostly for correctness, we had no report in trusty and its enabled (the apt binary) since ~jan
[09:01] <trijntje_>    ping pitti: i'm using ubuntu-defaults-builder to create localised Iso images for trusty but they can't boot in UEFI mode. Is this a known limitation or did I do something wrong?
[09:03] <xnox> is Kylin also built with ubuntu-defaults-builder? cause we'd need UEFI for those images...
[09:03] <infinity> mvo: Oh, and on the point of "apt" and "autoremove", since apt is a new binary with a new interface, there shouldn't currently be any behavioural assumptions.  If it's meant to be more user-friendly with fewer commands, could "full-upgrade" just offer to autoremove at the end of the run?
[09:03] <infinity> mvo: Bonus points if --purge is also made the default for remove/autoremove (haven't played with it yet to see if that's the case anyway).
[09:04] <infinity> xnox: Sort of.
[09:04] <mvo> infinity: auto-remove on full upgrade sounds useful, --purge by default is a bit dangerous as it may blow away carefully crafted configs
[09:04] <infinity> xnox: The livefs is, but then it's still jammed through the cdimage machinery for the ISO, so it depends on where your fix needs to be.
[09:04] <xnox> infinity: i see, let me sync a kylin and check if it has uefi or not.
[09:05] <infinity> mvo: I've often thought that the "non-technical end user's" expecation of "remove" is that it should --purge too.  This would obviously be a bad change for 'dpkg -r' or 'apt-get remove' where established behaviour is not to purge, but for new friendly tools, it feels like the right thing to do.
[09:05] <infinity> mvo: Opinions on that may vary, but for non-technical users, I don't think the concept of "removed but conffiles remaining" is useful, just confusing.
[09:06] <infinity> mvo: I guess that also depends on the target audience of 'apt', but given the tiny --help output, I'm guessing it's meant to be simplified and friendly, not to completely replace apt-*?
[09:06] <juliank> infinity: Many users accidentally remove packages because they do not listen to APT. I'm sure they do not want to lose their configuration.
[09:07] <infinity> juliank: I'd argue that people who don't read apt's output and accidentally remove packages probably don't have a lot of venn overlap with people who heavily customize conffiles.
[09:08] <infinity> juliank: And people who heavily customize conffiles will probably also continue using apt-get, with its known behaviour.
[09:09] <infinity> Unless the intent is to completely phase out apt-* in favour of the simpler-looking tool, which might annoy me. :P
[09:10] <mvo> infinity: apt-get is there forever, I don't want to even think how many scripts are using it
[09:11] <trijntje_> xnox: I don't know about that. I know that a Chinese version of ubuntu was in the original scope of ubuntu-defaults, but I don't think it's used now since the tool hasn't been updated a couple of releases AFAIK
[09:11] <infinity> mvo: Seven.  Seven scripts.
[09:11] <infinity> (give or take a few thousand)
[09:11] <mvo> infinity: I see your point, however removing configuration sounds dangerous given the small amount of diskspace etc. maybe the answer is to make it super easy to see/get rid of those packages
[09:12] <infinity> mvo: Well, if full-upgrade also offers an autoremove, it could follow up with a list of packages in ^rc state and ask what to do about them?  But that might be getting a bit verbose.
[09:12] <juliank> mvo: I pushed the change to git.
[09:12] <mvo> juliank: ta
[09:13] <infinity> mvo: So maybe a "clean" action that does what apt-get clean does (clear the ephemeral data), but also offers to autoremove and purge ^rc stuff?
[09:13] <mvo> infinity: I think that sounds very reasonable
[09:13]  * mvo wonder if it should be called "apt computer-janitor"
[09:14]  * infinity laughs.
[09:14] <infinity> mvo: To properly emulate past computer-janitor behaviour, it would also have to offer to rm ~
[09:14] <mvo> lol
[09:15] <darkxst> hey, pilot Laney! Bug 1294891
[09:16] <Laney> darkxst: f5
[09:17] <darkxst> Laney, sorry, its still queue though
[09:17] <darkxst> I suppose that takes some time to update?
[09:18]  * juliank will have breakfast now
[09:18] <darkxst> anyway, thanks!
[09:19] <Laney> darkxst: yeah, needs archive admin
[09:19] <infinity> mvo: While I'm filing wishlist bugs via IRC that you'll forget about, can we have an "apt-get autopurge" that's shorthand for "apt-get --purge autoremove" the same as "purge" == "--purge remove"?
[09:19] <xnox> trijntje_: infinity: kylin looks all good - has efi partition and all that.
[09:20] <infinity> xnox: Kay, the partition layout was expected, since that's done by debian-cd.
[09:20] <infinity> xnox: So, the bug for people using pure defaults-builder is that livecd-rootfs's ISO creation probably doesn't DTRT.
[09:20] <infinity> Err, live-build, I mean.
[09:20] <infinity> Some day, we need some round tuits to make live-build spit out nearly byte-identical ISOs to what debian-cd does.
[09:21] <mvo> infinity: that is a nice idea
[09:23] <pitti> trijntje_: not known, but u-d-b's live-image config hasn't been updated for quite a long time; I guess it needs some updates for UEFI
[09:23] <pitti> trijntje_: I don't think you did something wrong
[09:25] <trijntje_> xnox: that's good to know, I'll check out kylin to see if anything is applicable to udb
[09:25] <pitti> dholbach: the qemu armhf emulation isn't very reliable I'm afraid; I wouldn't blame it on upstream gcc or the KDE project unless it's been verified that it also segfaults (!) and fails the test on real hw
[09:25] <pitti> dholbach: quite a lot of syscalls aren't implemented in the user qemu emulation, like posix timers
[09:25] <pitti> dholbach: so as a first step I'd suggest to try and build it on real hw?
[09:26] <trijntje_> pitti: I've tried to take a look at the code myself but I'm completely out of my depth. Should I file a bug for the uefi problem?
[09:27] <pitti> trijntje_: sure
[09:29] <pitti> tseliot: happy birthday!
[09:29] <tseliot> pitti: thanks :)
[09:40] <dholbach> pitti, thanks
[09:53] <morphis> pitti: ping
[09:54] <pitti> morphis: hello
[09:54] <trijntje_> pitti: I'll file a bug against dub, thanks for your time
[09:55] <morphis> pitti: hey!
[09:56] <morphis> pitti: regarding https://bugs.launchpad.net/python-dbusmock/+bug/1225151
[09:56] <tjaalton> dholbach: there's no ffe bug for libxkbcommon?
[09:56] <morphis> do you have plans to implement that soon?
[09:57] <pitti> morphis: I can put it on my TODO list; so far, no plans (but should be fairly easy to do, so patches accepted, too)
[09:59] <morphis> pitti: ok, I can have a look myself
[10:00] <morphis> just didn't wanted to do double work :)
[10:00] <pitti> morphis: I guess the actual implementation is just a two-liner, most work is a new test case for that
[10:01] <dholbach> tjaalton, ah yes, that might be - it was just something that was reported to me and I wanted to bring everyone in touch about it
[10:02] <caribou> Laney: just saw your message regardin the sosreport SRU
[10:02] <dholbach> brb
[10:03] <caribou> Laney: I found out this morning that arges has been working on another SRU on the same package
[10:03] <morphis> pitti: yeah, that is what I guess too
[10:03] <Laney> caribou: yeah?
[10:03] <caribou> Laney: so I need to synchronize with him later today on how we go about this one
[10:03] <Laney> ok, please update the bug then and I'll leave it
[10:04] <Laney> same comments about backports apply of course
[10:04] <caribou> Laney: sure, I'll do that.
[10:07] <tjaalton> dholbach: ok, filed bug 1303706
[10:11]  * dholbach hugs tjaalton
[10:12] <jamespage> xnox, re bug 1297012 - not so close to release right? I'll comment
[10:18] <xnox> jamespage: we could try =)))) but it is dead close to release. I'd be happy with: mke2fs -t ext4 -O ^has_journal ^extent ^huge_file, which is pretty much what ext2 is yet called "ext4" not sure if freeze-api/ext4 kernel driver will like that or not.
[10:19] <xnox> jamespage: also i'd want to bump the default size of /boot, since current one is very small (also given that we do not autoremove kernels, only mark them for autoremoval)
[10:19] <jamespage> xnox, I'd prefer to push back on this so close to the release
[10:19] <xnox> jamespage: indeed.
[10:19] <jamespage> xnox, this might be a small change but I feel the potential impact could be big
[10:22] <jamespage> xnox, OK with you if I raised a task for U series and mark won't fix for trusty
[10:22] <jamespage> ?
[10:22] <xnox> jamespage: already did that + commenting.
[10:22] <jamespage> xnox, lol
[10:23] <didrocks> chrisccoulson: yeah, so your oxide-qt upload is fixing bug #1301341, right?
[10:24] <didrocks> chrisccoulson: I heard there is a need for a webbrowser-app change as well, are you driving that?
[10:25] <mwhudson> is do-release-upgrade -d the recommended way to get to trusty?
[10:25] <mwhudson> because it seems a bit flaky...
[10:25] <chrisccoulson> didrocks, oSoMoN is doing that change (for webbrowser-app)
[10:26] <chrisccoulson> and the upload doesn't fix that grooveshark bug. that requires a bit more work
[10:26] <didrocks> chrisccoulson: it will only be webbrowser-app change as well?
[10:26] <didrocks> s/as well/then/ ?
[10:26] <oSoMoN> chrisccoulson, no it will be only an oxide change :)
[10:27] <didrocks> hum, seems you guys are deadlocking on the other?
[10:27] <chrisccoulson> yeah, it requires a build system change in oxide and then a packaging change to build oxide twice, and split libffmpegsumo in to 2 conflicting packages (one with proprietary codecs and one without)
[10:28] <chrisccoulson> basically
[10:28] <juliank> Someone should move all webapps from universe to multiverse.
[10:28] <oSoMoN> didrocks, there’s no deadlock, only a build change in oxide needed
[10:28] <juliank> They all contain non-free images
[10:28] <didrocks> oSoMoN: seems that you are doing that change (what chris was telling)
[10:29]  * didrocks is puzzled now
[10:29] <oSoMoN> chrisccoulson, am I doing bug #1301341 ?
[10:30] <chrisccoulson> oSoMoN, it's ok, i can look at this one today
[10:30] <chrisccoulson> are you still looking at the geolocation bits?
[10:31] <oSoMoN> chrisccoulson, yes
[10:33] <chrisccoulson> oSoMoN, cool, thanks. i'll let you carry on with that :)
[10:47] <jamespage> xnox, ta
[11:55] <xnox> pitti: fixed ubiquity adt test, whilst not building ubuntuone plugin it was still installing it from the archive (listed as depends in debian/tests/control) despite it being well NBS. And hence the tests were failing.
[11:56] <xnox> pitti: it does indicate that possibly we are not quite running everything as installed - since installed != src-dir and we were failing on not finding u1 plugin in the src-dir.
[12:10] <pitti> xnox: I saw the success mail, thanks!
[12:40] <pitti> cyphermox: since today's update I often get DHCP reconnects, and dmesg says http://paste.ubuntu.com/7216850/ (apparmor violations)
[12:40] <pitti> cyphermox: are you aware of any recent changes in the network/dhcp stack?
[12:51] <dawnk_> When I change my scaling in Settings > Display from 1 to anything less than that, some parts of unity gets messed up.
[12:51] <dawnk_> For instance, when I right click on any application on the dash, the options I get are not aligned.
[12:51] <dawnk_> Can anyone check if it is replicable?
[12:51] <dawnk_> I'm using Ubuntu 14.04
[13:04] <Laney> @pilot out
[13:08] <xnox> dawnk_: yeah reproducible. file a bug against "unity" package in ubuntu with: $ ubuntu-bug unity
[13:08] <xnox> dawnk_: and attach photographs if possible, or just verbally describe
[13:11] <dawnk_> well, if I set my scale to any value less than 1, when I try to right click any programs in the unity-dash, the options do not look aligned properly
[13:11] <dawnk_> For instance, when I right click firefox, instead of "Open a New Window", it shows "Open a New Window     Open"
[13:12] <dawnk_> xnox: unfortunately, I won't be able to post a pic. My uni blocks most file sharing sites.
[13:12] <dawnk_> xnox: I'll try my best to describe it if you do not understand.
[13:12] <Laney> You can attach pictures to launchpad bugs
[13:18] <dawnk_> Laney: alright, I'll do that.
[13:22] <cjwatson> mdeslaur: Hi.  Do you folks need me to prepare updates for CVE-2014-2653, or is it already in progress?  I did the backports for squeeze and wheezy.
[13:23] <mdeslaur> cjwatson: no, that's fine, I was about to start doing it
[13:24] <cjwatson> OK, cool
[13:24] <mdeslaur> cjwatson: I'll take care of it
[13:24] <cjwatson> Thanks!
[13:24] <mdeslaur> thanks!
[13:29] <jtaylor> bug 970260 does not seem fixed or has reappeared in trusty :(
[13:30] <jtaylor> someone want to help me figuring gathering the required logs?
[13:33] <arges> @pilot in
[13:33] <jdstrand> pitti: that would be us
[13:33] <jdstrand> pitti: let me prepare and upload
[13:34] <jdstrand> weird that we didn't see it in testing
[13:35] <pitti> jdstrand: oh, thanks!
[13:35] <jdstrand> pitti: well, before I do the upload...
[13:36] <jdstrand> pitti: can you add this to /usr/lib/NetworkManager/nm-dhcp-client.action {} in /etc/apparmor.d/sbin.dhclient?
[13:36] <jdstrand> /var/lib/NetworkManager/*lease r,
[13:37] <pitti> jdstrand: done, and AA restarted
[13:37] <cyphermox> jdstrand: that was removed by mistake?
[13:37]  * pitti flushes dmesg -c, and will report back to jdstrand if it still happens
[13:37] <jdstrand> no, it is due to the new kernel
[13:37] <pitti> but this addition looks straightforward, thanks
[13:41] <dawnk_> xnox, https://launchpadlibrarian.net/172063791/Screenshot%20from%202014-04-07%2019%3A04%3A35.png
[13:42] <arges> dholbach: hi. doing some patch piloting and noticed that I can't unsubscribe sponsors... what permissions do I need to set up for that? Thanks
[13:43] <dholbach> arges, being part of the team should be it - let me check if you are
[13:44] <dholbach> fixed :)
[13:44] <arges> dholbach: thanks
[13:47] <xnox> dawnk_: what's the bug number?
[13:47] <xnox> dawnk_: i can't get to the bug from the attachment URL.
[13:47] <dawnk_> xnox: https://bugs.launchpad.net/unity/+bug/1303812
[13:48] <xnox> dawnk_: thanks!
[13:50] <dawnk_> xnox: Thanks for confirming.
[13:52] <jtaylor> cjwatson: grub-probe in trusty fails on lvm snapshots
[13:52] <jtaylor> I notice there was once a patch to handle that
[13:52] <jtaylor> which disappeared
[13:52] <cjwatson> Yeah, lamont asked me about that, that patch disappeared because it was supposed to have been fixed upstream
[13:53] <jtaylor> in some upstream commit with an unrelated commit message
[13:53] <cjwatson> I haven't had a chance to set up a reproduction environment yet
[13:53] <jtaylor> I wonder if it was a mistake
[13:53] <cjwatson> I'll see if I can set it up in Xen later today
[13:53] <jtaylor> the patch was upstream for a while
[13:53] <xnox> mvo: apt 1.0 is probably the best trusty feature!
[13:53] <xnox> and loving the new progress bar
[13:53] <jtaylor> it was removed in fc18f6
[13:53] <cjwatson> There may have been a mistake, but I remember dropping the patch intentionally
[13:54] <jtaylor> the issue just bit me when upgrading from saucy :/
[13:54] <cjwatson> I'll have a look, going into town now though
[13:54] <jtaylor> no usb disk available only broken usb stciks = much timewaste :/
[13:55] <jtaylor> I'll do some debugging to see if the patch still fixes it
[13:55] <xnox> jibel: $ ubiquity --greeter should start the page you want.
[13:55] <cjwatson> I'll want to set up that Xen guest regardless, if nothing else so that I have an easier way to test this kind of thing in future
[13:56] <xnox> jibel: apart from weird sizing issues, it should be ok. So far i can't manager to crash it.
[13:56] <xnox> jibel: which language did you pick?
[13:56] <xnox> bah wrong chan!
[13:56]  * ogra_ bets it was french though 
[14:06] <arges> dholbach: hey if something has already been sponsored should I unsubscribe sponsors, or just leave it?
[14:07] <Laney> arges: Set "Fix Committed" or something maybe
[14:07] <dholbach> arges, can the bug be closed maybe?
[14:07] <arges> Laney: hey! looking at bug 1298220. Just trying to go through the sponsoring queue
[14:08] <Laney> arges: Oh yeah, I was keeping sponsor-patch open "Wait for the bug to be closed…" for that one
[14:08] <Laney> but I lost that when I restarted my session :P
[14:08] <Laney> so I guess Fix Released and if it gets rejected reopen it
[14:08] <arges> Laney: ok will do thanks
[14:08]  * Laney did it
[14:08] <Laney> thanks for pointing it out
[14:09] <arges> : ) beat me to it
[14:09] <arges> np
[14:13] <Laney> Oh look, someone accepted it
[14:18] <ochosi> hey arges
[14:18] <arges> ochosi: hi
[14:18] <jdstrand> pitti: uploaded isc-dhcp for your fix
[14:18] <ochosi> Laney mentioned i could talk to you in case there is something urgent we'd need upload wise
[14:19] <ochosi> and indeed there are two items in the sponsors queue
[14:19] <pitti> jdstrand: cheers!
[14:19] <arges> ochosi: yes, i'm patch piloting today. What do you need reviewed?
[14:20] <ochosi> arges: to be exact, it's the light-locker-settings 1.2.1 update and the related sync_lock_xfpm_session
[14:20] <ochosi> arges: without those patches, the settings for lock-on-suspend aren't kept in sync, so that might cause a security problem because users currently have to check 3 dialogs individually to be sure
[14:21] <arges> ok so i see https://launchpad.net/bugs/1302484
[14:21] <ochosi> yup
[14:21] <ochosi> the other one is:
[14:21] <ochosi> https://code.launchpad.net/~smd-seandavis/ubuntu/trusty/xfce4-power-manager/sync_lock_xfpm_session/+merge/214392
[14:24] <smoser> pitti, you're back up on wolfe-0X, right?
[14:24] <smoser> they went down on friday as the host fell
[14:24] <arges> ochosi: why is bug 1302484 marked [needs-packaging] ?
[14:24] <infinity> smoser: Fell?  Was intentionally rebooted, you mean.
[14:24] <pitti> smoser: yes, so far they are holding up fine
[14:25] <pitti> last week they became unbearably segfaulty
[14:25] <infinity> smoser: I restarted all the VMs after the host.
[14:25] <ochosi> arges: i think that was a mistake, bluesabre meant "needs uploading"
[14:26] <arges> ochosi: is this update a bugfix only release?
[14:27] <ochosi> arges: yes, there are no new features apart from keeping the settings of those three dialogs in sync: xfce4-session-settings, xfce4-power-manager-settings, light-locker-settings
[14:28] <smoser> infinity, right.
[14:28] <smoser> "intentionally" deserves some quotes there.
[14:28] <smoser> it wasn't really planned downtime.
[14:28] <infinity> smoser: I planned it several minutes in advance. ;)
[14:29] <smoser> touche
[14:35] <arges> Laney: i'm looking at bug 1302484. I believe this is an FFe and it looks like the update is bugfix only. Do I need a release-team member to verify? Thanks
[14:35] <Laney> arges: Nah, not if it's bug fix only
[14:36] <arges> Laney: cool thanks
[14:36] <Laney> It'll go to the queue anyway so you can be spanked if that turns out to be false. :P
[14:36] <arges>  : )
[14:39] <Laney> Sweetshark: "we dont care for stderr in the autopkgtest configure" in libreoffice-l10n, yet there's no autopkgtest there
[14:39] <Laney> copy-paste error?
[14:40] <seb128> Laney, same packaging for libreoffice and l10n
[14:40] <mterry> @pilot in
[14:40] <seb128> Laney, so they share changelog entries
[14:40] <Laney> same packaging?
[14:40] <seb128> Laney, there is 1 packaging tree, the source has just been split to reduce build time
[14:41] <seb128> Laney, but you can consider libreoffice and -l10n as one package if you prefer
[14:41] <Laney> I don't prefer that
[14:42] <Twooey> Is there any good documentation on how to start contributing to ubuntu as a new programmer?
[14:42] <seb128> Laney, ok, I'm going to let Sweetshark answer then
[14:43] <Laney> I understand what you're saying, but ...
[14:43] <arges> Twooey: hey depends on how you want to contribute. There is lots of documentation at https://wiki.ubuntu.com/
[14:43] <Laney> Think about if you did that for an upstream project, it'd be weird
[14:43] <Laney> Same here
[14:44] <seb128> right, the other solution is to fork/double the packaging
[14:44] <seb128> with having the changelog different between the 2 trees
[14:44] <Laney> It manages to have a separate control file
[14:44] <seb128> and having to maintain them in sync
[14:44] <seb128> I guess they could have 2 changelogs and pick the one corresponding to the source built
[14:44] <Twooey> arges: I'm hoping to find some simple bugs and such I can work use to improve my programming, and help benefit the project. I could have sword I saw something a while ago, but I can't find it.
[14:44] <seb128> anyway, I'm not defending the solution
[14:44] <Laney> ok, thanks for explaining
[14:44] <seb128> just saying why you have changelog content non match l10n
[14:45] <seb128> yw!
[14:47] <arges> Twooey: I would find a bug that personally affects you that may seem simple, file an ubuntu bug (or find an existing one). Then look through this wiki a bit http://community.ubuntu.com/contribute/developers/package-maintenance/
[14:47] <Twooey> thanks!
[14:47] <Twooey> I had just found my way there.
[14:56] <mterry> @pilot out
[15:34] <seb128> does anyone know what's the right component for bug #1302192?
[15:35] <seb128> it works for me but that received a duplicate and some users confirming, so it's likely an issue
[15:47] <mvo> jibel: is it easy for you to do a upgade test with this PPA: https://launchpad.net/~mvo/+archive/eglibc-trusty ? (once eglic is build)? should fix #1298281
[15:53] <Elv1313> Hello, I am one of sflphone developper, we need to patch this bug ASAP https://bugs.launchpad.net/ubuntu/+source/sflphone/+bug/1299967 , there is two one liner patches to fix these issues. How can we get them in? (the packages come from Universe)
[15:56] <slangasek> xnox: please have a look at the latest comments on bug #893021
[15:58] <xnox> slangasek: right, indeed i just ripped out the previous way. I'll look into patching in the fallback path.
[15:58] <slangasek> xnox: thanks
[16:03] <Elv1313> I need to get this https://projects.kde.org/projects/playground/network/sflphone-kde/repository/revisions/937fc35baea892dcb4cc19334cab9dba98eaff8f/diff/src/lib/phonenumber.cpp and this https://projects.savoirfairelinux.com/projects/sflphone/repository/revisions/390d5826f2f0db8bf7634f773ca36fb622009a06/diff/gnome/src/sflphone_client.c into 14.04 or the app wont start for most users
[16:06] <xnox> Elv1313: file a bug on launchpad against ubuntu distribution and package in question + attach the required patches. For extra points, check that they apply cleanly, build and result in working packages, and prepare a full debdiff
[16:06] <xnox> Elv1313: on the bug report, steps to reproduce the issue would be useful (written for people who are unfamiliar with that package)
[16:07] <Elv1313> there already is a bug report and the patch is already linked (it also apply clean) https://bugs.launchpad.net/ubuntu/+source/sflphone/+bug/1299967
[16:08] <Elv1313> it doesn't open at all due to a glib change
[16:09] <xnox> dholbach: stokachu joined core-dev so he is now available to do patch piloting duties to review and sponsor packages =))))) he is well versed in SRU process, so should be easy for him to review those ;-)
[16:12] <dholbach> awesome, thanks xnox
[16:12] <dholbach> stokachu, congratulations!
[16:15] <tarpman> fresh blood!
[16:19] <Elv1313> xnox: Ok, I attached a patch to both bugs (with the "patch" checkbox), what's next?
[16:21] <xnox> Elv1313: what's the bug numbers?
[16:21] <Elv1313> xnox: #1299967 #1303897
[16:25] <xnox> Elv1313: look easy enough fixes. Bumped priority and targeted for trusty. Any developer now needs to apply those two simple fixes to the package and upload.
[16:25] <xnox> Elv1313: i might do it, unless somebody will beat me to it.
[16:27] <Elv1313> xnox: thanks! Is it possible to move the bugs to "sflphone-gnome" and "sflphone-kde" respectively instead of "sflphone"?
[16:28] <cjwatson> Elv1313: no, they're in the same source package and Ubuntu bugs are categorised only up to the granularity of source packages
[16:28] <Elv1313> ok, thanks. If you need any more info, just ping me, I will be AFK for lunch for the next half hour.
[16:40] <Sweetshark> Laney: libreoffice-l10n is autogenerated
[16:42] <Laney> Sweetshark: Yeah, I see; the results are a bit confusing IMO
[16:54] <stokachu> ScottK: sorry had ameeting, but yes the asking questions part :D
[16:54] <stokachu> Laney: i have that site bookmarked and will contribute
[16:54] <Laney> great
[20:02] <arges> @pilot out
[20:05] <trijntje> ping ypwong: can I ask you some questions about generating iso's for ubuntu kylin? I'm trying to do something similar for dutch using ubuntu-defaults-image, but the resulting image cant boot on UEFI hardware.
[20:13] <xnox> trijntje: ubuntu kylin do not just use ubuntu-defaults, there are assembled into final iso on the official cdimage builders and thus are capable of uefi just like normal ubuntu image.
[20:13] <xnox> trijntje: i'm don't know which changes/where are needed to enable ubuntu-defaults builder to also produce uefi capable images.
[20:15] <trijntje> xnox: I've been looking at their code on launchpad and it looks like they do use ubuntu-defaults as part of the build process, but I don't know the details
[20:16] <trijntje> thats why I figured I would ping someone of the kylin team to ask them, but it would probably have been more polite to use mailingist first :(
[20:16] <xnox> trijntje: sure, though that's only to build the livecd. (see scrollback between myself and infinity earlier today0
[20:17] <xnox> trijntje: ubuntu installer team / release team is producing the isos, not kylin team. Kylin team does development of the localised packages, and uploads those into the archive mostly.
[20:17] <xnox> trijntje: cdimage.ubuntu.com produces the iso's.
[20:18] <xnox> trijntje: see http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntukylin/trusty/ and http://people.canonical.com/~ubuntu-archive/livefs-build-logs/trusty/ubuntukylin/
[20:18] <xnox> for build logs.
[20:23] <trijntje> xnox: I see. So I should try to get the release team to produce the iso's for me ;)
[20:23] <xnox> trijntje: it's automated canonical servers, and they produce for official flavours only.
[20:24] <xnox> trijntje: =) but indeed we need to sort out defaults-builder / uefi story as it's very useful tool to remaster isos
[20:26] <trijntje> the problem is that I've only ever used the defaults-builder scripts to create iso's, so I cant really read the build logs you linked
[20:26] <ScottK> doko: The ruby packages you pointed us to are fixed/removed.  Because we're still using ruby1.9 as default and Debian is using ruby2.0, it was a little more complicated than just using what Debian had.  I'd suggest we switch default Ruby to 2.0 as part of the initial toolchain updates for "U", so it's default when the release opens.
[20:26] <trijntje> I'm guessing it wouldn't work to just copy the EFI folder from an official image to mine and rebuild the iso? I only have to create a single iso so I could do that manually
[20:26] <doko> ScottK, make this 2.1
[20:27] <ScottK> doko: OK.  Something > 2 and I'm happy.
[20:27] <doko> ScottK, can you prepare this? I'm travelling
[20:27] <ScottK> Maybe.
[20:29] <ScottK> doko: Would it make sense to sync 2.1 into Universe for Trusty so it's at least present in the previous release?
[20:40] <trijntje> xnox: is there any chance that would work or does UEFI boot require some sort of signature that only canonical can put on an image?
[20:47] <[reed]> anybody know the LP bug tracking the fix for CVE-2014-0160 (http://heartbleed.com)?
[20:49] <mdeslaur> [reed]: we don't track security updates in LP. It's compiling now, will be out tomorrow morning after QA.
[20:49] <[reed]> mdeslaur: did you all not have heads-up on this? :/
[20:49] <mdeslaur> nope
[20:49] <[reed]> that's ridiculous
[20:50]  * mdeslaur shrugs
[20:50] <[reed]> mdeslaur: it's a super bad bug... seems like somebody should have better coordinated so distros could have had patches ready :/
[21:53] <doko> zul, jamespage: python-taskflow is blocked by failing autopkg tests
[22:05] <zul> doko:  ill have a look tonight
[22:16] <hallyn_> mdeslaur: hey, looking at bug 1304008.
[22:16] <hallyn_> mdeslaur: (and zul) would it make sense to have libvirt-bin Pre-Depends on sudo?
[22:17] <hallyn_> i.e. would that ensure that group sudo would container the created user at libvirt setup time when using tasksel at machine install to setup libvirt-bin?
[22:31] <hallyn_> cjwatson: can you confirm how/when group sudo is populated when installing from iso?
[22:31] <hallyn_> does the initial user jsut get added?  does every 'group adm' user get added?
[23:16] <RAOF> jcastro: Hey, is the juju local provider expected to work in 14.04?
[23:16] <jcastro> yep
[23:16] <jcastro> ensure juju-local is installed
[23:19] <RAOF> jcastro: OOooh!
[23:19] <RAOF> jcastro: https://juju.ubuntu.com/docs/config-LXC.html should probably not say “you need to run ‘sudo juju bootstrap’”, given that doing so will cause juju to say “ERROR bootstrapping a local environment must not be done as root”
[23:20] <RAOF> Which I misread, missing the “not”.
[23:31] <RAOF> @pilot in