| === micahg_ is now known as micahg | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| 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:00 |
|---|---|---|
| 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 | 04:01 |
| 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" | 06:10 |
| dholbach | good morning | 07:11 |
| dholbach | zyga, happy birthday! | 07:16 |
| zyga | dholbach: thank you :) | 07:16 |
| brendand | zyga, birthday? | 07:31 |
| brendand | zyga, well happy birthday :) | 07:31 |
| zyga | brendand: well, what can I say, yes | 07:31 |
| zyga | brendand: thank you :-) | 07:32 |
| rbasak | pitti: do you happen to quickly know if https://launchpadlibrarian.net/214686286/DpkgTerminalLog.txt is a local configuration change or a bug? | 08:49 |
| 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] | 08:50 |
| 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:06 |
| rbasak | (I'd normally expect to see only .py files in /usr/lib/python2.7/dist-packages) | 10:07 |
| === _salem is now known as salem_ | ||
| === tedg is now known as ted | ||
| 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:27 |
| rbasak | OK. Thanks! | 13:30 |
| 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:32 |
| barry | pitti, slangasek same for cantor/amd64 | 13:36 |
| 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:17 |
| cyphermox | pete-woods: what do you mean by uninstallable in cross-build? | 14:59 |
| 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:02 |
| 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:44 |
| cyphermox | AlbertA: wfm... | 15:56 |
| AlbertA | cyphermox: armhf? | 15:56 |
| cyphermox | oh wait, I didn't try it on armhf | 15:56 |
| doko | AlbertA, I'll look at it tomorrow | 15:59 |
| AlbertA | doko: thanks | 16:00 |
| 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:01 |
| 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:20 |
| cjwatson | mterry: You don't need VMs for this kind of thing. chdist rules | 16:21 |
| mterry | cjwatson, oooh, never used that before. It does look like exactly what I needed, cheers | 16:22 |
| arunpyasi | Hi guys | 17:05 |
| arunpyasi | Can I get some support in respining an ISO ? | 17:05 |
| davmor2 | arunpyasi: do you mean respin or do you mean remaster? | 17:13 |
| 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:15 |
| 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:17 |
| 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:18 |
| 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:19 |
| davmor2 | arunpyasi: out of my league then | 17:21 |
| arunpyasi | davmor2, Ok sir. | 17:21 |
| 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:46 |
| doko | mitya57, you mean that people look at this for bug reports? | 17:48 |
| mitya57 | doko, I thought team subscriber is a requirement for getting the package into main. You may correct me though :) | 17:49 |
| mitya57 | I also requested a similar thing for previous MIRs, and you added it to some packages. | 17:50 |
| mitya57 | I hope I'll take care of all bug reports myself, but I am not the team… | 17:51 |
| 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:52 |
| mitya57 | barry, so please add it to foundations if you can | 17:55 |
| 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:08 |
| 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:10 |
| doko | barry, that doesn't help for the MIR | 18:11 |
| barry | doko: why not? | 18:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| barry | i think pythoneers is a better team than foundations, but i'm happy to discuss that on the mlist | 18:16 |
| 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:01 |
| doko | or don't use lifeless fork | 19:02 |
| 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:09 |
| 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) | 19:10 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| lifeless | doko: what ? | 19:55 |
| lifeless | zul: what fails with python35 ? | 19:57 |
| zul | lifeless: http://pastebin.ubuntu.com/12130288/ | 19:59 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:08 |
| 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:09 |
| 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:10 |
| lifeless | zul: thanks | 20:16 |
| 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 | 20:54 |
| infinity | jcastro: I missed context, but what SRU is "too slow"? | 21:03 |
| jcastro | for getting in the newest nvidia drivers. | 21:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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? | 21:07 |
| === aryan_ is now known as arunpyasi | ||
| 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:08 |
| 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:09 |
| 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:10 |
| jcastro | which is as I understand it how we got so behind in the first place | 21:11 |
| rbasak | What if we found a way to have two streams in the archive at once? | 21:16 |
| rbasak | Although I suppose that's what -proposed is. | 21:17 |
| 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? | 21:18 |
| === aryan_ is now known as arunpyasi | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!