[00:00] <doko> any reason for the differences?
[00:01] <xnox> doko: you should compare with http://people.canonical.com/~ubuntu-archive/transitions/html/html/python3.3-4.html on ubuntu side i think.
[00:02] <doko> xnox, why two sets of pages?
[00:02] <xnox> doko: because you asked me for the second one =)
[00:02] <xnox> doko: we appear to be diverged on the syntax with debian... do you want one that matches theirs?
[00:02] <doko> no
[00:03] <doko> just wanted to understand why the first ubuntu url was showing things that seemed odd
[00:13] <tkamppeter> doko, no, I was completely into mobile printing, see https://blueprints.launchpad.net/ubuntu/+spec/client-1305-printing-stack-with-mobile-in-mind. I did not try to test s-c-p on Python3.
[00:14] <tkamppeter> pitti, how far has the GNOME tool advanced? Is it ready for replacing s-c-p's GUI? Or should such stuff inm general be better done post-LTS?
[00:15] <pitti> tkamppeter: I don't know, I'm afraid
[04:00] <hyperair> has anyone successfully remapped keys using the new /etc/udev/hwdb.d stuff before?
[04:01]  * hyperair is trying to swap alt and meta on apple keyboards
[07:19] <infinity> TheMuso: The new speech-dispatcher seems to be pulling $world into main.
[07:20] <infinity> TheMuso: festival-* deps look to be the culprit.
[07:30] <dholbach> good morning
[07:31] <infinity> TheMuso: Oh, that's just because the -dbg package now depends on speech-dispatcher-festival ... We can probably just drop the -dbg out of main to solve that.
[07:32] <infinity> TheMuso: (Will do that now)
[07:40] <rbasak> cjwatson: (re: php-json) I see it. Thank you! For next time, apart from some foresight and advance warning, is there anything else I could have done to cause less pain? I understand that an archive admin was needed to unstick it; is there anything I could have done to not get it stuck in the first place?
[08:18] <tvoss> infinity, around?
[08:18] <infinity> tvoss: Vaguely.  What's up?
[08:49] <Saviq> pitti, hey, Q: so there's a bunch of ddebs in http://ddebs.ubuntu.com/pool/universe/u/unity8/ from PPAs, which are not indexed in http://ddebs.ubuntu.com/dists/trusty/universe/binary-armhf/Packages - does apport-retrace deal with that somehow?
[08:52] <zyga> hey everyone
[09:18] <tvoss> pitti, around?
[09:28] <cjwatson> rbasak: It's sometimes possible to bootstrap this kind of thing in a devirt PPA with multiple uploads, and then copy the result in.  It's not always worth it though.
[09:30] <rbasak> OK, thanks.
[09:44] <tseliot> didrocks: hi, can you accept jockey into precise-updates please? (bug #1279229)
[09:45] <didrocks> tseliot: I'm not part of the SRU team
[09:45] <tseliot> didrocks: oh, sorry
[10:00] <brendand> what's the difference between X-GNOME-Gettext-Domain and X-Ubuntu-Gettext-Domain in .desktop files?
[10:00] <brendand> should i use one (which one) or both?
[10:02] <brendand> dpm ^
[10:02] <seb128> brendand, we support both
[10:08] <brendand> seb128, but i guess gnome doesn't support X-Ubuntu-, so is X-GNOME- 'better' so to speak?
[10:08] <infinity> brendand: Depends on if you plan to upstream it, but yes, probably.
[10:08] <seb128> brendand, right, we added the X-Ubuntu one before, then got support accepted by GNOME iirc
[10:09] <seb128> so yeah, use X-GNOME
[10:34]  * cjwatson uses http://www.chiark.greenend.org.uk/~sgtatham/mp/ in production code
[10:34] <cjwatson> Or at least a small amount of it :-)
[11:49] <smoser> pitti, have you verified cloud image fixed?
[11:54] <bluesabre> I know it's crunch time around here, but could somebody please review https://bugs.launchpad.net/light-locker-settings/+bug/1281536 ?
[11:54] <bluesabre> ochosi ^
[11:55] <bluesabre> Seeking sponsorship for the above package, which will ship in xubuntu 14.04 assuming it can make it to the archive prior to FF
[11:57] <ochosi> yup, +1 on that ^
[11:57] <ochosi> would be great to get it in
[12:10] <hakermania> What is the process of uploading a new version of an app into the repos?
[12:20] <shadeslayer> tseliot: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1282059
[12:41] <doko> jtaylor, did you start looking at https://github.com/PyTables/PyTables/pull/311/commits ?
[12:52] <tseliot> shadeslayer: you might want to ask pitti about that
[13:03] <shadeslayer> pitti: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1282059
[13:03] <doko> https://launchpadlibrarian.net/166754677/buildlog_ubuntu-trusty-amd64.libpeas_1.8.1-2ubuntu2_FAILEDTOBUILD.txt.gz
[13:03] <doko> DEB_MAKE_CHECK_TARGET unset, not running checks
[13:03] <doko> HOME=/build/buildd/libpeas-1.8.1 xvfb-run /usr/bin/make check
[13:03] <doko> xvfb-run: error: Xvfb failed to start
[13:03] <doko> make: *** [build/libpeas-1.0-0] Error 1
[13:04] <doko> mlankhorst, ^^^ any known issues with xvfb?
[13:04] <mlankhorst> doko: yeah it tends to die when building xorg-server
[13:04] <mlankhorst> for no good reason
[13:05] <doko> so give back until the build succeeds?
[13:06] <mlankhorst> erm say again?
[13:25] <doko> dholbach, the synced nmap ftbfs on arm64 again
[13:28] <caribou> I need to tell the duplicity package in Trusty that it breaks deja-dup versions prior to trusty
[13:28] <caribou> deja-dup in Saucy is 27.3.1-0ubuntu1 and I added a "Breaks: (<= 27.3.1 ) in duplicity's control file but it doesn't seem to work
[13:29] <caribou> am I missing something ? (I guess I do)
[13:32] <cjwatson> You need a package name there, not just a version
[13:32] <cjwatson> And I suspect << is more appropriate than <=
[13:32] <cjwatson> So Breaks: deja-dup (<< 27.3.1)
[13:33] <cjwatson> Actually, that's not right either
[13:33] <cjwatson> I see you want to break the version in saucy, and 27.3.1 is less than 27.3.1-0ubuntu1
[13:34] <cjwatson> I suggest you find out exactly which version broke, at a finer grain than "prior to trusty" - that is, find out exactly which deja-dup version you need
[13:34] <caribou> cjwatson: I know, that's the first thing I tested
[13:35] <caribou> then anything before and including 27.3.1-0ubuntu1
[13:35] <caribou> cjwatson: ^^
[13:35] <cjwatson> That's not logically correct
[13:35] <cjwatson> At some point, deja-dup acquired the fix you need
[13:35] <cjwatson> It wasn't in anything infinitesimally after 27.3.1-0ubuntu1
[13:35] <cjwatson> It's quite possible that somebody has a 27.3.1-0ubuntu1ppa1 in some PPA, for instance, and you would want to break that too
[13:36] <cjwatson> This is why you need to know the version where the change you need was introduced
[13:36] <cjwatson> Am I making sense here?
[13:36] <caribou> cjwatson: the fix is in deja-dup 29.5-0ubuntu2 (version in trusty)
[13:36] <cjwatson> Was it introduced in exactly that version?
[13:36] <cjwatson> The rm-full-path thing?
[13:37] <cjwatson> That doesn't look right, that claims to be the fix for a DEP-8 test ...
[13:37] <caribou> cjwatson: yes; and I need to backport it to saucy & precise
[13:37] <caribou> cjwatson: the DEP-8 was in the same commit afaik
[13:37] <cjwatson> And the DEP-8 test wasn't even in precise
[13:38] <cjwatson> Could you give more detail?  Which upstream commit are we talking about?
[13:38] <caribou> cjwatson: the revision history is a bit tedious upstream (3 commits to solve the problem)
[13:38] <cjwatson> I'm hoping you'll tell me what the problem is :)
[13:39] <cjwatson> Because it doesn't make sense to me that we'd need Breaks for just a test failure - so it must be something else
[13:39] <caribou> cjwatson: 1527, 1528 and 1529 upstream
[13:39] <caribou> cjwatson: duplicity in trusty introduces a locking mechanism based on a locfile in the cache directory
[13:40] <caribou> cjwatson: deja-dup may not handle the lockfile properly prior to the version in trusty (those 3 commits do remove the lockfile)
[13:41] <cjwatson> OK, this makes more sense.  From duplicity's point of view, it just needs 29.5
[13:41] <caribou> cjwatson: it is a remote possibility (like if the user does kill -9 on deja-dup) but it may happen
[13:41] <cjwatson> (-0ubuntu2 was further cleanup, but doesn't have compatibility relevance here)
[13:41] <cjwatson> So I would advise Breaks: deja-dup (<< 29.5)
[13:42] <caribou> cjwatson: ok, make sense; now how do I handle the backport of that 'evolution' to Saucy and Precise ?
[13:42] <cjwatson> In the backports, you will need different Breaks versioning
[13:42] <cjwatson> Breaks: deja-dup (<< first-backported-version-containing-the-fix)
[13:43] <caribou> cjwatson: ah, ok I get it. But does the version needs to include the 0ubuntu{something} suffix ?
[13:43] <cjwatson> (Assuming you aren't going to backport the entire new upstream)
[13:43] <caribou> cjwatson: no, just that small fix
[13:43] <cjwatson> For the backport, yes.  For trusty, no
[13:44] <caribou> cjwatson: ok, makes total sense to me. I'll worry about trusty for now as I want it in before the freeze
[13:44] <caribou> cjwatson: thanks a lot
[13:44] <cjwatson> (Generally, things work better if you keep the specification minimal, so just the upstream version if you can; but that won't work for the backport)
[13:44] <cjwatson> np
[13:45] <cjwatson> Going back to the original example you gave, it *is* important to understand that <= 27.3.1 does not match 27.3.1-something
[13:46] <cjwatson> You can use dpkg --compare-versions to check:
[13:46] <cjwatson> $ if dpkg --compare-versions 27.3.1-0ubuntu1 le 27.3.1; then echo yes; else echo no; fi
[13:46] <cjwatson> no
[13:49] <caribou> cjwatson: hmm great test; I'll write it down somewhere
[14:40] <dholbach> seb128, does the existence of https://launchpad.net/ubuntu/+source/unity8-desktop-session mean that the package was uploaded already?
[14:40] <seb128> dholbach, uploaded to a ppa yes
[14:40] <dholbach> ah ok
[14:41] <dholbach> doko, I followed up on the sync request - thanks
[14:42] <doko> dholbach, fix uploaded
[14:42] <dholbach> doko, yep, I pointed that out on the bug - thanks a lot
[14:42] <xnox> dholbach: or e.g. a branch is pushed =) like i now did -> lp:~xnox/ubuntu/trusty/dholbach/rules resulted in https://launchpad.net/ubuntu/+source/dholbach
[14:43] <dholbach> xnox, so people can start filing bugs on 'dholbach' - great
[14:44] <Laney> heh
[14:45] <xnox> dholbach: [needspackaging]
[14:45] <xnox> =)
[14:46] <xnox> dholbach: actually that's very good for needs packaging bugs. push an empty branch to create package, then copy ITP from debian or file needs-packaging bug, but at least then you can close the needs-packaging bug with first upload.
[14:47] <dholbach> yeah, that's right :)
[15:25] <ritz> Sweetsha1k, hi, any thoughts on https://bugs.launchpad.net/ubuntu-advantage/+bug/1275574
[15:30] <seb128> ritz, have your seen sarnold comment on that bug? seems an accurate summary of where Ubuntu stands on the question
[15:31] <ritz> seb128, hmm, thanks . so, we could ship this be default, but turned off
[15:31] <seb128> right
[15:32] <ritz> thanks a ton
[15:43] <hallyn> jibel: oh yay, thanks for commit 84 to auto-upgrade-testing (fixing python3/distroinfo)  :)
[15:46] <jibel> hey hallyn, yw
[16:39] <seb128> bdmurray, hey, did you have any chance finding why retracings often don't work for e.u.c trusty reports?
[16:39] <pitti> Good morning
[16:39] <bdmurray> seb128: not specifically, I did notice that the trusty version of gdb often produces better results than the precise one
[16:40] <bdmurray> seb128: I think that's a corner case though
[16:40] <pitti> Saviq: when did unity8 get uploaded? index generation takes a few hours
[16:40] <pitti> tvoss: hey
[16:40] <seb128> bdmurray, the retracers run precise?
[16:40] <bdmurray> seb128: the ones for errors do
[16:41] <pitti> smoser: no, I'm afraid not: https://jenkins.qa.ubuntu.com/job/trusty-adt-setup-testbed/123/ARCH=amd64,label=wazn-adt/console
[16:41] <seb128> bdmurray, can you have access to one of the reports and try to retrace manually to see if that hits an error?
[16:41] <Saviq> pitti, well there's only one version in the indexes anyway, while the packages come from PPAs, so I assume they'd never end up in the index, would they?
[16:42] <pitti> Saviq: ah; yes, if they are not in the distro, then they won't get indexed
[16:42] <pitti> Saviq: and they will also get cleaned up again, as they really ought to live in the PPA only
[16:42] <mapreri> dholbach: sorry, but I can't reproduce the bug you reported against liferea. I can start it even on a clean install on virtualbox...
[16:42] <Saviq> pitti, indeed, any pointers on how to retrace .crashes from PPAs? can I download the ddebs and put them in the cache somewhere? would that help at all?
[16:43] <bdmurray> seb128: I'll see what I can do
[16:44] <pitti> Saviq: they should be in the PPA's Packages, are they not?
[16:44] <pitti> Saviq: then, if you add an apt source for them it should Just Work
[16:44] <dholbach> mapreri, maybe it doesn't work if you have preferences stored locally from a previous version?
[16:44] <Saviq> pitti, ah are they?
[16:45] <Saviq> pitti, http://pastebin.ubuntu.com/6960750/ doesn't look like it
[16:46] <seb128> bdmurray, thanks
[16:47] <smoser> pitti, yeah, i see that.
[16:47] <smoser> so the 20140219 build is just not marked current
[16:47] <smoser> utlemming, ^
[16:47] <smoser> http://cloud-images.ubuntu.com/trusty/current/ is 20140218,
[16:48] <smoser> did publish to ec2 fail ?
[16:50] <mapreri> dholbach: I don't think so: I had a previous configuration from a quite old installation (during quantal maybe) and worked fine (after that I delete all config file to see what happen on a new installation). Can you try with a guest user to exclude user config issues (or confirm)?
[16:50] <dholbach> mapreri, hah! now it works! :)
[16:51] <dholbach> I have no idea what happened in the meantime
[16:51] <mapreri> dholbach: automagically?
[16:51] <dholbach> sorry for the noise - maybe it was intermittent
[16:51] <dholbach> but I just started it again, just to try - because I had tried it at least 4-5 times earlier
[16:51] <dholbach> now it works
[16:52] <mapreri> dholbach: is the messaging menu working fine? (I had some trouble during the merging..)
[16:52] <dholbach> mapreri, this is really bizarre
[16:53] <dholbach> mapreri, yep, it works
[16:53] <dholbach> mapreri, let me close the bug again
[16:53] <dholbach> thanks for your work on this!
[16:53] <mapreri> dholbach: yeah, casual failures are always "weired"
[16:54] <dholbach> mapreri, if it should ever act up again, I'll let you know! :)
[16:54] <mapreri> dholbach: good! let's go on with another piece of software :)
[16:54] <dholbach> :)
[17:15] <pitti> smoser, utlemming: yep, jibel forced a manual build with 0219 instead of /current, works fine again
[17:17] <smoser> pitti, k. thanks.
[17:18] <smoser> pitti, so is this a test taht coudl get done in a dep-8 package test ?
[17:18] <smoser> i'd have to download the image, patch in the new cloud-init and then boot it.
[17:18] <pitti> smoser: you mean s/i/it/ ?
[17:18] <smoser> which is all reasonably well do able. with root and kvm.
[17:19] <pitti> smoser: indeed
[17:19] <pitti> smoser: if you boot the image with a seed the first time, it modifies the image, right?
[17:20] <pitti> smoser: but even at the second time cloud-init is still active and needs the seed, so it would still be an useful test
[17:20] <smoser> well, with root i'd just place it in
[17:20] <pitti> smoser: or wait, we could qemu-nbd mount the image, schroot in, dpkg -i the new cloud image
[17:20] <pitti> and then boot it
[17:20] <smoser> right.
[17:21] <smoser> i'd use mount-image-callback as that is why it exists. but that is somethign that is doable ?
[17:21] <smoser> ie, its ok to require nbd kernel module loaded, access to root and to kvm ?
[17:21] <pitti> ah, I wasn't aware of mount-image-callback, that sounds interesting
[17:21] <smoser> i told you about it on your blog!
[17:21] <pitti> smoser: yes, it is
[17:21] <smoser> you should at least read your *own* blog :)
[17:22] <pitti> heh; sorry, forgot about it
[17:22] <pitti> smoser: so yes, as long as this test runs in a full qemu, that'll work fine
[17:22] <pitti> qemu nests well
[17:22] <smoser> "well"
[17:22] <pitti> it won't work on arm/ppc64 in LXC containers
[17:22] <pitti> but that's ok
[17:23] <pitti> (and I'll soon add restrictions to declare which isolation level you need, it has recently been discussed in Debian)
[17:23] <smoser> we could actually test part of it though lxc, althoguh i've not done it.
[17:23] <smoser> you should be able to create a loop block device, and then present that to the container.
[17:23] <smoser> thanks
[17:24] <pitti> yes, but without nbd and qemu it's virtually impossible to mout and modify a qcow image
[17:25] <pitti> smoser: but I don't expect the cloud-init/seed logic to be much platform specific, is it?
[17:25] <pitti> i. e. testing it on x86 initially should be by and large sufficient
[17:27] <smoser> pitti, right. its not arch specific.
[17:28] <smoser> you dont need qemu to do qemu-nbd
[17:28] <smoser> anyway. thanks
[17:30] <pitti> smoser: right, but you need root, and modprobe nbd, which you don't have in lxc
[17:30] <pitti> (you have root, but not modprobe)
[17:37] <jtaylor> doko: pinged the maintainer about pytables
[17:41] <pitti> hm, so pyzmq, dh_python, ubuntu-release-upgrader, and perhaps some other tests are now broken with py 3.4 as a default
[17:41] <cjwatson> pitti: With pygobject/gi, is there any way to annotate a GVariant* parameter such that Python keyword arguments or maybe a Python dictionary get translated to/from a GVariant automatically, or do I have to write wrapper code for that?
[17:42] <pitti> cjwatson: there is no implicit conversion, but there is an override class for GLib.Variant which makes this relatively easy
[17:43] <pitti> https://git.gnome.org/browse/pygobject/tree/tests/test_overrides_glib.py#n11
[17:43] <jtaylor> pitti: pyzmq just needs a rebuild
[17:43] <jtaylor> I'm on it
[17:43] <pitti> cjwatson: or rather, https://git.gnome.org/browse/pygobject/tree/tests/test_overrides_glib.py#n64
[17:43] <jtaylor> just checking the build failure on ppc
[17:43] <pitti> jtaylor: ah, thanks
[17:43] <jtaylor> zeromq
[17:44] <jtaylor> ipython is also in works
[17:44] <cjwatson> pitti: GLib.Variant("a{ss}", {"foo": "bar"}) and suchlike?
[17:44] <pitti> cjwatson: i. e. it's GLib.Variant(signature, pydict)
[17:44] <pitti> cjwatson: right
[17:44] <cjwatson> pitti: OK, that'll do, thanks; just the first time I've written a library with gobject-introspection support and I wanted to check I wasn't missing something cleverer
[17:46] <cjwatson> Looks like roughly 3x/4x lines of code in C vs. Python, which I suppose isn't *terrible*
[17:49] <smoser> pitti, ah. ok. that makes sense.
[17:49] <hallyn> rbasak: uvt-simplestreams-libvirt sync release=quantal arch=i386   fails?
[17:50] <hallyn> maybe i'm in a bad state...  this doesn't make sense
[17:51] <hallyn> rbasak: http://paste.ubuntu.com/6961095/  does that look familiar to you?
[17:52] <rbasak> hallyn: not seen that before, no. otp right now.
[17:52] <hallyn> rbasak: kthx
[17:57] <jtaylor> fun zeromq does nto fail in debian ppc porterbox ._.
[17:58] <jtaylor> I assume we still don't have ubuntu porterboxes?
[18:02] <hallyn> Hm, update/reboot didn't help, and even  uvt-simplestreams-libvirt sync release=saucy arch=amd64 dies
[18:05] <pitti> fginther, barry: hey guys, how are you? greetings from Oakland!
[18:05] <pitti> fginther, barry: would you mind giving me a quick heads-up about the current state of running py3 ap tests in CI?
[18:06] <barry> pitti: hi!
[18:06] <pitti> fginther, barry: AFAIUI, there were some blockers to that a few weeks ago
[18:06] <pitti> I suppose once we can run py3 autopilot tests in CI at all, then the rest is just relatively simple porting that parallelizes well
[18:06] <barry> pitti, fginther yeah, unfortunately i got totally sidetracked on a deep image upgrade issue.  but i think i have fixes for that now and plan on getting back to py3 ap
[18:06] <pitti> and we'd like to do that on the sprint this afternoon
[18:07] <barry> pitti: i have many ports in progress.  we need the ci infrastructure to support it.  xnox iirc landed phablet-test-run changes and i have some autopilot changes that thomi has looked at and needs fixing.  once we get the autopilot reexec branch landed, we can port individual tests one at a time
[18:08] <pitti> barry: ah, so phablet-test-run is done
[18:08] <pitti> re-execing ap sounds a bit scary :)
[18:08] <barry> pitti: double check with xnox
[18:09] <barry> pitti: naw, not scary!  clever and fun! :)
[18:09] <pitti> barry: ah, you don't want tests to declare themselves whether they use py2 or 3?
[18:09] <barry> pitti: (like just a few lines of code)
[18:09] <pitti> barry: hehe, h4cks 4r3 us ☺
[18:09] <barry> pitti: we thought about that, but it's just temporary.  we *really* want everything ported to py3 by 14.04
[18:09] <pitti> barry: yes, understood
[18:09] <pitti> barry: ok, thank you!
[18:10] <barry> pitti: np!  thanks for helping get the ci infrastructure working.  please let me know how that goes
[18:10] <pitti> barry: I thought there was also some discussion about eliminating py2/3 from the installation, and building a chroot/virtualenv in $HOME for installing AP and the tests, or so?
[18:11] <pitti> barry: hm, I can't see that on https://code.launchpad.net/autopilot/+activereviews
[18:11] <barry> pitti: that was part of the "make tests work in read-only image and don't include autopilot in the sdk".  fginther and thomi might be able to answer that better. we had discussions about it in london, and came with some ideas, but i don't know what they decided
[18:12] <barry> pitti: thomi put the mp on hold, which is why that doesn't show up: https://code.launchpad.net/~barry/autopilot/reexec/+merge/203765
[18:12] <pitti> barry: ah, so ATM we still have both and thus this ^ is independent from porting tests and making AP do the "guess which py version I want" trick
[18:12] <pitti> ah
[18:13] <barry> right
[18:13] <pitti> barry: TBH I'm not that thrilled about that blatant violation of the py3 packaging policy by shipping both versions in python-autopilot
[18:14] <pitti> as that's not just a temporary hack but a long-term commitment (we can basically never clean that up without breakage)
[18:14] <pitti> barry: what's bad about having separate python3-autopilot* packages?
[18:14] <barry> pitti: there is a python3-autopilot package, right?
[18:14] <pitti> barry: yes, but I thought that MP removed it
[18:15] <pitti> This also collapses all the python3-* packages into the python-* packages. This supports a transition where we'll eventually delete all Python 2 support.
[18:15] <pitti> barry: I think that does quite the opposite
[18:15] <pitti> with separate py2/3 packages it is much easier to remove py2 support without breakage
[18:15] <barry> pitti: hmm.  i thought it would be easy to just remove /usr/bin/autopilot
[18:15] <barry> (from the python-autopilot package)
[18:16] <pitti> barry: but from the reverse depends of that hybrid python-autopilot you can never be quite sure whether they expect py2 or 3
[18:17] <thomi> barry: if you need that branch merged, ping me, and I'll have a look at adding the tests that are required. It was put on hold because it regressed test coverage :)
[18:17] <barry> pitti: i think i may have had other reasons for doing that too, but that's all been swapped out since london :/  please do me a favor and add a comment to the mp.  as long as we keep focused on getting rid of py2 on the phone, i'm for whatever makes the transition work best.
[18:17] <thomi> but it sounds like there's some discussion that still needs to happen
[18:18] <barry> thomi: yep, will do.  i really hope i can get back to that this week.
[18:18] <thomi> ok
[18:18] <pitti> barry: python3-autopilot could divert python-autopilot's /usr/bin/autopilot as long as it has your "reexec with py2" trick?
[18:18] <pitti> if /usr/bin/autopilot-py3 is not working for some reason
[18:19] <pitti> barry: ack, will do
[18:19] <barry> pitti: thanks.  i'm multi-multi-tasking atm ;)
[18:21] <barry> lifeless: http://bugs.python.org/issue20687
[18:22] <lifeless> barry: yay
[18:23] <barry> lifeless: yeah.  at least it's reported now.  given the changeset and age of the change, i'm not optimistic this will be fixed before 3.4 final :(
[18:23] <barry> *maybe* by 3.4.1, but by then, you're kind of screwed
[18:24] <pitti> barry: followed up
[18:25] <lifeless> barry: I'd call this a regression though; whats the process for dealing with regressions?
[18:26] <barry> lifeless: i would too.  if it's a critical regression, then it could hold up rc2.  you'd have to convince larry hastings (3.4 rm) about that.  probably a post on python-dev if you think it's critical enough, and bump the priority to release blocker
[18:26] <pitti> xnox: so what does phablet-test-run do these days in terms of py2 vs. 3?
[18:27] <lifeless> barry: well you must have opinions too ;) - what do you think, a break in a public API ?
[18:28] <barry> lifeless: that's the question - was testtools relying on documented public api, or implementation details.  i probably have an opinion, but right now my stack is too deep and i get a recursion error when i try to access it :)
[18:29] <barry> lifeless: so i would recommend commenting on the bug stating the public api that got broke.  if you need me to ping larry, i can do that, but not sure i'll have the resources to chime in
[18:29] <barry> *cycles
[18:33] <lifeless> barry: btw I'm rbcollins in the tracker
[18:33] <barry> lifeless: ah, that's why i couldn't find you ;)
[18:35] <lifeless> commented
[18:36] <lifeless> thomi: are you working up a patch to fix Python3.4?
[18:37] <barry> lifeless: i nosied larry and bumped it to release blocker
[18:56] <pitti> xnox, barry: so thomi and I just discussed this, and we think the main problem that's left is how tests declare that they got ported to py3
[18:57] <pitti> xnox, barry: for packaged tests we could check their deps, but that doesn't work for click and tests from bzr (which apparently we need to support)
[18:57] <pitti> xnox, barry: so we found that it might be easiest to just add a magic comment or a global _AP_PY3 = True variable into the tests
[18:58] <pitti> xnox, barry: and then phablet-test-run or /usr/bin/autopilot could check that and call autopilot-py3 (for p-t-r) or run python[3] -m autopilot (for /u/b/ap)
[18:59] <pitti> xnox, barry: that ought to work for all scenarios, is explicit (i. e. we can measure/check the porting status), and we can drop that flag variable in the future again
[18:59] <pitti> xnox, barry: we can also have a hangout if you wish
[19:04] <pitti> I summarized that in https://code.launchpad.net/~barry/autopilot/reexec/+merge/203765
[19:05] <rbasak> hallyn: looks like maybe you have a corrupt or missing file in /var/lib/uvtool/libvirt/metadata/
[19:05] <rbasak> hallyn: that might be a bug. I'm not sure if I atomically move new files in, or write them in place.
[19:06] <rbasak> hallyn: fix: remove the offending file, and resync.
[19:09] <pitti> barry: wow, this problem violates the laws of projectivity; it becomes bigger the closer you get to it :(
[19:10] <barry> pitti: i need to be afk for a while.  can you set up a hangout with you, me, xnox, and thomi for tomorrow?
[19:10] <hallyn> rbasak: after removing the cache i had to purge and reinstall uvtool-libvirt to get directories re-created with the right perms
[19:11] <hallyn> rbasak: but now it's building, thanks
[19:12] <pitti> barry: would tomorrow 1700 UTC work for you?
[19:14] <hallyn> rbasak: another q: is there a way to shut up the 'Warning: this CLI is experimental and may change.' ?
[19:15] <hallyn> (not very amenable to scripting)
[19:16] <pitti> barry: done
[19:54] <rbasak> hallyn: I've left a "uvt-simplestreams-libvirt purge" command that wipes all volumes (potentially breaking any existing VMs that might use them).
[19:54] <rbasak> Though it's broken in Trusty (fixed locally; I'll upload before FF)
[19:54] <hallyn> rbasak: what do you mean by 'left' ?
[19:54] <rbasak> Er, working in Trusty, broken in Precise.
[19:54] <rbasak> hallyn: as in it's there, though really intended for cleaning up after a mess; it's still a bug if a mess occurs.
[19:55] <hallyn> ok
[19:55] <hallyn> i'm slowly making progress;  now have an unbootable quantal vm, but at least i have it :)
[19:55] <rbasak> hallyn: uvtool issues? Or elsewhere?
[19:56] <hallyn> not sure.  i don't see where i had room (before this failure) to mess up the image...  but lemme try by hand
[19:56] <rbasak> About the CLI experimental warning - I'm just about ready to drop that. Also before FF.
[19:56]  * rbasak has a few more things to do today :-/
[19:58] <hallyn> rbasak: oh, it's on stderr, so i should be able to tell subprocess to ignroe it
[19:58] <rbasak> hallyn: ah yes; that's intentional for that reason.
[19:58] <hallyn> i just didn't think subprocess would give me stderr by default
[19:58] <rbasak> It does, but separately, IIRC.
[20:00] <hallyn> actually no,
[20:00] <hallyn> subprocess.check_output(["uvt-kvm", "list"], stderr=None)
[20:00] <hallyn> Warning: this CLI is experimental and may change.
[20:02] <rbasak> hallyn: None doesn't do what you think. You want:
[20:03] <rbasak> with open('/dev/null', 'wb') as null_file:
[20:03] <rbasak>   subprocess.check_output(["uvt-kvm", "list", stderr=null_file)
[20:03] <jtaylor> *nitpick* os.devnull
[20:03] <rbasak>                                             ^
[20:04] <rbasak>                                             ]                  # :)
[20:04] <rbasak> Oh, that exists?
[20:04] <jtaylor> yes but only relevant for windows
[20:04] <hallyn> rbasak: well that's a pain :)  ok, thx.  first to see why my vm wont' boot
[20:05] <rbasak> Oh I see. Just the path, rather than a file object. Thanks ;)
[20:05] <hallyn> hangs on 'booting from Hard Disk'.  maybe it's a qemu bug.
[20:05] <rbasak> hallyn: two ways to debug. --log-console-output, then look at /var/log/libvirt/qemu/<machine>.log
[20:05] <cjwatson> rbasak: There's also stderr=subprocess.STDERR, but that's new in 3.3
[20:06] <rbasak> hallyn: or, no --log-console-output, and then "virsh console <machine>" to get an interactive VT
[20:06] <cjwatson> err
[20:06] <cjwatson> stderr=subprocess.DEVNULL I mean
[20:06] <rbasak> Nice. I've always wanted that :)
[20:06] <rbasak> Getting an interactive VT with "virsh console" races VM start though I think. Should be good enough if you're ready for it though.
[20:12] <hallyn> rbasak: but so yes, uvt-kvm create xxx release=quantal arch=i386 --ssh-public-key-file ~/auto-
[20:12] <hallyn> upgrade-tester/ssh-key
[20:12] <hallyn> gives me an unbootable vm.  sigh
[20:13] <rbasak> It really shouldn't do that.
[20:13] <hallyn> mind you i'm nested
[20:14] <rbasak> How many levels?
[20:15] <rbasak> One level (of nesting) works fine for me. One additional level caused the middle kernel to hang, IIRC. I didn't experiment further.
[20:15] <hallyn> just one level - running quantal vm in a trusty vm on precise
[20:16] <jpds> You need to go deeper.
[20:17] <rbasak> Each level does appear to run at a fraction of the speed :)
[20:17] <hallyn> jpds: yup that'll solve it :)
[20:17] <hallyn> you know, if my problem is a race condition when things run too fast
[20:17]  * rbasak wonders if that's backwards
[20:30] <frafu> Hi, We have just published an update of Onboard, the default on-screen keyboard shipping with Ubuntu. Could anybody please review the debian package I prepared for trusty before feature freeze is in place? Many thanks in advance.
[20:31] <frafu> https://bugs.launchpad.net/ubuntu/+source/onboard/+bug/1282231
[20:48] <infinity> Setting up python3-minimal (3.4~rc1-1) ...
[20:48] <infinity> Exception ignored in: <bound method Popen.__del__ of <subprocess.Popen object at 0xf75c1610>>
[20:48] <infinity> Traceback (most recent call last):
[20:48] <infinity>   File "/usr/lib/python3.4/subprocess.py", line 897, in __del__
[20:48] <infinity> TypeError: 'NoneType' object is not callable
[20:48] <lifeless> classic
[20:48] <infinity> doko: ^-- I'm seeing a lot of that.  Do you know what's going on?
[20:53] <roadmr> can I get "apt-get install" to fully expand the list of unmet dependencies? e.g. it can't install X because it depends on Y, but it won't tell me why Y can't be installed (it may depend on Z which *is* uninstallable)
[21:01] <cjwatson> roadmr: Sadly AFAIK you generally just have to keep supplying additional package names from the error output until you get a useful answer
[21:01] <roadmr> cjwatson: oh bummer... that's what I'm doing but it's cumbersome :/ thanks anyway!
[21:51] <frafu> TheMuso: I suppose that we missed feature freeze with this: https://bugs.launchpad.net/ubuntu/+source/onboard/+bug/1282231   ?
[23:04] <pitti> cjwatson: jibel and I believe we understand what happened last week in britney with gccgo; I just committed a test case which reproduces that: http://bazaar.launchpad.net/~canonical-platform-qa/britney/tests/revision/397
[23:21] <roaksoax> has something changed packaging wise that python mpackages are installing in /usr/lib/pythonX.y/etc/etc instead of creating the symlink to /usr/share/pyshared?
[23:23] <cjwatson> roaksoax: https://launchpad.net/ubuntu/+source/python-defaults/2.7.5-5ubuntu3
[23:23] <cjwatson> (I think.  Yes, anyway.)
[23:24] <roaksoax> cjwatson: cool thanks!