[00:57] <lifeless> man, where did the day go
[00:58] <mwhudson> lifeless: good question
[00:58] <poolie> hello lifeless, mwhudson
[00:58] <mwhudson> poolie: i've gotten a bit confused, sorry to say -- do you want me to land your mbp-trivial branch?
[01:01] <poolie> i'd like someone to do it
[01:01] <poolie> i don't think i have the right to land myself atm
[01:01]  * thumper -> modaks for lunch
[01:01] <lifeless> are you in ~launchpad? if so you should modulo someone putting your key in pqm
[01:02] <lifeless> which is a simple losa request :)
[01:02] <mwhudson> poolie: i'll land it then
[01:02]  * poolie looks
[01:02] <poolie> also, landing is kind of a many-roundtrip thing
[01:02] <poolie> and it seems to mess up my "i'll spend one day on launchpad" plan
[01:03] <lifeless> yeah, I can get that
[01:03] <mwhudson> well, if you get in the position that you can run ec2 land yourself it's a lot easier
[01:03] <mwhudson> but yes
[01:03] <lifeless> happy to do for you in general, just noting that policy wise, you should be allowed
[01:03] <poolie> i realize it may be partly my fault but the mean latency is somewhere over 24h
[01:03] <poolie> s//well over
[01:04] <poolie> thanks
[01:04] <poolie> just got a "thankyou" mail for bzr, specifically for mgz
[01:04] <poolie> and also for gnukeyring
[01:04] <poolie> what a nice way to start the week
[01:04] <poolie> btw i'm sure this landing latency will get better
[01:06] <mwhudson> i was saying to jml the other day that one thing i miss least from the days of officially being a launchpad hacker is the battle to land branches
[01:06] <lifeless> I've figured out why we get N running librarians
[01:06] <mwhudson> poolie: your branch is playing in pqm now
[01:06] <lifeless> mwhudson: you're now doing that what, 50% of the time ;P
[01:06] <lifeless> we get N running librarians because:
[01:06] <lifeless>  - we use atexit (which isn't what you might think it is)
[01:06] <mwhudson> lifeless: only when cody-somerville is being slow at reviewing branches
[01:07] <lifeless>  - the existing kill-stuff code looks in $root/librarian.pid
[01:07] <lifeless>  - we rm -rt $root
[01:07] <lifeless> s/rt/rf/
[01:07] <lifeless> mwhudson: oh, so your soyuz-skin is going into a different tree?
[01:07] <lifeless> or you're working on this bash stuff?
[01:07]  * lifeless twists the knife
[01:07]  * mwhudson goes for a walk in the sun instead
[01:08] <lifeless> mwhudson: I am genuinely interested in the soyuz skin project, its very unclear to me where its at.
[01:08] <mwhudson> lifeless: yes, a fair bit of bash hacking
[01:08] <mwhudson> lifeless: i think "a bit stalled" would be the current summary
[01:08] <mwhudson> lifeless: salgado would know more than me
[01:08] <mwhudson> back in a bit
[01:09] <poolie> heh, how can anyone not be in ~launchpad-users? :)
[01:09] <lifeless> kk
[01:09] <poolie> (i realize it's a list)
[01:09] <poolie> i am in ~launchpad
[01:09] <lifeless> we could add new accounts to it automatically
[01:09] <poolie> can i send a mail or should you?
[01:09] <poolie> an RT, i mean
[01:09] <lifeless> then they would get a prompt to subscribe straight away.
[01:09] <lifeless> poolie: you should; usual thing.
[01:10] <poolie> k thanks
[01:17] <lifeless> oh yeah, I know where the day went. daylight savings.
[01:17] <lifeless> nz is UTC+13 now
[01:19] <lifeless> and with my typical early start
[02:05] <lifeless>  5 files changed, 60 insertions(+), 85 deletions(-)
[02:05] <lifeless> \o/
[02:16] <lifeless> mwhudson: and here is your monday present https://code.edge.launchpad.net/~lifeless/launchpad/test/+merge/36674
[02:34] <michaelh1> Afternoon.  Can access the blueprints on a project from the API?
[02:34] <poolie> hi michaelh1, i think you can
[02:35] <mwhudson> uhh
[02:35] <beuno> I thought blueprints didn't have an API at all?
[02:35] <mwhudson> i don't think blueprints are _very_ exposed
[02:35] <beuno> :)  hi mwhudson!
[02:35] <mwhudson> hi beuno
[02:36] <michaelh1> poolie: I see there's a 'specification' object in the API docs but no 'specifications_collection' on a project
[02:36] <lifeless> james_w put them up on the API
[02:36] <lifeless> they are probably still quite vestigial
[02:36] <mwhudson> certainly, there is a lot of permission-by-view in the blueprints code, so i really hope those bits aren't exposed
[02:36] <lifeless> probably it is
[02:36] <lifeless> acid test on whether stallman was right about needing passwords
[02:37] <mwhudson> seems like the only bit that's exposed is for linking/unlinking branches and specs, probably for ajax love to that feature?
[02:37] <ajmitch> mwhudson: I think that's what was blocking that branch from being merged, last I saw it was still a work in progress
[02:37] <wgrant> mwhudson: That was my vague recollection, yes.
[02:38] <mwhudson> michaelh1: you can ask the linaro infrastructure team to work on this if you like :-)
[02:38] <lifeless> mwhudson: but they might go blind :P
[02:38] <michaelh1> mwhudson: I might do.  I'm looking for some type of meta blueprint that has others attached to it.  The current Launchpad UI makes this hard to navigate
[02:39] <ajmitch> lifeless: I would say "it's not that bad", but then again it's why I didn't go any further with it :)
[02:39] <lifeless> ajmitch: its primarily a) old and b) unmaintained.
[02:39] <wgrant> c) pointless
[02:39] <ajmitch> both of which don't really lend themselves well to having someone jump in & do a few fixes
[02:39] <lifeless> its currently unique in LP
[02:40] <wgrant> lifeless: Howso?
[02:40] <lifeless> I have sympathy for the view that blueprints and bugs should be facets of one thing; but at the moment thats the way it is
[02:40] <lifeless> wgrant: ^
[02:40] <wgrant> lifeless: How is it unique?
[02:40] <lifeless> wgrant: dependencies primarily
[02:40] <wgrant> Ah.
[02:40] <wgrant> Yes.
[02:40] <lifeless> also some of the reports
[02:41] <wgrant> It also shells out to dot.
[02:41] <wgrant> I died inside when I saw that.
[02:41] <ajmitch> on page view?
[02:41] <wgrant> Yes/
[02:41] <ajmitch> oh my
[02:41] <lifeless> old skool
[02:42] <persia> Very
[02:42] <ajmitch> I bet that won't fall under the 99% rule very easily
[02:42] <lifeless> for rendering?
[02:42] <lifeless> mmm separate resource I think; also deleted nw.
[02:42] <ajmitch> ok
[02:42] <lifeless> (At least, i think it was deleted)
[02:43] <wgrant> I didn't think it was deleted.
[02:43] <wgrant> Maybe the full project overview thing.
[02:43]  * ajmitch woudl think it could take awhile to do if it was a large graph of blueprints, and that page hadn't been hit recently
[02:43] <wgrant> https://blueprints.edge.launchpad.net/soyuz
[02:43] <mwhudson> fortunately it's also totally unreadable when there are a lot of blueprints
[02:43] <wgrant> Launchpad also doesn't know how to capitalise its own name, apparently.
[02:44] <ajmitch> wgrant: that's amusing, given how https://blueprints.edge.launchpad.net/launchpad-project links to it
[02:45] <wgrant> Indeed.
[02:46] <wgrant> The blueprint listing reminds me of the good old days.
[02:46] <wgrant> Of the really old 2005-ish theme.
[02:46] <ajmitch> that was stylish
[02:46] <lifeless> hey
[02:46] <ajmitch> at least compared to the ubuntu bugzilla :)
[02:47] <lifeless> anyone know how to get buildout working outside of LP?
[02:53] <mwhudson> lifeless: svn cat <some url> > bootstrap.py; python bootstrap.py
[03:02] <james_w> the branch is blocked on making the model safe to expose
[03:03] <james_w> I have a partial branch to do that, I think the main thing before it can be reviewed is some permission checks which involve moving some code from security.py to the model
[03:06] <lifeless> mwhudson: I meant in zope.testing specifically
[03:28] <lifeless> mwhudson: this is what I was meaning:
[03:28] <lifeless> http://pastebin.com/Q2KbG7rs
[03:29] <ajmitch> oh, that problem - I ran into that in the weekend & didn't go any further
[03:29] <mwhudson> lifeless: that looks odd
[03:29] <lifeless> mwhudson: this happens every time I attempt to use buildout.
[03:29] <lifeless> mwhudson: I've a pretty firmly entrenched opinion now.
[03:29] <mwhudson> there are some arguments you can pass to bootstrap i think...
[03:30] <ajmitch> lifeless: this is why I was complaining in #nzpug this morning about buildout :)
[03:30] <lifeless> it trying to write to /usr/local is spectactularly naughty.
[03:30] <mwhudson> lifeless: bootstrap.py --eggs=eggs maybe
[03:31] <lifeless> mwhudson: this isn't in the LP tree, I don't see why that would help ?
[03:31] <mwhudson> lifeless: i think this will make it install eggs in a directory called 'eggs'
[03:31] <lifeless> its finding my existing setuptools deb package, then going nana
[03:31] <mwhudson> lifeless: rather than /usr/local
[03:31] <lifeless> mwhudson: ah, interesting.
[03:31] <mwhudson> lifeless: i'm cargo culting, clearly, but try it
[03:31] <lifeless> sure
[03:32] <lifeless> I probably shouldn't be so negative about it
[03:32] <lifeless> except that it seems to be a net time consumer
[03:33] <mwhudson> i have mixed feelings about buildbot
[03:33] <mwhudson> when it works, it's quite ok
[03:33] <mwhudson> when it doesn't, it's ****ing mysterious at times
[03:33] <lifeless> robertc@lpdev:~/zope.testing$ python ./bootstrap.py --eggs=eggs
[03:33] <lifeless> Error: Invalid option --
[03:33] <mwhudson> um
[03:33] <mwhudson> i meant buildout there
[03:33] <mwhudson> although both statements are accurate
[03:34] <mwhudson> !?
[03:34] <lifeless> mwhudson: spectacular
[03:34] <lifeless> :)
[03:35] <lifeless> $ python ./bootstrap.py bootstrap --help
[03:35] <lifeless> Getting distribution for 'distribute'.
[03:35] <lifeless> ...
[03:35] <lifeless> see under 'above failure'
[03:35] <mwhudson> maybe the bootstrap.py in the zope.testing tree is very old?
[03:35] <lifeless> http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=error+%2Fusr%2Flocal%2Flib%2Fpython2.6%2Fdist-packages%2Fsetuptools-0.6c11-py2.6.egg-info%3A+Permission+denied
[03:36] <lifeless> its not an unknown thing :)
[03:36] <mwhudson> yeah i tried that too :)
[03:38] <lifeless> I think this is a sign that I should migrate my lappy to maverick too
[03:38] <lifeless> so, I shall.
[03:39] <wgrant> Beware the wallpaper.
[03:39] <lifeless> wgrant: Doom3 >> all other.
[03:40] <wgrant> Hm?
[03:42] <lifeless> I've not had a default wallpaper in many many many years
[03:42] <lifeless> my desktop does, so I already know what the mav paper looks like.
[03:43] <wgrant> Ah.
[03:43] <mwhudson> i see my desktop about once a month
[03:44] <wgrant> I occasionally empty a workspace, and then am blinded.
[03:46] <lifeless> the moire on my 1600x1200 crt is quite spectacular
[05:19] <lifeless> wheee wow dpkg is slow these days.
[05:19] <lifeless> fsync for the -pain-
[05:19] <lifeless> [on ssd no less]
[06:31] <poolie> https://bugs.launchpad.net/bugs/648504 has a complaint about the dupefinder being too tight now
[06:31] <_mup_> Bug #648504: exceptions.NotImplementedError: should resend request to http://feeds.edge.launchpad.net/bazaar/, but this isn't implemented <Bazaar:New> <https://launchpad.net/bugs/648504>
[06:31] <poolie> i realize it's a tradeoff
[06:37] <spiv> What would be magic would be some sort of "yes this traceback and version match (and this traceback isn't a symptom of multiple separate bugs)" dupe-matching.
[06:37] <spiv> But there's a fair bit of handwaving involved in describing exactly what would be awesome there :)
[06:44] <wgrant> spiv: apport does that.
[06:44] <wgrant> The retracers compare stack traces and dupe bugs as appropriate.
[06:44] <spiv> wgrant: not exactly
[06:45] <spiv> Right, after I've either filed my bug or, as a reporter, decided one of the suggested bugs is probably the same even though I'm not a developer and hardly qualified to know.
[06:46] <wgrant> It has been argued that the dupefinder should be disabled for crashes, since the retracers can match them much more accurately.
[06:46] <spiv> I've been regularly asked by Launchpad recently to judge if random Xorg crash reports from other people with vaguely similar laptops are the same as mine, whic his a bit erid.
[06:46] <spiv> s/erid/weird/
[06:46] <spiv> Almost as weird as that typo!
[06:46] <spiv> Yeah, that would make sense to me.
[08:00] <jtv> mwhudson: did you see the oopses for the recipe branch build?  BuildFarmJob without specific_job.
[08:00] <jtv> (See the launchpad-dev list.)
[08:01] <wgrant> jtv: You sure it was a recipe build?
[08:01] <jtv> wgrant: BuildFarmJob.job_type == 3
[08:01] <jtv> That's a RECIPEBRANCHBUILD, according to my map.
[08:02] <wgrant> Ah.
[08:02] <wgrant> That kind of BuildFarmJob.
[08:03] <wgrant> Errrrrrrr.
[08:03] <wgrant> Hwhat?
[08:04] <wgrant> Oh, wait, misread.
[08:04] <wgrant> Fail.
[08:05] <wgrant> Is there a packagebuild with build_farm_job=1977174?
[08:06] <cody-somerville> Is anyone here familiar with how pip interprets package versions?
[08:06] <wgrant> I know just enough to not drown. What's the issue?
[08:08] <cody-somerville> wgrant, sent you pm since its offtopic
[08:40] <adeuring> good morning
[09:03] <poolie> does the lp webapp have a default log file in production?
[09:07] <bigjools> good morning
[09:07] <poolie> hi bigjools
[09:07] <thumper> bigjools: morning / evening
[09:07] <poolie> hi jml ?
[09:08]  * bigjools has too much email
[09:10] <wgrant> Morning bigjools.
[09:10] <bigjools> hello William
[09:11] <mrevell> Hello
[09:11] <bigjools> morning mrevell
[09:12] <wgrant> bigjools: Ubuntu wants ubuntu-release to be able to accept from UNAPPROVED in the Release pocket, and ubuntu-sru from UNAPPROVED in Proposed. Do you have any objections to extending queue admin perms to include optional pocket and status restrictions?
[09:13] <bigjools> wgrant: provided I see a bug filed with a comment from Colin, that's fine
[09:13] <wgrant> bigjools: Great, thanks.
[09:14] <bigjools> wgrant: however I don't want those values hard-coded
[09:14] <bigjools> I guess we can do it through ArchivePermission
[09:14] <wgrant> bigjools: Certainly not. I'll just extend ArchivePermission to have upload_status and pocket fields.
[09:14] <wgrant> Like we do with components already.
[09:14] <bigjools> cool
[09:14] <bigjools> yay for nullable FKs
[09:48] <jml> hello everyone.
[09:57] <bigjools> morning jml
[09:58] <jml> bigjools, hi
[09:59] <bigjools> jml: did you do any more work on the tests over the weekend?
[09:59] <jml> bigjools, fwiw, I didn't get around to buildd-slavescanner.txt. I got fed up with having to do that TwistedLaunchpadZopeless dance so I started work on Deferred support for testtools.
[09:59] <jml> bigjools, and then my batteries ran out.
[09:59] <bigjools> heh
[09:59] <bigjools> you need to run powertop
[09:59] <jml> bigjools, I wanted to land a branch that killed buildd-slavescanner independently of the refactoring
[09:59] <jml> bigjools, I do so from time to time
[09:59] <bigjools> something's screwing you over
[09:59] <jml> bigjools, I think it was Chrome, actually
[10:00] <bigjools> npviewer.bin?
[10:00] <jml> no, I don't think so.
[10:01] <wgrant> :( A power problem not caused by Flash?
[10:01] <bigjools> jml: ok did you figure out those adaptation errors?
[10:01] <jml> bigjools, no. just focused on buildd-slavescanner
[10:01] <bigjools> ok
[10:01] <jml> bigjools, only had 90mins of hacking time :)
[10:01] <bigjools> so you didn't change any of the builderslave-resume branch?
[10:02] <bigjools> (which appears to  be the new integration branch!)
[10:04] <jml> bigjools, I'll push up what I've got.
[10:04] <jml> bigjools, I don't think I did.
[10:04] <bigjools> ok
[10:04] <bigjools> I will spend the next million hours reading email then get back to that branch
[10:19] <lifeless> yay upgrade glitches
[10:21] <jml> lifeless, yay indeed.
[10:23]  * bigjools WTFs at the wtf bug tag
[11:24] <bigjools> StevenK: will i-f-p skip disabled arches?
[11:25] <jml> stub, will -vvv on ./bin/test also give transaction debug messages?
[11:26] <stub> jml: Doubtful - I don't think test runners can use the python logging module as that is being used by the tests they are running.
[11:26] <jml> stub, cool. checking since we run w/ -vvv on ec2.
[11:26] <StevenK> bigjools: Doubtful, since that didn't exist when I was working on it.
[11:27] <lifeless> stub: jml: You could sensible capture debug messages to a detail.
[11:27]  * lifeless crashes completely.
[11:27] <bigjools> StevenK: ok can you add it to the list please, it's critical to get fixed before natty
[11:27] <wgrant> Do we have a rollout before natty?
[11:27] <wgrant> Doesn't the current i-f-p stuff live in db-devel?
[11:28] <bigjools> we don't have a db rollout
[11:28] <stub> lifeless, jml: Yes. We could make bin/test add a handler to getLogger('txn') that emits messages where we want, although we might have to reset it after every test in case the test tore things up.
[11:28] <lifeless> stub: not bin/test - use a Fixture and register it with self.addDetail.
[11:29] <StevenK> wgrant: No
[11:29] <StevenK> bigjools: Right, I'll sort it out tomorrow
[11:29] <wgrant> StevenK: Ah, good.
[11:29] <bigjools> StevenK: thanks - I'll add a card now
[11:29] <StevenK> It should be quite quick
[11:29] <jml> stub, I think lifeless is talking about the facility in TestCase where you can add details to test output in response to certain events (generally exceptions)
[11:29]  * wgrant pokes at apt-ftparchive.
[11:30]  * bigjools gets caffeine
[11:30] <stub> Right. We could do it, but we haven't done it :)
[11:31] <StevenK> bigjools: It can be worked around with application of -a
[11:31] <stub> As it emits a log message when the transaction starts, this might be useful for tracking down code that holds open long running transactions which can be sucky (such as the transaction being opened by Storm refreshing a property...)
[11:35] <wgrant> Gnargh lucilleconfig kill kill.
[11:35] <wgrant> Oh wtf.
[11:39] <wgrant> bigjools: We need to stop creation of new arch-indep publications before maverick, or we'll need to do some manual cleanup before maverick gets changed to CURRENT.
[11:40] <wgrant> Since we need p-d-r to remove all the files.
[11:41] <bigjools> wgrant: gnar
[11:42] <wgrant> Hm, except that p-d-r doesn't obviously respect the Release pocket freeze, so it might be OK to have it remove them afterwards.
[11:43] <bigjools> I'd rather it worked now
[11:45] <wgrant> At least there appear to only be two places that create arch-indep publications.
[11:47] <wgrant> So, fix those two locations, tweak lucilleconfig to exclude disabled DASes, Delete existing publications, and we may be able to get maverick into a sane state.
[11:47] <wgrant> I think.
[11:50] <wgrant> Has the on-disk archive ever been compared with what Soyuz thinks should be there?
[11:50] <bigjools> not to me knowledge
[11:50] <bigjools> my*
[11:52] <wgrant> p-d-r looks buggy, so I suspect there's a lot of cruft in the pool.
[12:06] <deryck> Morning, all.
[12:16] <jml> deryck, good morning
[12:19] <bigjools> wgrant: fyi, I just filed bug 648715
[12:19] <_mup_> Bug #648715: Binary publications should not be created for disabled architectures <soyuz-publish> <Soyuz:Triaged> <https://launchpad.net/bugs/648715>
[12:33] <gmb> Okay, I know that I know the answer to this, but I can't remember what it is for the life of me: "psycopg2.InterfaceError: connection already closed" <-- what is that and why is it happening? Any ideas?
[12:35] <wgrant> gmb: Your PostgreSQL may be in recovery mode.
[12:35] <wgrant> Check its logs.
[12:37] <wgrant> Hm, no, that's a different thing.
[12:48] <gmb> wgrant, It is a pg problem though; make schema is blowing up. I'll dig into it further. Thanks for the pointer anyway.
[13:07] <jml> danilos, hi
[13:07] <danilos> jml, hi
[13:08] <jml> danilos, marjo has asked for a feature along these lines: "Enable translators working in Launchpad to seamlessly submit those translations to the upstream project to which they apply. "
[13:08] <jml> danilos, I thought we did that already.
[13:09] <danilos> jml, well, "seamlessly" is very hard... that's next on our list after we've got the "seamless" imports going
[13:09] <danilos> jml, ("next on our list" if we are to continue on our bridging-the-gap theme for translations)
[13:09] <danilos> jml, what we've got know are partial tools that enable people to do lot of that work manually
[13:09] <danilos> s/got know/got now/
[13:10]  * bigjools notices the EINTR bug that poolie fixed and doesn't know whether to laugh or cry
[13:10] <jml> danilos, you guys are working on smoother imports now?
[13:11] <danilos> jml, "seamless" would be to have a button saying something like "submit these translations upstream" where they'd get into the upstream workflow for handling translations
[13:11] <danilos> jml, well, it's more like "we are still working on that"
[13:11] <danilos> jml, it's been going pretty slow
[13:11] <danilos> jml, "smoother imports" is getting translations directly from upstream into ubuntu
[13:12] <jml> danilos, with what degree of interaction from users / admins?
[13:14] <danilos> jml, two differing steps: 1. get upstream translations into LP upstreams (requires code imports and admin interaction for now, but already possible); 2. set up packaging links between upstream series in LP and Ubuntu sourcepackages
[13:14] <danilos> jml, for 1, we want to improve the process further once we have the groundwork laid out to support actual sharing of translations between ubuntu and upstreams
[13:15] <jml> danilos, I think Registry has done a lot of work on making code import, project registration & linking easier. Not 100% sure about series branches specifically.
[13:15] <danilos> jml, 1. already works for a wide range of intltool- and gettext-based upstreams, but requires admin set-up which is not nice
[13:16] <jml> danilos, admin set up per package?
[13:16] <danilos> jml, I know, they are doing a good job with splitting the "official_*" tags as well
[13:16] <danilos> jml, in general, for translations it's pretty simple to set up so we just need to follow the same pattern and come up with good privilege models
[13:17] <danilos> jml, basically, set-up for translations should only include "this has external translations, IMPORT THEM" and "link the series with sourcepackage"
[13:17] <danilos> jml, "link the series" step is pretty nicely handled by registry folks already
[13:17] <jml> cool.
[13:18] <danilos> jml, though, it'd be nice to integrate into one step if someone's interested in doing it all in one code (i.e. integrate set-up code branches, turn the translation imports on, link to source packages steps)
[13:19] <danilos> s/in one code/in one go/
[13:19] <danilos> typing ahead of me :)
[13:19] <jml> danilos, I guess there are two potential issues with having them split up: multiple POSTs, and users not necessarily knowing what the next step is
[13:20] <danilos> jml, well, there's always ajax, and there's always code-reuse :) if we make those bits of pages nice reusable ajaxy "portlets" (not necessarily in zope sense, but just bits that can be plugged into other pages), it would make a nicer experience without increasing our workload too much
[13:21] <danilos> jml, fwiw, some of these things might already be easily reusable, I haven't looked
[13:21] <jml> danilos, you said there's some ground work that needs to be done. I had thought you'd already done it.
[13:21]  * jml nods
[13:21] <danilos> jml, well, we've got a huge feature branch in progress that I said is going slower than expected: that's to actually get upstream translations shared with Ubuntu directly
[13:22] <danilos> jml, we are nearing completion of that bit, but likely not this cycle after all
[13:22] <jml> danilos, I understand :) huge feature branches being what they are.
[13:24] <jml> danilos, with the other side, sending translations upstream seamlessly -- is there any reason to *not* do it after you've done the inbound direction?
[13:26] <danilos> jml, not really, it's just a lot of work because many upstreams will have differing needs... but we should attack it in a similar way, go for big "easy" upstreams first (gnome, kde, translationproject), then for big "hard" upstreams (mozilla, openoffice) and so forth
[13:28] <jml> danilos, cool
[13:28] <jml> danilos, it's rather nice that our broader plans happen to mesh with what Ubuntu says they need :)
[13:29] <danilos> jml, yeah, I am very happy with that as well :)
[13:35] <jml> danilos, thanks for your time. I'll let Marjo know our current plans.
[13:37] <danilos> jml, cheers
[14:17] <jml> flacoste!
[14:17] <flacoste> hi jml!
[14:17] <jml> flacoste: welcome back :)
[14:17] <flacoste> hello fellow launchpadders!
[14:17] <noodles775> Hey! Welcome back flacoste
[14:18] <flacoste> hi noodles775! are still a launchpadder ;-)
[14:18] <flacoste> or did you move on already?
[14:18] <flacoste> not that I wouldn't greet you if that was the case :-)
[14:18] <noodles775> heh, yep - will be switching sometime soon, but just working on some soyuz UI work beforehand.
[14:19] <noodles775> (And I'll still be here on #launchpad-dev anyway)
[14:21] <bigjools> hey flacoste, flumper will be pleased to see you :)
[14:21] <flacoste> bigjools: yeah, he told me that he was looking forward to give me my job back!
[14:21] <flacoste> you guys gave him a hard time?
[14:22] <bigjools> depends who "you guys" is I guess :)
[14:24] <deryck> hey wb flacoste!
[14:25] <flacoste> hi deryck!
[14:31] <wgrant> bigjools: Disabling an arch is somewhat problematic. If you disable it (to prevent new publications) then mark its publications deleted, it never gets published to actually remove them.
[14:31] <bigjools>  /o\
[14:31] <bigjools> grar
[14:31] <wgrant> But I suppose we won't be doing this until powerpc dies in at least a couple of releases.
[14:32] <bigjools> ?
[14:33] <wgrant> bigjools: We shouldn't be disabling another DAS until powerpc dies. And that will be a while.
[14:33] <wgrant> And sparc/ia64 need manual cleanup anyway, so it's not too bad.
[14:33] <bigjools> ok
[14:33] <bigjools> right
[14:33] <wgrant> Hmmm.
[15:00] <cr3> buildout question: is there a way to leverage buildout someone to build against package versions available in a particular release to make sure the code will work on that release?
[15:04] <jml> huh?
[15:06] <jml> sinzui: you around?
[15:06] <sinzui> I am
[15:07] <jml> sinzui: there have been some requests about blueprints on the stakeholder list. I have this feeling that you're the right person to talk to to get a sense of difficulty of implementation
[15:07] <sinzui> jml :( Am I really the last remaining engineer to have hacked on blueprint?
[15:08] <jml> sinzui: I don't know! You just have a blueish tinge to your aura.
[15:09] <sinzui> I can help. I am pretty knowledgeable of the bug reports that often underly a blueprint feature request
[15:09] <jml> sinzui: cool.
[15:09] <jml> sinzui: what we want, probably, is easy ways to get a list of blueprints that are assigned to members of a given team
[15:11] <sinzui> That sounds a lot like my proposal to find the intersection of items assigned to a team for a milestone. I really would like a common way to say I want to see the items for the members of a team for any structure
[15:11] <cr3> jml: what that "huh" for me?
[15:12] <jml> sinzui: yes, that would be ideal.
[15:12] <jml> cr3: I guess when you say "release" you're talking about something other than a release of Launchpad.
[15:12] <cr3> jml: sorry, yes, I meant release of Ubuntu
[15:13] <jml> cr3: the whole point of buildout is that you are insulated from the underlying OS.
[15:13] <jml> cr3: well, maybe that's the whole point.
[15:13] <cr3> jml: that is indeed a point but I figured it would also be used to couple with a particular OS
[15:14] <cr3> jml: for example, I happen to used a dependencies branch from where buildout can only get dependencies, nowhere else. I use this as a snapshot of what is known to work, rather than relying on the latest code. I believe launchpad does the same under source-dependencies or somesuch
[15:16] <cr3> jml: however, if that list of packages were taken from the release of an OS, that would provide somekind of predictability that it should work on the OS. the problem with that is that: 1. the orig.tar.gz files on archive.u.c are named funny; 2. those files are also not quite what's on the release of the OS.
[15:16] <cr3> jml: so, perhaps another approach would be to bzr branch lp:ubuntu/release/dependency instead of using tarballs
[15:17] <cr3> jml: I was hoping this was already attempted by someone so that I could learn from their experience rather than wasting time myself finding out there's a real problem
[15:21] <jml> cr3: perhaps. you might also want to ask on general zope channels.
[15:30] <jml> abentley, jelmer: where are we at with being able to import non-master git branches?
[15:31] <abentley> jml: it's not something I've been following.
[15:32] <jml> abentley: np. just picking on you as a visible code team member :)
[15:33] <abentley> jml: the issue is that bzr-git is tied into the standard Bazaar branch behaviour, and that doesn't support colocated branches.
[15:33] <abentley> jml: so someone from the Bazaar team could update you on colocated branch support.
[15:34] <jml> abentley: ta. I'll mosey on to #bzr.
[15:52] <deryck> *sigh*
[15:52] <deryck> I wish I had a notification system that would ping me -- "the builders are up and green.  go for it! now!"
[15:54] <wgrant> Don't worry, there's still gambling involved -- if you're lucky we'll be in testfix again by the time EC2 finishes :)
[15:54] <deryck> heh
[15:55] <deryck> My statement presumed I had already had a couple ec2 failures and was prepared to go to pqm directly.
[15:55] <wgrant> Ah.
[15:56] <wgrant> Thus ensuring that the cycle continues.
[15:56] <deryck> maybe.  In this case, I had a translations windmill test that failed in ec2, and I ran locally with no issues.  So submitted directly.
[16:02] <jml> sinzui: hi
[16:02] <sinzui> hi jml
[16:08] <danilos> deryck[lunch], it might be a test that could be helped with a longer timeout somewhere for ec2 runs, it's useful if you file a bug so we can look at it and close it as 'invalid' because we can't reproduce it... I mean, perhaps increase a timeout for a page load or two if it's a clear-cut case like that
[16:33] <jml> noodles775: do I remember wrongly, or were you looking at generic comments code recently?
[16:33] <noodles775> jml: Yes I was.
[16:34] <abentley> jml: I was, too.
[16:34] <jml> ooh.
[16:34] <jml> well, my question to both of you...
[16:34] <jml> ted was asking about attachments on MPs
[16:35] <jml> I thought this was roughly analogous to sharing comments code between bugs & MPs.
[16:36]  * noodles775 didn't realise the lp.services.comments code was used by bugs yet?
[16:36] <jml> I don't know if it is
[16:36] <jml> I'm asking you :)
[16:37] <jml> I guess not then.
[16:37] <noodles775> AFAICS, the distroseriesdifference comments were the first re-use, but abentley might know more.
[16:38] <abentley> jml: I'm pretty sure the display of comments is shared between bugs and merge proposals.
[16:39] <noodles775> abentley: grep for "from lp.services.comments"
[16:39] <noodles775> In db-devel I see only code and (now) registry (for the distroseriesdifferences)
[16:39] <stub> Do we ever delete Revisions? Might we ever?
[16:40] <abentley> rockstar: didn't we work on sharing comments code with bugs?
[16:40] <noodles775> jml: sorry, what was your question?
[16:41] <jml> noodles775: I still haven't formulated it yet :)
[16:41] <rockstar> abentley, I think thumper did something like that.
[16:42] <jml> perhaps, a) how different are MP comments and bugs comments at the code level?
[16:42] <jml> and b) how easy would it be to extract the bugs attachment thing and make it re-usable
[16:43] <noodles775> jml: don't MP comments already support attachments?
[16:43] <jml> noodles775: I think there's no web UI for it
[16:43] <wgrant> They're also implemented rather differently.
[16:44] <wgrant> MPs just look at extra MessageChunks.
[16:44] <wgrant> Bugs have explicit BugAttachments created from MessageChunks.
[16:51] <rockstar> abentley, jml, noodles, I'm pretty sure BjornT and thumper talked about how to unify them.
[16:52] <noodles775> jml: but fwiw, I don't see why the UI code couldn't be shared in lp.services.comments
[16:52] <jml> rockstar: noodles775: thanks.
[16:54] <cr3> out of curiosity, where does the name "assets" come from in respect to static css files seem to be built?
[16:55] <noodles775> Night all.
[17:59] <maxb> [Merge] lp:~mterry/gnome-control-center/ubuntu-2.32.0 into	lp:~ubuntu-desktop/gnome-control-center/ubuntu
[17:59]  * maxb is deeply confused why ~vcs-imports got attached as a reviewer to that
[18:03] <bdmurray> Is there a convenient way to get <h1> from browser.contents in a test?
[18:09] <deryck> bdmurray, it's just beautiful soup underneath, so can't you do browser.contents.h1 or browser.h1 to get the first h1?
[18:19] <bdmurray> deryck: that didn' work out so well
[18:22] <deryck> bdmurray, have you seen lib/canonical/launchpad/doc/pagetest-helpers.txt ?  Nothing on h1 specifically, but might help you think about how to get at the content you want.
[18:22] <jml> findByTag('h1'), perhaps?
[18:25] <deryck> bdmurray, also the README and REFERENCE in lib/canonical/launchpad/pagetests might help.
[18:25] <bdmurray> deryck: thanks
[18:46] <lifeless> moin
[18:47] <mars> morning lifeless
[18:49] <lifeless> hmm, no gary
[18:49] <jml> lifeless: good morning.
[18:49] <jml> lifeless: you're up bright and early
[18:49] <lifeless> jml: daylight savings
[18:49] <mars> lifeless, gary won't be back until Wednesday
[18:49] <lifeless> mars: darn
[18:49] <lifeless> I have this buildout problem ...
[18:50] <jml> lifeless: oh. nice.
[18:51] <mars> lifeless, what is the problem?
[18:51] <mars> lifeless, I may be able to help, having set up buildout for a project or two recently
[18:52] <lifeless> robertc@lpdev:~/zope.testing$ python ./bootstrap.py
[18:52] <lifeless> After install bootstrap.
[18:52] <lifeless> Creating /usr/local/lib/python2.6/dist-packages/setuptools-0.6c11-py2.6.egg-info
[18:52] <lifeless> error: /usr/local/lib/python2.6/dist-packages/setuptools-0.6c11-py2.6.egg-info: Permission denied
[18:52] <lifeless> An error occurred when trying to install distribute 0.6.14. Look above this message for any errors that were output by easy_install.
[18:52] <lifeless> While:
[18:52] <lifeless>   Bootstrapping.
[18:53] <lifeless>   Getting distribution for 'distribute'.
[18:53] <lifeless> Error: Couldn't install: distribute 0.6.14
[18:53] <mars> lifeless, weird.  What bootstrap are you using?  The one from the PyPi zc.buildout page/
[18:53] <lifeless> mars: the one in the source tree
[18:54] <mars> hmm, that should work
[18:54] <lifeless> mars: bzr branch lp:zope.testing; python ./bootstrap.py
[18:54] <lifeless> mars: see what happens?
[18:54] <mars> ah
[18:55] <mars> lifeless, ok.  That may be an old bootstrap.py
[18:55] <mars> checking
[18:55] <benji> lifeless: I /think/ this is cause by distribute trying to fake up a setuptools egg (part of the setuptools impersonation it does); it's somewhat icky, but you should be able to fix it by running your bootstrap as root one time
[18:55] <mars> :(
[18:55] <lifeless> benji: hell no
[18:55] <benji> heh
[18:55] <mars> benji, maybe just 'sudo aptitude install python-distribute'?
[18:56] <lifeless> benji: if it wants to write to /usr/* it die a fiery death.
[18:56] <benji> mars: don't know; maybe
[18:56] <mars> lifeless, yes, it should not be trying that
[18:56] <lifeless> statik: hi; I think google calendar forgot that you're on the other side of the world: its moved the appointment to be the same NZT rather than UTC
[18:57] <lifeless> statik: but, as it got me up for it, want to me now, or in an hour ?
[18:57] <mars> "Copyright (c) 2006 Zope Foundation and Contributors." - yeah, that's an old one
[18:57] <mars> 2006 for bootstrap.py in zope.testing
[18:57] <lifeless> mars: this is in my lp vm - a lucid one; distribute isn't packaged there.
[18:57] <lifeless> mars: so, how does one fix this?
[18:58] <james_w> setuptools in lucid /is/ distribute isn't it?
[18:58] <lifeless> james_w: in maverick maybe
[18:59] <lifeless> python-setuptools                                     0.6.10-4ubuntu1launchpad1                             Python Distutils Enhancements (setuptools compatibility)
[18:59] <mars> mine died on 'fetching distriubte', trying 'python bootstrap.py -vvvv'
[18:59] <mars> it worked that time?
[18:59] <lifeless> no, thats dpkg -l python-setuptools
[18:59] <mars> lifeless, what happens when you run "python bootstrap.py -vvvv" ?
[19:00] <lifeless> so, copying the lp bootstrap into the tree worked
[19:00] <mars> running it again after it faults should not make it run.  That is some weird bug.
[19:00] <james_w> lifeless: http://packages.ubuntu.com/source/lucid/distribute
[19:00] <lifeless> mars: it didn't work at all
[19:01] <lifeless> mars: however many times it was tried; copying the lp bootstrap.py into the tree made it work.
[19:01] <lifeless> james_w: thanks
[19:01] <lifeless> grah
[19:01] <lifeless> bin/test
[19:01] <lifeless> Traceback (most recent call last):
[19:01] <lifeless>   File "bin/test", line 17, in <module>
[19:01] <lifeless>     import zope.testing.testrunner
[19:01] <lifeless> ImportError: No module named testrunner
[19:02] <lifeless> (this is zope.testing :/)
[19:03] <mars> lifeless, yep, they split
[19:04] <mars> lifeless, did you run bin/buildout?
[19:05] <mars> lifeless, I'm checking buildout.cfg in the zope.testing source tree - it knows about zc.recipe.testrunner, so it should work correctly
[19:05] <mars> look at the built parts in that file
[19:06] <mars> bin/test is broken for me too
[19:06] <lifeless> mars: yes, I ran bin/buildout
[19:06] <lifeless> mars: you're serious? zope.testing.testrunner is not in the zope.testing package?
[19:07] <mars> lifeless, yes, they split: zope.testing.testrunner became its own package, IIRC.  Jim Fulton coded it himself?
[19:07] <lifeless> I hope I won't seem shallow when I say that this is madness: I just want to fix layers for lp
[19:07] <jml> z.testrunner 4.0
[19:07] <mars> heh
[19:07] <jml> lifeless: the recent move has slowed me down from contributing upstream to z.testrunner
[19:08] <lifeless> perhaps we should just stop using it
[19:08] <jml> you won't see me arguing
[19:08] <lifeless> jml: I was going to run the test suite, so that the subunit fixing patch could be applied
[19:08] <mars> lifeless, funny - zope.testing's setup.py does not reference zope.testrunner, and neither does the buildout.cfg
[19:08] <mars> I guess someone forgot to add the dependency
[19:09] <lifeless> I wonder how much money I could make, taking bets on how many years before this is packaged properly in Ubuntu
[19:09] <mars> lifeless, add 'zope.testrunner' to the list of files in buildout.cfg [versions], then add 'zope.testrunner' to the [test] part eggs= list
[19:10] <lifeless> mars: zope.testrunner is what I need to be working on I suspect, or both at once.
[19:10] <lifeless> mars: how does one tell buildout to do that ?
[19:11] <mars> lifeless, hack buildout.cfg
[19:11] <mars> here, just a sec
[19:12] <benji> it appears that the comment in zope.testing's [versions] section applies; someone forgot to remove that version pin; if I remove it and rebuild the tests run and pass
[19:12] <mars> lifeless, ^
[19:12] <lifeless> benji: thats in buildout.cfg?
[19:12] <mars> benji, cool.  I think sidnei has commit rights?  For all I know you do too :)
[19:13] <lifeless> wow,
[19:13] <lifeless>   Ran 30 tests with 0 failures and 0 errors in 18.258 seconds.
[19:13] <benji> lifeless: yes
[19:13] <benji> mars: I do.
[19:13] <lifeless> I'm impressed at 0.5 sec each for a lightweight project :><
[19:14] <lifeless> so, I presume these projects needs to be changed in lockstep; whats the blessed way to do that?
[19:14] <lifeless> If it was deb based I'd just set PYTHONPATH and be done with it.
[19:15] <benji> lifeless: >= version requirements in setup.py should be enough
[19:17] <lifeless> benji: I'm not sure that I' asking the correct question.
[19:17] <lifeless> benji: I need to edit code in *both* packages.
[19:17] <lifeless> benji: and run one against the edited other. Not against pypi versions.
[19:17] <lifeless> benji: how would you do this?
[19:17] <james_w> lifeless: develop = . ../other-project
[19:17] <lifeless> james_w: in?
[19:17] <james_w> the one that imports the other
[19:18] <james_w> buildout.cfg in the main section
[19:18] <lifeless> james_w: they import each other
[19:18] <james_w> then in both?
[19:18] <lifeless> ok
[19:18] <james_w> it basically puts ../other-project on PYTHONPATH when you run ./bin/ in the branch you put that setting in
[19:19] <james_w> with extra magic of cours
[19:19] <benji> lifeless: ah, I was talking about making the releases; you can use "develop = /path/to/the/other/thing" in the [buildout] section of each check out to make them see each other (possibly with changes to each [versions] section as well)
[19:19] <lifeless> is there a way to do that without editing a version controlled file?
[19:19] <lifeless> it will be frustrating to have an unclean tree all the time
[19:21] <benji> lifeless: you can use a different config (other than buildout.cfg) and run buildout with -c /my/hacked/up/config.cfg
[19:21] <lifeless> benji: does that have to be a full copy?
[19:21] <james_w> bug 13002
[19:21] <_mup_> Bug #13002: Toshiba battery events flood <acpi-support (Ubuntu):Fix Released by thombot> <https://launchpad.net/bugs/13002>
[19:21] <lifeless> theres no way to just override develop= ? e.g. via .buildout.cfg or something ?
[19:21] <james_w> err bug 613002
[19:21] <_mup_> Bug #613002: Please add a way to optionally extend <Buildout:New> <https://launchpad.net/bugs/613002>
[19:22] <jml> g'night all.
[19:22] <lifeless> night jml
[19:22] <james_w> lifeless: extends =, but you it's editing a version controlled file and you can't commit it
[19:22] <benji> lifeless: or you can give buildout the info on the command line, something like bin/buildout buildout:develop=...
[19:22] <benji> lifeless: yep
[19:22] <benji> (full copy)
[19:51] <rockstar> benji, do you know much about buildout? (I'd ask gary, but he's not around)
[19:52] <benji> rockstar: a bit; what's up?
[19:52] <rockstar> benji, a voice call would be great, if you can spare it.
[19:53] <benji> rockstar: sure; it'll be a few minutes though.  Do you want me to ping you when I'm available?
[19:53] <rockstar> benji, that would be great.
[19:53] <benji> k
[19:55] <lifeless> benji: hi
[19:55] <lifeless> https://code.edge.launchpad.net/~lifeless/zope.testing/subunit/+merge/26638
[19:55] <lifeless> benji: this is going to remain broken forever I think
[19:56] <lifeless> benji: it took me 8 weeks to figure out how to run the test suite; I humbly suggest that practicality should win here.
[19:58] <salgado> Edwin-afk, we seem to have some spurious TeamParticipation entries which might be caused by those changes you did to the code which maintains that table: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/597208 (last comment is the relevant one)
[19:58] <_mup_> Bug #597208: Run cronscripts/check-teamparticipation.py on production and make its output more visible <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/597208>
[19:59] <benji> lifeless: I should be able to take a look in a few hours
[20:08] <malaria> jtv: danilos wanted me to pop here about this bug: https://bugs.launchpad.net/rosetta/+bug/608631
[20:08] <_mup_> Bug #608631: Visual tag to represent narrow non-breaking spaces <diacritic:Invalid> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/608631>
[20:09] <malaria> (anyway, hi everyone)
[20:11] <lifeless> malaria: jtv will be around in about 7-8 hours
[20:12] <malaria> lifeless: ok, it's the same every day?
[20:12] <lifeless> I don't know what you're asking
[20:12] <lifeless> he sleeps like everyone else ;)
[20:13] <malaria> lifeless: of, course, I mean it's because of it's timezone
[20:13] <lifeless> yes
[20:13] <malaria> so I have to schedule the best moment to go back here
[20:26] <benji> rockstar: skype?
[20:26] <benji> or mumble
[20:26] <benji> or smoke signals
[20:26] <rockstar> benji, whoa, the people I needed both responded at the same time.
[20:26] <benji> heh
[20:26] <rockstar> benji, let me chat with sidnei first.  It's possible I may not even need to bug you.
[20:27] <benji> k
[20:35] <rockstar> benji, okay, I do think I want to chat with you.
[20:35] <rockstar> benji, what's your skype name?
[20:36] <benji> rockstar: benji_york
[21:11] <flacoste> lifeless: morning
[21:12] <lifeless> hi flacoste
[21:12] <lifeless> are you back ?
[21:12] <lifeless> flacoste: I was just running out the door for a short errand
[21:12] <flacoste> lifeless: i am!
[21:13] <lifeless> but would love to catch up after that, if thats ok ?
[21:13] <flacoste> lifeless: that was my goal, when will you be back?
[21:13] <lifeless> < 20 min
[21:13] <flacoste> ok
[21:18] <thumper> rockstar: please check QA on kanban
[21:18] <rockstar> thumper, ah!
[21:26] <lifeless> flacoste: ok
[21:30] <rockstar> thumper, hm, qa on one of my items is bad (it doesn't fix the bug it's supposed to, nfi).  Where should that card go?
[21:31] <thumper> rockstar: it stays in the qa lane and you fix it :)
[21:31] <rockstar> thumper, okay.
[22:05] <wallyworld> morning
[22:06] <flacoste> lifeless: https://chinstrap.canonical.com/~stub/splitit/
[22:12] <Ursinha> lifeless, hello
[22:12] <rockstar> "Get up, stand up. Stand up for your right"
[22:12] <Ursinha> haha
[22:16] <Ursinha> lifeless, I believe r11579 landed the other half's fix of bug 506256, but the landing has no qa tags, so the bad-commit tag is still there
[22:16] <_mup_> Bug #506256: Remove Popen from buildstatus_OK <bad-commit-11566> <buildfarm> <qa-needstesting> <Soyuz:Fix Committed by jelmer> <https://launchpad.net/bugs/506256>
[22:16] <Ursinha> and it's blocking further revisions
[22:20] <lifeless> Ursinha: hi
[22:21] <lifeless> bigjools was going to cp both revs
[22:21] <lifeless> I don't think he has yet, lets check prod-stable
[22:28] <Ursinha> lifeless, so I guess we could unblock other bugs by marking this one as qa-ok?
[22:28] <Ursinha> assuming both parts have already been QAed, of course :)
[22:29] <lifeless> flacoste: https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt
[22:30] <Ursinha> lifeless, flacoste, prettier: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html :)
[22:44] <lifeless> Ursinha: so, prod stable does not have both fixes
[22:44] <lifeless> Ursinha: and we have to deploy both - see the bad-commit-xxxx tag
[22:45] <Ursinha> lifeless, I know... let me try again
[22:45] <Ursinha> lifeless, are both on edge and QAed?
[22:45] <lifeless> looking
[22:45] <Ursinha> lifeless, that's what matters so we can unblock the bug, right?
[22:46] <lifeless> this is the fixes=12345 stuff I was mentioning - same as rollback but rollforward
[22:46] <Ursinha> I know
[22:46] <lifeless> :P
[22:46] <Ursinha> that needs to be discussed and implemented
[22:46] <Ursinha> I mean something else
[22:46] <lifeless> I'll be back in a minute, real-life interrupt
[22:46] <Ursinha> sure
[23:02] <lifeless> sorry, back
[23:03] <lifeless> wgrant: around perchance?
[23:05] <lifeless> Ursinha: https://bugs.edge.launchpad.net/soyuz/+bug/128259
[23:05] <_mup_> Bug #128259: Buildmaster should not call "uploader" script for processing incoming binaries <buildd-manager> <qa-needstesting> <soyuz-build> <Soyuz:Fix Committed by jelmer> <https://launchpad.net/bugs/128259>
[23:05] <lifeless> qa-needstesting
[23:13] <Ursinha> lifeless, hmm, what's your point? :)
[23:13] <lifeless> Ursinha: you were asking if the second half fixed it - its unknown ?
[23:14] <Ursinha> lifeless, I'm asking what's about that bug
[23:14] <lifeless> Ursinha: that bug is attached to the commit that is the other half of 11566
[23:17] <Ursinha> I thought the other half of that bug was something related to that bug, just another branch ref. the same bug #
[23:17] <Ursinha> but now I see
[23:17] <lifeless> Ursinha: yeah; the other half references two bugs.
[23:38] <wgrant> lifeless: Hi.
[23:38] <lifeless> hi
[23:38] <lifeless> wgrant: wondering if you have an opinion on the qa-ness of bug 128259
[23:38] <_mup_> Bug #128259: Buildmaster should not call "uploader" script for processing incoming binaries <buildd-manager> <qa-needstesting> <soyuz-build> <Soyuz:Fix Committed by jelmer> <https://launchpad.net/bugs/128259>
[23:39] <lifeless> see backscroll
[23:39] <wgrant> I haven't heard.
[23:39] <wgrant> StevenK might know.
[23:39] <lifeless> also, killing pids that happen to be in a file that was stale weeks ago is really pretty nasty.
[23:39] <wgrant> But deploying that without thorough, thorough QA would be a seriously terrible idea.
[23:39] <lifeless> This layer stuff really concerns me :)
[23:39] <wgrant> Hm?
[23:39] <wgrant> Ah.
[23:39] <wgrant> Right.
[23:40] <wgrant> Are those revs in prod-stable yet?
[23:40] <wgrant> bigjools might have already CP'd them.