[02:05] <TheMuso> @pilot out
[02:17] <TheMuso> @pilot out
[02:18] <TheMuso> oh already done. :)
[03:08] <happyaron> bdmurray: well no, it's a small feature, and the cooperation project is still private.
[05:18] <pitti> Good morning
[05:19] <pitti> bdmurray: in principle yes; but that would need more cleverness in sandboxutils/the apt_dpkg to retrieve versions which aren't published in the archive any more (i. e. not in apt) directly from LP
[05:20] <mitya57> rsalveti: thanks for pyqt5 upload!
[05:20] <mitya57> In case someone is interested, I pushed a branch to fix qt3d FTBFS, waiting for CI approve.
[05:50] <Noskcaj> pitti, thanks for the uploads
[05:52] <Noskcaj> Any chance you could improve the testimonial you gave me? https://wiki.ubuntu.com/Noskcaj#MOTU
[06:00] <pitti> Noskcaj: ah, looking
[06:03] <pitti> Noskcaj: done now; http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=Martin+Pitt&sponsor_search=name&sponsoree=Jackson+Doak&sponsoree_search=name now looks fairly impressive :)
[06:09] <sarnold> ubuntu-dev.alioth.debian.org? :)
[06:09] <sarnold> wow, that's impressive :)
[06:11] <Noskcaj> thanks Pici
[06:11] <Noskcaj> oops, pitti
[06:11] <pitti> Noskcaj: thanks to you!
[06:27] <mitya57> sarnold: That webpage uses Ultimate Debian Database, that's why it is there
[06:32] <sarnold> mitya57: oh man, that's even cooler :)
[07:44] <dholbach> good morning
[08:12] <mitya57> Mirv: Should I do anything special with my qt3d MP to trigger CI?
[08:14] <Mirv> mitya57: I was also wondering why it's not working, I'll ping CI folks at #ubuntu-ci-eng
[08:15] <mitya57> Mirv: thanks
[08:23] <mightyiam> Since the trusty updates today I can't type in any other language than English.
[09:36] <dholbach> seb128, can you reproduce bug 1292382?
[09:37] <seb128> dholbach, uninstall libhybris?
[09:37] <dholbach> ah ok
[09:37] <seb128> that diverts the libGL
[09:37] <dholbach> I wanted to try out the unity8 desktop session - that's probably where I got it from :)
[09:37] <seb128> well, just guessing from the title, but that's usually the issue when we see that error
[09:37] <seb128> yeah
[09:38] <seb128> it's a bit unfortunate that it screws libGL for desktop users this way
[09:40] <RAOF> seb128, dholbach: You're looking at bug #1291761
[09:41] <seb128> RAOF, well, from the title solving that issue wouldn't solve the problem, that problem keeps happening through different components
[09:41] <seb128> RAOF, we should just make libhybris less destructive for desktop users
[09:42] <seb128> like make it not divert your libGL by default
[09:42] <RAOF> But it kinda has to.
[09:43] <RAOF> I don't know if it's possible, but the right behaviour would be ‘divert if there's an underlying Android stack for hybris’.
[09:43] <dholbach> seb128, confirmed, that's the problem
[09:44] <seb128> dholbach, great
[09:44] <seb128> RAOF, right
[09:44] <dholbach> seb128, shall I mark it as a dup of 1291761?
[09:44] <seb128> but yeah, not having unity8 pulling it in would already be a good thing
[09:44] <seb128> dholbach, yes please
[09:45] <dholbach> done, thanks
[12:12] <chrisccoulson> hmm, it seems that https://launchpad.net/ubuntu/+source/libdbusmenu-qt/0.9.2+14.04.20140305-0ubuntu1 has migrated from proposed, but it built against qt5.2 which hasn't migrated yet (and depends on some symbols introduced in 5.2)
[12:12] <rbasak> jamespage: python-websocket-client (indirect dependency of juju-quickstart) is behind PyPI. It's an Ubuntu-only package. I don't see any reason to break FF and bump it now, but that isn't good for MIR and maintanence. Do we have any system for tracking outstanding watches in Ubuntu?
[12:13] <jamespage> rbasak, no and that sucks
[12:13]  * jamespage tries to remember something
[12:13] <rbasak> We could quite easily create a report that just looks for -0ubuntu packages and runs uscan
[12:14] <jamespage> rbasak, is the latest 0.12.0 ?
[12:14] <rbasak> Yes
[12:14] <jamespage> right - we've got two packages providing the same version
[12:14] <jamespage> one is incorrectly named
[12:14]  * jamespage sighs
[12:14] <jamespage> rbasak, python-websocket
[12:15] <rbasak> https://launchpad.net/ubuntu/+source/websocket-client
[12:15] <rbasak> https://launchpad.net/ubuntu/+source/python-websocket-client
[12:15] <jamespage> rbasak, can I suggest we switch the dep in jujuclient and drop python-websocket-client
[12:15] <rbasak> The first is in Debian.
[12:15] <jamespage> yeah
[12:15] <rbasak> jamespage: agreed. I'll take care of it.
[12:15] <jamespage> thanks
[12:15]  * rbasak wonders if this needs an FFe.
[12:17] <jamespage> rbasak, I don't think so
[12:17] <jamespage> its tidying
[12:17] <jamespage> fundamentally the underlying python is the same
[12:17] <rbasak> It's a version bump :)
[12:18] <jamespage> rbasak,  trying to overwrite '/usr/lib/python2.7/dist-packages/websocket.py', which is also in package python-websocket-client 0.11.0-0ubuntu1
[12:18] <rbasak> (for python-jujuclient)
[12:18] <rbasak> OK well that's a bug :)
[12:19] <jamespage> rbasak, lets ask kapil
[12:19] <jamespage> rbasak, but I don't think it will be an issue
[12:19] <jamespage> rbasak, this is my bad for never pushing this package back up to debian
[12:20]  * jamespage either forgot or ran out of time
[12:23] <geser> rbasak: something like http://qa.ubuntuwire.org/uehs/no_updated.html for tracking watch files?
[12:24] <jamespage> rbasak, urgh - the package from debian is not really named correctly IMHO
[12:24] <rbasak> jamespage: why? It matches the upstream tarball name, right? What's the correct way to do it?
[12:25] <jamespage> rbasak, the name of the python project is websocket-client
[12:25] <jamespage> the name of the binary from Debian is python-websocket
[12:25] <jamespage> when dh_python2 does its business it auto-generates a dependency on python-websocket-client
[12:25] <jamespage> naming convention being python-(project-name)
[12:25] <rbasak> geser: thanks! Though I don't see this websocket thing in there, and am not sure why.
[12:26] <jamespage> but I can think of other things that don't follow that
[12:26] <jamespage> barry, care to give an opinion on the above?
[12:26] <rbasak> I presume the binary name difference stopped this issue being flagged up before, too.
[12:29] <rbasak> jamespage: "The binary package for module foo should preferably be named python-foo, if the module name allows..."
[12:29] <rbasak> jamespage: since it provides websocket.py, I think the right binary package name would be python-websocket.
[12:29] <rbasak> So "import websocket" -> "apt-get install python-websocket"
[12:31] <rbasak> jamespage: I've filed https://bugs.launchpad.net/ubuntu/+source/python-jujuclient/+bug/1292502
[12:31] <jamespage> rbasak, yeah - I guess so
[12:31] <jamespage> so it aligns to the actual module name, not the upstream project name
[12:31] <rbasak> The binary does, yes. I'd expect the source to align with the upstream project name, though that's just an assumption I made and I'm not aware of any policy around that.
[12:32] <jamespage> rbasak, we'll need to insert an appropriate Breaks/Replaces/Conflicts on python-websocket to ensure it gets bumped from installs
[12:32] <rbasak> jamespage: good point, thanks. I'll add a task for that.
[12:32] <rbasak> At least we can drop that delta in U I suppose.
[12:32] <jamespage> rbasak, I can confirm that python-jujuclient appears functional with python-websocket
[12:32] <rbasak> Thanks
[12:33] <jamespage> but we'll need to add a pydist-override to map websocket-client -> python-websocket
[12:40] <rbasak> ack
[12:50] <rbasak> jamespage: https://github.com/liris/websocket-client/issues/60 'websocket' clashes with other popular python libraries
[12:50] <jamespage> rbasak, nice
[12:50] <rbasak> And the test suite is missing from the Python sdist.
[12:50] <rbasak> This seems to be a really common thing (things missing from the sdist tarball)
[12:51]  * rbasak files a github issue for that
[12:57] <xnox> ..
[12:57]  * xnox IT'S IN!
[12:57] <xnox> ..
[12:57] <didrocks> (be scared) ;)
[12:58] <davmor2> I don't won't to know what xnox is doing
[12:58] <xnox> davmor2: Qt5.2
[12:59] <davmor2> \o/
[13:08] <lamont> The following packages have been kept back:
[13:08] <lamont>   libdb-dev tk8.5
[13:08] <lamont> I wonder if I care
[13:09] <barry> jamespage: did you guys figure it out?
[13:09]  * lamont manually installs them and watches the package shuffles
[13:10] <jamespage> barry, I think so yes
[13:10] <barry> jamespage: cool
[13:18] <rsalveti> seb128: I'm investigating the hybris issue today
[13:18] <rsalveti> just need a clean up and split some other pieces (input), then we shouldn't have anyone depending on it at all
[13:19] <rsalveti> qtubuntu needs the input headers, creating all the mess
[13:19] <seb128> rsalveti, hey, great, thanks!
[13:19] <rsalveti> such as powerd
[14:13] <bdmurray> happyaron: we don't generally SRU new features
[14:15] <bdmurray> pitti: my thought was more that we could use that to notice ones that are published in the archive but just don't exist on the ddebs for whatever reason.
[15:07] <hyperair> what's a good test for whether systemd is running as pid1 or not in ubuntu?
[15:07] <hyperair> or rather, a good cross-distro way that doesn't check /sys/fs/cgroup/systemd, since that exists in ubuntu via systemd-shim
[15:08] <hyperair> (inside a udev script)
[15:08] <hyperair> er udev rule
[15:12] <ScottK> systemd is never running as pid 1 in Ubuntu.
[15:12] <ScottK> So if you are on Ubuntu (at least now) you know.
[15:14] <cjwatson> hyperair: The sd_booted library function in systemd tests for whether /run/systemd/system exists and is a directory
[15:15] <hyperair> cjwatson: oh nice thanks
[15:15] <cjwatson> hyperair: /usr/bin/deb-systemd-helper does likewise (-d "/run/systemd/system")
[15:15] <cjwatson> So I think that's the canonical answer
[15:15] <hyperair> heh
[15:15] <hyperair> alright
[15:15] <cjwatson> Yeah, sd_booted(3) agrees
[15:18] <hyperair> thanks
[15:30] <pitti> hyperair, cjwatson: correct, that's the official upstream answer now (it used to be the cgroup, but we changed that for our case of running logind without systemd pid 1)
[15:39] <xnox> cjwatson: i wonder if the $ initctl version; check as advocated by debian policy will start giving false positives, if we start running systemd as pid1 and system-upstart as pid2
[15:44] <dholbach> asac, I think I have accidentally moved the landing taskforce calls in the calendar - they are at 9:30 utc in the morning, right?
[15:48] <dholbach> ok, looks like they're fine again
[16:08] <lamont> resizing windows by grabbing corners has become harder with trusty, and it seems that the upper left corner just doesn't want to recognize the mouse at all.  and then there's the occasional "oh you want full screen, sure" surprise.
[16:09] <Meerkat> since a few version it seems you only have a 1 pixel thick border to do any resizing on
[16:09] <Meerkat> lamont, alt+right click should work fine. Try it.
[16:10] <Meerkat> alt+hold right mouse rather
[16:10] <lamont> well... for these particular things,  alt-rtmouse gives me a menu, which happens to have 'resize' in it, so it works
[16:11] <lamont> in times past, I may have smacked the theme into once again having a 10-pixel border....
[16:11]  * lamont whistles
[16:11] <Meerkat> 1 pixel dragable border is really silly
[16:12] <Meerkat> good that you found a way
[16:20] <ogra_> lamont, are you up to date on your trusty ? for me it is like a 20px area since there are no borders anymore ... way easier to grab
[16:21] <lamont> I might not have restarted X this morning
[16:21] <ogra_> ah
[16:21] <xnox> lamont: in display, i've increased the UI scaling to give me everything just a tad bigger. It seems that grabbing area also increases.
[16:21] <lamont> but it was currnet 2 days ago when I rebooted...
[16:22] <xnox> lamont: are you on a better than 98dpi screen?
[16:22] <ogra_> it might be psychological though ... i simply dont try to hit the 1px border anymore since it is gone :)
[16:22] <xnox> lamont: (e.g. an HD or FULL-HD one)
[16:23] <xnox> lamont: my top-left corner grab areas is the size of about half the title-bar height on the left edge of the screen.
[16:26] <lamont> xnox: and when the window goes to the top of the display area, and bumps up against the bottom of the panel?
[16:27] <xnox> lamont: oh, one is screwed when that happens =)
[16:27] <lamont>   resolution:    96x96 dots per inch
[16:27] <ogra_> thats the resolution X thinks you have :)
[16:27] <lamont> xnox: the real question is, is that a bug, or is it considered a feature
[16:27] <xnox> lamont: but, you just grab any portion of the top bar and drag down, it "un-maximizes" the window?!
[16:28] <lamont> it's the resolution that the display thinks I have, too, I think... inspiron 5010
[16:28] <lamont> xnox: nope.
[16:29] <xnox> lamont: i see what you mean now, the grabers are fully gone one the edges meet. that's weird.
[16:29] <lamont> once I drag it down, then I can grab it and resize it...
[16:29] <lamont> somehow I suspect that this might be related to my 3x3 workspace topology
[16:29] <xnox> i just have dual-screen and no workspaces, same problem.
[16:32] <ogra_> xnox, btw, my GF has a yoga, do you have any script that switches off kbd/touchpad when in tablet mode for yours ?
[16:34] <xnox> ogra_: something hacked up, yes. not quite reliable.
[16:35] <xnox> ogra_: disable keyboard -> http://paste.ubuntu.com/7091051/
[16:35] <xnox> ogra_: rotate screen & touchpad into vertical mode http://paste.ubuntu.com/7091052/
[16:36] <xnox> ogra_:  i didn't hook that up to the setkeycode, but some gists on github have that fully working with a setkeycode.
[16:36] <xnox> ogra_: kernel in trusty or 3.14 will have setkeycode mapped for that i think...
[16:36] <ogra_> well, i would like to disable the touchpad altogether when it is in tablet mode ... but thanks with that i should find my way along
[16:39] <xnox> ogra_: yeah, i think touchpad is another xinput thing one can disable. just check the args, it should have option to list all devices and thus find the touchpad.
[16:40] <ogra_> yeah
[16:40] <ogra_> thanks !!
[16:40] <ogra_> something to do on the upcoming rainy weekend :)
[18:08] <smoser> xnox, i realized yesterday that i had (possibly incorrectly) associated performance regression with your changes
[18:08] <smoser> to plymouth. rather than with the fix that we wanted.
[19:51] <jtaylor> doko is on vacation or? until when?
[20:05] <slangasek> jtaylor: doko is currently unavailable; something you need that someone else can help with?
[20:06] <jtaylor> I would like 1290287 fixed soonish
[20:06] <jtaylor> but next week is probably ok
[20:28] <infinity> jtaylor: I can fix that.
[20:29] <jtaylor> infinity: thanks that would be great, it affects debian too, there is a patch in the bug there
[20:30] <infinity> jtaylor: Yeah, I won't NMU to Debian unless it's urgent.  Is there an upstream commit for this?
[20:30] <infinity> jtaylor: It's a bit disconcerting that the patch in the Debian bug is different from the one in the mailing list post you pointed at.
[20:30] <jtaylor> hm didn't find a upstream VCS, but also didn#t search much
[20:30] <jtaylor> yes my link is a old upstream reply
[20:31] <jtaylor> I'll add the latest one which the patch is based of
[20:31] <jtaylor> 34 instead of 31 in the link
[20:31] <infinity> Ahh, this has the new one http://lists.gnu.org/archive/html/bug-readline/2014-03/msg00034.html
[20:31] <Noskcaj> stgraber, Mind if i package the new bugfix release for busybox? "1.21.1 has fixes for ntfs detection (big-endian fix), xz decompression of concatenated streams, mdev acquired a [ENV=regex;] extension instead of undocumented subsystem match hack it used to have prior to 1.21.x."
[20:31] <infinity> Check.
[20:33] <stgraber> Noskcaj: I don't mind it, though note that dealing with busybox config and making sure they are correct in all cases is very tricky. So I have the feeling it's one of those merges where the only way to make sure it was done right is to do it again yourself.
[20:34] <stgraber> so I'm not against it but I doubt I'll have time to review it myself (since it's not a priority target for me at all)
[20:34] <Noskcaj> Debian went straight to 1.22, so i'd just be merging a minor release from upstream
[20:34] <stgraber> yeah, the problem is that our busybox build config is pretty different from Debian and upstream has a tendency to add/remove/rename config options all the time...
[20:35] <infinity> jtaylor: Hrm, doesn't look to be committed upstream yet.  Oh well.
[20:35] <jtaylor> there is this: http://lists.gnu.org/archive/html/bug-readline/2014-03/msg00040.html
[20:36] <stgraber> so just swapping the source tarball and assuming that since Debian didn't change their config ours don't need to either, isn't a good plan at all and has been a problem in the past. You actually need to go through the upstream diff and make sure they didn't sneak some config renames in there
[20:37] <Noskcaj> stgraber, ok. I'll leave that one then. The entire changelog was what i quoted above
[20:37] <jtaylor> infinity: did you find an upstream source repo? url?
[20:37] <stgraber> Noskcaj: sure, I just tend not to trust the changelog ;)
[20:37] <Noskcaj> understandable
[20:38] <jtaylor> a found it on savannah
[20:38] <stgraber> and considering that a broken busybox tends to break all Ubuntu systems from booting, I prefer to keep what we have unless we're 100% sure it won't regress us
[20:39] <stgraber> s/break/prevent/
[20:39] <infinity> jtaylor: That look like what you tested? http://paste.ubuntu.com/7092227/
[20:40] <jtaylor> infinity: yes
[20:40] <infinity> Oh, I guess I should put a bug closure in there.
[20:42] <infinity> jtaylor: Uploaded.
[20:43] <jtaylor> infinity: great, thanks
[22:52] <asac> dholbach: i think so :) ... ogra and didrocks should know for sure
[22:52] <asac> ogra_: when is the morning landing team call?
[22:53] <asac> ogra_: dholbach moved it accidentially, can you confirm it was 10:30 our time?
[23:51] <ogra_> asac, yup ... all fine, i checked the calendar