[00:40]  * thumper lunches
=== matsubara-afk is now known as matsubara
=== Ursinha_ is now known as Ursinha-afk
=== matsubara is now known as matsubara-afk
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
[08:02] <wgrant> noodles775: Are you guys lurking somewhere?
=== almaisan-away is now known as al-maisan
[08:31] <lifeless> wgrant:
[08:31] <lifeless> Branched 10725 revision(s).
[08:31] <lifeless> real    9m29.912s
[08:31] <lifeless> user    5m47.220s
[08:31] <lifeless> sys     0m2.050s
[08:31] <lifeless> we're looking at it
[08:32] <wgrant> lifeless: Is that devel?
[08:32] <wgrant> That's a fair bit better than I thought it was, but that may be because the latency here is tiny, I guess.
[08:47] <noodles775> wgrant: In Flamboyant room atm.
[09:26] <wgrant> bigjools: Why are gutsy and intrepid still accepting PPA uploads?
[09:27] <bigjools> wgrant: forgetfulness?
[09:27] <cody-somerville> Does anybody know how I can get postgresql to stop writing to pgstats.tmp?
[09:27]  * bigjools thinks about making the das:+admin page lp,commercial
[09:28] <wgrant> bigjools: Eww.
[09:28] <wgrant> Aren't there enough ~admins here?
[09:28] <bigjools> wgrant: ?
[09:28] <bigjools> lp.admin is too restrictive
[09:29] <wgrant> Possibly.
[09:29] <bigjools> it's not ad admin function, it should be a distro manager's job really
[09:29] <bigjools> s/ad/an/
[09:29] <wgrant> Possibly.
[09:29] <wgrant> But distro permissions are broken.
[09:30] <bigjools> quite
[10:52] <maxb> EdwinGrubbs: pong from friday
=== al-maisan is now known as almaisan-away
[10:54] <mwhudson> danilos: https://bugs.edge.launchpad.net/launchpad-code/+bug/578331/comments/3
[10:54] <mup> Bug #578331: exporting to bzr seems broken since a few days <Launchpad Bazaar Integration:New> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/578331>
[10:57] <danilos> mwhudson, thanks, how soon can we get this in? I think this is a CP candidate for us
[10:58] <danilos> mwhudson, do you think we should change anything on the translations side as well, or should we just close the rosetta bug there?
[10:58] <mwhudson> danilos: i'd hope to be able to hack something up today
[10:58] <danilos> mwhudson, cool, thanks
[10:59] <mwhudson> danilos: i _think_ it's probably a code task, not a rosetta one
[10:59] <danilos> mwhudson, I guess there's not much sense in fixing all the other branches until the fix is in production
[10:59] <mwhudson> danilos: i guess not
[10:59] <mwhudson> the lock/unlock the branch trick should free up a branch
[10:59] <mwhudson> but that can be done case by case
[11:00] <mwhudson> danilos: have to go do uds stuff now, back in an hour
[11:00] <danilos> mwhudson, right, it'd be nice to have a workaround for users wanting to unblock their translation exports listed there
[11:00] <danilos> mwhudson, sure, thanks
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
[12:43] <mars> gary_poster, can you see any problem with setting haltOnFailure=True if buildbot fails on shell_6 or compile_2?
[12:44] <mars> gary_poster, I really don't see why we should run the test suite if either of those steps die.
[12:46] <gary_poster> mars: on call; sounds ok on face of it
[13:03] <danilos> jtv, regarding traits approach in your setCurrentTranslation branch; I really don't see value in constructing this parameter object, especially since you do it with a separate function on every call
[13:04] <danilos> jtv, also, you are changing getCurrentTranslation to be specific as well, whereas it should be a mirror of setCurrentTranslation and get you a relevant one
[13:04] <danilos> jtv, so, it's "incompatible" change
[13:04] <jtv> danilos: that's where I didn't want to change what we already had, ironically.  :)
[13:05] <danilos> jtv, but you end up doing it by not changing it :)
[13:05] <danilos> jtv, since we are changing the underlying model, we have to change the "public" APIs to work around that change
[13:06] <jtv> I do want that to change, but avoided doing it in this branch.
[13:06] <danilos> jtv, that's why you shouldn't have touched those methods, because they are changed in my branch :)
[13:07] <jtv> As for the traits object: it moved the getattr/setattr dirty work out of setCurrentTranslation, making it easier to read.  Otherwise it's a bunch of variables like "callable to read the other flag on a message"
[13:07] <jtv> danilos: It's no problem to keep those as they are;
[13:08] <jtv> that was just an afterthought since things became simpler
=== almaisan-away is now known as al-maisan
=== matsubara-afk is now known as matsubara
[13:13] <danilos> jtv, right, so please do away with that; if you are trying to use getCurrentTranslation for testing, you probably shouldn't, but instead just check properties on the created/returned translationmessage
[13:14] <danilos> jtv, and with that, you also won't need the 'getIncumbentMessage' on TranslationSideMessageTraits class, since that's what getCurrentTranslationMessage will do
[13:15] <jtv> danilos: that's great... obviously a lot of overlap between what we're doing
[13:15] <danilos> jtv, so, the only thing I see as meaningful in traits is get/setFlag and translations side, up to you if that still makes sense for a separate parameter object class
[13:16] <jtv> danilos: yes, it still does afaic
[13:17] <danilos> jtv, sure, then keep it in :)
[13:17]  * danilos gets some lunch
[13:18]  * jtv considers the same
[13:22] <gary_poster> mars, off call, and looked at your question more carefully.  haltOnFailure=True is the default, I believe.  jml tried to fix this for shell 6 already.  I looked at what he did and it looked correct, but whatever it was didn't actually work.  Please tell me when you find out the error.
[13:22] <gary_poster> I'm surprised that compile 2 is haltOnFailure=False now; that seems more patently obvious that it needs t succeed.  (shell 6 doesn't have to succeed if the revisions are already up-to-date).
=== Ursinha-afk is now known as Ursinha
[13:50] <mars> gary_poster, any idea where I may find jml's shell 6 fix?
[13:50] <cody-somerville> how can I stop someone spamming me with retrying a code import that fails?
[13:51] <cody-somerville> ah, I know
[13:56] <mars> gary_poster, regarding shell 6, it looks like it will succeed even if there are no updates.  {halt,flunk}OnFailure would still work fine.  The step would only stop on real errors.
[13:58] <mars> gary_poster, and consider that stale sourcecode often causes test failures, then I would argue that sourcecode *must* be updated for a particular test run to be considered valid.  Stale sourcecode and passing tests /may/ lead to testcase false passes.
[14:09] <jml> remind me what I did?
[14:15] <jml> StevenK, hello. where are you?
[14:54] <allenap> bac: Hello there, glad you made it :)
[15:06] <gmb> BjornT, can I have your approval on https://code.edge.launchpad.net/~gmb/launchpad/halp/+merge/25058 please? This is a branch that landed on db-devel at the end of last week. I want to merge those changes into devel (they were db-devel specific last cycle but not any more).
[15:07] <gmb> I've merged the revision in which the changes landed from db-devel into devel for this branch to avoid conflicts.
[15:15] <gary_poster> jml, you made a change to lpbuildbot to make a failed update of sourcecode actually fail the build.  It didn't work, for a reason neither of us could figure out.
[15:15] <jml> gary_poster, ahh, ok.
[15:18] <wgrant> bigjools: We may need a further branch to fix some copies. http://paste.ubuntu.com/431607/ will tell us the problematic files, and how much we need to worry.
[15:25] <bac> hi allenap ... thanks
[15:31] <manish> gary_poster, Hey Gary. You have a few minutes to spare?
[15:33] <gary_poster> manish: hey!  honestly, I'm dealing with a couple of high priority issues right now, but I don't want to send you away.  I'm also skeptical of actually being a help to you. ;-) But ask away, and I'll get back to you as quickly as I can.
[15:35] <manish> gary_poster, I think it would be better that I ask you the doubts on the launchpad-dev list. You can answer the doubts in your free time and also those mails would be publicly archived.
[15:35] <manish> gary_poster, You can go ahead with your work. Not something blocking as of now.
[15:35] <gary_poster> manish: ok, great.  thank you again!
=== Ursinha is now known as Ursinha-lunch
[16:46] <BjornT> gmb: if it's just changes that have already landed in db-devel, that's ok. just be prepared to fix any conflicts after merge merge
[16:46] <gmb> BjornT, Thanks, will do.
=== gary_poster_ is now known as gary_poster
=== matsubara is now known as matsubara-lunch
=== beuno is now known as beuno-lunch
[17:38] <EdwinGrubbs> maxb, ping again
[17:39] <maxb> hi
[17:40] <EdwinGrubbs> maxb, hi, I'm having a weird problem with the python-tickcount package in the ~launchpad ppa on lucid. If I run "dpkg -c" on it, it clearly contains a tickcount.so for python2.5, but when I install it, only the tickcount.so for python2.6 gets installed.
[17:40] <maxb> aha
[17:41] <EdwinGrubbs> maxb, btw, I'm running lucid 64bit
[17:41] <maxb> I believe you are experiencing bug 576159
[17:41] <mup> Bug #576159: launchpad-dependencies / rocketfuel-setup does not ensure all launchpad PPA dependencies have been installed  <Launchpad Foundations:Triaged by maxb> <https://launchpad.net/bugs/576159>
[17:41] <maxb> Short version: update all your packages to latest *after* enabling the LP PPA and installing launchpad-developer-dependencies
=== Ursinha-lunch is now known as Ursinha
=== matsubara-lunch is now known as matsubara
[18:07] <EdwinGrubbs> maxb, but I already have it all installed, and I've updated all my packages since then. Should I downgrade something and then uninstall/reinstall launchpad-developer-dependencies?
[18:07] <maxb> You are saying 'apt-get dist-upgrade' does nothign?
=== gary_poster is now known as gary-lunch
[18:08] <EdwinGrubbs> maxb, apt-get dist-upgrade installed some other packages, but it didn't fix tickcount.
[18:10] <maxb> hmm
[18:11] <maxb> Please: dpkg -l python python-minimal python-support, and pastebin
[18:13] <EdwinGrubbs> maxb, https://pastebin.canonical.com/32165/
[18:13]  * maxb != canonical
[18:13] <EdwinGrubbs> I also just noticed that "aptitude update" says "Ign" next to the ppa urls.
[18:14] <EdwinGrubbs> maxb, oops, http://paste.ubuntu.com/431781/
[18:15] <maxb> ugh, the size of the columns has removed relevant info. Can you run dpkg -l .... | cat, which will cause it not to size itself to your terminal?
[18:15] <EdwinGrubbs> sorry, here it is. http://paste.ubuntu.com/431782/
[18:17] <maxb> OK, now I am fairly confused
[18:17] <maxb> the versions all look file
[18:17] <maxb> *fine
[18:19] <EdwinGrubbs> btw, the /usr/lib/pymodules/python2.5 directory didn't even exist. I symlinked it over to /usr/lib/pyshared/python2.5, but it only has .py files and .so files.
[18:19] <maxb> erm
[18:20] <maxb> I would suggest that adhoc symlinking is liable to confuse matters
=== al-maisan is now known as almaisan-away
[18:23] <EdwinGrubbs> maxb, I downloaded and reinstalled python-support and python-tickcount, and now the .so shows up.
[18:23] <EdwinGrubbs> thanks for your help
[18:23] <maxb> ok then
[18:24] <maxb> A bit weird, I recently tested installing into a clean lucid chroot, and it worked fine there
[18:24] <EdwinGrubbs> and pymodules/python2.5 also got generated correctly.
=== beuno-lunch is now known as beuno
=== gary-lunch is now known as gary_poster
[22:11] <thumper> morning
[22:12] <Ursinha> thumper, morning
[22:13] <Ursinha> thumper, let me ask something: is this a known problem? https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1591S1000
[22:14]  * thumper looks
[22:14] <thumper> WTF?
[22:14] <thumper> ah staging
[22:14] <thumper> we need to fix the staging puller script
[22:15] <thumper> Ursinha: not known (is now)
[22:28] <Ursinha> thumper, want me to file a bug ?
[22:28] <thumper> Ursinha: yeah, sure
[22:28] <thumper> it is just a config change in the cron scripts on staging
=== matsubara is now known as matsubara-afk
=== Ursinha is now known as Ursinha-afk