[00:02] doko: yes, already looking [00:05] Ah, I think I want sitepackages=True in tox.ini [00:30] cjwatson: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1287436 [00:30] Launchpad bug 1287436 in grub2 (Ubuntu) "grub-probe fails in the presence of snapshot logical volumes" [Undecided,New] [00:34] lamont: could you also figure out the grub-probe command being run here ("sh -x /usr/sbin/grub-mkconfig >/dev/null" should help identify it), run it with -vv added to its arguments, and attach the output? [00:43] sure [00:43] cjwatson: I already had the command, just for debugging things [00:46] cjwatson: done [00:49] ta [00:53] cjwatson, lamont, did the patch to ignore snapshot volumes get lost? [00:54] psusi: I didn't bother to see if it was a regression or something new [00:54] OTOH, I suspect that a test case could be written for this [00:55] * lamont runs dpkg --configure -a [00:56] File descriptor 3 (pipe:[754560]) leaked on vgs invocation. Parent PID 28874: /usr/sbin/grub-probe [00:57] * lamont reremoves the volume, and does it again, after kicking himself [01:00] psusi: seems unlikely as such, it was an upstream change [01:00] lamont, last time I played with lvm snapshots a few years back, cjwatson patched grub to ignore snapshot volumes since at the time, I think it was trying to find a filesystem in the snapshot volume. [01:00] unless my changelogs are misleading me, it was fixed upstream, not by me [01:00] 5944958c61a4b8aa11162d01ea61462d02db7ac4 [01:00] well, frankly, I should be able to boot from the snapshot, but maybe that's just crazy talk [01:00] ohh, I could have sworn you fixed it [01:01] lol.. yea, it *would* be nice if grub actually understood the snapshots, but.. ;) [01:03] that being said, that area of code *has* changed and no longer explicitly mentions snapshots [01:04] if you plan on playing with lvm snapshots it is probably a good idea to use a /boot partition [01:04] (outside of lvm, or at the least, one you never will snapshot ) [01:05] lvm snapshots are kina sucky though anyhow.. btrfs does it much nicer... I really need to play with that again [01:05] wtf, bisect shows fc18f6a3cb15db980e65dda9e305a1d176b14b3a which seems to be an accidental bundling of lots of things into one commit [01:06] ah, but followed by 70e75364fa8627e24bb5ed9eead391c778c4504e which was the changelog for that [01:08] I'm not even sure we're going at this from the right angle - it's quite possible that it's supposed to have snapshot support now and is just having some localised trouble [01:08] * cjwatson gives up for the night === TheLordOfTime is now known as teward === Logan_ is now known as Guest66133 === Guest66133 is now known as Logan_ [07:55] good morning [08:30] dobey, do you think you can reply to https://twitter.com/publiclz/status/440421467038027776? [09:01] ogasawara: hah, I've beat you to https://launchpad.net/~ubuntu-x-swat/+archive/t-lts-backport :D [09:27] xnox: the version of ofono in the archive has your fix? [09:29] didrocks: yes. [09:30] xnox: did you try with dialer-app AP tests as suggested? [09:31] didrocks: they did pass in emulator yesterday, awe did same independantly, that's all before the upload. [09:31] didrocks: let me try out the version from the archive in the emulator. [09:31] xnox: http://ci.ubuntu.com/smokeng/trusty/touch/mako/219:20140304:20140304/6967/dialer_app/ [09:31] seems there is still a crash on ofono_scripts_dial-number [09:31] xnox, the dial-number script still produces a traceback [09:31] didrocks: looks all good. [09:32] the test passes fine though [09:32] xnox: do you think the timeout is due to dialer-app crashing? [09:32] xnox: (we had this dialer-app crash for quite a while, but without the script issue) [09:32] didrocks: ogra_: not sure where dial-number is used, it has 120 second timeout.... it'd consider tests to fail, whichever tried to dial a number. [09:33] xnox, it was there yesterday, i pointed you to it and you said it would be transient [09:33] yeah [09:33] ogra_: i did not say it's would be transient. i said it's inconclusive, whilst we still have the other two / phonesim not strating reliably. [09:33] xnox, i think it just needs the same try/except dance seems to not influence the test [09:34] ogra_: the call/traceback in dial-number has 120 second timeout.... i can dial numbers faster than that by hand =) [09:35] didrocks: looking at the Autopilot tests, they appear to be wrong, as they don't check if dial-number succeeds: [09:35] def invoke_incoming_call(): [09:35] """Invoke an incoming call for test purpose.""" [09:35] # magic number 199 will cause a callback from 1234567; dialing 199 [09:35] # itself will fail, so quiesce the error [09:35] subprocess.call(['/usr/share/ofono/scripts/dial-number', '199'], [09:35] stdout=subprocess.PIPE, stderr=subprocess.PIPE) [09:37] xnox: can you reach upstream with those infos? [09:37] didrocks: sure, let me file a bug report. [09:38] xnox: ok, and pinging them at the same time, please :) [09:46] didrocks: ogra_: well the test is written by pitti by the looks of things. let me try to figure out how it is suppose to work =) [09:48] bug #1287628 [09:48] bug 1287628 in ofono (Ubuntu) "invoke_incoming_call() doesn't seem to work, result is not checked, yet test_incoming test passes (?!)" [Undecided,New] https://launchpad.net/bugs/1287628 [09:49] xnox, but thats for incoming [09:49] wouldnt involve dialing a number [09:50] oh [09:50] sorry ... i missed the top part :P [09:50] so it dials 199 to get a call back [09:51] and it explains why it is supposed to produce the traceback in the comment ! [09:51] heh [09:52] ogra_: a dbus method is executed to dial, and that should return something sensible back over dbus to exit the client.... =) [09:52] ogra_: are magic numbers, magic in ofono or phonesim? [09:52] well but it states that an error is expected for dialling 199 [09:54] xnox, i suspect the dial-number script simply cant properly return an error here which causes the traceback [09:55] (same apport issue as with the other scripts i guess) [10:01] ogra_: no, not the same. ofono is actually returning an error "Operation failed", yet i'm not getting same result on a desktop. [10:02] well, the same as in "with py2 approt didnt react to it" [10:02] *apport [10:02] i'm sure that issue is there forever even with py2, it was just never catched in a .crash file before [10:06] ogra_: how? it's unrelated to python at all, if dialing the number doesn't work over dbus (e.g. using d-feet and not using the python script at all) [10:06] ogra_: on desktop, it's suppose to bring up a persistent pop-up. [10:06] xnox, could it be that pitti added a new apport hook or something when he ported ? [10:06] ogra_: or at list get an incomming call listed with ./list-calls. [10:07] (during the py3 transition) [10:07] ogra_: i'm on a slow internet today, downloading both images to compare. [10:09] ogra_: things you are saying don't make sense. apport doesn't generate crashes / tracebacks, whoopsie does. And that did not change. With the other ofono, the dial-number script / dbus calls to request callback did work. It's strange that autopilot test is not catching it, but it already catches MissmatchError instead of like failing the test / marking it as skipped, thus test_incomming is not working properly at the moment. [10:09] what about this one https://github.com/martinpitt/ofono/commit/97ba8139abf0a42d8568fa1cc3ea7432cf639e03 [10:10] ogra_: what about it? do you know python at all? both syntaxes are equivalent. [10:10] xnox, the point is that there has not much changed in the scripts, before the port apport didnt produce a crash file, now it does [10:11] sure, ofono itself has changed as well =) [10:11] as you noiticed yesterday that errors must have been there before as well ... for the ofono-phonesim-autostart package they are in the startup script by design [10:11] ogra_: can you please stop guessing, and give me time to actually debug this. [10:11] i'm sure the same goes for the dial-number script [10:12] so something changed that makes apport pick the tracebacks up ... which it did not with the python2 version [10:12] (and yes, i know they are equivalent) [10:12] ogra_: did you run dial-number in python2, and it does generate traceback on the whichever image which has either reverted stack or before upgrade? [10:13] ogra_: i'm still downloading that image here. [10:13] not yet, i can doo that soon [10:13] (my maguro is dead, needs a bit of charge first, it has an old image) [10:25] * ogra_ sighs, sill ymaguro is in a reboot loop [10:28] * ogra_ re-flashes with 194 [10:38] mardy: I just got syncevolution building, but your diff doesn't make it install any extra files? [10:39] Laney: let me check... [10:41] it builds a library called provideruoa which never gets put into any package [10:41] is that all that's needed? [10:42] Laney: yes, that's it [10:42] Laney: weird that it doesn't warn of missing installed files [10:43] dh_install --fail-missing ftw [10:43] you can make it do that, but it's not the default [10:43] mardy: so, make a syncevolution-provider-uoa package? [10:43] s/,/, shall I/ [10:46] Laney: I don't know, I don't think it's needed [10:46] no? [10:52] xnox, http://paste.ubuntu.com/7032374/ [10:53] ogra_: and did you get incomming callback popup? [10:53] xnox, thats image 188 (about two weeks old, scripts are python2 ... the dialling works btw, i get a call back) [10:53] xnox, yeah, works as advertised [10:53] just spills that traceback [10:53] and i bet i know why it fails ... [10:53] * ogra_ tests something [10:54] ogra_: is the magic callback stuff in phonesim? it should return normally over dbus. [10:54] ogra_: my emulator is still running content-hub hook =) [10:54] xnox, soo [10:54] i get no traceback when running it as root [10:55] but the dialer-app test (as all AP tests) run as phablet user [10:55] xnox, yeah, it is in phonesim [10:55] mardy: there are some .service .provider and .service-type files that it wants to install into /usr/share/doc too? [10:55] wasn't dialer-app suppose to become a click-app? [10:55] i dont think so [10:55] i dialer and messaging are the two exceptions [10:55] Laney: you can ignore them [10:55] okay [10:55] *i think [10:56] xnox, ah, and the script is blocking, i have to ctrl-c out of it even as root (which produces the same traceback then) [10:57] ogra_: well, wait for 120 seconds. [10:57] oh, right [10:57] ogra_: it has a timeout. [10:57] yeah, forgot about that [10:57] but in any case the traceback was there before as i thought [10:57] just that apport didnt pick it up before [10:58] ogra_: so that crash has always been there. thus not a regression, but still bad none-the-less. [10:58] right, and bad because it shows on the testing dashboard [10:58] we shouldn't have crashes supressed. [10:58] we shouldnt have crashes :) [10:58] ogra_: right, not artificially however =) [10:59] ogra_: i don't like the idea of shipping ofono-scripts on the image by default, and allow unpriviledged users to execute them and thus spoof calls / txt messages etc. [10:59] well, so for clearing the dashboard lets upload a hack, and then leave it to pitti to fix that properly i'd say ... unless you want to go on debugging it [11:00] there are many cases wheer you need the scripts to make use of specific features [11:00] if you mess up your PIN three times we dont have a UI to enter the PUK for example ... to unlock the card again [11:00] you need the scripts [11:01] (there are other features you can only reach via the scripts) [11:01] ogra_: no, we will not suppress crashes. [11:01] once we have UIs for them we can drop the scripts [11:02] didrocks: the crash in dial-number was always there, we don't know how, but whoopsie/apport were not picking it up before. [11:02] xnox, well, do you have another solution in mind apart from rolling back two revisions ? [11:02] xnox: interesting… what makes you think that? [11:02] didrocks, see above i have just proven it [11:03] didrocks, it is on 188 as well, but does not produce a .crash file [11:03] weird… [11:03] didrocks, something wrt apport changed, all the crashes were there before [11:03] ogra_: my solution is to acknowledge and work on fixing two bugs: one why python2 dial-number is not generating crash, but python3 one does. Two: make it not-crash in ofono, when it succeeds. [11:03] it just never produces .crash files for them [11:03] *produced [11:03] ogra_: ok ;) [11:03] ogra_: Three: fix dialer-app tests to actually verify that dian-number succeeds and dial back is there. [11:04] didrocks: there are three bugs to fix however =) [11:04] didrocks, are you ok with that ? [11:04] promoting with dangling around .crash files on the dashboard ? [11:04] ogra_: this sounds legit to me as this was analyzed and it's not a real issue [11:04] didrocks, awesome [11:05] well, we don't promote until clock app is fixed anyway, so there is time for getting 1/2/3 leaded by xnox done :) [11:05] ogra_: didrocks: actually, we can fix this in the AP tests. AP tests shouldn't use the dial-number script, instead they should invoke the dbus call to org.ofono themself and thus properly catch/process dbus exception from there. [11:05] didrocks, well, not sure we can expect him to do the work of the QA team :) [11:06] didrocks, i think the fix of the test is really their responsibility [11:06] ogra_: no, but talking to them is "leading" :) [11:07] didrocks, its pittis test ... there is a bug filed, but pitti is on vac this week [11:07] ok, I think pitti won't lay that off the radar, so fine [11:07] beyond that, the unfixed test wont do harm, it still works, it has just unsafe calls to the lower layer [11:08] filed https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1287659 [11:08] Launchpad bug 1287659 in whoopsie (Ubuntu) "python2 crash traceback was not caught, yet python3 one was" [Undecided,New] [11:08] great ! [11:09] * ogra_ hugs xnox ... thanks so much for helping with that [11:11] oh, and ofono-phonesim needs autopackage tests for starting up without crashing =) [11:12] bug #1287660 [11:12] bug 1287660 in ofono-phonesim (Ubuntu) "Needs autopackage test for phonesim-autostart" [Undecided,New] https://launchpad.net/bugs/1287660 [11:18] xnox: that's probably better filed against apport [11:18] remember that whoopsie is just the shovel for daisy.ubuntu.com [11:18] by the time the report hits whoopsie, it's already complete [11:19] ev: ah ok, i it's all apportwhoopsiedaisyerrors to me =) [11:23] xnox: we could use a nice diagram, yeah [11:26] ev: in dot, with LaTeX labels, rendered on the fly, by moinmoin wiki page. [11:27] *nobody will ever edit it again* [11:27] xnox: woefully out of date, but https://wiki.ubuntu.com/ErrorTracker/ServerArchitecture [11:28] xnox: also https://wiki.ubuntu.com/ErrorTracker#Anatomy_of_a_crash.2C_in_detail [11:30] ev: kernel generates python3 traceback report file? [11:30] only if you use the python kernel [11:30] :P [11:31] ev: re:diagram in russian there is a great expression:"I am starring at it, like a goat at a billboard" (as in, it's pretty, but little is comprehended) [11:32] lol [11:33] yeah, I showed that to lifeless ages ago and he very politely suggested that I try a sequence diagram. Never managed to find time for it though [11:35] ev: do python crashes require python-problem-report to be installed? [11:37] xnox: very much so, yes [11:37] all crashes require it [11:38] ev: there is also python3-problem-report, i guess either is sufficient (well should match the apport one is running) [11:39] xnox, hmm, well, only the python3 one is installed on the images ... [11:40] xnox: there's an easy way of testing you have what you need [11:40] let me install the py2 version of it and lets see if i get a crash file [11:40] bash &; kill -SEGV $? === MacSlow is now known as MacSlow|lunch [11:42] ev: well, we get crashes for binaries crashing. we are not getting them for simple python scripts that raise dbus exceptions and not crashing the interpreter itself (python2 one, we get .crash file for python3) [11:42] ev: ogra_: or we can just move to python3 asap where it's still used =) [11:43] xnox: anything of value in /var/log/apport.log? [11:44] ev: emulator crashed... rebooting. [11:45] ev, nope, not for me [11:45] at least nothing related to calling the script that produces the traceback [11:45] also installing python-problem-report didnt create any .crash file [11:45] it's python - I'd start instrumenting it and seeing where it's failing to produce the crash file [11:46] well, to be honest i dont really care as long as we get them now :) [11:46] thats mostly a matter of curiosity why we didnt get them with py2 [11:48] * ogra_ is mostly with xnox here ... lets just move to py3 everywhere :) [11:50] ev: the apport's test-suite doesn't help, it relies on the python3 crasher under test to install/raise apport hook, but new apport only allows python3 hooks and we want a python2 crasher =/ [11:51] xnox: I'm sure pitti would appreciate patches [12:32] cjwatson, how would you expect invoke-rc.d to behave for an upstart configuration that does exist but on a system where upstart is not the init system i.e. Debian? [12:32] i was expecting a 100 - but a 102 get thrown [12:32] xnox, I guess you might have an opinion on this as well [12:35] 102 feels like a bug [12:35] probably best to sh -x it [12:46] cjwatson, OK _ I'll poke [12:51] jamespage: per debian policy, an init.d script and/or systemd unit should be provided. [12:52] (e.g. systemd unit should be sufficient for a linux-any package) [12:56] .. [12:56] how does one do conflicts resolution, between multiple branches that are to be part of one silo? === MacSlow|lunch is now known as MacSlow [12:58] xnox, we it is [12:58] but the upstart configurations have different features [12:58] 'ceph' is provided for init.d script [12:58] we/well [12:59] jamespage: oh, if there is equavalent initd script (but under different name) [12:59] Where does policy talk about systemd? [12:59] jamespage: one needs to generate dummy / empty - either upstart or initd scripts, to get back to one-to-one mapping. [12:59] jamespage: i believe slangasek address that in the debian compatible upstart scripts wikipage. [12:59] xnox, well its not 100% equivalent as init.d scripts can't really be event driven [13:00] mardy: ppa:laney/arm - try syncevoluion & syncevolution-provider-uoa please [13:00] xnox, ceph under upstart works in quite a different way to ceph under init.d script [13:01] happyaron: what happened to the ibus-pinyin-db-android binary package? it's no longer built by the ibus-pinyin source, but the changelog doesn't mention that at all, so it's not clear what to do with reverse-dependencies [13:01] jamespage: right, but either gets you something like a cephd daemon running, albeit different. see https://wiki.ubuntu.com/UpstartCompatibleInitScripts and https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037150.html [13:01] jamespage: we had same thing with e.g. mountall upstart job and mountall.sh, both are very different, but only one should run under each system. [13:01] jamespage: and the right one. [13:02] xnox, indeed - for ceph you can't really configure your system to run both ways [13:02] xnox, you either do it old style (using /etc/ceph/ceph.conf) or you use all of the new-style tooling to create per daemon configs [13:03] so infact on Ubuntu and Debian, its really a choice [13:03] jamespage: thus the missing init.d scripts should be no-op. either not present at all, or do nothing. depends on the situation. Or like exec the normal-initd one instead. [13:03] hmm [13:03] jamespage: where is the packaging for it? can i take a look? === Sweetsha1k is now known as Sweetshark [13:03] xnox, http://anonscm.debian.org/gitweb/?p=pkg-ceph/ceph.git [13:04] xnox, well right now its " either not present at all" [13:20] Laney: thanks a lot, I will let Renato testing it (he's working with Contacts, and he requested this new version) [13:52] cjwatson: looking at content-hub hook, it declares "Pattern: ${home}/.local/share/content-hub/${id}" yet none of the apps ship that, yet the hook is triggered. Also is it triggered ones per each click (manual or pre-installed) or once against all of them? [13:52] (it does a run against all it can find by default) [13:55] xnox: Pattern declares the symlink to create, not the expected target [13:56] * xnox goes to read the docs again. [13:57] xnox: assuming you mean on boot under "click hook ...", the Exec line is run once at the end of syncing up symlinks, and is expected to catch up with everything [13:57] correct, right. [13:58] (it quite deliberately doesn't e.g. get parameters telling it which package to run on, to encourage good hook design) [14:10] cjwatson: good, so click side things are all good. [14:17] xnox: but of course! ;-) [14:36] dholbach: i'd rather not. my only answer is "no" but i don't know if anyone was bringing a fork back or anything. the "official" plug-in is not coming back though [14:37] dobey, ok... I just wasn't sure if this was answered anywhere else and I could point to some discussion [14:57] ev: :) [15:41] Hello, where does lightdm put logs of the user session ? [15:43] AnAnt, nowhere, log of the user sessions are not from lightdm and they are in the user directory [15:44] seb128: well, I am trying to debug a problem with GNOME shell extensions on trusty [15:44] seb128: the logs used to be in ~/.xsession-errors [15:44] try ~/.cache/upstart [15:45] seb128: I ask the guys on GNOME, they say that it is handled by systemd's journal, and I should use journalctl, but there isn't a journalctl command on trusty [15:45] seb128: thanks [15:48] seb128: thanks it is in ~/.cache/upstart/gnome-session-gnome.log [16:29] could someone offer some advice on the MISSING symbols on this log https://launchpadlibrarian.net/165726560/buildlog_ubuntu-trusty-amd64.kdepimlibs_4%3A4.12.2-0ubuntu2_UPLOADING.txt.gz [16:29] because the symbols are for the ctor and dtor for a struct [16:29] KMime::Types::AddrSpec::AddrSpec() and KMime::Types::AddrSpec::~AddrSpec() is what c++filt gives me [16:30] should I drop them without a ABI bump considering they should have never been exposed ? [16:30] since it's not really public API? [17:00] ogra_: in the "Self service CI (CI train)" line 42, one branch was renamed, it's now called lp:~ubuntu-core-dev/ubuntu-ui-toolkit/py32ap [17:00] ogra_: previously it was owned by ~xnox. [17:01] ogra_: can you fix it? [17:02] xnox, are you sure ? i guess bzoltan changed it [17:02] i actually see ~xnox ... you mean i need to point to the url above [17:03] ogra_: no, i renamed my branch. it used to be owned by ~xnox, that is now 404, it should be https://code.launchpad.net/~ubuntu-core-dev/ubuntu-ui-toolkit/py32ap [17:03] now. [17:03] xnox, right, fixed [17:04] ogra_: and reset comment for it then. [17:04] ogra_: comment says "third URL is a 404, needs to be fixed before silo can be assigned" [17:04] done [17:04] ogra_: danke schon. [17:05] :D === robru is now known as robru-sick === elleuca is now known as Guest71754 === bfiller is now known as bfiller_afk === WebbyIT is now known as rpadovani [19:59] anyone know... in a cloud-image i am not seeing a 'boot.log' [20:00] /var/log/boot.log [20:00] but i do see that in a d-i based install that i did of trusty. [20:01] anyone know what would cause that ? [20:13] smoser: ah, plymouth :P [20:14] well, yeah, i knew it was my old friend plymouth that did that. [20:14] smoser: you're currently not running plymouth in the cloud-image, right? [20:14] and i'm at this point accustomed to he and I not getting along well. [20:14] we currently are running it. [20:14] ah [20:15] not sure then [20:16] its this: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1160079 [20:16] Launchpad bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Undecided,Invalid] [20:17] oh; why is that marked invalid? [20:17] it expired [20:18] no, utlemming marked it invalid [20:19] slangesk: I have no idea why I did that... [20:19] k :) [20:20] slangasek, how do i enable apport ? === bfiller_afk is now known as bfiller [20:21] smoser: what does /etc/default/apport contain for you? (Which version of apport is this?) [20:21] smoser: oh, the other problem is that /etc/init/apport.conf is 'start on runlevel [2345]', which is late to catch a plymouth crash at boot :P [20:22] + dpkg-query --show apport [20:22] apport 2.13.2-0ubuntu5 [20:22] + grep --color=auto -v '^#' /etc/default/apport [20:22] enabled=1 [20:22] yeah. [20:22] smoser: so I think you're probably going to need to grab a core file from plymouth directly by manipulating /etc/init/plymouth.conf to set up the core handler in pre-start [20:23] thats fine by me. thoguhts on how ? [20:25] smoser: it might just be as simple as replacing the 'exec' line of /etc/init/plymouth.conf with this: http://paste.ubuntu.com/7034935/ [20:25] and that will just (we think) dump core.$PID into / ? [20:25] yeah [20:26] well, depending of the content of /proc/sys/kernel/core_pattern [20:26] which you can tweak to name it differently, or you can leave it as-is and just find the core wherever it's dropped :) [20:29] slangasek, can i maybe just: [20:30] exec /bin/sh -c 'exec "$@"' -- /sbin/plymouthd --mode=boot --attach-to-session [20:30] or will that confuse upstarts's process tracking [20:30] well, you've confused me [20:30] what are you hoping to accomplish? [20:31] you need the explicit call to 'ulimit -c unlimited', because by default we don't drop cores [20:31] right. i forgot that part :) [21:09] hm whats the best way to bisect glibc [21:10] do I need to remove the build folder each time or will incremental build work? [21:16] nice, seems to work [21:17] still seems it would profit from non recursive make :7 [21:54] are we finally going to get a new icon set for 14.04? [21:55] hallyn: hey. if I wanted to patch vm-builder in precise to have 'trusty' as a proper series. where do I fix this? in the bzr, as a patch, ? [21:57] arges: for the current series I use lp:vmbuilder and lp:~vmbuilder-dev/vmbuilder/packaging. for precise just just do a debdiff against the precise package i guess. [21:58] hallyn: ok i'll do that. [21:58] arges: since it doesn't look liek vmbuilder will be out of the archive in time for trusty, I'm looking forward (haha) to spending somet time getting refamiliarized with it [21:58] I'll shun uvtool and embrace vmbuilder :) [21:58] hallyn: yea i started using it recently, and it works out pretty nicely. i was using virt-install+preseed files before [21:59] downloading cloud iamges is generally nicer, and i *had* hoped to dump vmbuilder, but it is what it is :) [22:00] arges: shout if/when you open a bug and want the debdiff SRU'd into archive [22:03] cool [22:05] barry: hey, so I've got an issue with a test suite using the system python modules if they are installed even if I use PYTHONPATH. Eg: [22:05] PYTHONPATH=./ python3 [22:06] import apparmor.click [22:06] ^ that will use /usr/lib/python3/dist-packages/apparmor/click.py if it is installed [22:06] wild guess, try an absolute path [22:06] if I uninstall python3-click-apparmor, then import apparmor.click works fine [22:07] jdstrand: try PYTHONPATH=./ python3 -E [22:07] er, no [22:07] sorry, misunderstood you [22:08] printing out sys.path seems to show that ./ is first [22:08] jdstrand: although it is verbose, you can use -v to see all the import attempts [22:10] barry: I'll try -v now, but this paste shows it is first: http://paste.ubuntu.com/7035400/ [22:10] and if I remove what is in /usr/lib/python3/dist-packages/, it will find it [22:10] * jdstrand is puzzled [22:11] did you try $PWD? [22:11] I did [22:11] :( [22:12] is it a binary extension? [22:12] no [22:13] well, actually, I do use a ctype [22:14] this is with -v: http://paste.ubuntu.com/7035419/ [22:15] so it finds /home/jamie/bzr-pulls/click-apparmor/apparmor/__init__.py [22:15] jdstrand: the first entry, i.e. '' is interpreted as current working directory [22:15] but down below, it uses /usr/lib/python3/dist-packages/apparmor/click.py [22:16] so I don't even need PYTHONPATH [22:16] which is what I had thought [22:17] not if you're in a directory that contains the package or module you want to import === bfiller is now known as bfiller_afk [22:18] barry: can you rephrase? eg, if I am in the toplevel source tree, apparmor/click.py and apparmor/__init__.py exists [22:19] barry: and that is where I am doing 'python3' following by 'import apparmor.click', yet the system apparmor.click is being used [22:19] I feel like this worked before [22:19] jdstrand: can i reproduce your environment? [22:19] barry: sure: bzr branch lp:click-apparmor [22:20] barry: sudo apt-get install python3-apparmor-click [22:20] barry: how I am testing is that towards the top of apparmor/click.py, I added: print("HERE") [22:21] barry: then I just do: cd ./click-apparmor ; python3 [22:21] barry: import apparmor.click [22:22] hmm, I have an 'import apparmor' at the top [22:22] jdstrand: try `python3 -S` :) [22:24] * jdstrand scratches head [22:24] I don't even know what that is [22:25] jdstrand: i don't remember exactly how atm, but i think our site.py is hacked to install apparmor from the system path, even before you get an interpreter prompt (or import your own code). -S disables loading site.py [22:27] huh [22:27] * jdstrand wonders why we do that [22:28] jdstrand: i would have to dig in a little deeper to see how it's done, but don't have the time atm. as to motivation, i guess you'll have to ask the apparmor devs. my guess is so that it's embedded at the lowest level so it can't be subverted [22:29] * jdstrand is an apparmor dev [22:29] barry: ok, thanks, I'll look into it [22:29] jdstrand: i guess you should ask jdstrand then! [22:29] :) [22:33] barry: fwiw, we don't seem to do anything special with apparmor in site.py [22:34] jdstrand: hmm. there has to be some effect, since -S makes it work [22:34] yeah. I'll keep poking at it [22:36] hmm. apparmor-easyprof installs files into /usr/lib/python3/dist-packages/apparmor/, and so does python3-apparmor-click [22:36] but apparmor-easyprof's __init__.py is what's in /usr/lib/python3/dist-packages/apparmor/ [22:37] I bet there is a weird interaction that [22:37] there* [22:38] arges: I pushed the vmbuilder fix to trusty. shout if you want me to push the precise one as well [22:38] hallyn: ah you beat me to it [22:38] arges: sorry [22:39] hallyn: bug 1287943, its not in any of the other stable releases [22:39] bug 1287943 in vm-builder (Ubuntu) "vm-builder needs trusty suite" [High,In progress] https://launchpad.net/bugs/1287943 [22:39] hallyn: precise probably the more important on [22:39] one [22:39] arges: on it [22:40] hallyn: cool thanks! [22:41] barry: interesting, if I zero out apparmor/__init__.py, then it works [22:42]