xnoxdoko_: no point in updating llvm-defaults to 3.5, clamav builds, mesa fails. There are also others that fail with 3.5 - creduce & beignet01:01
xnoxi'll finish up building things tomorrow & will file bugs.01:01
hallyninfinity: a 2.1 rc (very rc) is building in ppa:serge-hallyn/virt .   based on not-yet-released debian experimental package01:49
infinityhallyn: Awesome, thanks.02:11
infinityOh, not that that builds for ppc.  But I can copy that and see what happens.02:12
* infinity does so.02:12
Unit193cjwatson: Hello, is there a specific trigger for when you update tasksel from the seeds, or does someone have to poke you/request a merge?02:13
infinityhallyn: Building for all arches at https://launchpad.net/~adconrad/+archive/ubuntu/ppa/+packages if you're curious how that goes.02:14
infinityUnpacking gnat-4.9 (4.9.1-1ubuntu2) over (4.9.0-1ubuntu5) ...02:15
infinitydpkg: error processing archive /var/cache/apt/archives/gnat-4.9_4.9.1-1ubuntu2_ppc64el.deb (--unpack):02:15
infinity trying to overwrite '/usr/share/doc/gnat-4.9-base/test-summary.gz', which is also in package gnat-4.9-base 4.9.0-1ubuntu502:15
infinitydoko_: ^02:15
cjwatsonUnit193: when I feel like it, basically02:17
cjwatsonUnit193: don't bother preparing a merge request if it's just an automatic update though02:17
cjwatsonUnit193: but it's 3am here and I generally like to think about the changes and make sure they're sane, so mail me?02:17
Unit193cjwatson: Cool, OK.  Yeah, figured that would be a little useless.  I don't suppose that'll be soon?  Yeah.  3AM can be troublesome at times.02:18
cjwatsonit can be soon, but I'll need a reminder02:18
Unit193A random poke later on IRC good enough or do you want that email?02:19
cjwatsonUnit193: as you like02:29
cjwatsonUnit193: but if you want an IRC poke to be effective it'll need to be vaguely within UK working hours :)02:30
Unit193cjwatson: Got it, will do.  Thanks!02:30
=== _salem is now known as salem_
pittihallyn: yes, I will, but I'm still working on the systemd units to start lxc.net and call the apparmor commands03:50
pittiGood morning03:50
sarnoldpitti: wow, this seems early even for you :)03:52
pittisarnold: yeah, can't sleep any more; darn hayfever03:52
sarnoldpitti: ugh, sorry to hear it :(03:53
infinityhallyn: So, it at least built on ppc64el.  Testing will come later.03:59
infinity19:31 < benh> hrm04:04
infinity19:31 < benh> W: Failed to fetch04:04
infinity              Hash Sum mismatch04:05
infinity19:31 < benh> been going on for a while today04:05
infinitypitti: ^04:05
infinitypitti: Did you break something, or is that pilot error on Ben's part?04:05
pittiinfinity: I'm sure it's a ddeb-retriever issue again :/04:06
pittialthough I'm not sure how04:07
pittithat Packages is from July 18, Release is from July 22, and it does have the wrong md504:07
* pitti sends flowers to apt-ftparchive04:08
hallyninfinity: awesome04:10
=== doko_ is now known as doko
dokoxnox, http://people.canonical.com/~doko/tigervnc_1.3.1+X1.15.0-0ubuntu1.dsc05:59
dokocjwatson, barry: seeding system-image causes some component mismatches, including python-pip again, which we were trying to avoid. is this really necessary?06:21
=== evfool__ is now known as evfool
dholbachgood morning06:53
pittihallyn: hm, did you disable github pull requests for LXC? I can't send them any more, the button is disabled06:57
pittihallyn: I sub'ed to the ML now and went through the git-send-email exercise, including greylisting and all that fun *ugh* :)06:58
=== salem_ is now known as _salem
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
cjwatsondoko: yes it is really necessary, can you ignore it for now please and we'll sort out the seeds later (maybe move it to a different collection or something)?07:28
dokocjwatson, ok07:45
=== psivaa is now known as psivaa-brb
xnoxdoko: omg! why are you touching that beast?! =)07:59
dokoxnox, I'm not, just looking at component mismatches08:06
dokoor what is the context?08:07
xnoxdoko: tigervnc =)08:13
xnoxdoko: it tries hard to statically link against a self-included copy.... =)08:13
xnox(embedded copy of code)08:13
dokoxnox, no, it is using the system one08:14
=== psivaa-brb is now known as psivaa
dokoxnox, http://paste.ubuntu.com/7912543/  using the system one08:23
xnoxdoko: i have a crude patch.....08:28
xnoxfind_package(FLTK) should find and define fltk_images_shared & fltk_shared, but it doesn't.... But we know the libraries are available from the global location.... so we can override it.08:29
xnoxthat gives me http://paste.ubuntu.com/7912581/08:31
dokoahh, good, will go from there08:32
pittixnox: sorry, I already asked you about bug 1326327 (forward with CC'ing pkg-systemd) yesterday, but I think I didn't see your reply08:42
ubottubug 1326327 in debhelper (Ubuntu) "dh_installinit should generated update-rc.d remove to remove rc*.d symlinks" [Undecided,New] https://launchpad.net/bugs/132632708:42
xnoxpitti: arrrr. there is nothing to apply in debian for ti.08:42
xnoxpitti: we had an ubuntu delta to drop, which is what that bug was about.08:42
pittixnox: oh, pirate speak day today? :-)08:43
LocutusOfBorg1sorry which bits are missing for libpcap?08:43
pittixnox: ah! nice08:43
LocutusOfBorg1I don't see any, but still in proposed08:43
xnoxpitti: and it's unrelated to the other bug that i don't agree with, but affects both debian & ubuntu08:43
infinityLocutusOfBorg1: "Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)"08:44
xnoxpitti: let me verify things though before closing it, that i did fix it right.08:44
infinityLocutusOfBorg1: In other words, patience until after Alpha2.08:44
pittixnox: that patch isn't applied in current utopic FTR08:46
xnoxpitti: yeah, so e.g. looking at cgmanager_0.27-0ubuntu8_amd64.deb it has no postrm witch has "update-rc.d cgmanager remove"08:47
* xnox checks debian08:47
=== terror_bird is now known as inner_ugliness
pittixnox: ah, I see it now in https://patches.ubuntu.com/d/debhelper/debhelper_9.20140613ubuntu1.patch08:48
xnoxyeah, and debian does generate "update-rc.d cgmanager remove" at purge.08:49
pittixnox: so, your patch LGTM08:50
xnoxwe need both upstart-preinst & update-rc.d removal.08:50
k1lhi: when will the LTS 12.04 to LTS 14.04 upgrade path be opened? we got masses on users in #ubuntu complainin they waited for the .1 release and still cant upgrade. is there a timetable for that?08:50
xnoxk1l: it's been open for a long while =) but there are bugs preventing upgrades, thus we have update-manager in precise-proposed to resolve that.08:51
xnoxk1l: once that is published in precise-updates and people install it, more people will get upgrade notifications and etc.08:52
pittixnox: will you upload, or want me to test with a cgmanager rebuild and upload?08:52
k1lhttp://changelogs.ubuntu.com/meta-release-lts still says no trusty08:53
xnoxpitti: i think i need to reorder things, since $script is overriden by the preinst-upstart-compatibility.08:53
xnoxk1l: that's a bit odd.08:54
xnoxbdmurray: as per k1l above, have 12.04 -> 14.04 upgrades been enabled or are they waiting on update-manager fixes?08:55
LocutusOfBorg1thanks infinity I read about the alpha, indeed, sorry I though there was a line on update_output too08:56
cjwatsonLocutusOfBorg1: update_output only reports on things that haven't been filtered out by individual-package checks at the previous update_excuses stage08:57
LocutusOfBorg1ok thanks, fair enough08:58
TJ-xnox: It's in meta-release-lts-proposed ... I guessed it was waiting on the 12.04 promotion of upgrade-manager-core from -proposed08:59
xnoxTJ-: yeah, i see that. But I have no idea what's the difference between meta-release-lts and meta-release-lts-proposed....09:00
LocutusOfBorg1cjwatson, can I take a look at debian #755327 ? I don't know how to properly fix, but I can give you a debdiff09:00
ubottuDebian bug 755327 in src:gridsite "gridsite: FTBFS: htcp.c:65:27: error: 'CURLOPT_FILE' undeclared (first use in this function)" [Serious,Open] http://bugs.debian.org/75532709:00
cjwatsonLocutusOfBorg1: I already fixed that this morning09:01
LocutusOfBorg1oh wonderful09:01
xnoxpitti: actually with patch from the bug, it all looks correct and sensible.09:01
cjwatsonreload the bug :)09:01
LocutusOfBorg1I was stuch in a gstreamer build with some spare time ;)09:01
LocutusOfBorg1no NMU in delayed?09:02
xnoxpitti: uploaded.09:03
xnoxpitti: it is relatively harmless though, as any insserv invocation removes stale symlinks.09:03
cjwatsonLocutusOfBorg1: *shrug* might do that later, no rush09:03
LocutusOfBorg1anyway, they fixed upstream with a slightly different patch https://github.com/CESNET/gridsite/commit/2124d471f9fc1eed4bf5893ed2701350357c01af09:03
cjwatsonLocutusOfBorg1: I'm busy this morning09:04
cjwatsonLocutusOfBorg1: feel free to pass a reference to the Debian bug09:04
cjwatsonsure, that's fine too, just not something I felt entitled to do as a downstream09:04
pittixnox: ah, good; thanks!09:04
LocutusOfBorg1yes, I'll prepare a debdiff with the upstream cherry-picked commit, I'm sure the debian maintainer will be happy to apply :)09:05
pittiapw: do you still have bug 1329056?09:10
apwlp: #1329056?09:11
apwpitti, i do, but i realise that the fixes xnox tried for me didn't work because i have the WIP initramfs-tools on that machine, so all bets are off09:12
apwi will try and get that downgraded09:12
pittiapw: hm, mup failure?09:12
pittiapw: oh, how would that affect lightdm?09:12
pittiubottu: <poke>09:13
pittiapply resuscitation to ubottu09:13
=== udevbot_ is now known as udevbot
Laney#ubuntu-bots IIRC09:14
xnoxdoko: found the bug in cmake-data FindFLTK -> it does everything to consider static FLTK only.09:14
Unit193It takes a bit to sync up, has many channels to join.  ubottu that is.09:15
pittiLaney: oh, it just sent me a privmsg complaining about <poke>09:15
pittibug 132905609:15
ubottubug 1329056 in lightdm (Ubuntu) "lightdm does not start under systemd" [Undecided,Incomplete] https://launchpad.net/bugs/132905609:15
jamespagepitti, cjwatson: would the foundations team considering owning pm-utils? its currently subscribed to by the server team but pretty much every bug I've touched this morning is a laptop suspend/resume problem of some description09:16
apwpitti, the conjecture is that the main issue is that the systemd stuff doesn't work if you have encrypted stuff in your initramfs, and plymouth ends up there; and i have that inadvertantly09:16
cjwatsonjamespage: it's thematically appropriate but I don't know if we have any relevant experts09:17
apwpitti, due to bugs in initramfs-tools, which xnox has fixed in the older version09:17
pittiapw: ah, that's easy enough to test; installin "cryptsetup" should do that, right?09:17
xnoxapw: horum.09:17
apwpitti, well no, it is meant to be bright enough to only do it if your actual root is special09:17
xnoxpitti: well, my cryptsetup hooks are modified to not include themself, if one doesn't have encrypted root.09:17
xnoxapw: did i actually upload that path fix, or not?! =)09:18
pittiapw: oh, is that new? in the past we only installed cryptsetup-bin by defualt, and cryptsetup only if you actually use encrypted root09:18
pittiapw: anyway, easy enough to check by the contents of the initramfs09:18
apwxnox, though it if was fixed in cryptsetup i don't think my initrafms-tools would account for it09:18
* apw lets xnox figure out if he uploaded it or not :)09:18
xnoxpitti: so with https://launchpad.net/ubuntu/+source/plymouth/0.9.0-0ubuntu1 or better, encrypted root should work with systemd and systemd should be asking password via plymouth password ask.09:19
xnoxpitti: except it won't.09:19
xnoxpitti: cause our initramfs would ask for that....09:19
xnoxpitti: with that plymouth and a non-root encrypted fs, systemd should ask password for it via plymouth.09:19
pittiapw: so, merely installing cryptsetup does get the plymouth bits into initramfs09:19
xnoxpitti: if that's the case, that's broken =(09:20
xnoxit's not meant to.09:20
pittiwell, that's how it always has behaved, hence my question about whether that changed recenlty09:20
pittibut anyway, lightdm comes up09:20
apwyeah i am a special snow-flake here for sure, it is somehow local to me09:20
apwso i'd say not worry too heartily about it for now09:21
pittiapw: AFAIR "sudo systemctl start lightdm" still worked for you, it was just not started automatically, right?09:21
pittiapw: Im' worried because that doesn't sound initramfs-ish, much rather some locally modified sysvinit or /etc/default/ or whatever conffile09:21
LocutusOfBorg1cjwatson, debdiff attached to the bug report and uploaded on mentors09:21
cjwatsonLocutusOfBorg1: ok, will leave it to the maintainer09:22
apwpitti, it does start indeed when i incant as you say09:22
pittijamespage: in practice I do most of the uploads, but the whole concept of pm-utils quirks is a thing of the past; also, most of its bug reports shouldn't even be against it but the kernel, so bug reports are a lost cause :/09:22
Unit193https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742600 looks like it'd have problems with systemd-shim.09:23
ubottuDebian bug 742600 in cryptsetup "cryptsetup: add support for systemd to askpass" [Wishlist,Open]09:23
pittiapw: display manager startup is rather delicate, due to the various layers of configuratino that Debian piled up (enabling/disabling units, enabling/disabling syvinit files, default files, /etc/X11/default-display-manager, etc. -- lots of things that can go wrong09:23
pittiapw: so, when you have a few mins, please ping me, and we can check and compare all these09:24
xnoxUnit193: not sure why it would, and we don't use askpass by default in ubuntu. We use plymouth ask-pass, as we require plymouth on all products.09:24
apwpitti, ack will do shortly09:24
jamespagepitti, I noticed your uploads09:25
tseliotpitti: I restarted a build of ubuntu-drivers-common on amd64 and it went well. I've just restarted builds for all the remaining architectures, so there's no need for a reupload09:26
pittitseliot: right, for an FTBFS retrying the build is sufficient; thanks09:26
xnoxdoko: with this https://launchpad.net/ubuntu/+source/plymouth/0.9.0-0ubuntu1 tigervnc just builds fine, and uses shared libraries.09:27
=== inner_ugliness is now known as zmok
pittidpm: sorry, still no new export on https://translations.launchpad.net/ubuntu/utopic/+language-packs -- I figure something went wrong in LP?11:09
* pitti gazes at wgrant (yes, I know, everyone is, sorry :/)11:09
dpmwgrant, do you know if the utopic translations export was cancelled for some reason? It was scheduled to start on Tuesday, but we cannot see it in https://translations.launchpad.net/ubuntu/utopic/+language-packs yet11:11
=== MacSlow is now known as MacSlow|lunch
wgrantdpm, pitti: Let me see.11:24
wgrantI see no failures, weird.11:25
wgrantI'll check deeper logs.11:25
=== tvoss is now known as tvoss|lunch
dpmthanks wgrant11:27
wgrantAh, I lie, I had just moved it to another folder.11:30
wgrantIt failed for the normal reason.11:31
wgrantdpm: Is it particularly urgent? I can't reasonably kick one off before Monday without suspending some other fairly critical maintenance tasks.11:31
dpmwgrant, I think Monday should be fine - pitti?11:36
=== greyback is now known as greyback|away
pittidpm: sure, WFM; thanks wgrant!11:42
wgrantdpm, pitti: The failures and concurrency limitations should hopefully go away with the new DB servers, fingers crossed.11:47
wgrantSorry about this.11:47
dpmwgrant, that's good to know, thanks11:49
=== tvoss|lunch is now known as tvoss
=== _salem is now known as salem_
barrydoko: do you know what in system-image is pulling in pip?  it's not a direct Depends of si.13:02
dokobarry, see component-mismatches-proposed13:03
barrydoko: build depends13:04
xnoxbarry: is that for unit tests? can it be moved into autopackage tests? (autopackage tests have universe enabled, even for packages in main)13:05
barryxnox: not sure it's really appropriate for ap.  there's no ui and tons of dbus.  even so, it's probably a lot of work13:06
=== zmok is now known as zdoch
xnoxbarry: it saves us from having pip pulled into main. Drop build-depends -> move to debian/tests/control depends and run that the same way things are currently run.13:15
=== Pici` is now known as Pici
xnoxbarry: we do that for a lot of test suites which have dependencies beyond main, e.g. automake's full test-suite is only run as an autopackagetest.13:16
xnoxbecause it wants like all javas, haskells, fortrans and etc.13:16
barryxnox: maybe.  seems like an unfortunate systemic problem really.13:17
barryi mean, what's the point of having support for build-time tests if you can't use them? ;/13:17
barryplus, they're not exactly the same environments, so in theory it could miss problems13:18
xnoxbarry: they should be.13:19
xnoxbarry: there are years old plans to abolish main/universe splits, have single archive and declare "depends" closed set, such that one can use universe build-deps. Worst thing is like boost, where I have two identical source packages: one to build most things in main, and one to build universe build-depends portions.13:21
barryxnox: makes sense to me :)13:21
xnoxbarry: how environments are different? it's still asserted that the test-suite is run before the binaries hit release pocket & autopackage test can have smaller stray dependencies than you'd have at build-time.13:22
xnoxbarry: e.g. you can choose to not install build-essential, whereas on buildds it will always be there.13:22
=== ValicekB_ is now known as ValicekB
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
tseliotpitti: any ideas how I can support both systemd and upstart in nvidia-prime (LP: #1312255)? Are there any examples I can look at?13:32
ubottuLaunchpad bug 1312255 in nvidia-prime (Ubuntu) "[systemd] nvidia-prime package needs systemd unit or init.d script" [Undecided,Triaged] https://launchpad.net/bugs/131225513:32
barryxnox: do autopkgtests prevent internet access by default?13:32
xnoxbarry: mostly yes.13:33
xnoxbarry: you have e.g. access to archive.ubuntu.com, but for further protection exporting a bad proxy helps.13:34
barryxnox: right.  see, build-time tests (esp. with --buildsystem=pybuild) takes care of this for you automatically.  without this, it's easy to accidentally add a silent dependency that gets satisfied by pypi but not the archive.  this is just one example that comes to mind.  but i know in the past i've had issues where i tried to run the full s-i test suite in dep8 too, and got different results.  also, think about local reproduction -13:38
barrywith build-time tests, you can very accurately reproduce -- and debug! -- locally any failures.  you can do it with dep8, but it's more difficult and there's more variability (e.g. which virtualization do you use, etc.)13:38
xnoxbarry: i'm telling you for autopackage test to do ./debian/rules test13:41
xnoxbarry: and execute dh_auto_test --buildsystem=pybuild13:41
xnoxbarry: but skip that bit, if python-pip is not available.13:41
xnox(or well ./debian/rules override_dh_auto_test most likely)13:41
didrocksbarry: xnox: hey, a python2/3 question for you guys. So, I'm updating argcomplete for supporting both. There are some binary helpers that can work for both. I separated them in a different packages and have it depending on python2-argcomplete | python3-argcomplete flavors.13:43
barryxnox: i've no doubt it can be made to work, but just saying it seems like a clumsy workaround for an artificial problem.  but anyway, i'll keep pondering it.  ultimately i think you're right, we need to abolish the split, esp. for build depends13:43
didrockshowever dh_python change the interpreter /usr/bin/env python to /usr/bin/python13:43
didrocksso not really sure how I can have it working with both, so that you don't need to always install python-argcomplete13:43
=== tarpman_ is now known as tarpman
barrydidrocks: it's the right thing to do.  devs should use /u/b/e but installed scripts should always use /u/b/python{,3}13:44
xnoxdidrocks: i wish there was "#!/usr/bin/python2or3" which did the right thing =)13:44
didrocksbarry: yeah, so how do we do this? seems silly that if you install python3-argcomplete, you have to install python2-argcomplete for the helpers :)13:44
barryxnox: yeah, that's come up many times.  i've even done a little hacking on a solution to that.  it's subtly tricky!13:44
didrocksxnox: right! :)13:44
barrydidrocks: don't forget, anything with a shebang can be explicitly invoked too, e.g. $ python3 /usr/bin/mypy3shebangedfoo13:45
barry$ python3 /usr/bin/mypy2shebangedfoo13:45
didrocksbarry: well, it's an end-user tool…13:45
didrocksnot sure we'll ask them to13:45
barrydidrocks: the usual solution - not saying it's ideal - is to lay down /usr/bin/helper and /usr/bin/helper3 where almost literally the only difference is the shebang13:46
didrocksyeah, not really nice13:47
barrydidrocks: and that can be very easy if you arrange your code where most of the logic lives in the library.  and in fact, using setuptools tricks, you don't even need to write the cli script (let it be generated)13:47
didrocksthat's the way other packages are doing it?13:47
didrocksbarry: it's not my code actually13:47
barrydidrocks: yep.  e.g. gunicorn, which i've recently been adding py3 archive support for (upstream supports py3)13:48
didrocks(and yeah, I let it being generated)13:48
barryso, in the gunicorn bpkg you get /usr/bin/gunicorn and in the gunicorn3 bpkg you get /usr/bin/gunicorn313:48
didrocksbarry: ah, so, there is some magical trick in debian/rules to have a second version the python shebang?13:48
* didrocks apt-get source13:48
barrydidrocks: not in archive yet.  hang on, i'll get you the github url13:49
didrocksseems like the perfect timing then :p13:49
barrydidrocks: indeed, the only way you could have done better is if you'd pinged me last night. :)  https://github.com/warsaw/pkg-gunicorn/tree/py313:50
didrocksbarry: heh ;)13:50
* didrocks looks13:50
barrydidrocks: with a well-behaved setup.py and setuptools, the right scripts will be generated.  the trick you'll see in that package just have to shuffling the /usr/bin stuff around into the right binary package.  ping me if you have questions!13:51
didrocksbarry: so, I see that you mv the binary name… I'm unsure how this helper dh_python3 to put the correct shebang13:52
barrydidrocks: in gunicorn `$python setup.py install` - which gets run by the build system (set DH_VERBOSE=1 for details) - is the thing that generates the correct shebang.  you can also add an `override_dh_python3: dh_python3 --shebang /usr/bin/python3` rule if you need to (man dh_python3 - i might have the wrong switch name)13:53
=== masACC is now known as maswan
didrocksbarry: oh, perfect, so yeah, will do this then13:54
barrydidrocks: *gunicorn -> setuptools compatible setup.py based project13:54
didrocksthanks a lot13:54
didrocksyeah ;)13:54
barrydidrocks: yw!13:54
xnoxbarry: i have a tricky question for you =) how to run unit tests for metapackages under both python2 and python3?13:55
barryxnox: "tricky" or "trick"? :)13:55
xnoxbarry: cause for python2, i need the __init__.py with resource thing in-place and for python3 it must be removed (and the .pyc as well). And from a single tree that supports both python2 and python3 I have no idea how to do it?13:56
xnoxbarry: apart from what i do now.... "rm __init__.py*; run python3 tests; bzr revert __init__.py"13:56
xnoxbarry: and that's just pure upstream with setuptools -> no debian packaging / pybuild, nothing else....13:56
barryxnox: not sure what "the resource thing" is, but is the presence of the __init__.py the problem, or the contents of that file?13:57
barryxnox: which project is this?13:57
hallynpitti: uh, no.  lxc gets tons of git pull requests.  maybe github was having an outage?13:57
barrycontents of file are easily hacked around with a sys.version_info test guard13:57
xnoxbarry: either or i believe. Since presence of __init__.py makes it not an implicit metapackage in python3.13:57
barryxnox: ah, you mean a namespace package (in python parlance)13:58
xnoxbarry: it's lazr.* stuff. E.g. i want to run lazr.restfulclient test suite in $PWD against system lazr.uri, yet with __init__.py present locally system-wide lazr.restfulclient ends up being tested.... =(13:59
barryxnox: i think i get what you mean.  yeah, unfortunately, there's no way afaik atm to fake not having an __init__.py to get a namespace package under py3, but a quasi-ns package under py313:59
xnoxbarry: which one of the two py3s was meant to be py2?13:59
barryxnox: oops, sorry, the last one :)13:59
xnoxbarry: i was thinking doing a build, and post-build under py3 force rm init.py? or like add it in post python2?14:00
barryxnox: okay, so "tricky" :)  i can't think of anything off the top of my head.  i've run into this with my flufl.* packages, but never really dug deep to figure it out.  it's worth some experimentation though14:00
xnoxbarry: can i force skip __init__.py copy/bytecompile/install under a given python version?14:00
xnoxbarry: at the moment it looks like i should use autopackagetests =) as everything is installed globally and tested correctly ;-)14:01
barryxnox: skipping bytecomp won't help.  seems like you'd like to be able to put an exception in there to "tell" py3 to treat the __init__.py as if it doesn't exist14:01
barryxnox: yeah.  there should be a way at least to ensure you're not testing system packages.  i'd need to think more on it14:02
barryand futz around with code14:02
xnoxbarry: shall i prepare an example and throw it into ppa? or is the problem space well understood?14:03
xnoxbarry: i think i should be overriding pythonpath, excluding systempath, yet including the things i want, and use relative imports.14:04
barryxnox: i think i understand the problem, but maybe a bug report would be useful?  if so, subscribe me and i can dig into it when i have a little more time14:04
barryxnox: cheers14:04
=== timrc is now known as timrc-afk
kentbhello, I've got a couple of packages that need sponsor review:  https://bugs.launchpad.net/ubuntu/+source/ledmon/+bug/1349920 (SRU).  Supposedly a fix has been uploaded into debian for the same thing, but, I haven't seen it land yet.14:22
ubottuUbuntu bug 1349920 in The Dell-poweredge project "ledmon does not work in Ubuntu 14.04" [High,In progress]14:22
kentbother one is:  https://launchpad.net/bugs/133590714:23
ubottuUbuntu bug 1335907 in sblim-sfcb (Ubuntu) "Update to version 1.4.8 sblim-sfcc for Utopic" [Undecided,New]14:23
=== timrc-afk is now known as timrc
=== greyback|away is now known as greyback
pittihallyn: perhaps; I read the "how to contribute" section and went the git patch email mail as advertised  then15:03
pittitseliot: it needs an init.d script or systemd unit which is equivalent to the upstart job15:04
tseliotpitti: and some detection code too, so that it won't try to install the upstart job. This is the part I don't know how to handle15:05
pittitseliot: just looking at the job15:05
hallynpitti: i prefer email so good with me :)15:06
pittitseliot: so I recommend factoring out the rather complicated "script" section into /usr/share/nvidia-prime/nvidia-prime-start (or similar) shell script, and then calling that from the upstart job and systemd unit15:07
pittitseliot: oh, writing to the upstart log looks a bit odd, does that actually work?15:08
pittitseliot: if upstart has an open fd to the log at that time, wouldn't that just fail?15:08
tseliotpitti: it's always worked AFAIK15:08
pittitseliot: but this is a message which should be on the screen anyway, so echo15:08
pittithat way it'll land in the upstart log the proper way, or in systemd's journal with systemd15:08
pittitseliot: hm, where does /usr/bin/start-nvidia-persistenced come from? not from nvidia-prime apparently?15:09
tseliotpitti: start-nvidia-persistenced comes from the drivers. Maybe that's what's causing the failure: http://paste.ubuntu.com/7915250/15:11
pittitseliot: eek, what is that?15:11
tseliotpitti: unfortunately I have to delay the daemon or it will fail to start on boot15:11
pittitseliot: is that start-nvidia-persistenced?15:12
tseliotpitti: yes15:12
tseliota bit of a hack, I know15:12
pittitseliot: ok; so nvidia-prime doesn't have a dependency to ensure start-nvidia-persistenced is there15:13
pittitseliot: would't that upstart job better belong into whatever actually provides nvidia-persistenced?15:13
tseliotpitti: the drivers depend (recommend) nvidia-prime15:13
pittitseliot: and what reacts to bbswitch-ready?15:14
tseliotpitti: the drivers provide nvidia-persistenced and the script15:14
=== pete-woods1 is now known as pete-woods|lunch
tseliotpitti: the drivers have the nvidia-persistenced.conf job that starts on bbswitch-ready15:15
pittitseliot: so perhaps nvidia-prime.upstart should not be "start on starting lightdm" but actually on something like "bbswitch is ready" (for whatever that is, an uevent, or something in /sys appearing  plus sleep 10)15:15
pittitseliot: so why does http://paste.ubuntu.com/7915250/ need to be a separate script, instead of just being in the .upstart?15:16
pittitseliot: what's the actual condition that needs to be satisfied here? the bbswitch module being loaded?15:17
tseliotpitti: I wrote that last December but, IIRC there were race conditions (I don't remember exactly where atm)15:18
tseliotpitti: bbswitch, and (I think) X, and proper X driver initialisation15:19
pittitseliot: so like start on started lightdm and device-added SUBSYSTEM=graphics DEVPATH=bbswitch* (I'm making up the subsystem and the env match)15:20
pittitseliot: and this could then go directly into whatever reacts on bbswitch-ready? would that work?15:21
barrydidrocks: \o/ python-argcomplete (0.8.1-0ubuntu1) utopic; urgency=medium15:21
didrocksbarry: heh, yeah! ;)15:21
didrocksbarry: speaking of which…15:21
didrocksbarry: I see this interesting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748404 :)15:22
ubottuDebian bug 748404 in wnpp "ITP: cov-core -- plugin core for use by pytest-cov, nose-cov and nose2-cov" [Wishlist,Fixed]15:22
pittitseliot: no idea what the bbswitch module does; an udevadm info --export dump might be insightful15:22
barrydidrocks: yep!  are you using it?15:22
didrocksbarry: right! ;)15:22
didrocksin my virtualenv for now15:22
didrocksI just need to backport it to trusty in my ppa (as I need to support trusty and I want to run my nose tests on it as well)15:23
didrocksso, yeah, some hours won :)15:23
barryawesome.  yes, i have a long-lived branch to add coverage to s-i.  still having problems collecting coverage data from dbus activated subprocesses tho15:23
barrydidrocks: :)15:23
tseliotpitti: I'm not sure if that's enough but I can definitely try.15:23
didrocksbarry: I "just" have subprocess :p15:24
didrocksbarry: my docker tests are not trapped by the coverage, but I'm not asking for that much, subprocess support is already awesome :)15:24
barrydidrocks: yep, coverage should handle that although there's some inconsistent docs on the subject.  i think my problem is dbus :/15:24
didrocksyeah, I guess can be something similar than my docker issue (when I ssh to a local container)15:25
didrocksI see how hard it can be to track, even with the bindmount15:25
pittitseliot: anyway, it'll be much easier if http://paste.ubuntu.com/7915250/ isn't its own script (and not in $PATH), but part of the upstart/systemd job; but of course even better to find the actual startup condition :)15:25
tseliotpitti: yes, I think I can make it much simpler now, thanks to some recent changes in the gpu-manager15:27
pittihallyn: oh BTW, not sure how notifications work, I reviewed the new cgmanager on mentors15:34
hallynpitti: oh no.15:35
* hallyn goes to look15:35
pittihallyn: ah, so IRC ping it is :)15:37
pittihallyn: so wrt. LXC, if I pretend cgmanager isn't started on boot (which is fixed in your new version), lxc-start-ephemeral works OOTB now15:40
pittihallyn: curiously lxc-start isn't, and fails with lots of apparmor denials on changing mount points to "private"15:40
pittihallyn: so the policy fix from yesterday is incomplete; I don't really have a good idea what the essential difference is between l-s-ephemeral and l-s, I'll keep digging15:41
didrocksbarry: works perfectly on trusty, muchas gracias :)15:41
barrydidrocks: \o/15:41
hallynpitti: i'd ping sarnold or jjohansen.  maybe there is a 'rbind' or 'rslave' option you can add to the policy15:45
pittihallyn: do you know, does /etc/apparmor.d/abstractions/lxc/start-container still apply to lxc-start? or does that need to go into /etc/apparmor.d/abstractions/lxc/container-base or similar?15:46
stgraberpitti: lxc-start executes under the start-container profile, lxc-start-ephemeral (because it's a python script), doesn't15:48
hallynpitti: start-container applies during lxc-start, then switches to container-base when init is executed15:48
stgraberlxc-autostart will also skip the start-container profile for similar reasons15:48
stgrabermaybe it's something we should fix :)15:48
hallynstgraber: we *could* have lxc-start-ephemeral manually move itself into the start-container profile15:49
pittistgraber: shouldn't you be on holiday? (but thanks, of course!)15:49
stgraberhallyn: yeah, I actually wonder if symlinking the lxc-start profile to usr.bin.lxc-start-ephemeral would do the trick15:49
pittisomehow this morning I got into a situation where lxc-start worked15:49
stgraberpitti: nope, I'm back since Monday15:49
pittiafter I ran start-ephemeral, or some apparmor profile load commands, or something15:49
pittibut I don't remember any more how15:50
pittihallyn: so that apparmor fix from yesterday definitively worked for some situation, but apparently I was in that "special" one ^15:50
pittistgraber: ah, did you have a good time?15:50
stgraberjdstrand, jjohansen: hey, so can I have a profile for say usr.bin.lxc-start-ephemeral if that binary is actually a python script or would that only work if the profile was against the interpreter itself (not an option in this case)15:50
stgraberpitti: yep, was nice, got lucky with the weather too, thanks!15:51
jjohansenstgraber: you can have a profile against the script15:51
hallynstgraber: i may have to look into setting the t440s back and getting a mac :(15:52
jjohansenstgraber: however if the script is started via the interpreter eg.  bash myscript.sh, then you either need to just confine the interpreter or have the interpreter do a change_profile for the script15:52
jjohansenstgraber: basically any script that is started by binfmt_misc should work with kernel based profile attachment15:53
stgraberjjohansen: ah great, I'll send a patchset upstream then, thanks!15:54
pittismoser: btw, http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=83172c8d - thanks for pointing out, it's a good habit to get into15:57
=== psivaa is now known as psivaa-bbl
pittiapparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="/usr/bin/lxc-start" name="/" pid=4405 comm="lxc-start" flags="rw, slave"16:01
pittijjohansen, jdstrand: so I tried to allow this ^ with this: mount options=(rw, slave) -> /,16:01
pittibut that doesn't work; neither does mount options in (rw, slave) -> /,16:01
pittido you happen to have an idea what's wrong? just specifying "mount," makes it work, but that's of course way too lose16:02
pittior does that need some stracing to find out the particular mount() call it's trying to do?16:02
pittithe corresponding lxc error message is "Permission denied - Failed to make / rslave" (quite expected, but for completeness)16:03
hallynpitti: uh, so,16:04
hallynpitti: what about patching systemd to not do MS_SHARED? :)16:04
hallynit'll also break containers wrt ip netns16:05
pittihallyn: big pain point :/16:05
pittithis has been discussed a lot in the past year or so, and it's highly annoying16:05
pittirock (backwards compat with older releases) <-> hard place (break compatibility with stuff that expects shared by default)16:06
jjohansenpitti hrmm, at a first pass that seems like it should work. Its possible there is a bug around rbind and MS_REC16:06
* jjohansen will have to poke16:06
pittijjohansen: the odd thing is, this line used to work, but not on current utopic16:07
jjohansenpitti: oh! hrmmm, its possible something change in mount under us16:07
hallyn3.16 regresses in several ways :(  /proc also is mounted nobody:nogroup16:08
pittijjohansen: do you have an idea how I can relax this restriction a bit to see when it starts working? I tried "mount options=(rw, rslave) ** -> **", but that doesn't work either (not sure if that's valid)16:10
jjohansenpitti: mount options=(rw, slave),16:11
hallynpitti: 2 questions,16:11
pitti[pid  6584] mount(NULL, "/", NULL, MS_SLAVE, NULL) = -1 EACCES (Permission denied)16:11
hallyn1. are we sure that 'Type=simple' will always be the default?16:11
pitti^ strace16:11
pittihallyn: yes; but feel free to keep it in there, it really doesn't matter much; that was mostly for simplifying the file16:12
hallyn2. should i hae dh_systemd_enable at top of that block and then the --nostart at bottom?  or only one call to dh_systemd_enable16:13
pittijjohansen: "mount options=(rw, rslave)" still fails16:13
hallyni mean, --no-enable16:13
pittihallyn: in general you call dh_systemd_enable $OPTIONS; dh_installinit $OPTIONS; dh_systemd_start $OPTIONS16:13
pittihallyn: i. e. all three with the same $OPTIONS16:14
jjohansenpitti: this is current utopic kernel, and utopic userspace16:14
hallynpitti: yuck16:14
jjohansenpitti: can you open a bug16:14
pittihallyn: I hope some day this will all move into dh_installinit16:14
hallynpitti: but so if i don't want dh_systemd_start, do i just put one call to dh_systemd_enable --no-enable at the top?16:14
pittijjohansen: sure; I'll test with the trusty kernel to ensure it's an acutal regression; I just wanted to check that this syntax is supposed to work16:15
pittihallyn: yes; but I still think it's safer to call dh_systemd_enable too; that stuff syncs up with the sysv stuff etc.16:15
jjohansenpitti: it looks good to me16:15
pittijjohansen: thanks; so I'll do some kernel version bisection16:16
hallynpitti: not groking.  http://paste.ubuntu.com/7915722/ ?16:17
pittihallyn: something like http://paste.ubuntu.com/7915733/16:19
pittihallyn: sorry, with --no-enable for dh_systemd_enable16:20
hallynpitti: yuck again16:20
pittihallyn: yeah; as I said, it shuold really be in dh_installinit, but isn't yet16:20
hallynpitti: thanks.  i'll push another version in a min16:20
pittithus it's like dh_installinit_before and dh_installinit_after16:20
pittihallyn: oh, I think you can actually leave out dh_systemd_start (sorry for being confusing, I just read the docs again)16:21
pitti"dh_systemd_start is a debhelper program that is responsible for starting/stopping or restarting systemd unit files in16:21
pitti       case no corresponding sysv init script is available."16:21
pittibut cgmanager does have an init script16:22
=== sarnold is now known as Guest42067
=== sarnold_ is now known as sarnold
hallynpitti: as for the start-stop-daemon return values, that was cut-pasted from skeleton, but what you say makes sense so i'll change it16:23
pittihallyn: so: http://paste.ubuntu.com/7915761/16:23
pittihallyn: oh, really? there might be some subtle semantics I missed, but "2" generally means "already runing", and that shoudl count as success, no?16:23
hallynpitti: the comments said 1 means already rnning, 2 means error <shrug>16:25
pittihallyn: right, or that way around16:28
pittihallyn: but it looked like it would return 2 if s-s-d returned 116:28
pitti(or vice versa)16:28
=== psivaa-bbl is now known as psivaa
hallynpitti: i suppose it was racy, but it first checked with --test to see if it was already running, reutrned 1 if so;  then returned 2 on any start error16:33
hallynso long as start-stop-daemon does in fact always return 2 on error, then your way is better16:33
pittihallyn: ah, so that would have sorted out the "already running" case16:33
hallynwell, races aside16:33
hallynactually in that case ssd will return 016:34
pittihallyn: so for stop, --oknodo already deals with the "already running" case, and will then return 016:34
hallynand ssd says it exits 3 on error16:34
hallynis it ok for the init scrip tto return 3?16:34
pittiit also works for start, but not sure if it's ok to use it there, or whether you are supposed to return 116:34
pittiinit.d scripts are also a big mess16:34
hallynso you think still use $?16:35
* pitti looks at http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html16:36
* hallyn reboots to enable kvm, biam16:36
pittihallyn: so what the do_start() action returns to the "main" section of the init.d script is largely an implementation detail16:37
pittihallyn: the init.d script jsut needs to exit with 0 when it's already running/already stopped16:37
pittijjohansen: hm, so I tried the trusty kernel now (3.13.0-32) and also 3.15.0-6, and they both fail in the same way16:42
pittijjohansen: so not a regression then16:42
jjohansenpitti: okay, thanks. can you strace the command that is failing16:43
pitti[pid  8228] mount(NULL, "/", NULL, MS_SLAVE, NULL) = -1 EACCES (Permission denied)16:43
pittilxc-start: Permission denied - Failed to make / rslave16:43
pittijjohansen: yes; ^ (see above)16:44
=== pete-woods|lunch is now known as pete-woods
pittijjohansen: many similar ones, like16:44
pittimount(NULL, "/dev/pts", NULL, MS_SLAVE, NULL) = -1 EACCES16:44
pittii. e. for all mount points16:44
pitti(which is the translation of rslave, I figure)16:44
jjohansenpitti: and you tried16:45
jjohansen  mount options in (rw, rslave),16:45
pittijjohansen: I tried with =, let me try again with in and no path16:47
pittijjohansen: same error16:47
pittijjohansen: same with (rw, slave)16:47
jjohansenpitti: hrmmm, okay. I'll look into it, do we have a bug # for this yet?16:50
pittijjohansen: I'll file one now; it's a bit hard to reproduce, it requires a number of fixes to the lxc systemd scripts; but I think it can be reproduced under upstart with mounting everyhting as MS_SHARED before lxc-start, I'll look into that16:50
pitti(it's not systemd specific, just specific to the default sharing)16:51
jjohansenpitti: uhm, have you tried16:52
jjohansen  mount options in (rw, rslave, rshared),16:52
pitti  mount options in (rw, slave, rslave, shared, rshared),16:53
* jjohansen add wi to identify which flag a match is failing16:53
jjohansenpitti: okay16:53
pitti  mount -> /,16:53
pittifails as well16:53
pittithe only thing that works so far is just "mount,"16:53
jjohansenpitti: hrmmm, okay16:53
hallynpitti: new version pushed to mentors.  (no ack msg from mentors yet though)16:54
pitti  mount -> **,16:54
pittijjohansen: ooh, that works16:54
pitti  mount options in (rw, slave, rslave, shared, rshared) -> **,16:54
pittithat doesn't16:54
pittihallyn: ack; will do tomorrow morning, getting late here16:55
jjohansenpitti: is the message still info="failed flags match"?16:55
pittihallyn: thanks! (required some patience..)16:55
pittitype=1400 audit(1406825689.899:812): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="/usr/bin/lxc-start" name="/" pid=9893 comm="lxc-start" flags="rw, slave"16:55
pittijjohansen: yes16:55
pittijjohansen: ack, very easy to reproduce under upstart with "sudo mount --make-rshared /", so I'll include that in the bug report16:57
jjohansenoh nice, I like easy reproducers16:57
pittiyes, who doesn't :)16:58
hallynpitti: ok - i'm going to test here under sysvinit and systemd, then maybe beg slangasek to push it (assuming it's working)17:02
pittijjohansen: bug 1350947, I hope the reproducer is clear enough17:10
ubottubug 1350947 in linux (Ubuntu) "apparmor: no working rule to allow making a mount private" [Undecided,New] https://launchpad.net/bugs/135094717:10
pittijjohansen: at least with the start/reload/cleanup commands one can iterate/test very fast (< 1 s)17:11
jjohansenpitti: thanks17:12
pittijjohansen: I filed it against linux, might also be a bug in appamor, of course (parser or so); I'll leave that to you17:13
pittijjohansen: thanks in advance!17:14
* pitti waves good night17:18
=== roadmr is now known as roadmr_afk
popeywhere should I filed a bug in the live 14.10 environment? (the initial boot menu has a "Back..." option which seems not to be needed, and is broken)17:56
=== roadmr_afk is now known as roadmr
roadmrpopey: https://launchpad.net/ubuntu-cdimage maybe? (I'm not sure though)18:00
=== DalekSec_ is now known as DalekSec
=== ricmm_ is now known as ricmm
bdmurraydoko: could you have a look at bug 1351018?20:27
ubottubug 1351018 in gdb (Ubuntu) "issues debugging program threads on 12.04" [Undecided,New] https://launchpad.net/bugs/135101820:27
dokobdmurray, sure, probably not tomorrow, will need to fix the gcc-4.9 cross compilers21:39
dokobdmurray, I assume this is seen in utopic (7.8) too?21:55
bdmurraydoko: I haven't backported that version to precise21:56
=== salem_ is now known as _salem

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!