[01:01] doko_: no point in updating llvm-defaults to 3.5, clamav builds, mesa fails. There are also others that fail with 3.5 - creduce & beignet [01:01] i'll finish up building things tomorrow & will file bugs. [01:49] infinity: a 2.1 rc (very rc) is building in ppa:serge-hallyn/virt . based on not-yet-released debian experimental package [02:11] hallyn: Awesome, thanks. [02:12] Oh, not that that builds for ppc. But I can copy that and see what happens. [02:12] * infinity does so. [02:13] cjwatson: 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:14] hallyn: Building for all arches at https://launchpad.net/~adconrad/+archive/ubuntu/ppa/+packages if you're curious how that goes. [02:15] doko_: [02:15] Unpacking gnat-4.9 (4.9.1-1ubuntu2) over (4.9.0-1ubuntu5) ... [02:15] dpkg: error processing archive /var/cache/apt/archives/gnat-4.9_4.9.1-1ubuntu2_ppc64el.deb (--unpack): [02:15] 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-1ubuntu5 [02:15] doko_: ^ [02:17] Unit193: when I feel like it, basically [02:17] Unit193: don't bother preparing a merge request if it's just an automatic update though [02:17] Unit193: but it's 3am here and I generally like to think about the changes and make sure they're sane, so mail me? [02:18] cjwatson: 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] it can be soon, but I'll need a reminder [02:19] A random poke later on IRC good enough or do you want that email? [02:29] Unit193: as you like [02:30] Unit193: but if you want an IRC poke to be effective it'll need to be vaguely within UK working hours :) [02:30] cjwatson: Got it, will do. Thanks! === _salem is now known as salem_ [03:50] hallyn: yes, I will, but I'm still working on the systemd units to start lxc.net and call the apparmor commands [03:50] Good morning [03:52] pitti: wow, this seems early even for you :) [03:52] sarnold: yeah, can't sleep any more; darn hayfever [03:53] pitti: ugh, sorry to hear it :( [03:59] hallyn: So, it at least built on ppc64el. Testing will come later. [04:04] 19:31 < benh> hrm [04:04] 19:31 < benh> W: Failed to fetch [04:04] gzip:/var/lib/apt/lists/partial/ddebs.ubuntu.com_dists_trusty-updates_main_binary-ppc64el_Packages [04:05] Hash Sum mismatch [04:05] 19:31 < benh> been going on for a while today [04:05] pitti: ^ [04:05] pitti: Did you break something, or is that pilot error on Ben's part? [04:06] infinity: I'm sure it's a ddeb-retriever issue again :/ [04:07] although I'm not sure how [04:07] that Packages is from July 18, Release is from July 22, and it does have the wrong md5 [04:08] * pitti sends flowers to apt-ftparchive [04:10] infinity: awesome === doko_ is now known as doko [05:59] xnox, http://people.canonical.com/~doko/tigervnc_1.3.1+X1.15.0-0ubuntu1.dsc [06:21] cjwatson, barry: seeding system-image causes some component mismatches, including python-pip again, which we were trying to avoid. is this really necessary? === evfool__ is now known as evfool [06:53] good morning [06:57] hallyn: hm, did you disable github pull requests for LXC? I can't send them any more, the button is disabled [06:58] hallyn: I sub'ed to the ML now and went through the git-send-email exercise, including greylisting and all that fun *ugh* :) === salem_ is now known as _salem === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [07:28] doko: 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:45] cjwatson, ok === psivaa is now known as psivaa-brb [07:59] doko: omg! why are you touching that beast?! =) [08:06] xnox, I'm not, just looking at component mismatches [08:07] or what is the context? [08:13] doko: tigervnc =) [08:13] doko: it tries hard to statically link against a self-included copy.... =) [08:13] (embedded copy of code) [08:14] xnox, no, it is using the system one === psivaa-brb is now known as psivaa [08:23] xnox, http://paste.ubuntu.com/7912543/ using the system one [08:28] doko: i have a crude patch..... [08:29] find_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:30] http://paste.ubuntu.com/7912575/ [08:31] that gives me http://paste.ubuntu.com/7912581/ [08:32] ahh, good, will go from there [08:42] xnox: sorry, I already asked you about bug 1326327 (forward with CC'ing pkg-systemd) yesterday, but I think I didn't see your reply [08:42] bug 1326327 in debhelper (Ubuntu) "dh_installinit should generated update-rc.d remove to remove rc*.d symlinks" [Undecided,New] https://launchpad.net/bugs/1326327 [08:42] pitti: arrrr. there is nothing to apply in debian for ti. [08:42] pitti: we had an ubuntu delta to drop, which is what that bug was about. [08:43] xnox: oh, pirate speak day today? :-) [08:43] sorry which bits are missing for libpcap? [08:43] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt [08:43] xnox: ah! nice [08:43] I don't see any, but still in proposed [08:43] pitti: and it's unrelated to the other bug that i don't agree with, but affects both debian & ubuntu [08:44] LocutusOfBorg1: "Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)" [08:44] pitti: let me verify things though before closing it, that i did fix it right. [08:44] LocutusOfBorg1: In other words, patience until after Alpha2. [08:46] xnox: that patch isn't applied in current utopic FTR [08:47] pitti: 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 debian === terror_bird is now known as inner_ugliness [08:48] xnox: ah, I see it now in https://patches.ubuntu.com/d/debhelper/debhelper_9.20140613ubuntu1.patch [08:49] yeah, and debian does generate "update-rc.d cgmanager remove" at purge. [08:50] xnox: so, your patch LGTM [08:50] we need both upstart-preinst & update-rc.d removal. [08:50] hi: 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:51] k1l: 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:52] k1l: once that is published in precise-updates and people install it, more people will get upgrade notifications and etc. [08:52] xnox: will you upload, or want me to test with a cgmanager rebuild and upload? [08:53] http://changelogs.ubuntu.com/meta-release-lts still says no trusty [08:53] pitti: i think i need to reorder things, since $script is overriden by the preinst-upstart-compatibility. [08:54] k1l: that's a bit odd. [08:55] bdmurray: as per k1l above, have 12.04 -> 14.04 upgrades been enabled or are they waiting on update-manager fixes? [08:56] thanks infinity I read about the alpha, indeed, sorry I though there was a line on update_output too [08:57] LocutusOfBorg1: update_output only reports on things that haven't been filtered out by individual-package checks at the previous update_excuses stage [08:58] ok thanks, fair enough [08:59] xnox: It's in meta-release-lts-proposed ... I guessed it was waiting on the 12.04 promotion of upgrade-manager-core from -proposed [09:00] TJ-: yeah, i see that. But I have no idea what's the difference between meta-release-lts and meta-release-lts-proposed.... [09:00] cjwatson, can I take a look at debian #755327 ? I don't know how to properly fix, but I can give you a debdiff [09:00] Debian 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/755327 [09:01] LocutusOfBorg1: I already fixed that this morning [09:01] oh wonderful [09:01] :) [09:01] pitti: actually with patch from the bug, it all looks correct and sensible. [09:01] reload the bug :) [09:01] I was stuch in a gstreamer build with some spare time ;) [09:02] no NMU in delayed? [09:03] pitti: uploaded. [09:03] pitti: it is relatively harmless though, as any insserv invocation removes stale symlinks. [09:03] LocutusOfBorg1: *shrug* might do that later, no rush [09:03] anyway, they fixed upstream with a slightly different patch https://github.com/CESNET/gridsite/commit/2124d471f9fc1eed4bf5893ed2701350357c01af [09:04] LocutusOfBorg1: I'm busy this morning [09:04] LocutusOfBorg1: feel free to pass a reference to the Debian bug [09:04] ack [09:04] sure, that's fine too, just not something I felt entitled to do as a downstream [09:04] xnox: ah, good; thanks! [09:05] yes, I'll prepare a debdiff with the upstream cherry-picked commit, I'm sure the debian maintainer will be happy to apply :) [09:10] apw: do you still have bug 1329056? [09:11] lp: #1329056? [09:12] pitti, 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 off [09:12] i will try and get that downgraded [09:12] apw: hm, mup failure? [09:12] apw: oh, how would that affect lightdm? [09:13] ubottu: [09:13] apply resuscitation to ubottu === udevbot_ is now known as udevbot [09:14] #ubuntu-bots IIRC [09:14] doko: found the bug in cmake-data FindFLTK -> it does everything to consider static FLTK only. [09:15] It takes a bit to sync up, has many channels to join. ubottu that is. [09:15] Laney: oh, it just sent me a privmsg complaining about [09:15] bug 1329056 [09:15] bug 1329056 in lightdm (Ubuntu) "lightdm does not start under systemd" [Undecided,Incomplete] https://launchpad.net/bugs/1329056 [09:15] \o/ [09:16] aha [09:16] pitti, 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 description [09:16] pitti, 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 inadvertantly [09:17] jamespage: it's thematically appropriate but I don't know if we have any relevant experts [09:17] pitti, due to bugs in initramfs-tools, which xnox has fixed in the older version [09:17] apw: ah, that's easy enough to test; installin "cryptsetup" should do that, right? [09:17] apw: horum. [09:17] pitti, well no, it is meant to be bright enough to only do it if your actual root is special [09:17] pitti: well, my cryptsetup hooks are modified to not include themself, if one doesn't have encrypted root. [09:18] apw: did i actually upload that path fix, or not?! =) [09:18] apw: oh, is that new? in the past we only installed cryptsetup-bin by defualt, and cryptsetup only if you actually use encrypted root [09:18] apw: anyway, easy enough to check by the contents of the initramfs [09:18] xnox, though it if was fixed in cryptsetup i don't think my initrafms-tools would account for it [09:18] * apw lets xnox figure out if he uploaded it or not :) [09:19] pitti: 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] pitti: except it won't. [09:19] pitti: cause our initramfs would ask for that.... [09:19] pitti: with that plymouth and a non-root encrypted fs, systemd should ask password for it via plymouth. [09:19] apw: so, merely installing cryptsetup does get the plymouth bits into initramfs [09:20] pitti: if that's the case, that's broken =( [09:20] it's not meant to. [09:20] well, that's how it always has behaved, hence my question about whether that changed recenlty [09:20] but anyway, lightdm comes up [09:20] yeah i am a special snow-flake here for sure, it is somehow local to me [09:21] so i'd say not worry too heartily about it for now [09:21] apw: AFAIR "sudo systemctl start lightdm" still worked for you, it was just not started automatically, right? [09:21] apw: Im' worried because that doesn't sound initramfs-ish, much rather some locally modified sysvinit or /etc/default/ or whatever conffile [09:21] cjwatson, debdiff attached to the bug report and uploaded on mentors [09:22] LocutusOfBorg1: ok, will leave it to the maintainer [09:22] pitti, it does start indeed when i incant as you say [09:22] jamespage: 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:23] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742600 looks like it'd have problems with systemd-shim. [09:23] Debian bug 742600 in cryptsetup "cryptsetup: add support for systemd to askpass" [Wishlist,Open] [09:23] apw: 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 wrong [09:24] apw: so, when you have a few mins, please ping me, and we can check and compare all these [09:24] Unit193: 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] pitti, ack will do shortly [09:25] pitti, I noticed your uploads [09:26] pitti: 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 reupload [09:26] tseliot: right, for an FTBFS retrying the build is sufficient; thanks [09:27] doko: with this https://launchpad.net/ubuntu/+source/plymouth/0.9.0-0ubuntu1 tigervnc just builds fine, and uses shared libraries. === inner_ugliness is now known as zmok [11:09] dpm: 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:10] argh [11:11] wgrant, 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 yet === MacSlow is now known as MacSlow|lunch [11:24] dpm, pitti: Let me see. [11:25] I see no failures, weird. [11:25] I'll check deeper logs. === tvoss is now known as tvoss|lunch [11:27] thanks wgrant [11:30] Ah, I lie, I had just moved it to another folder. [11:31] It failed for the normal reason. [11:31] dpm: Is it particularly urgent? I can't reasonably kick one off before Monday without suspending some other fairly critical maintenance tasks. [11:36] wgrant, I think Monday should be fine - pitti? === greyback is now known as greyback|away [11:42] dpm: sure, WFM; thanks wgrant! [11:47] dpm, pitti: The failures and concurrency limitations should hopefully go away with the new DB servers, fingers crossed. [11:47] Sorry about this. [11:49] wgrant, that's good to know, thanks === tvoss|lunch is now known as tvoss === _salem is now known as salem_ [13:02] doko: do you know what in system-image is pulling in pip? it's not a direct Depends of si. [13:03] barry, see component-mismatches-proposed [13:04] doko: build depends [13:05] barry: is that for unit tests? can it be moved into autopackage tests? (autopackage tests have universe enabled, even for packages in main) [13:06] xnox: not sure it's really appropriate for ap. there's no ui and tons of dbus. even so, it's probably a lot of work === zmok is now known as zdoch [13:15] barry: 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. === Pici` is now known as Pici [13:16] barry: 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] because it wants like all javas, haskells, fortrans and etc. [13:17] xnox: maybe. seems like an unfortunate systemic problem really. [13:17] i mean, what's the point of having support for build-time tests if you can't use them? ;/ [13:18] plus, they're not exactly the same environments, so in theory it could miss problems [13:19] barry: they should be. [13:21] barry: 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] xnox: makes sense to me :) [13:22] barry: 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] barry: e.g. you can choose to not install build-essential, whereas on buildds it will always be there. === ValicekB_ is now known as ValicekB === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [13:32] pitti: 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] Launchpad bug 1312255 in nvidia-prime (Ubuntu) "[systemd] nvidia-prime package needs systemd unit or init.d script" [Undecided,Triaged] https://launchpad.net/bugs/1312255 [13:32] xnox: do autopkgtests prevent internet access by default? [13:33] barry: mostly yes. [13:34] barry: you have e.g. access to archive.ubuntu.com, but for further protection exporting a bad proxy helps. [13:38] xnox: 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] with 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:41] barry: i'm telling you for autopackage test to do ./debian/rules test [13:41] barry: and execute dh_auto_test --buildsystem=pybuild [13:41] barry: but skip that bit, if python-pip is not available. [13:41] (or well ./debian/rules override_dh_auto_test most likely) [13:43] barry: 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] xnox: 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 depends [13:43] however dh_python change the interpreter /usr/bin/env python to /usr/bin/python [13:43] so not really sure how I can have it working with both, so that you don't need to always install python-argcomplete === tarpman_ is now known as tarpman [13:44] didrocks: 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] didrocks: i wish there was "#!/usr/bin/python2or3" which did the right thing =) [13:44] barry: 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] xnox: 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] xnox: right! :) [13:45] didrocks: don't forget, anything with a shebang can be explicitly invoked too, e.g. $ python3 /usr/bin/mypy3shebangedfoo [13:45] er [13:45] $ python3 /usr/bin/mypy2shebangedfoo [13:45] barry: well, it's an end-user tool… [13:45] not sure we'll ask them to [13:46] didrocks: 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 shebang [13:47] yeah, not really nice [13:47] didrocks: 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] that's the way other packages are doing it? [13:47] barry: it's not my code actually [13:48] didrocks: yep. e.g. gunicorn, which i've recently been adding py3 archive support for (upstream supports py3) [13:48] (and yeah, I let it being generated) [13:48] so, in the gunicorn bpkg you get /usr/bin/gunicorn and in the gunicorn3 bpkg you get /usr/bin/gunicorn3 [13:48] barry: ah, so, there is some magical trick in debian/rules to have a second version the python shebang? [13:48] * didrocks apt-get source [13:49] didrocks: not in archive yet. hang on, i'll get you the github url [13:49] seems like the perfect timing then :p [13:50] didrocks: indeed, the only way you could have done better is if you'd pinged me last night. :) https://github.com/warsaw/pkg-gunicorn/tree/py3 [13:50] barry: heh ;) [13:50] * didrocks looks [13:51] didrocks: 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:52] barry: so, I see that you mv the binary name… I'm unsure how this helper dh_python3 to put the correct shebang [13:53] didrocks: 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) === masACC is now known as maswan [13:54] barry: oh, perfect, so yeah, will do this then [13:54] didrocks: *gunicorn -> setuptools compatible setup.py based project [13:54] thanks a lot [13:54] yeah ;) [13:54] didrocks: yw! [13:54] :) [13:55] barry: i have a tricky question for you =) how to run unit tests for metapackages under both python2 and python3? [13:55] xnox: "tricky" or "trick"? :) [13:56] barry: 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] barry: apart from what i do now.... "rm __init__.py*; run python3 tests; bzr revert __init__.py" [13:56] ew [13:56] barry: and that's just pure upstream with setuptools -> no debian packaging / pybuild, nothing else.... [13:57] xnox: 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] xnox: which project is this? [13:57] pitti: uh, no. lxc gets tons of git pull requests. maybe github was having an outage? [13:57] contents of file are easily hacked around with a sys.version_info test guard [13:57] barry: either or i believe. Since presence of __init__.py makes it not an implicit metapackage in python3. [13:58] xnox: ah, you mean a namespace package (in python parlance) [13:59] barry: 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] xnox: 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 py3 [13:59] *py2 [13:59] barry: which one of the two py3s was meant to be py2? [13:59] xnox: oops, sorry, the last one :) [14:00] barry: i was thinking doing a build, and post-build under py3 force rm init.py? or like add it in post python2? [14:00] xnox: 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 though [14:00] barry: can i force skip __init__.py copy/bytecompile/install under a given python version? [14:01] barry: at the moment it looks like i should use autopackagetests =) as everything is installed globally and tested correctly ;-) [14:01] xnox: 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 exist [14:02] xnox: yeah. there should be a way at least to ensure you're not testing system packages. i'd need to think more on it [14:02] and futz around with code [14:03] barry: shall i prepare an example and throw it into ppa? or is the problem space well understood? [14:04] barry: i think i should be overriding pythonpath, excluding systempath, yet including the things i want, and use relative imports. [14:04] xnox: 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 time [14:04] ack. [14:04] xnox: cheers === timrc is now known as timrc-afk [14:22] hello, 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] Ubuntu bug 1349920 in The Dell-poweredge project "ledmon does not work in Ubuntu 14.04" [High,In progress] [14:23] other one is: https://launchpad.net/bugs/1335907 [14:23] Ubuntu bug 1335907 in sblim-sfcb (Ubuntu) "Update to version 1.4.8 sblim-sfcc for Utopic" [Undecided,New] === timrc-afk is now known as timrc === greyback|away is now known as greyback [15:03] hallyn: perhaps; I read the "how to contribute" section and went the git patch email mail as advertised then [15:04] tseliot: it needs an init.d script or systemd unit which is equivalent to the upstart job [15:05] pitti: 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 handle [15:05] tseliot: just looking at the job [15:06] pitti: i prefer email so good with me :) [15:07] tseliot: 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 unit [15:08] tseliot: oh, writing to the upstart log looks a bit odd, does that actually work? [15:08] tseliot: if upstart has an open fd to the log at that time, wouldn't that just fail? [15:08] pitti: it's always worked AFAIK [15:08] tseliot: but this is a message which should be on the screen anyway, so echo [15:08] that way it'll land in the upstart log the proper way, or in systemd's journal with systemd [15:09] tseliot: hm, where does /usr/bin/start-nvidia-persistenced come from? not from nvidia-prime apparently? [15:11] pitti: start-nvidia-persistenced comes from the drivers. Maybe that's what's causing the failure: http://paste.ubuntu.com/7915250/ [15:11] tseliot: eek, what is that? [15:11] pitti: unfortunately I have to delay the daemon or it will fail to start on boot [15:12] tseliot: is that start-nvidia-persistenced? [15:12] pitti: yes [15:12] a bit of a hack, I know [15:13] tseliot: ok; so nvidia-prime doesn't have a dependency to ensure start-nvidia-persistenced is there [15:13] tseliot: would't that upstart job better belong into whatever actually provides nvidia-persistenced? [15:13] pitti: the drivers depend (recommend) nvidia-prime [15:14] tseliot: and what reacts to bbswitch-ready? [15:14] pitti: the drivers provide nvidia-persistenced and the script === pete-woods1 is now known as pete-woods|lunch [15:15] pitti: the drivers have the nvidia-persistenced.conf job that starts on bbswitch-ready [15:15] tseliot: 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:16] tseliot: so why does http://paste.ubuntu.com/7915250/ need to be a separate script, instead of just being in the .upstart? [15:17] tseliot: what's the actual condition that needs to be satisfied here? the bbswitch module being loaded? [15:18] pitti: I wrote that last December but, IIRC there were race conditions (I don't remember exactly where atm) [15:19] pitti: bbswitch, and (I think) X, and proper X driver initialisation [15:19] ~, [15:20] tseliot: so like start on started lightdm and device-added SUBSYSTEM=graphics DEVPATH=bbswitch* (I'm making up the subsystem and the env match) [15:21] tseliot: and this could then go directly into whatever reacts on bbswitch-ready? would that work? [15:21] didrocks: \o/ python-argcomplete (0.8.1-0ubuntu1) utopic; urgency=medium [15:21] barry: heh, yeah! ;) [15:21] barry: speaking of which… [15:22] barry: I see this interesting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748404 :) [15:22] Debian bug 748404 in wnpp "ITP: cov-core -- plugin core for use by pytest-cov, nose-cov and nose2-cov" [Wishlist,Fixed] [15:22] tseliot: no idea what the bbswitch module does; an udevadm info --export dump might be insightful [15:22] didrocks: yep! are you using it? [15:22] barry: right! ;) [15:22] in my virtualenv for now [15:23] I 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] so, yeah, some hours won :) [15:23] awesome. yes, i have a long-lived branch to add coverage to s-i. still having problems collecting coverage data from dbus activated subprocesses tho [15:23] didrocks: :) [15:23] pitti: I'm not sure if that's enough but I can definitely try. [15:24] barry: I "just" have subprocess :p [15:24] barry: my docker tests are not trapped by the coverage, but I'm not asking for that much, subprocess support is already awesome :) [15:24] didrocks: yep, coverage should handle that although there's some inconsistent docs on the subject. i think my problem is dbus :/ [15:25] yeah, I guess can be something similar than my docker issue (when I ssh to a local container) [15:25] I see how hard it can be to track, even with the bindmount [15:25] tseliot: 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:27] pitti: yes, I think I can make it much simpler now, thanks to some recent changes in the gpu-manager [15:34] hallyn: oh BTW, not sure how notifications work, I reviewed the new cgmanager on mentors [15:35] pitti: oh no. [15:35] * hallyn goes to look [15:37] hallyn: ah, so IRC ping it is :) [15:40] hallyn: so wrt. LXC, if I pretend cgmanager isn't started on boot (which is fixed in your new version), lxc-start-ephemeral works OOTB now [15:40] hallyn: curiously lxc-start isn't, and fails with lots of apparmor denials on changing mount points to "private" [15:41] hallyn: 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 digging [15:41] barry: works perfectly on trusty, muchas gracias :) [15:41] didrocks: \o/ [15:45] pitti: i'd ping sarnold or jjohansen. maybe there is a 'rbind' or 'rslave' option you can add to the policy [15:46] hallyn: 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:48] pitti: lxc-start executes under the start-container profile, lxc-start-ephemeral (because it's a python script), doesn't [15:48] pitti: start-container applies during lxc-start, then switches to container-base when init is executed [15:48] lxc-autostart will also skip the start-container profile for similar reasons [15:48] maybe it's something we should fix :) [15:49] stgraber: we *could* have lxc-start-ephemeral manually move itself into the start-container profile [15:49] stgraber: shouldn't you be on holiday? (but thanks, of course!) [15:49] hallyn: yeah, I actually wonder if symlinking the lxc-start profile to usr.bin.lxc-start-ephemeral would do the trick [15:49] somehow this morning I got into a situation where lxc-start worked [15:49] pitti: nope, I'm back since Monday [15:49] after I ran start-ephemeral, or some apparmor profile load commands, or something [15:50] but I don't remember any more how [15:50] hallyn: so that apparmor fix from yesterday definitively worked for some situation, but apparently I was in that "special" one ^ [15:50] stgraber: ah, did you have a good time? [15:50] jdstrand, 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:51] pitti: yep, was nice, got lucky with the weather too, thanks! [15:51] stgraber: you can have a profile against the script [15:52] stgraber: i may have to look into setting the t440s back and getting a mac :( [15:52] stgraber: 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 script [15:53] stgraber: basically any script that is started by binfmt_misc should work with kernel based profile attachment [15:54] jjohansen: ah great, I'll send a patchset upstream then, thanks! [15:57] smoser: btw, http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=83172c8d - thanks for pointing out, it's a good habit to get into === psivaa is now known as psivaa-bbl [15:58] cool. [16:01] apparmor="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] jjohansen, jdstrand: so I tried to allow this ^ with this: mount options=(rw, slave) -> /, [16:01] but that doesn't work; neither does mount options in (rw, slave) -> /, [16:02] do you happen to have an idea what's wrong? just specifying "mount," makes it work, but that's of course way too lose [16:02] or does that need some stracing to find out the particular mount() call it's trying to do? [16:03] the corresponding lxc error message is "Permission denied - Failed to make / rslave" (quite expected, but for completeness) [16:04] pitti: uh, so, [16:04] pitti: what about patching systemd to not do MS_SHARED? :) [16:05] it'll also break containers wrt ip netns [16:05] hallyn: big pain point :/ [16:05] this has been discussed a lot in the past year or so, and it's highly annoying [16:06] rock (backwards compat with older releases) <-> hard place (break compatibility with stuff that expects shared by default) [16:06] pitti hrmm, at a first pass that seems like it should work. Its possible there is a bug around rbind and MS_REC [16:06] * jjohansen will have to poke [16:07] jjohansen: the odd thing is, this line used to work, but not on current utopic [16:07] pitti: oh! hrmmm, its possible something change in mount under us [16:08] 3.16 regresses in several ways :( /proc also is mounted nobody:nogroup [16:10] jjohansen: 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:11] pitti: mount options=(rw, slave), [16:11] pitti: 2 questions, [16:11] [pid 6584] mount(NULL, "/", NULL, MS_SLAVE, NULL) = -1 EACCES (Permission denied) [16:11] 1. are we sure that 'Type=simple' will always be the default? [16:11] ^ strace [16:12] hallyn: yes; but feel free to keep it in there, it really doesn't matter much; that was mostly for simplifying the file [16:13] 2. should i hae dh_systemd_enable at top of that block and then the --nostart at bottom? or only one call to dh_systemd_enable [16:13] jjohansen: "mount options=(rw, rslave)" still fails [16:13] i mean, --no-enable [16:13] hallyn: in general you call dh_systemd_enable $OPTIONS; dh_installinit $OPTIONS; dh_systemd_start $OPTIONS [16:14] hallyn: i. e. all three with the same $OPTIONS [16:14] pitti: this is current utopic kernel, and utopic userspace [16:14] pitti: yuck [16:14] pitti: can you open a bug [16:14] hallyn: I hope some day this will all move into dh_installinit [16:14] pitti: 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:15] jjohansen: 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 work [16:15] hallyn: 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] pitti: it looks good to me [16:16] jjohansen: thanks; so I'll do some kernel version bisection [16:17] pitti: not groking. http://paste.ubuntu.com/7915722/ ? [16:19]