=== kees_ is now known as kees
[01:38] <micahg> asac: I can give you dev membership without upload rights if you want
[02:59] <BenC> Any reason why packages.ubuntu.com contents search isn't working for saucy?
[03:07] <ScottK> Hasn't been set up yet.
[03:07] <ScottK> Rhonda handles it both for Ubuntu and Debian.  Not sure what's blocking it.
=== _salem` is now known as _salem
[05:12] <pitti> xnox: erk, your update-manager merge (common dialogs) broke quite a lot -- got the tests mostly fixed again, but this dropped UpdateManager/UpdateProgress.py which was still being included
[05:18] <dylan-m> pitti: Eep, I thought I had those tests passing.
[05:18] <pitti> dylan-m: the pep-8 and pyflakes errors were simple, I got these committed
[05:19] <pitti> dylan-m: it looks like I'd replace UpdateProgress(main) with something like get_backend(self, InstallBackend.ACTION_UPDATE) ?
[05:19] <pitti> in ./tests/test_update_error.py
[05:19] <dylan-m> pitti: I'll be happy to work through these tomorrow, if you'd like :)
[05:23] <dylan-m> pitti: Hang on, just going to jog my memory on that one, but I think that's right. The Update / Install backends were stuck together, if I remember correctly.
[05:30] <pitti> dylan-m: hm, I'm afraid I can't figure it out without truly understanding what's going on there :/
[05:30] <dylan-m> Hm, action-done isn't a signal any more, either, so that'll need to be changed to just call the hidden method _action_done. Should take the same arguments.
[05:35] <pitti> dylan-m: ok, in bzr I now fixed all failures except this one
[05:36] <dylan-m> Hm, are there some existing failures trying to import DistUpgrade.DistUpgradeCache, or is that just me?
[05:37] <pitti> not with "env -u LANGUAGE LANG=C nosetests3" here
[05:38] <dylan-m> Ah, yes, using the right version of nosetests helps :)
[05:54] <dylan-m> pitti: Okay, that one is fixed! https://code.launchpad.net/~dylanmccall/update-manager/test_update_error-fix
[05:55] <pitti> dylan-m: ah, nice header_markup() fix, I changed that differently in trunk but I'll take your version
[05:55] <pitti> dylan-m: thanks!
[05:57] <dylan-m> pitti: I thought about just using get_text instead of get_label, but some translations could add Pango markup for some reason (not sure if they should, though), so that could cause some unusual failures
[05:57] <pitti> ah, overlong line again
[05:58]  * pitti fixes
[05:58] <pitti> yay, all pass now
[05:58] <pitti> time for another "real life" test, and then I'll upload
[05:58] <dylan-m> pitti: d'oh! This is what happens when I use the wrong text editor.
[05:58] <pitti> dylan-m: pep8 test was failng
[06:02] <pitti> xnox: unping, all good now
[06:04] <dylan-m> pitti: Yay! Sorry about the trouble :) I really appreciate good unit tests, and I'm really glad you're keeping on top of them! I really need to fix my ugly habit where I always forgetting to run them when they're there.
[06:05] <pitti> dylan-m: heh, thanks for the fast fix
[06:05] <pitti> dylan-m: all I did was to drop the obsolete threads_init() call, and that got me into some more work :)
[06:11] <dylan-m> Oh, right, I was brushing my teeth. Err, good night, then! :)
[06:12] <pitti> dylan-m: night!
[06:43] <dholbach> good morning
=== smb` is now known as smb
=== Lutin is now known as Guest11889
[07:59] <tvoss> pitti, ping
[08:00] <pitti> hey tvoss
[08:07] <Laney> dobey: well, those changes alone aren't enough to make the autopkgtests pass
[08:08] <Laney> I'll give you what I have atm but it's unfortunately still not enough - it seems to block forever at some point even though they were passing when I ran them manually
[08:08] <Laney> kind of annoying that adt-run buffers output so you don't get it at all if you have to ctrl-c :/
[08:11] <pitti> Laney: you can tail -f the stdout/stderr files in the tmp dir
[08:12] <Laney> pitti: oh really? let me try this
[08:12] <Laney> I was playing with --output-dir and --log-file
[08:13] <pitti> Laney: that works as well in run-adt-test, you can ssh into the VM and tail -f the files in /tmp/adtmp/...
[08:13] <pitti> ssh -p 54323 ubuntu@localhost
[08:13] <pitti> (get the precise port from the initial output or from the qemu command line)
[08:16] <dholbach> we're at 62 sponsoring items - does anyone have a bit of time today to go through a few?
[08:21] <xnox> pitti: cool, thanks. sorry about that.
=== mwhudson_ is now known as mwhudson
[08:31] <cjwatson> pitti: Please could you merge subversion?
[08:32] <pitti> ugh, did I make the error of touching it?
[08:32] <pitti> ah, a no-change rebuild
[08:32] <cjwatson> Yeah :)  Or I can do the merge if you like
[08:32] <pitti> cjwatson: I'll have a look
[08:33] <pitti> I don't even see it on MoM, perhaps it's still catching up
[08:34] <xnox> barry: i think i got broken icon in emacs24, it was a combination of having a server on the tty and launching a new gui instance.... it turned into a "?"
[08:35] <cjwatson> MoM got stuck.  I've poked it
=== vibhavp_ is now known as vibhavp
[08:35] <cjwatson> Should catch up within an hour or so I hope
[08:41] <cjwatson> Is there a good example package anywhere which uses both the autotools and setup.py?  I need/want to use the autotools for C parts of this project, but I already have setup.py in place for the Python parts ...
[08:43] <pitti> cjwatson: merged, test sbuild running now
[08:43] <pitti> http://bazaar.launchpad.net/~ubuntu-branches/debian/sid/subversion/sid/revision/22 FTW :)
[08:47] <mpt> ev, how do you track bugs that, when fixed, will alter the apparent error rate but not the actual error rate? For example bug 1196740.
[08:47] <ubottu> bug 1196740 in software-center (Ubuntu) "not all package install failures generate a crash report" [High,Confirmed] https://launchpad.net/bugs/1196740
[08:47] <ev> mpt: we don't at present
[08:48] <ev> didn't we come up with a plan for that at the January sprint?
[08:49] <mpt> ev, if so, it isn't mentioned in https://wiki.ubuntu.com/ErrorTracker#Cross-release_comparisons
[08:51] <ev> mpt: https://docs.google.com/a/canonical.com/document/d/1BWOIRdJvUueJa4cWV68UEY3nlmHgAVJY6aNGo6YSCQg/edit# - "How do we handle anticipating more errors?"
[08:52] <ev> there's no implementation for this yet though
[08:53] <mpt> aha, DetectedSince, DetectedUntil
[08:54] <mpt> but there's no field for that in the database?
[09:01] <ev> mpt: not yet, no
[09:03] <ev> my priority at the moment is getting error reporting working on mobile and server, while working through this datacenter move (then back population jobs, woo) and testing acunu analytics for possible use. Detected{Since,Until} is just not something I'll have time for in the near future
[09:05] <ev> dpm: you're my hero for the workaround in https://bugreports.qt-project.org/browse/QTBUG-32225
[09:06] <dpm> ev, no worries, Wellark is the person to credit, he suggested it to me :)
[09:06] <ev> thanks to the both of you then :)
[09:07] <seb128> hum
[09:07] <dpm> :-)
[09:07] <seb128> update-manager is hanging on a " [debconf-communi] <defunct>"
[09:27] <ev> seb128: do you know what the plan is for mobile with respect to dbus services that currently require authentication via policykit? Are we going to start shipping 10-vendor.d configs setting ResultActive=yes for the phablet group?
[09:29] <ev> the background for this being that we currently have com.ubuntu.WhoopsiePreferences which controls access to /etc/default/whoopsie. On the desktop, it requires an admin user to enter their password via polkit to call the dbus methods. My understanding is that we don't want to ask the user to reauthenticate when changing system settings on the phone.
[09:32] <seb128> ev: no, I don't know, it's on my list of things to check with the sdk/security teams, the previous times I asked people didn't really know/think about it yet
[09:32] <seb128> ev: I'm not sure we even have polkit on the touch image atm (the UI is GTK as well which is an issue)
[09:33] <pitti> cjwatson: ah, it finally finished building, uploaded svn
[09:33] <ev> seb128: *nods* thank you
=== vibhav is now known as Guest62647
[09:34] <seb128> ev: yw ... I'm going to try resume discussions about that and I will include you
[09:34] <ev> very much appreciated, thanks
[09:50] <capdenuca> anyone over here?
[09:50] <cjwatson> Just ask - don't ask to ask
[09:52] <capdenuca> do u know how to get a mirc user?
[09:52] <cjwatson> I'm not sure how a Windows IRC client is relevant to this channel?
[09:53] <capdenuca> cuz i m new on this...
[09:54] <cjwatson> I think you're confused and want some other channel.  I'm not sure which.
[09:54] <cjwatson> This channel is for development of Ubuntu.
[09:55] <quadrispro> hello everybody
[10:26] <ev> mpt: got a second?
[10:48] <ev> mpt: so it's not going to centre, because the toolkit defaults to left-aligned for captions and does not expose that property: http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/modules/Ubuntu/Components/ListItems/Caption.qml#L57
[10:48] <ev> think I should file a bug for that?
[10:49] <mpt> ev, no, that's fine, all captions should line up the same.
[10:49]  * ev nods
[10:56] <seb128> ev: what are you trying to do?
[10:57] <ev> seb128: https://wiki.ubuntu.com/ErrorTracker#Privacy_settings (righthand mockup)
[11:01] <seb128> ev: you can do http://paste.ubuntu.com/5867801/
[11:02] <seb128> ev: but please open a bug on the toolkit asking them to allow changing the alignement
[11:02] <ev> seb128: sure, but I'm more keen on staying consistent
[11:02] <seb128> ev: consistant with what?
[11:02] <ev> the rest of the interface
[11:02] <seb128> ev: caption will not do what you want anyway
[11:02] <ev> it's going to look weird if we have some captions left aligned and some centred
[11:03] <ev> as mpt also seemed to suggest
[11:03] <seb128> ev: ok, well still caption is going to be weird, they have colored background
[11:03] <seb128> ev: cf. https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1194513
[11:03] <xnox> ev: file:///usr/share/ubuntu-ui-toolkit/doc/html/qml-ubuntu-components-listitems0-standard.html
[11:03] <ubottu> Launchpad bug 1194513 in Ubuntu UI Toolkit "[ListItem] Should be possible to wrap text in list items" [Undecided,In progress]
[11:03] <seb128> xnox, you can't wrap in standard, see ^
[11:04] <xnox> ev: List Items -> progression. It's a left aligned text with progress arrow on the right. I would have used that standard element.
[11:04] <xnox> seb128: yeah, sucks =)
[11:05] <ev> xnox: I'm already using progression - we're talking about the caption item
[11:06] <xnox> oh, isee.
[11:06] <xnox> I got ubuntu-sdk guru answer a question on centered wrapping for me here: http://askubuntu.com/questions/308088/how-to-make-a-centred-wrapped-and-padded-container-of-elements-in-qml
[11:06] <xnox> which does work in a Column.
[11:09] <seb128> xnox, http://paste.ubuntu.com/5867801/ works
[11:09] <seb128> xnox, but ev doesn't want to use non standard elements
[11:10] <xnox> seb128: ok. I don't think I've done inheritance yet.
[11:10] <seb128> xnox, the system settings are mostly listitems
[11:10] <seb128> see e.g the about settings
[11:11] <seb128> we have random alignments and hacking there ;-)
[11:11] <xnox> seb128: ok. i think i've asked yesterday, but is anybody working on porting chewieui / indicators-client / wifi portion into the system settings?
[11:11] <seb128> xnox, ted
[11:11] <seb128> xnox, well, he's working on the indicator
=== tjaalton_ is now known as tjaalton
[11:12] <seb128> but the idea is that the indicator is gmenu based code sent to unity which renders it through a qmenumodel/unitymenumodel
[11:12] <seb128> we plan to reuse the model in system settings
[11:12] <seb128> since most of the items/actions will be shared
[11:13] <xnox> seb128: but there is slight differences in design, the system settings has more options.
[11:13] <seb128> right
[11:13] <seb128> the indicators services will have several "profiles"
[11:13] <seb128> e.g different layouts they export
[11:13] <seb128> one for desktop
[11:13] <seb128> one for greeter
[11:13] <seb128> one for phone
[11:13] <seb128> one for settings
[11:14] <seb128> the service basically has all the items that will be used and actions
[11:14] <seb128> then you build models with the layout/actions you need
[11:14] <xnox> seb128: what should I do for oobe then, cause i also need "connect to network" step.
[11:14] <seb128> talk to ted
[11:14] <xnox> ted, talk to me =)
[11:14] <seb128> but it should be "hit the menu/action though unitymenumodel", I'm not sure how that works though
[11:14] <seb128> it's a bit early for ted
[11:15] <xnox> yeah, and not idling via irc proxy. Right. will poke him in late afternoon.
=== MacSlow is now known as MacSlow|lunch
[11:37] <ev> xnox, seb128: if you have some free time: https://code.launchpad.net/~ev/ubuntu-system-settings/diagnostics/+merge/174385
[11:39] <seb128> ev: thanks, I will try to review/comment today
[11:40] <seb128> ev: could you or mpt update the design on https://wiki.ubuntu.com/SystemSettings to list that panel because it's not there at the moment? (should it really be a main category item in rather rather than a subpanel in security&privacy for example)?
[11:41] <seb128> ev: oh, it's in https://wiki.ubuntu.com/SecurityAndPrivacySettings#Phone
=== asac` is now known as asac
[12:04] <mpt> Ugh, why did I think it was top level?
[12:04] <mpt> Sorry, ev
[12:04] <mpt> Memory malfunction
[12:05] <ev> mpt: so it should be accessible from "Security & Privacy"?
[12:05] <mpt> ev, yes
[12:06]  * ev nods
[12:07] <ev> I'll fix that in the MP
[12:07]  * Laney pauses reviewing :P
[12:07] <ev> oh boo :)
[12:07] <ev> do feel free to pick apart the rest of it
[12:07] <Laney> just saw some from seb anyway
[12:08] <seb128> Laney, I did a quick one before lunch, it would still be good if you would review/comment
[12:08] <Laney> I'll take Round Two after those are addressed
[12:08] <seb128> especially on the cpp code, I glanced to that one only
[12:08] <seb128> thanks
=== sergiuse1s is now known as sergiusens
=== MacSlow|lunch is now known as MacSlow
=== andreas__ is now known as ahasenack
=== _salem is now known as salem_
=== cmagina-away is now known as cmagina
=== KRF_ is now known as kfunk
[13:27] <obounaim> Hi everybody
[13:27] <obounaim> Is there a way in Ubuntu to get the number of users of a given package
[13:32] <geser> not really, you could look at the popcon data but it's only a *very* rough estimate
[13:35] <obounaim> Ok thanks
[13:35] <obounaim> but where can I find this popcon data?
[13:35] <pitti> cjwatson: libapache2-svn is NBS now, removing
[13:35] <cjwatson> I already did
[13:35] <pitti> or, someone already did that
[13:35] <cjwatson> Thanks
[13:37] <geser> obounaim: http://popcon.ubuntu.com/
[13:45] <obounaim> thanks
[13:53] <obounaim> is popularity-contest installed by default in Ubuntu?
[13:53] <debfx> obounaim: yes, but submission is opt-in
[13:56] <obounaim> so it sends data about installed packages by defaults right?
[13:57] <debfx> obounaim: no, only when you configure it to do so (I think the installer has a checkbox that is disabled by default)
[13:58] <obounaim> ok
[13:58] <obounaim> so what did you mean by "opt-in"?
[14:02] <geser> exactly that, the user has actively to enable it during installation (opt-in) otherwise no data gets send
[14:05] <obounaim> ok thanks
=== Ursinha-afk is now known as Ursinha
=== kentb-out is now known as kentb
[14:45] <caribou> when a submitted debdiff fixes two existing bugs, should it be uploaded to both bugs or only one ?
[14:46] <caribou> sorry to bug you about this here but didn't get an answer in #ubuntu-bug
[14:58] <infinity> caribou: It should mention both bugs in the changelog.  Don't really care where the diffs go, best to just find a sponsor and get it sorted.
=== s1aden is now known as sladen
[14:59] <caribou> infinity: well that's the danted fixes we talked about yesterday. Both bugs are outlined in the changelog
[15:00] <infinity> caribou: Toss me a diff, and I'll look at sponsoring it.
[15:00] <caribou> infinity: I completed the SRU template  & subscribed the appropriate teams.
[15:01] <caribou> infinity: they're attached here : https://bugs.launchpad.net/ubuntu/+source/dante/+bug/816153
[15:01] <ubottu> Launchpad bug 816153 in dante (Ubuntu Precise) "dante-server using the wrong libc.so" [Medium,In progress]
[15:01] <caribou> I can send them over by mail if you want; both precise & saucy
[15:02] <caribou> infinity: I added the search snippet you suggested yesterday
[15:03] <caribou> infinity: both tested on saucy & precise, 32 & 64 bit
[15:03] <infinity> caribou: I'll look at the bug(s) in a second.
[15:03] <caribou> infinity: no rush,I'm almost done for the week
[15:05] <dobey> who is it again that is most appropriate to ping about busted bzr imports of package uploads? wgrant and who else? i pinged wgrant last night before i left, but unfortunately didn't get a reply :-/
[15:06] <infinity> dobey: I think xnox has been looking into import issues.
[15:06] <dobey> xnox: have you? :)
[15:07] <xnox> dobey: what package?
[15:07] <xnox> dobey: yeah, i have access to the imported and _some_ experience in it.
[15:08] <dobey> xnox: software-center failed
[15:08] <dobey> http://package-import.ubuntu.com/status/software-center.html#2013-07-05%2021:56:29.968306 is the error
[15:09] <dobey> seems to be a common problem though, those missing revisions from james_w :-/
=== zyga_ is now known as zyga
[15:46] <dpb1> slangasek: Hi -- upstart question.  I have a non-forking daemon that is early exiting (log file permissions are wrong).  Is there a way to catch this error so the "start daemon" command fails?  Or is that not something to worry about?
[15:48] <tedg> cjwatson, Do you expect the $(pkgdir)/.click/$(pkgname)/manifest path to remain constant?
[15:48] <tedg> cjwatson, At least in the near term.
[15:48] <stgraber> dpb1: so it's not exiting non-null before it's done double-forking? otherwise I'd expect upstart to notice the failure and make the start call fail
[15:49] <dpb1> stgraber: this is a non-forking daemon (running in foreground)
[15:57] <stgraber> hmm, not sure that's possible for a non-task to return a failure to start when it's not forking
[16:10] <dpb1> :( ok  I thought post-start could be helpful, but it seems to ignore exit codes from therewq
[16:14] <slangasek> dpb1: so you have no 'expect' stanza; which means upstart believes the job is successfully started as soon as it has exec'ed the program.  I'd say you want to change it so upstart can know that it's failed, if you care about 'start' not returning success when the startup hasn't succeeded.
[16:16] <cjwatson> tedg: Yes.
[16:17] <tedg> cjwatson, cool, thanks!
[16:17] <cjwatson> tedg: Though it's actually $(pkgdir)/.click/info/$(pkgname).manifest ...
[16:18] <stgraber> slangasek: but how would you do that with a non-forking service (as seems to be the case here)?
[16:18] <tedg> cjwatson, Ah, sorry, I wrote from memory instead of cut-and-paste.  I was planning to look again :-)
[16:19] <dpb1> slangasek: hmm.  So, adding a post-start "sleep 5" for instance prints the "daemon stop/waiting", but I still get a 0 exit code from the service command.  And I get 0 exit from status as well, which doesn't seem right?  Unless I'm missing something.
[16:19] <dpb1> (which is likely)
[16:19] <slangasek> stgraber: 'expect stop' is the least intrusive
[16:20] <slangasek> dpb1: 'sleep 5' just means that upstart thinks that a) the main program started successfully, b) the post-start script exits successfully, so 'service' (or 'start') returns success.
=== dannf` is now known as dannf
=== Ursinha is now known as Ursinha-afk
[16:37] <dpb1> slangasek: http://paste.ubuntu.com/5868569/ -- I worked up a paste that demonstrates what I'm talking about.  Hopefully it makes more sense than my prose.  How do I get non-zero exit status when the daemon is not running?
[16:39] <jbicha> mardy: could you approve https://code.launchpad.net/~jbicha/gnome-control-center-signon/fix-build-with-control-center too?
=== BenC- is now known as BenC
=== hatch_ is now known as hatch
[17:04] <slangasek> dpb1: sorry, I understood already exactly what you were asking for, it must be my answers which were unclear. :)  The easiest way for upstart to reliably know whether your non-daemon process has launched successfully is to use 'expect stop', and modify your program to raise SIGSTOP when it considers itself successfully started
=== BenC- is now known as BenC
[17:04] <slangasek> dpb1: (probably something that you want to have as a commandline option to the program, since raising SIGSTOP isn't normally something you'd do when run from the commandline)
=== andreas__ is now known as ahasenack
[17:08] <dpb1> slangasek: intersting.  I'm looking into that now, thanks.
=== cody-somerville_ is now known as cody-somerville
[17:10] <slangasek> dpb1: documentation in init(5), though that doesn't add much over what I've already said
[17:11] <dpb1> slangasek: OK, thanks.  I'm still curious though why service status is not showing an error when the daemon is not running (and upstart knows it is not).  If I switch over to SIGSTOP, that will suddenly start working, I hope? :)
[17:12] <dpb1> by error, I mean, exit status
=== enrico__ is now known as enrico
[17:16] <slangasek> dpb1: that seems like a bug in the service command
[17:20] <dpb1> Tracing, it's just a pass-through to status, which is a call to initctl, which also shows the same behavior.  I'll look for a bug.
[17:21] <dobey> xnox: hey. were you able to get software-center branch import fixed up?
[17:23] <slangasek> dpb1: it's not a bug in initctl, whose exit codes are defined to represent success/failure of the dbus calls, not anything about the service status
[17:23] <slangasek> dpb1: it may be a bug in the service command, I'm not sure
[17:23] <dpb1> slangasek: not this? https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/552786  seems the same?
[17:23] <ubottu> Launchpad bug 552786 in upstart "initctl: lacks proper exit codes" [Medium,Triaged]
[17:24] <slangasek> dpb1: comment #11 - this is about return codes from upstart-job, which is deprecated
[17:25] <slangasek> dpb1: is this on saucy? precise?
[17:25] <xnox> dobey: i did requeue it...
[17:25] <dpb1> slangasek: precise
[17:25] <xnox> dobey: $ bzr branch lp:ubuntu/software-center
[17:25] <xnox> Most recent Ubuntu version: 13.05-0ubuntu2
[17:25] <xnox> Packaging branch status: CURRENT
[17:25] <slangasek> dpb1: ok - then yes, that version of service may be affected by that bug in upstart-job
[17:25] <xnox> yes.
[17:27] <dobey> xnox: ah cool, thanks! :)
[17:27] <dpb1> slangasek: ah, gotcha.  initctl also shows this behavior though.  Is there a way to poll the service status more reliably on precise?
[17:28] <slangasek> dpb1: initctl is *supposed* to behave that way
[17:28] <slangasek> things that want a different exit code for running/not-running need to parse the initctl output and do their own mapping to error codes
[17:28] <slangasek> this is what 'service' is meant to do
[17:28] <slangasek> (or upstart-job, depending on which iteration)
[17:29] <dpb1> slangasek: ok, thanks.  that helps.
[17:29]  * dpb1 stops sucking up all of slangasek's time now
[17:29] <slangasek> fwiw, it looks like this issue is still present in the saucy version of service
[17:33] <dpb1> slangasek: yes, I'm seeing that, thanks.  I wonder what puppet has done to workaround it.  probably parse I guess
[17:33] <slangasek> I believe so
[17:33] <ev> mardy: so I tried your suggestion of subclassing QDBusInterface, but I'm running into a segfault deep in the bowels of the generated code: http://paste.ubuntu.com/5868715/ (diff against lp:~ev/ubuntu-system-settings/diagnostics) and http://paste.ubuntu.com/5868718/
[17:34] <ev> I can't seem to figure out what's going on here
[18:42] <Snow-Man> hrmmm, ipv6 for the systems behind us.archive.ubuntu.com appears to be non-functional this afternoon. :(
=== Ursinha-afk is now known as Ursinha
=== ricmm_ is now known as ricmm
[21:07] <dobey> anyone care to sponsor https://code.launchpad.net/~dobey/ubuntu/saucy/ubuntu-meta/drop-u1-gnome/+merge/174471 please? :)
[21:20] <infinity> dobey: If by "sponsor", you mean update the seeds, maybe...
[21:25] <dobey> infinity: i guess that's what it means. i just want to get ubuntuone-client-gnome gone :)
[21:25] <dobey> (anyway, i'm gone now. thanks.)
[21:29] <infinity> dobey: Uploaded.
=== salem_ is now known as _salem
=== cmagina is now known as cmagina-away
=== JZTech101 is now known as Andromeda
=== Andromeda is now known as JZTEch101
[22:44] <cjwatson> barry: Hum.  Does ./run-tests in lp:click fail for you (you'll need to "./configure && make" first, nowadays)?
[22:44] <cjwatson> barry: I get an outstandingly weird failure: http://paste.ubuntu.com/5869503/
[22:45] <barry> cjwatson: `apt-get purge python-configparser` and try again ;)
[22:45] <slangasek> hah
[22:45] <barry> slangasek: yeah ;)
[22:46]  * slangasek punches configparser in the exception handler
[22:47] <barry> slangasek, cjwatson i had a long chat today with upstream.  most of the failures we saw really are bugs in the code that uses configparser, not in configparser itself.  configglue, but virtue of using configparser broke its api which caused the cascading problems.  virtualenv is at fault here (and it's really insane anyway) but upstream has promised to make configparser more bullet proof
[22:47] <cjwatson> Right - but why am I seeing '/usr/bin/python3.3', '/usr/lib/python2.7/dist-packages/virtualenv.py' ... there?
[22:48] <cjwatson> It's true that purging python-configparser fixes it; I was just put off by what appeared to be attempts to run Python 2 code in Python3
[22:49] <barry> cjwatson: that's virtualenv's insanity.  it re-invokes itself with the version of python its creating the venv for but does it in a python 2 context.  yes, it's fscking nuts, but that's the way it works!  the bullet proofing i mentioned is to make configparser python 3 compatible for exactly this reason, even though it isn't intended to run under python 3 normally (because py3 has the real configparser)
[22:50] <barry> iow, venv will execute some py2 code under py3
[22:50]  * barry boggled
[22:52] <cjwatson> owwwwwwwwwwww
[22:52] <cjwatson> gotcha.  I think. :)
[22:55] <barry> don't ask me *why* it does that ;)
[22:57] <cjwatson> argh freaking python-debian out of sync in pip
[22:57] <cjwatson> barry: remind me how you got click's tests working in python3.2 despite the cheeseshop version of python-debian being confused?
[22:57] <cjwatson> I remember you talking about this but not the resolution ...
[22:57] <barry> virtualenv --system-site-packages ...
[22:57] <barry> ignores pypi for anything you already have installed
[22:58] <cjwatson> ah.  can tox pass that along?
[22:58] <barry> errr, yeahhh.  let me look that up
[22:58] <cjwatson> or do I just need to make the virtualenv by hand first?
[22:58] <barry> cjwatson: http://testrun.org/tox/latest//config.html#confval-sitepackages=True|False
[22:59] <cjwatson> Hm, sitepackages=True already in tox.ini
[23:00] <cjwatson> Oh, maybe this is because my python3.2 build has the wrong site-packages
[23:02] <cjwatson> Much better, woo
[23:02] <cjwatson> Thanks
[23:02] <barry> np!
[23:28] <cjwatson> beuno: Do we have anything anywhere yet about what the click app download arrangements are going to be - URLs etc.?
[23:29] <cjwatson> beuno: ... never mind, just found it on https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex