[05:26] <pitti> good morning
[05:26] <pitti> sarnold_: yes, the i386 retracer crashed, I restarted it yesterday
[05:34] <pitti> ERROR: Package download error, try again later: Failed to fetch http://ddebs.ubuntu.com/pool/universe/g/gnome-python-extras/python-gtkspell-dbgsym_2.25.3-13_i386.ddeb Size mismatch
[05:34]  * pitti curses ddebs.u.c.
[05:35] <pitti> sarnold_: ^ that's why it breaks, I'll have a look
[06:53] <mlankhor1t> good morning!
[07:17] <dholbach> good morning
[08:07] <SpamapS> infinity: just FYI, mysql's tools and daemons static link libmysqlclient because they use private symbols from the library. Upstream is unwilling to compromise on that.
[08:09] <SpamapS> jamespage: (just reading backscroll) regarding "raise these objections at the beginning of the cycle: sorry. I have a hard time taking vUDS seriously. I will try harder.
[08:10] <SpamapS> jamespage: had I been privvy to such discussions, I'd have -1'd at that time, because 5.6 didn't even really exist in Debian until very recently. Not LTS material at all.
[09:26] <darkxst> pitti, bug 1290270? does apt check md5 hashes on index files or just timestamps?
[09:38] <rbasak> darkxst: AIUI, that problem usually happens when there's a bad external http cache. This being a "mobile" Internet connection points to that, but it's not clear.
[09:39] <rbasak> I believe there's an existing bug that covers /var/lib/apt/lists/* needing manual cleaning when it gets a bad file and subsequent gpg verification failure on downloading a bad file though. This commonly happens on "free wifi" that serves apt-get a bad file in an attempt to redirect the user to a sign-in page.
[09:50] <ogra_> xnox, could there possibly be some hidden dependency on dbus-x11 in network-manager ? seems we have some random wlan probs in the last images (there was also an lxc change that seems to touch wlan devices but i want to be sure the dropping of dbus-x11 cant cause anything here)
[10:21] <infinity> SpamapS: You can use private symbols and dynamically link, just need a more exact versioned dep.  Which, when all the packages are produced from the same source, ain't hard.
[10:38] <pitti> darkxst: the gpg check is the correctness check
[10:38] <pitti> darkxst: making this better for little-bandwidth connections is quite a task, and it has been discussed several times already; e. g. adopting Debian's pdiff approach
[10:39] <pitti> darkxst: I think that can't be applied straightforward to Ubuntu as we have so many publisher cycles
[13:12] <mlankhorst> can't repliate barry's issue >:(
[13:20] <seb128> dholbach, something weird happened to the sponsoring queue
[13:21] <seb128> it has 19 items, it was a bit over 30 an hour ago and some of those which dropped should still be listed
[13:29] <seb128> dholbach, unping, went back to normal by itself on the next refresh
[13:32] <mlankhorst> barry: ping
[13:38] <barry> mlankhorst: hi. thanks for responding on that bug.  i am doing a dist-upgrade and can respond in more detail... or we can chat about it now :)
[13:39] <mlankhorst> I got lucky(?) once, but I really can't reproduce it
[13:39] <barry> crashes for me every time
[13:41] <barry> (of course the login hang of LP: #1289410 doesn't help)
[13:41] <mlankhorst> I've had a hang when I had apport enabled
[13:45] <pitti> mlankhorst: of the crashed app?
[13:46] <mlankhorst> no, apport, but I guess it could be the same xorg freeze bug :p
[13:59] <mlankhorst> barry: can you install xserver.*dbg xserver-xorg-video-vmware-dbgsym xserver-xorg-input-vmmouse-dbgsym xserver-xorg-input-mouse-dbgsym ?
[13:59] <mlankhorst> might need to install the ddebs repository from https://wiki.ubuntu.com/DebuggingProgramCrash
[13:59] <barry> mlankhorst: sure thing
[14:00] <mlankhorst> and gdb, should be possible to figure out what is going on then
[14:02] <barry> mlankhorst: yep.  give me a few minutes
[14:02] <mlankhorst> you can simply attach through ssh to the xorg server as root with 'gdb /usr/bin/Xorg $(pidof X)' 'handle SIGPIPE nostop' 'cont'
[14:04] <mlankhorst> and then crash the thing, should have a nice backtrace
[14:13] <barry> mlankhorst: ah, good trick with the ssh.. okay, everything's installed, let's see if i can trigger it
[14:17] <barry> mlankhorst: is this helpful? http://paste.ubuntu.com/7067823/
[14:17] <mlankhorst> assert("svga->curr.sampler[i]");
[14:17] <barry> oh how interesting.  libxatracker is in the bt.  i had a bug a while ago about libxatracker
[14:17]  * barry looks
[14:18] <mlankhorst> there is a sampler_view[i], but no sampler[i]
[14:19] <dholbach> seb128, sorry - no idea what happened
[14:20] <seb128> dholbach, no worry, launchpad glitch I guess (it was midday where they usually have their short not-available-time)
[14:20] <seb128> dholbach, down to 32 items in the queue btw ;-)
[14:21] <cjwatson> there was no fastdowntime today AFAIK
[14:22] <seb128> ok, so I don't know what was wrong in the sponsoring queue, but it autofixed itself
[14:23] <mlankhorst> I have no idea what that means here though :P
[14:23] <mlankhorst> but guessing it's a vmware bug
[14:24] <barry> mlankhorst: dang.  i can't find that libxatracker bug.  iirc, it caused the graphics to revert to llvmpipe instead of actual 3d
[14:24] <barry> but that was a while ago
[14:24] <mlankhorst> different one
[14:24] <barry> k
[14:24] <mlankhorst> bug #1271186
[14:24] <barry> yep, that's it
[14:24] <barry> mlankhorst: is there any other information i can gather for you here at the gdb prompt?
[14:25] <mlankhorst> I've pinged prf_jakob in #ubuntu-x
[14:26] <mlankhorst> barry: from a fresh vm what are the exact steps you do to hit that bug?
[14:27] <barry> mlankhorst: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-vmware/+bug/1284134/comments/13
[14:27] <barry> happens every time
[14:27] <mlankhorst> ah k
[14:27]  * barry reboots his vm
[14:30] <mlankhorst> doesn't work for me :/
[14:31] <barry> really?  wow.  okay, let me do this.  i'll create a spanking new trusty vm and see if i can reproduce it
[14:36] <xnox> popey: i'm after calendar r205+ and music r370+ to be released, as it's blocking my python2 removal work. When would those happen or is there anything i can do to make that happen sooner?
[14:37] <popey> xnox: poke balloons or sergio
[14:37] <xnox> popey: ack, thanks.
[14:37] <popey> np
[14:37] <balloons> a release you say?
[14:37] <xnox> balloons: sergiusens: can i please get calendar r205+ and music r370+ released.
[14:37] <xnox> =))))
[14:38] <balloons> I'll push up the chain ;-)
[14:39] <sergiusens> balloons, you doing it then?
[14:40] <balloons> sergiusens, yes I will
[14:40] <sergiusens> xnox, for what it's worth this can be simpler
[14:44] <sergiusens> xnox, mock isn't used when running as click as they use it to patch env to return a different home but makes no sense when confined and started with upstart
[14:47] <balloons> popey, so both are pushed but I need a test review
[14:48] <balloons> I didn't check them before pushing, so I'll be doing it now alos
[14:49] <pitti> jamespage, SpamapS: err, all the juju binaries are > 30 MB big? that smells like statically linking the whole Go runtime lib or so; can this be done dynamically somehow?
[14:49] <pitti> 128 MB installed size is quite large
[14:49] <xnox> sergiusens: the test should work as non-click on e.g. desktop. thus using python3 compatible mock.
[14:49] <xnox> sergiusens: and since it's a naked import (even when running under click) it fails with python3.
[14:49] <xnox> (global, e.g. it's not in the "desktop-only" code branch)
[14:49] <sergiusens> xnox, yeah; I'm just saying that you can forget about that for click, move to the non click code path and perhaps just dep on python3 for running in desktop/deb mode
[14:49] <sergiusens> anyways, not blocking; just a suggestion
[14:49] <xnox> sergiusens: meh, true. I'll do that when dropping python2 code-path everywhere.
[14:50] <kentb> is it too late to request an upstream version bump for a package?   I.e. update openwsman 2.4.3 to 2.4.4?
[14:50] <mitya57> kentb: it's not too late provided that that is a bugfix-only release
[14:50] <pitti> kentb: if the new upstream release only fixes bugs (likely for microrelease updates), there's no problem at all; for new features you need to file a feature freeze exception request
[14:51] <xnox> pitti: juju binaries are unstripped.
[14:51] <pitti> xnox: right, stripping gets them down to 20 MB; but that's still a lot of duplication
[14:51] <xnox> pitti: correct.
[14:51] <pitti> and it doesn't link to some kind of libgo
[14:51] <xnox> pitti: per archive policy it should be built with gccgo, however it isn't.
[14:51]  * xnox ponders if there was a bug open about it.
[14:51] <jamespage> pitti, unfortunately not
[14:51] <pitti> xnox: ah, gccgo-go [!amd64 !i386 !armhf], golang-go (>= 2:1.1.1) [amd64 i386 armhf]
[14:51] <pitti> fun
[14:51] <mlankhorst> o.O
[14:51] <arges> @pilot in
[14:51] <arges> hmm... is the bot down?
[14:52] <pitti> so it seems gcc-go works in general (as it's used for ports)
[14:53] <xnox> pitti: there is https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1267393 thus i think it's appropriate to request to use same go compiler with shared linking across all arches.
[14:54] <xnox> pitti: although as per jamespage's comments there are reasons for prefering golang-go where available.
[14:55] <pitti> thanks for pointing out
[14:55] <pitti> jamespage: i. e. golang-go does not have any shared runtime lib? (indeed I don't see any binary package like that)
[14:55] <pitti> that's ... eww
[14:56] <jamespage> pitti, yeah - feels odd i know
[14:56] <jamespage> pitti, the entire golang-go tool chain builds around static linking
[14:56] <jamespage> pitti, which is why most golang-xxx-dev packages are just a ship of source code
[14:56]  * pitti now regrets that he even asked; I just noticed the ginormous debs
[14:57] <jamespage> means that all rbd's need a rebuild every time they change
[14:57] <jamespage> dh-golang makes some effort to annotate this using Build-Using fields
[14:57] <pitti> rebuild-o-mania, archive space / download / HD space waste, and a security update nightmare, yay :)
[14:58]  * jamespage makes no further comments so he does not get himself into trouble
[14:58] <jamespage> but yeah - I know
[14:59] <jamespage> pitti, oh - and stripped go built binaries tend to explode in odd ways
[15:00]  * pitti sheds a tear for the previous implementation in Python..
[15:01] <jamespage> pitti, you're going to make me cry in a minute
[15:01] <pitti> jamespage: ok, I better STFU and forget that I even asked :)
[15:05] <cjwatson> lool,jdstrand: not to be overly are-we-there-yet but if I get reasonably prompt feedback on that click supported-frameworks branch then I might be able to squeeze it in before Qt 5.2 :-)
[15:05] <cjwatson> (yeah, I know I only just filed it)
[15:06] <pitti> jamespage: on a different note, I just installed juju-local, and "sudo juju bootstrap" fails, without much to go at: http://paste.ubuntu.com/7068091/
[15:06] <pitti> jamespage: do you have a hint how to debug what's going on?
[15:06] <pitti> jamespage: I set root-dir in .juju/environments.yaml to /home/martin-scratch/juju and created that directory
[15:07] <pitti> jamespage: sudo lxc-ls --fancy tells me that it didn't create any container
[15:08] <jamespage> pitti, --debug
[15:08] <pitti> I was following https://juju.ubuntu.com/docs/config-LXC.html
[15:09] <pitti> jamespage: http://paste.ubuntu.com/7068109/
[15:09] <jamespage> pitti, ok - drop the sudo
[15:09] <jamespage> the documentation is for the current stable release - 1.16.x
[15:09] <pitti> jamespage: hm, I didn't set up my system for lxc-create to work as user
[15:09]  * pitti cleans up ~/.juju and $JUJU_HOME
[15:09] <jamespage> pitti, 14.04 has the current dev release which drops the need to explicitly sudo
[15:10] <jamespage> kinda like py-juju used todo
[15:10] <pitti> jamespage: ah, thanks!
[15:10] <pitti> jamespage: that succeeded now
[15:10] <jamespage> pitti, excellent
[15:10] <pitti> there's a mongod running now
[15:10] <pitti> jamespage: thanks!
[15:11] <pitti> jamespage: sorry, it's been a while since I touched this last (was pyjuju and canonistack before, but with local and LXC that's so much nicer to play with)
[15:11] <jamespage> np
[15:11] <jamespage> pitti, next stable should be out this week or next (fingers crossed)
[15:11] <jamespage> the juju-core team have been sprinting on it
[15:14] <cjwatson> Laney: I'm looking at converting ubuntu-system-settings to my as-yet-unreleased interface in libclick for getting manifests.  That interface returns a JsonArray *, which of course will need to be turned into a QJsonDocument.  Would you prefer that I serialise/deserialise it via a string, or walk through the members of the JsonArray and recursively translate to QJsonFoo directly?
[15:21] <Laney> cjwatson: Sorry, DMBing --- I'd probably do the walking way as a matter of taste, but I don't mind really if that's going to be annoying.
[15:27] <cjwatson> Laney: ok, yeah, it seemed marginal enough for me that I thought I'd ask, so happy to go with your taste
[15:27] <xnox> sergiusens: balloons: barry: once calendar_app 205+ and music_app 370+ lands we can upload phablet-tools which does python 3 or 2 detection and execution without regressing any results.
[15:28] <barry> xnox: fantastic!  thanks for pushing this forward while i've been distracted on other things
[15:37] <sergiusens> xnox, did th unity8 and uitoolkit stuff get resolved already?
[15:37] <sergiusens> if so, yes
[15:40] <xnox> sergiusens: yes, it's fully landed in the archive.
[15:42] <xnox> sergiusens: that also assumes there are no other new/untested apps converted to clicks.
[15:45] <balloons> popey, it seems music tests don't pass for me, running calendar now
[15:47] <lool> cjwatson: I looked at the click changes for the framework dir changes, looked good; doing a test build now
[15:48] <Laney> stgraber: hallyn: Did you see https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1290315 ?
[15:49] <stgraber> I saw you blame me in #ubuntu-desktop, didn't see the bug report yet though
[15:49] <Laney> :-)
[15:49] <cjwatson> lool: it'll be going through CI Train, so that'll catch any build problems that I somehow missed - I mostly wanted to check that it was OK to lock us down to the base name / base version thing
[15:49] <cjwatson> or double-check I suppose
[15:49] <lool> cjwatson: I wanted to run the testsuite before approving, and since it requires generated files anyway...
[15:50] <hallyn> Laney: looking now
[15:50] <lool> cjwatson: the only thing I noted was that we're exposing functions to get the directory, which is an implementation detail that clients shouldn't poke at
[15:50] <lool> but I guess they should not use it
[15:53] <cjwatson> lool: mm, I guess I could hide that; it was by analogy with getting the hooks dir and the db dir which I'd already exposed
[15:53] <lool> yeah
[15:54] <cjwatson> lool: tried to hide it but that breaks the tests, hmm
[15:54] <lool> cjwatson: you could just name it _get_frameworks_dir
[15:54] <lool> I mean prefix with _
[15:54] <sergiusens> xnox, will silo and see
[15:54] <xnox> sergiusens: \o/
[15:54] <stgraber> Laney: so that's very weird, LXC indeed creates those symlinks but only in the container's rootfs, so unless you have a container without a rootfs (or with your machine's own / as its rootfs), that shouldn't be possible
[15:56] <cjwatson> lool: mm, I don't really want to have multiple ways to indicate ABI stability
[15:58] <cjwatson> lool: it might not be worth the effort to hide it - that directory is already a published interface in that other packages install into it
[15:58] <cjwatson> lool: so we could argue that it's theoretically useful for their build systems ;-)
[15:58]  * cjwatson handwaves
[16:00] <cjwatson> I wonder if the linker is assuming that it can non-lazily relocate anything that isn't an exported symbol
[16:01] <cjwatson> I'm not using -z now though
[16:01] <Laney> stgraber: http://paste.ubuntu.com/7068381/
[16:03] <stgraber> Laney: that's your container's fstab?
[16:03] <Laney> ya
[16:04] <stgraber> Laney: drop the devtmpfs line, that's your problem
[16:04] <Laney> did I add that?
[16:04] <stgraber> yep
[16:04] <Laney> I don't know why I would have
[16:04] <stgraber> we never had it in our templates
[16:04] <stgraber> Laney: you can also shorten all the other lines by using rootfs-relative targets
[16:04] <Laney> no leading / you mean?
[16:05] <stgraber> Laney: e.g. "/var/lib/schroot var/lib/schroot none bind 0 0"
[16:05] <Laney> neat
[16:05] <Laney> lemme try removing that then
[16:05] <ScottK> yolanda: Your clamav tests are in Debian now: http://ci.debian.net/#package/clamav
[16:05] <ScottK> (and work)
[16:08] <stgraber> Laney: devtmpfs isn't namespaced by default, so that mount was basically the equivalent of a bind-mount of /dev into your container (with the devastating effects you noticed)
[16:08] <Laney> stgraber: indeed, I figured that this would have come from the template though
[16:10] <hallyn> I'm pretty sure there was a time where templates did that, but that woudl be probably a year ago
[16:10] <hallyn> (and probably lasted like a week)
[16:10] <hallyn> timing is everything :)
[16:11] <Laney> I think I created this container in Quantal
[16:11] <stgraber> Laney: odd that you didn't notice this issue earlier, I guess you don
[16:12] <stgraber> don't use your ttys a lot :)
[16:12] <Laney> they were broken, so no :-)
[16:16] <Laney> ah
[16:16] <yolanda> hi ScottK, cool
[16:16] <yolanda> and thx
[16:16] <Laney> it looks like it was in the version of lxc released with Q
[16:16] <Laney> bad hallyn :P
[16:17] <hallyn> yeah.  i really don't like the way devtmpfs is single-instance.
[16:17] <hallyn> it's so non-linux-y
[16:17] <Laney> can this be cleaned up somehow?
[16:22] <stgraber> Laney: not easily, we have weird users who actually want to do that kind of stuff on purpose...
[16:23] <stgraber> Laney: looking in current quantal's source package, I'm not seeing any mention of devtmpfs in templates/ though
[16:23] <Laney> stgraber: it was removed in a SRU it seems
[16:23] <Laney> debian/patches/0024-* in the version in quantal-release
[16:24] <stgraber> yeah, looks like we broke it in ubnutu37 and fixed it in ubuntu38
[16:25] <stgraber> there was a 20 days window between the two...
[16:26] <Laney> oh well
[16:26] <Laney> I guess it's probably quite limited
[16:27] <hallyn> it *might* be worth spitting out a warning if we see devtmpfs.  i can't think of a legitimate use for that
[16:27] <hallyn> with lxc-execute, maybe
[16:28] <stgraber> that and people using lxc.pty = 0 and don't want to run udev in the container but still want all the new nodes to show up
[16:36] <juliank> pitti: So, is there a chance we'll see 0.9.3.2 in trusty, or will it stay at 0.9.1ubuntu1?
[16:37] <pitti> juliank: I was going to sync 0.9.3.2 as soon as it gets published in Debian and imported in LP (which will still take a few hours)
[16:37] <juliank> pitti: Great.
[16:37] <pitti> juliank: thanks for the fast fix
[16:37] <juliank> pitti: No problem, git bisect did most of the work.
[16:37] <pitti> juliank: did you un-archive the debian bug? (I guess so, last time I did that it just took ages to get processed)
[16:39] <juliank> pitti: Yes, of course. It hope it is visible on all bugs.d.o hosts now, it took some time for all to show an updated bug report.
[16:42] <Laney> DMB results are awaiting moderation to u-d-a
[16:46] <GunnarHj> Laney: Me again.
[16:46] <cjwatson> Laney: clicketyclick
[16:46] <GunnarHj> Laney: Time to follow up on https://mentors.debian.net/package/mythes-sv ?
[16:47] <Laney> cjwatson: ta
[16:47] <Laney> GunnarHj: I'll queue it up this afternoon
[16:47] <Laney> thanks
[16:47] <GunnarHj> Laney: TIA
[16:49] <Logan_> xnox, micahg, bdmurray: congrats! :D
[16:50] <mitya57> Congratulations! :)
[16:54] <xnox> Logan_: thanks.
[17:39] <SpamapS> infinity: IMO there is _zero_ point to such an exact versioned dynamic link. That feels like dogma to me. Also MySQL's engineers, for whatever reason, have never understood how to create shared libraries right.
[17:41] <SpamapS> pitti: re: juju, I have never run the go version, nor do I expect I ever will. :-P
[17:43] <infinity> SpamapS: Well, the point would be that if you already have the shared library mapped, you don't need to have a quarter of it statically mapped elsewhere.
[17:44] <infinity> SpamapS: But yes, it's also not a massively big deal, since the usual security argument doesn't apply when it ships from the same source.
[17:44] <SpamapS> infinity: you're talking about micro optimizations of /usr/bin/mysql, and /usr/bin/mysqldump
[17:44] <SpamapS> infinity: EPRIORITIES ;)
[17:44] <infinity> SpamapS: Every bit helps. :P
[17:44] <cjwatson> the samba 3 clients shipped that way for ages ... it was a problem for image size but I think not otherwise
[17:45] <infinity> SpamapS: (But yes, not something I'm passionate about, just something that would really bug me if I was still involved in MySQL maintenance)
[17:46] <SpamapS> infinity: there are 130 other things to be annoyed about  bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=mysql-5.5
[18:01] <tkamppeter> OdyX, hi
[19:09] <hallyn> rhythmbox has become a virus?  i keep killing it and it keeps starting back up
[19:11] <Meerkat> rhythmbox needs a kick in the behind. I installed it yesteryday and its first action on start was to search my entire home folder for music filer, without my consent. Then when I closed it down it kept playing the music and I had to kill the process. Reminds me of Windows apps in that way.
[19:43] <JanC> Meerkat: closing a window is not the same as closing a process... (it will keep running in the background and you can control it through the sound indicator menu--maybe there should be a better visual indication of that though)
[19:44] <Meerkat> oh, forgot to mention. There was no icon down where there's usually icons.
[19:45] <Meerkat> I just tried again and it shuts down as I expected. So that is good.
[19:50] <justCarakas> I have a question about html 5 apps: what should I use for a date picker ? an option selector ?
[19:53] <Meerkat> input type=date
[19:53] <justCarakas> ok
[19:53] <mitya57-mobile> Also, -> #ubuntu-app-devel
[19:54] <justCarakas> ive asked it there a couple of times but never got a reply
[19:56] <Meerkat> so many ubuntu channels. Hard to keep track.
[20:06] <dobey> justCarakas: this channel isn't really about app dev. i think you want #ubuntu-appdev (or something similar, iirc) for that
[20:07] <justCarakas> oki
[20:58] <bdmurray> superm1: have you seen bug 1290460?
[21:15] <arges> @pilot out
[21:43] <superm1> bdmurray: no i hadn't
[21:43] <superm1> i'll add it to the list to look at
[22:13] <saiarcot895> Would a no-change rebuild of a package go in as a Stable Release Update?
[22:18] <TheMuso`> saiarcot895: Its been done before afaicr, given a good reason to do so.
[22:28] <sarnold> what's the deal with all those "TypeError: 'NoneType' object is not callable" messages when apt-get dist-upgrading trusty VMs? Should I be filing bugs for all the ones I spot or is it a known issue that is being addressed elsewhere?
[22:28] <sarnold> (see e.g. https://bugs.launchpad.net/ubuntu/+source/newt/+bug/1282216 for one example from someone else)
[22:29] <sarnold> (perhaps part of the python 3.4 conversion?)
[22:41] <sergiusens> xnox, hey, gallery would be failing as well with the py3 setup
[23:39] <xnox> sergiusens: .click or app?
[23:39] <xnox> sergiusens: either don't introduce new clicks, or tell me which ones are ready to go for me to fix.
[23:39] <xnox> sergiusens: will take a look into gallery now.
[23:40] <xnox> sarnold: it's a python3.4 bug itself.
[23:40] <sergiusens> xnox, gallery was changed to click last week (as camera, but that didn't have issues)
[23:40] <sergiusens> xnox, it's rather simple; need to get the full path to the python module
[23:40] <xnox> sarnold: known and being worked on .
[23:40] <sergiusens> xnox, here's the full test run http://q-jenkins:8080/job/andy-smoke-daily-test/3/#showFailuresLink
[23:41] <sarnold> xnox: great :) thanks
[23:41] <xnox> sergiusens: right from __future__ absolute_imports, will make merge proposal.
[23:41] <xnox> sergiusens: somehow on my image today i didn't have them as click, or maybe i'm just blind =)
[23:41] <xnox> sergiusens: let me reflash it first.
[23:41] <sergiusens> xnox, no; different than that; the module has payload data that needs to be copied
[23:42] <sergiusens> xnox, it used relative data, that needs to be made absolute (joining the module path should fix it)
[23:42] <sergiusens> ie; http://paste.ubuntu.com/7070697/
[23:44] <xnox> sergiusens: right, yes. cause the $PWD is not /legacy-py2/, or we can just check if they run under python3
[23:44] <xnox> sergiusens: and declared the "autopilot" direcotry key to make it run under python3.
[23:45] <xnox> sergiusens: i wonder if $PWD under python2 should be /home/autopilot/legacy-py2 and /home/autopilot simply added to the pythonpath, to be moe compatible.
[23:45] <xnox> sergiusens: since python2 tests should not need any changes at all.
[23:45] <sergiusens> xnox, I say just path.join(module_name.__path__, the_rel_path)
[23:45] <xnox> sergiusens: ok, more explicit.
[23:46] <sergiusens> so gallery_app.__path__
[23:50] <xnox> sergiusens: btw, can you click http://s-jenkins.ubuntu-ci:8080/job/notes-app-ci/275/rebuild ? to get jenkins to recheck https://code.launchpad.net/~xnox/notes-app/py32/+merge/210254
[23:55] <sergiusens> xnox, ok, just did; but with those results you can imply everything is ok given you write the commit message