=== micahg_ is now known as micahg
=== _salem is now known as salem_
=== salem_ is now known as _salem
[04:00] <moroniclibber> Hey guys.  I'm a little concerned about mir.  I see applications getting ported over to wayland but I'm afraid mir will be neglectated.  If I  continue to use Ubuntu can I expect to get eventual native Libreoffice and Firefox mir support eventually?
[04:01] <moroniclibber> Mostly my concern is I don't want to be running tons of applications under xmir while wayland users get most of their apps natively and not under xwayland
[06:10] <pitti> infinity: interest-noawait seems fine to me at first sight; I'm not familiar with the history, but it doesn't seem to have been a conscious decision "this needs to block"
[07:11] <dholbach> good morning
[07:16] <dholbach> zyga, happy birthday!
[07:16] <zyga> dholbach: thank you :)
[07:31] <brendand> zyga, birthday?
[07:31] <brendand> zyga, well happy birthday :)
[07:31] <zyga> brendand: well, what can I say, yes
[07:32] <zyga> brendand: thank you :-)
[08:49] <rbasak> pitti: do you happen to quickly know if https://launchpadlibrarian.net/214686286/DpkgTerminalLog.txt is a local configuration change or a bug?
[08:50] <rbasak> I've not seen that before - can a user disable the service to cause that, or is it because something else caused it to fail to start?
[08:50] <rbasak> (this is from https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1485487)
[08:50] <ubottu> Launchpad bug 1485487 in openssh (Ubuntu) "package openssh-server 1:6.7p1-5ubuntu1.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed]
[10:06] <rbasak> barry: could you please advise if installing eg. ./usr/lib/python2.7/dist-packages/kimchi/plugins/ginger/API.json is acceptable or if that should be in /usr/share/kimchi instead? It looks unusual to me so I thought I'd check. This is review for a new package.
[10:07] <rbasak> (I'd normally expect to see only .py files in /usr/lib/python2.7/dist-packages)
=== _salem is now known as salem_
=== tedg is now known as ted
[13:27] <barry> rbasak: tl;dr: it's fine.  many python libraries do include data files in their directory structure, and that works well with pkg_resources.  they can use that api to find the data files easily.  it does seem odd that those data files don't go in /usr/share but it's normal.  moving them is more trouble than it's worth.  upstream we've talked about ways to put such data files elsewhere but in a way that they're still easily found by the
[13:27] <barry> normal apis, but so far that hasn't gone anywhere.
[13:30] <rbasak> OK. Thanks!
[13:32] <barry> pitti, slangasek or anybody else who has shell to autopkgtest.u.c: could you please retry the tox i386 build?  it's tmpfail for what looks like problems related to the testbed (i.e. amd64 passes, and i386 should pass too now)
[13:36] <barry> pitti, slangasek same for cantor/amd64
[14:17] <pete-woods> any package-fu-masters out there who could tell me what's wrong with the packaging of indicator-network that makes it non-installable in cross-build?
[14:17] <pete-woods> http://bazaar.launchpad.net/~indicator-applet-developers/indicator-network/trunk.15.10/view/head:/debian/control
[14:59] <cyphermox> pete-woods: what do you mean by uninstallable in cross-build?
[15:02] <pete-woods> cyphermox: https://bugs.launchpad.net/ubuntu/+source/connectivity-api/+bug/1472186
[15:02] <ubottu> Launchpad bug 1472186 in connectivity-api (Ubuntu) "Can't install libconnectivty-qt1-dev on multiarch" [Undecided,Confirmed]
[15:44] <AlbertA> doko: can I get some help to submit this bug upstream? https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1482320
[15:44] <ubottu> Launchpad bug 1482320 in gcc-5 (Ubuntu) "[armhf] exception not caught when defining identical lambdas built with -O2" [Undecided,New]
[15:56] <cyphermox> AlbertA: wfm...
[15:56] <AlbertA> cyphermox: armhf?
[15:56] <cyphermox> oh wait, I didn't try it on armhf
[15:59] <doko> AlbertA, I'll look at it tomorrow
[16:00] <AlbertA> doko: thanks
[16:01] <cjwatson> mterry: oh BTW http://irclogs.ubuntu.com/2015/08/18/%23ubuntu-devel.html#t22:23 was a reply to you but you weren't actually on IRC at the time
[16:20] <mterry> cjwatson, oh thank you!  I noticed some kind soul retried it and it worked
[16:20] <mterry> cjwatson, I never did have success getting an arm64 VM going to poke around
[16:21] <cjwatson> mterry: You don't need VMs for this kind of thing.  chdist rules
[16:22] <mterry> cjwatson, oooh, never used that before.  It does look like exactly what I needed, cheers
[17:05] <arunpyasi> Hi guys
[17:05] <arunpyasi> Can I get some support in respining an ISO ?
[17:13] <davmor2> arunpyasi: do you mean respin or do you mean remaster?
[17:15] <arunpyasi> davmor2, I want to install/upgrade linux kernel 4.0 on a ubuntu iso I have using ubuntu builder or similar. I had tried with ubuntu builder but while testing, it stuck at busybox initramfs, it didn't boot the system to the desktop. Thanks.
[17:17] <davmor2> arunpyasi: not sure how up-to-date this is but it might help you out a little https://help.ubuntu.com/community/LiveCDCustomization
[17:18] <arunpyasi> davmor2, sir, this guide doesn't have the portion what I am wanting to do. I just want to install linux kernel 4.0 to my trusty iso, thats all sir.
[17:19] <arunpyasi> davmor2, as I have already told, I got stuck on busybox shell, can you please tell me why its stuck. I mean some general reasons for the stuck.
[17:21] <davmor2> arunpyasi: out of my league then
[17:21] <arunpyasi> davmor2, Ok sir.
[17:46] <mitya57> barry, doko: can I please get ~pythoneers subscribed to https://launchpad.net/ubuntu/+source/sphinx-rtd-theme bugs? For LP: #1485231
[17:46] <ubottu> Launchpad bug 1485231 in sphinx-rtd-theme (Ubuntu) "[MIR] sphinx-rtd-theme" [Undecided,Incomplete] https://launchpad.net/bugs/1485231
[17:48] <doko> mitya57, you mean that people look at this for bug reports?
[17:49] <mitya57> doko, I thought team subscriber is a requirement for getting the package into main. You may correct me though :)
[17:50] <mitya57> I also requested a similar thing for previous MIRs, and you added it to some packages.
[17:51] <mitya57> I hope I'll take care of all bug reports myself, but I am not the team…
[17:52] <doko> yes, but for main it should be a team with somebody from canonical. so barry maybe should add it to foundations
[17:52] <doko> mitya57, but I wouldn't mind updating pythoneers to the current set of python modules in main ...
[17:55] <mitya57> barry, so please add it to foundations if you can
[18:08] <barry> doko, mitya57 i agree long term we should subscribe pythoneers to python packages in main.  i don't have time for that right now, so for now i'll just subscribe pythoneers to sphinx-rtd-theme
[18:10] <mitya57> barry, thanks!
[18:10] <mitya57> I'm not yet sure if my MIR makes sense the day before feature freeze, but even if not now, I would need it at the beginning of next cycle anyway.
[18:11] <doko> barry, that doesn't help for the MIR
[18:12] <barry> doko: why not?
[18:13] <doko> barry, because pythoneers is no "canonical" team. or are you looking at all packages in this team on a regular basis, and keep the packages in this team up to date?
[18:14] <doko> apparently not =)
[18:14] <mitya57> FWIW https://wiki.ubuntu.com/UbuntuMainInclusionRequirements tells "a developer or team of developers paying attention to their bugs", but doesn't say anything about "Canonical team"
[18:15] <mitya57> If it's really the requirement, it perhaps should be mentioned in the wiki
[18:15] <barry> well, looking and fixing are two different things :/
[18:16] <barry> i think pythoneers is a better team than foundations, but i'm happy to discuss that on the mlist
[19:01] <doko> bad zul ... debian/rules: Dont run tests for python35.
[19:01] <barry> :(
[19:01] <zul> doko: fails miserably with python35
[19:01] <doko> fix it
[19:02] <doko> or don't use lifeless fork
[19:09] <hallyn_> pitti: hi - do you know of a way in a .service file to ask systemd to not create a slice at all for the service?
[19:09] <hallyn_> Using Slice=boo I can ask that the slice be created *under* boo, but I can't seem to say "dont create one"
[19:10] <hallyn_> although in the code I see checks for "if ->cgroup_name == NULL", so I assume there's a way to say what I want...
[19:10] <hallyn_> (and, using "Slice=-.slice" I'm only asking for service.slice to be created as a root level cgroup rather than under system.slice - still not what i want)
=== salem_ is now known as _salem
=== _salem is now known as salem_
[19:55] <lifeless> doko: what ?
[19:57] <lifeless> zul: what fails with python35 ?
[19:59] <zul> lifeless: http://pastebin.ubuntu.com/12130288/
[20:03] <lifeless> zul: appears to be a bug in unittest2
[20:03] <lifeless> zul: I haven't synced it in a bit. If you wanted to put a patch up (in the bug tracker which has just moved from google code - its now https://github.com/testing-cabal/unittest-ext
[20:04] <lifeless> zul: but the code is still - https://hg.python.org/unittest2
[20:04] <lifeless> zul: On my short term todo is moving it from there into git and then setting up travis for it with the nightly branch tests
[20:04] <zul> lifeless: ok ill take a look when i get a chance
[20:05] <lifeless> zul: I suspect the failure might be due to the bug in traceback about exception header lines
[20:05] <lifeless> zul: e.g. cosmetic at most
[20:08] <pitti> slangasek: FYI, I already retried all tmpfail issues, there were some "hit the quota limit" issues
[20:08] <lifeless> zul: so yeah, I think its related to issue #24695:
[20:08] <lifeless> zul: which I haven't backported yet
[20:09] <lifeless> zul: probably there's some mismatch - some point where its using the built in traceback module vs traceback2
[20:09] <lifeless> zul: I've reproduced it locally though - so its not a packaging issue.
[20:09] <lifeless> zul: file the bug upstream, move on.
[20:09] <zul> ok
[20:10] <zul> ill do that in a bit
[20:10] <pitti> hallyn_: i. e. you want a service to be in cgroup /servicename.service directly without a slice parent? I don't know whether that's possible or even makes sense (especially not in the future unified hierarchy), might be worth asking in #systemd or the ML?
[20:16] <lifeless> zul: thanks
[20:54] <jcastro> pitti: so I suppose that it would be a combination of the SRU queue processing and the seven day wait period.
[20:54] <jcastro> that just seems to slow
[21:03] <infinity> jcastro: I missed context, but what SRU is "too slow"?
[21:03] <jcastro> for getting in the newest nvidia drivers.
[21:04] <jcastro> I mean, tbh, if the SRU process wasn't slow we would have never needed to make a PPA.
[21:04] <infinity> jcastro: Talking hypotheticals, I guess?  There aren't any in the queue or proposed.
[21:04] <infinity> jcastro: You do remember the wild west that was SRUs before we made the process slow, right?
[21:04] <hallyn_> pitti: no, i can do /servicename.service using Slice=-.slice.  But I want it to be in /
[21:04] <infinity> jcastro: It's a bit of a catch-22 here.
[21:04] <jcastro> yes I do
[21:05] <cjwatson> wild west => we're all fired
[21:05] <jcastro> and I realize what I am asking for is totally opposite of what we know is the right thing
[21:05] <infinity> jcastro: And given the packaging of those drivers, they *do* need review and testing, because they *do* break, often.
[21:05] <jcastro> but if the answer is "nope, not going to happen" then that's fine too, there are plenty of things we can work on
[21:05] <infinity> jcastro: It's not a simple case like tzdata, where the packaging is minimal, and the data is verifiable.
[21:05] <jcastro> infinity: right, but I was hoping to get away with "not our problem, if they break, talk to the vendor."
[21:06] <jcastro> like they do for every single platform except for us apparently. :-/
[21:06] <infinity> jcastro: The *packaging* breaks often. :P
[21:06] <infinity> jcastro: Which totally is our problem.
[21:06] <jcastro> oh, I see!
[21:06] <jcastro> infinity: so do you think we should just sort ourselves for a while and see how it goes and then approach later?
[21:07] <infinity> jcastro: The binary blobs break even more often, true, but as you say, not a whole lot we can do about that.
[21:07] <infinity> jcastro: Who is us, and what are you sorting, and with whom?
=== aryan_ is now known as arunpyasi
[21:08] <infinity> jcastro: I mean, driver updates in stable releases need to happen.  Making them happen more quickly is a laudable goal.  Making them happen 0-day with upstream releases isn't going to happen without you having advance copies and pre-review and a bunch of other fancy.  The history of these packages is not good enough for any of us to give them a hand-wave without reviewing every, single, upload thoroughly (which sucks...)
[21:08] <jcastro> https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa
[21:09] <jcastro> infinity: imo it doesn't need to be perfect, it needs to be enough to stop people from saying "if you game don't use ubuntu."
[21:09] <infinity> jcastro: Ugh.  No.  We're not adding PPAs as official repos in installers.
[21:10] <jcastro> heh
[21:10] <infinity> jcastro: If it's good enough to put our name on it, it belongs in the primary archive, if it's so crap it can only happen in a PPA, it shouldn't be recommended to users, don't game the system.
[21:10] <jcastro> fair enough
[21:10] <jcastro> We apparently don't have the resources to have people dedicated to bringing things into the primary archive
[21:11] <jcastro> which is as I understand it how we got so behind in the first place
[21:16] <rbasak> What if we found a way to have two streams in the archive at once?
[21:17] <rbasak> Although I suppose that's what -proposed is.
[21:18] <rbasak> Could we for example get things into -proposed very quickly, and make it easy for consenting users to specifically consume nvidia drivers from -proposed very easily?
[21:18] <rbasak> Or will we not be able to keep up with that?
=== aryan_ is now known as arunpyasi