[00:12] <jelmer> wgrant: ok :(
[00:12] <wgrant> Yes :(
[00:49] <lifeless> wgrant: community-contributions; can you sudo to lpqateam ?
[00:49] <lifeless> if so, you could run it from that service accounts crontab
[00:54] <wgrant> lifeless: I can't.
[00:54] <wgrant> I don't think many can.
[00:55] <lifeless> its available on request, if you want it
[00:58] <jelmer> wgrant: I think we should just drop that branch; it was a nice refactoring, but it's taking more time than it's worth
[00:58] <wgrant> jelmer: Yeah ;/
[00:58] <wgrant> :/
[01:32] <LPCIBot> Project devel build #925: STILL FAILING in 5 hr 44 min: https://lpci.wedontsleep.org/job/devel/925/
[05:09] <LPCIBot> Project db-devel build #761: STILL FAILING in 5 hr 38 min: https://lpci.wedontsleep.org/job/db-devel/761/
[06:31] <lifeless> stub: \o/
[06:34] <stub> *\o/*       *_o_*      *\o/*
[06:35] <lifeless> :)
[06:36] <lifeless> want to see if the internets are working and do a catchup call ?
[06:40] <stub> lifeless: sure. gimme a tick for the caffine to kick in.
[06:51] <lifeless> wgrant: do you know -why- or ui gets broken by having series tasks w/no non-series 'parent' task ?
[06:51] <lifeless> wgrant: like, was it oversight? deliberate? ...?
[06:53] <wgrant> lifeless: It seems to be completely designed around always having a non-series task. I don't see how it would behave without one, without a complete redesign.
[06:53] <wgrant> As series tasks have only the series name.
[06:53] <wgrant> Not the Distribution/Product/DSP
[06:53] <lifeless> the original wasn't like this
[06:53] <wgrant> As in most cases they would just be massively duplicating information.
[06:54] <wgrant> Mmmm, it hasn't been changed much since 2006's release management rework.
[06:54] <wgrant> Which introduced conjoinment.
[06:54] <lifeless> I'm old skool
[06:54] <wgrant> I didn't really use series tasks before then.
[06:58] <rvba> Hi StevenK.
[06:59] <wgrant> lifeless: So, until we redesign the UI and or model...
[06:59] <lifeless> I may be wrong, but it seems shallow to me.
[06:59] <wgrant> It requires a major redesign of a piece of UI which was thoroughly designed in 2006.
[07:00] <lifeless> set a variable when looping over tasks for 'current pillar' [a lie, tell me the right name] and if it doesn't match and the next task is for a subordinate, emit a pretty line describing it.
[07:00] <rvba> StevenK: I'd like to have your opinion about a change I'm making to lib/lp/soyuz/model/distroseriesdifferencejob.py. I don't need a full review from you but I'd be glad if you could take a look at lines [267 - 286]. In particular, I'm not sure I understand the old code (that I'm removing) properly because it looks to me that DSDJs with parent_series=the parent derived_series=its grandchildren could be created ... https://code.launchpad.net/~rv
[07:00] <rvba> b/launchpad/dsd-creation-multiple-parents-bug-815775/+merge/69407
[07:00] <rvba> StevenK: https://code.launchpad.net/~rvb/launchpad/dsd-creation-multiple-parents-bug-815775/+merge/69407
[07:00] <lifeless> wgrant: I'm sure we could do a major redesign, I don't see that one is needed.
[07:00] <wgrant> lifeless: How do you propose to fix it?
[07:01] <lifeless> up 2 lines.
[07:01] <wgrant> I'm not sure it's worth it, given it will hopefully all be redesigned soon.
[07:01] <wgrant> Oh.
[07:02] <wgrant> Could do, I guess.
[07:02] <lifeless> thats what the bug boils down to isn't it? 'series task on its lonesome is missing context description'
[07:02] <StevenK> rvba: You only need one loop: for series in derived_series.getParentSeries() + derived_series.getDerivedSeries():
[07:03] <lifeless> other than conjoined tasks we don't have special business rules or cross-task conditional logic.
[07:03] <StevenK> rvba: I thought may_require_job() did the child stuff?
[07:03] <StevenK> -> out
[07:04] <rvba> StevenK: Thanks.
[07:06] <wgrant> lifeless: Yeah, true. It's just a bit ew.
[07:06] <wgrant> But this possibly makes it a bit less ew.
[07:08] <lifeless> I think this is a shallow oversight in that earlier work, rather than a big issue.
[07:09] <wgrant> Possibly.
[07:09] <wgrant> Not sure how to make it clear that it's not a real task.
[07:10] <wgrant> But I guess we'll find out.
[07:10] <lifeless> well it is a real task isn't it ?
[07:10] <lifeless> the only real special logic needs to be conjoined - when the user sees one task, we need to move two.
[07:11] <wgrant> Do you propose to show the project/distro/DSP in the series task, or as a ghost parent?
[07:11] <wgrant> I assumed the latter.
[07:12] <lifeless> oh, I see what you mean
[07:12] <lifeless> I was proposing a line, like a task line, but with no status importance assignee milestone fields
[07:12] <wgrant> That's what I thought.
[07:12] <wgrant> Just need to make it clear it's not a real task.
[07:12] <lifeless> sure
[07:12] <wgrant> Conjoinment already confuses people with fake tasks.
[07:13] <lifeless> huwshimi may have some ideas. We could do what conjoinment does - no worse.
[07:18] <LPCIBot> Project devel build #926: STILL FAILING in 5 hr 45 min: https://lpci.wedontsleep.org/job/devel/926/
[07:34] <lifeless> stub: caffeinated ?
[07:36] <stub> lifeless: for now :)
[07:42] <adeuring> good morning
[07:57] <wgrant> lifeless: It turns out it's rather easy to do that in the existing code. http://people.canonical.com/~wgrant/launchpad/ghost-task.png, but it, er, needs some UI work.
[07:57] <wgrant> Not sure what to say.
[07:57] <wgrant> Since I don't think we're allowed to talk about tasks.
[07:58] <lifeless> wgrant: I think it would be fine with no blah blah blah
[07:58] <wgrant> Possibly.
[07:59] <wgrant> I guess it's going to be fairly rare.
[07:59] <jtv> Reviewer in the house?  https://code.launchpad.net/~jtv/launchpad/bug-816833/+merge/69597
[07:59] <lifeless> wgrant: yeah
[07:59] <wgrant> But it would be nice if it were clear that it wasn't really a task and you could get status/importance tracking by clicking a link below.
[08:11] <mrevell> Hello
[08:42] <jtv> hi mrevell
[08:43] <mrevell> Hallo jtv
[09:01] <jml> could someone please review https://code.launchpad.net/~jml/launchpad/create-private-ppa-814567/+merge/69539
[09:06] <james_w> jml, is that going to stay a commercial admin-only operation?
[09:06] <jml> james_w: bigjools often expresses a desire to change it.
[09:07] <jml> james_w: although I've not actually heard an outline of an alternative.
[09:07] <jml> james_w: why do you ask?
[09:08] <bigjools> We need a PPA admin celeb
[09:09] <james_w> if this is for appdevelopers then we're not going to make them commercial admins
[09:09] <bigjools> there's a software center celeb for that
[09:09] <bigjools> it has permission to make private PPAs
[09:11] <james_w> but that doesn't necessarily fit the desired workflow though
[09:12] <bigjools> right
[09:12] <bigjools> the workflows are ill defined
[09:17] <jml> this is a specific instance of a more general entitlement problem
[09:17] <jml> permission to create private X, and the means by which those permissions are acquired
[09:19] <bigjools> jml: in your branch did you consider refactoring the check for commercial admin, somehow?
[09:20] <bigjools> I'm not sure how I'd do it tbh :(
[09:20] <jml> bigjools: the only thing that came to mind was writing a version of check_permission that took user as a parameter, rather than getting it from the session.
[09:21] <bigjools> jml: I'm just wary of duplicating the check, that's all.  Been there, picked up the pieces :(
[09:22] <jml> bigjools: yeah. I can put a note in the new code & the zcml if you'd like, pointing one to the other.
[09:22] <bigjools> jml: fair enough, thanks
[09:26] <jml> bigjools: clear enough? http://pastebin.ubuntu.com/653641/
[09:26] <bigjools> jml: perfect
[09:27] <jml> bigjools: I've pushed that change up. Could you please land the branch for me?
[09:27]  * jml no longer has permissions to do so.
[09:27] <bigjools> jml: !
[09:27] <bigjools> wth
[09:27] <gmb> allenap: Are you OCRing today?
[09:27] <allenap> gmb: Yes.
[09:27] <bigjools> jml: set a commit msg
[09:27] <jml> bigjools: I left ~canonical-launchpad. lifeless & flacoste have yet to re-establish the broader launchpad committer policy.
[09:27] <allenap> gmb: I've just done one of yours.
[09:28] <bigjools> jml: I am sure we have other internal committers
[09:28] <gmb> allenap: Ah, magico. Thanks.
[09:28] <lifeless> bigjools: they are in ~launchpad
[09:28] <lifeless> bigjools: jml jumped, he was not pushed :P
[09:29] <jml> yeah.
[09:29] <jml> wanted to be clean.
[09:29] <allenap> gmb: Fwiw, I think that would have been fine as a self-review.
[09:29] <bigjools> dirty :)
[09:29] <jml> & also to not get sucked back into LP stuff too much, thus doing  a disservice to my new overlords
[09:29] <gmb> allenap: Agreed. But I always forget I can do those until after I've asked.
[09:34] <bigjools> jml: your branch is hitting ec2 now, thanks for your contribution :)
[09:34] <jml> my pleasure :)
[09:49] <henninge> anybody with buildout foo around?
[09:52] <gmb> henninge: I hesitate to say this, but I have a little. What's up.
[09:53] <henninge> gmb: I am trying to get my own version of ZConfig build.
[09:54] <lifeless> hackinglazrlibraries ?
[09:54] <rvba> allenap: may I add that to you queue? https://code.launchpad.net/~rvb/launchpad/dsd-creation-multiple-parents-bug-815775/+merge/69407
[09:55] <rvba> *your
[09:55] <henninge> gmb: I am following the instructions in doc/buildout.txt
[09:55] <allenap> rvba: Certainly :)
[09:55] <rvba> allenap: Thanks ;)
[09:55] <henninge> gmb: so, I have the modified source tree and did "setup.py egg_info sdist" which gave me a tarball in dist
[09:56] <henninge> gmb: I put that tarball into the download-cache, updated version.cfg and ran bin/buildout.
[09:56] <henninge> gmb: that gives me this error:
[09:57] <henninge> Getting distribution for 'ZConfig==2.9.1dev-20110728'.
[09:57] <henninge> error: NEWS.txt: No such file or directory
[09:57] <henninge> An error occurred when trying to install ZConfig 2.9.1dev-20110728. Look above this message for any errors that were output by easy_install.
[09:57] <gmb> henninge: Just for clarity, did you put the tarball in download-cache or download-cache/dist?
[09:57] <wgrant> henninge: How did you get the version suffix?
[09:57] <henninge> gmb: so two possible questions: Why does NEWS.txt not get included in the tarball?
[09:57] <wgrant> henninge: You didn't rename the tarball manually?
[09:57] <henninge> gmb: in dist
[09:58] <henninge> wgrant: no, sorry, I used "-d" on setup.py
[09:58] <wgrant> Ah, good.
[09:58] <wgrant> -d, or -b?
[09:58]  * henninge checks
[09:58] <henninge> wgrant: the one that does it automatically
[09:59] <henninge> -d
[09:59] <wgrant> Right.
[09:59] <gmb> henninge: Lickily for you, the Oracle of Melbourne has arrived.
[09:59] <gmb> Luckily, even.
[09:59] <henninge> second possible question: Why does buildout expect NEWS.txt to be in there?
[09:59] <henninge> gmb: ;-)
[09:59] <wgrant> henninge: It must be in the manifest of the tarball.
[10:00] <wgrant> jtv, allenap, danilos: Need any help with QA? There's a germanium cowboy that I'd like to squash ASAP.
[10:00] <wgrant> henninge: Is this tarball in lp-sourcedeps yet?
[10:00] <bigjools> Lickily sounded eerily appropriate
[10:00] <jtv> I need to run publish-ftpmaster.
[10:00] <allenap> wgrant: I'll take a look at mine.
[10:00] <henninge> wgrant: yes, it is
[10:00] <wgrant> Let me see.
[10:00] <bigjools> jtv!  Let's do it
[10:00] <wgrant> jtv, allenap: Thanks.
[10:01] <wgrant> jtv: I guess you should also test cron.publish-ftpmaster, or maybe just pretend that everything will be OK.
[10:01] <wgrant> Since it's not exactly a controversial change.
[10:01] <jtv> Yes, good point — I can run the existing cron.publish-ftpmaster.
[10:01] <jtv> That's assuming I can.
[10:01] <wgrant> Worth a try.
[10:01] <allenap> wgrant: Done.
[10:01] <wgrant> But not worth a vast quantity of effort if it proves non-trivial.
[10:02] <jtv> wgrant: I'd still like to be able to run the new script separately later today though, and get verifiable results.
[10:02] <wgrant> True.
[10:03] <danilos> wgrant, I need help with CHR, will get to QA asap :)
[10:04] <wgrant> henninge: I'm not sure ZConfig is set up well enough that you can use setup.py to build a tarball.
[10:04] <wgrant> henninge: I suspect you may need to hack the version and tar it up manually.
[10:04] <wgrant> Since setup.py references NEWS.txt in the cwd without asking for it to be installed.
[10:05] <wgrant> Hmm, but 2.7.1 still has egg_info...
[10:06] <wgrant> You may need to invoke gary or similar, I fear.
[10:06] <wgrant> ZConfig is a little strange.
[10:07] <henninge> wgrant: gary sent me down this path ... ;-)
[10:08] <wgrant> I wonder if adding NEWS.txt to MANIFEST.in would work.
[10:09] <henninge> let me see what I get when I build from the 2.7.1 source
[10:11] <allenap> wgrant: Actually, I need to spend some more time looking at r13538.
[10:12] <danilos> wgrant, my rev is qa-ok
[10:13] <wgrant> danilos: Thanks.
[10:14] <jtv> wgrant: bigjools just told me we can test the existing publish-ftpmaster script now.
[10:14] <lifeless> henninge: you've tracked the rotation segfault to zconfig ?
[10:15] <henninge> lifeless: yes, it simply closes and opens the files with no logging whatsoever.
[10:15] <henninge> s/logging/locking/
[10:15] <lifeless> \o/
[10:15] <henninge> gary suggested a simple fix to simply not close the file. GC will do that ones all processes are done with it.
[10:16] <henninge> s/ones/once/
[10:16] <wgrant> I hope upstream won't accept that. It's not very portable.
[10:16] <henninge> why not?
[10:16] <henninge> portable accross python version?
[10:16] <wgrant> CPython's reference counting is an implementation detail. Relying on GC for managing external resources like that isn't a great idea.
[10:17] <wgrant> eg. will behave differently in Jython and PyPy.
[10:17] <henninge> I see what you mean
[10:18] <lifeless> also on windows
[10:19] <lifeless> on windows you can't replace open files under all conditions
[10:19] <lifeless> (not that I care about windows)
[10:19] <lifeless> henninge: do you mean 'threads' or 'processes' ?
[10:23] <henninge> lifeless: it's threads AFAIUI
[10:23] <henninge> it should not be too hard to implement proper locking
[10:23] <henninge> the logging module does that, too.
[10:25] <henninge> There is also WatchedFileHandler but it does a "stat" call on the log file each time it logs a line which seems a bad idea, too.
[10:26] <lifeless> henninge: if I may suggest, use a single thread for writes; hand off things to log to that thread using a threading.queue, and that one thread can receive a message in the queue to do rotations.
[10:26] <lifeless> henninge: or something-like-that
[10:27] <lifeless> e.g. rotate() would look something like: insert the 'rotate now message', with a callback to notify on completion; bind that to a temporary threading event, and you're done, more or less
[10:27] <henninge> lifeless: I had been thinking along those lines at first, too, but hoped for a simpler solution ...
[10:28] <henninge> oh, that is a nice idea, too.
[10:30] <jtv> bigjools: can I just run cron.publish-ftpmaster on dogfood then?
[10:31] <jtv> And allenap… thanks!
[10:31] <bigjools> jtv: doit
[10:31] <jtv> And given that you're speaking French today…
[10:31] <jtv> "must"
[10:32] <bigjools> :)
[10:32] <bigjools> jtv: allez
[10:37] <danilos> henninge, hi, will you have a few minutes to discuss translations sharing today? dpm has filed a bunch of questions about it not working for different projects, and he suggested that you've already done some investigation
[10:37] <henninge> danilos: I have not, no.
[10:38] <henninge> danilos: I just told him that it would need some and that it looks like there are more bugs hidden there.#
[10:39] <danilos> henninge, right, fair enough, I'll see if I can get some dedicated time to look into it tomorrow-ish then
[10:39] <danilos> mrevell, hi, do you think you'd have time to help me with announcing the import queue management change and perhaps even start on the documentation?
[10:40] <mrevell> danilos, Yes, certainly. Tomorrow would be best for me but if it needs to be today then I can rearrange a couple of things.
[10:41] <danilos> mrevell, it'd be nice for us to at least come up with an announcement today since it's probably going to go out in a nodowntime deployment soon
[10:41] <mrevell> danilos, Okay, no problem.
[10:42] <mrevell> danilos, I can talk now.
[10:42] <danilos> mrevell, excellent
[10:42]  * danilos shuts the music down and switches to headset
[10:42] <danilos> mrevell, how about skype? :)
[10:42] <henninge> danilos: thanks
[10:43]  * mrevell engages the Skypotron
[10:43] <jtv> bigjools, wgrant: cron.publish-ftpmaster isn't really supposed to complete within the minute, is it?
[10:43] <bigjools> depends how much work there is.  got a log?
[10:44] <bigjools> but generally no :)
[10:45] <jtv> rsync: change_dir "/srv/launchpad.net/ppa/ubuntu-partner/dists" failed: No such file or directory (2)
[10:45] <bigjools> heh
[10:46] <jtv> log: http://paste.ubuntu.com/653691/
[10:47] <bigjools> jtv: just make the dir
[10:48] <bigjools> seems like the PPA repo purge I did blew away DF's partner archive
[10:48] <jtv> /srv/launchpad.net/ppa/ubuntu-partner is empty… mkdir /srv/launchpad.net/ppa/ubuntu-partner/dists?
[10:48] <bigjools> yes
[10:48] <wgrant> Erm, /srv/launchpad.net/ppa?
[10:48] <wgrant> Oh.
[10:48] <wgrant> You need to hack the script.
[10:48] <bigjools> publisher doesn't need it but that script does
[10:48] <wgrant> I remember this from last time.
[10:48] <wgrant> It checks if the config is right or something.
[10:49] <wgrant> And if not uses /srv/launchpad.net/ppa, because why not.
[10:49] <bigjools> that directory is served on Apache, it's useful for testing
[10:49] <wgrant> if [ "$LPCONFIG" = "$PRODUCTION_CONFIG" ]; then ARCHIVEROOT_PARTNER=/srv/launchpad.net/ubuntu-archive/ubuntu-partner
[10:49] <wgrant> Ah.
[10:50] <bigjools> the script is fine
[10:50] <wgrant> Fine, perhaps. But still crazy :)
[10:50] <bigjools> except rsync hates it when dists is missing
[10:50] <jtv> So we'll give it one.
[10:50] <bigjools> yes
[10:53] <jtv> (haven't mentioned it but it's running)
[10:58] <LPCIBot> Project db-devel build #762: STILL FAILING in 5 hr 48 min: https://lpci.wedontsleep.org/job/db-devel/762/
[11:14] <cjohnston> mrevell: ping
[11:14] <mrevell> Hi cjohnston
[11:14] <cjohnston> Want to setup a time?
[11:15] <mrevell> cjohnston, Yes please. How does 14.00 UTC sound?
[11:16] <cjohnston> ~3 hours from now?
[11:16] <cjohnston> I guess 2 hours 45 minutes from now
[11:17] <mrevell> cjohnston, Yeah.
[11:17] <cjohnston> Sounds good
[11:18] <mrevell> Great, thanks cjohnston, speak to you later.
[11:24] <bigjools> StevenK: the notification code you wrote always seems to use changed-by as the From: address which I think  is wrong and should be blamer, do you agree?
[11:34] <StevenK> bigjools: Hmmmm. For which bit?
[11:34] <bigjools> StevenK: it calls fetch_information which always returns from_addr that way
[11:34] <bigjools> the syncs we did yesterday had "From:" as the Debian uploader
[11:35] <StevenK> bigjools: Yes, but the notification to changed-by, or the announce?
[11:35] <bigjools> StevenK: both
[11:35] <StevenK> Hmmmmm.
[11:35] <wgrant> This is difficult.
[11:35] <StevenK> Agreed
[11:35] <wgrant> For the announce list we really want the author of the change.
[11:36] <wgrant> For an Ubuntu upload that's Changed-By.
[11:36] <wgrant> For a sync, that's the requester... not necessarily the blamer, but perhaps we can just use the blamer there.
[11:36] <wgrant> We can't just unconditionally use the blamer.
[11:36] <bigjools> ok
[11:36] <bigjools> the old code used katie as a sign it was a sync
[11:36] <wgrant> Yes :/
[11:36] <bigjools> feck sake
[11:37] <bigjools> in fact wasn't that the chnaged-by?
[11:37] <StevenK> If it's from PCJ, the requester is the blamer.
[11:37] <bigjools> indeed
[11:38] <wgrant> bigjools: katie was for autosyncs.
[11:38] <wgrant> It's in Changed-By in that case.
[11:38] <bigjools> right
[11:38] <wgrant> For manual syncs, katie is not involved.
[11:38] <bigjools> is sync-source mangling anything ?
[11:38] <StevenK> For manual syncs, Changed-By was the requester
[11:38] <StevenK> I *think*
[11:38] <bigjools> exactly
[11:38] <wgrant> bigjools: Yes.
[11:39] <wgrant> sync-source puts the requester in Changed-By.
[11:39] <bigjools> https://launchpad.net/debian/sid/+source/gedit-plugins/3.0.5-1
[11:40] <bigjools> I think Gina has a bug, can you spot it? :)
[11:40] <wgrant> Yes.
[11:40] <wgrant> Also, it's using Debian URLs in emails.
[11:40] <bigjools> yeah I know
[11:40] <wgrant> I guess it's asking for the SPR's canonical_url, rather than the DSPR, perhaps.
[11:40] <StevenK> It does use the SPR
[11:40] <wgrant> bigjools: Oh, you're using changelog_entry in notify()?
[11:40] <wgrant> That's not really suitable.
[11:41] <bigjools> when you say "you're" ....
[11:41] <wgrant> We need to parse changelogs.
[11:41] <wgrant> "you're" == red
[11:41] <bigjools> == StevenK :)
[11:41] <StevenK> Not my code any more
[11:41] <bigjools> ha
[11:41] <bigjools> it's all our code but since you wrote it you don't get to escape
[11:41] <wgrant> I waved StevenK's code through with the understanding that it was an initial refactoring to be tested and made suitable later :(
[11:42] <wgrant> Since there was lots of refactoring :(
[11:42] <StevenK> And so far, we've discovered that the one missue of it was due to PCJ suckage
[11:42] <StevenK> bigjools: I don't get to fix it either
[11:43] <bigjools> StevenK: dude, I am just asking for some info, not a fix
[11:43] <StevenK> Which you have -- sync-source does Wierd Shit[tm]
[11:44] <bigjools> so, the code as it is works fine, except for syncs where we want From: to be the blamer
[11:44] <bigjools> yes?
[11:44] <wgrant> bigjools: I believe so.
[11:44] <bigjools> thanks
[11:45] <bigjools> easy enough to fix
[11:47] <wgrant> Let's hope.
[11:47] <wgrant> It's faaaairly well-factored now.
[11:47] <wgrant> And even somewhat tested.
[11:50] <bigjools> so I can either pass in an override for from_addr or an is_sync bool.  I'm not sure the code itself can work out this.
[11:50] <StevenK> Pass in the override
[11:50] <StevenK> Simplest, easiest way
[11:51] <StevenK> And won't effect the existing tests
[11:51] <wgrant> It shouldn't know about syncs, so is_sync is out.
[11:51] <wgrant> Possibly a from_blamer, or some similar flag like that, though...
[11:51] <wgrant> Rather than having to calculate the address yourself.
[11:52] <bigjools> well it should pass in a Person
[11:52] <StevenK> From may not be a Person
[11:53] <bigjools> it should be
[11:53] <bigjools> so that the preferred email stuff is all dealt with inside the notify code
[11:53] <StevenK> notify() doesn't take a from_addr
[11:53] <bigjools> it will do in 5 minutes
[11:53] <StevenK> Ew
[11:54] <StevenK> notify() has too many arguments already :-)
[11:54] <bigjools> shit happens
[11:54] <wgrant> Perhaps a trust_changed_by=True argument, or something.
[11:54] <wgrant> Otherwise you are going to have to inspect the SPR's people.
[11:55] <bigjools> eh?
[11:55] <bigjools> the from_person will default to None
[11:55] <wgrant> It just feels fairly dirty for the callsite to have to get the people itself.
[11:55] <bigjools> I disagree on that - it's just an override and used in special cases, like syncing.  We already know the person.
[11:56] <bigjools> and this is feeling like bikeshedding
[11:57] <wgrant> It is not quite bikeshedding, but close, true.
[11:57] <bigjools> we already pass blamer, I don't see the problem with knowing the person who sends the email
[11:58] <wgrant> Yeah, maybe.
[11:58] <wgrant> I'm just worried that this could end up turning into a bigger mess than it was before :)
[11:58] <wgrant> Still, at least it won't have katie celebrities this time.
[12:00] <bigjools> yeah, when sync-source stops getting used we can throw that bit of code away
[12:01] <bigjools> thank you for your input gentlemen
[12:02] <wgrant> Killing celebrities is a favourite pasttime of mine.
[12:04] <bigjools> hmm interesting, the email to blamer would end up being the config.uploader.default_sender_address)
[12:04] <bigjools> from the*
[12:04] <wgrant> That's how it tends to be, yes.
[12:04] <bigjools> guess that's ok
[12:04] <wgrant> 'Launchpad PPA' or 'Ubuntu Installer' have historically sent the non-announcement emails.
[12:04] <bigjools> indeed
[12:10] <wgrant> jtv: cron.publish-ftpmaster's not yet blown up?
[12:10] <jtv> No, sorry
[12:10] <jtv> 2011-04-18 10:59:36 INFO    Done with ubuntu natty.
[12:10] <jtv> .0.1-1
[12:10] <jtv> Getting ancestry for 3depict - 0.0.2-1
[12:10] <jtv> Getting ancestry for gdc-4.4 - 1.063-4.4.5-2ubuntu1
[12:10] <jtv> Getting ancestry for gdc-4.4 - 1.063-4.4.5-2
[12:11] <jtv> Actually, maybe it's blown up and just not told anybody.
[12:11] <jtv> It hasn't produced any new output for a while.
[12:11] <henninge> gary_poster: Hi!
[12:11] <wgrant> jtv: I would not put that past it.
[12:12] <jtv> Hmm can't find the process.
[12:12] <jtv> So that sounds dead.
[12:12] <gary_poster> sinzui, I need to qa that Mailman's XMLRPC is still working after a bugfix I made.  AFAICT Mailman doesn't work at all on qastaging--when I try to interact at all with Mailman lists things blow up.  Am I missing something?  How would you recommend I qa this kind of thing?
[12:12] <wgrant> But what is that?
[12:12] <wgrant> germinate?
[12:12] <gary_poster> hey henninge
[12:12] <wgrant> LP doesn't print that sort of message.
[12:12] <wgrant> gary_poster: qastaging doesn't have mailman.
[12:12] <wgrant> gary_poster: But staging does, and got the rev a while ago.
[12:12] <gary_poster> wgrant, I was afraid of that
[12:12] <gary_poster> oh ok excellent
[12:12] <gary_poster> thanks wgrant
[12:12] <wgrant> gary_poster: And successfully resynced, and I created a new list and it was created after it resynced.
[12:12] <wgrant> So it seems to be OK.
[12:12] <gary_poster> wgrant, heh, you rock!
[12:13] <gary_poster> thanks also for the email about the OOPS wgrant
[12:13] <wgrant> Sorry I didn't chase that up earlier.
[12:13] <gary_poster> np at all
[12:13] <henninge> gary_poster: I am almost there but I have a problem with building the egg using the egg_info command.
[12:14] <gary_poster> and, bigjools, thanks for your email.  I'll rerun that query after I get a few other things handled
[12:14] <bigjools> yup
[12:14] <jtv> Pretty much all the runtime seems to be 20 minutes of just this.
[12:14] <gary_poster> henninge ok (egg_info just modifies egg data; sdist makes the sdist)
[12:14] <henninge> gary_poster: it does not include the file NEWS.txt althogh that is mention in setup.cfg. Any idea why?
[12:14] <henninge> gary_poster: ok, then it's sdist
[12:15] <henninge> I did not realized those were two chained commads
[12:15] <wgrant> It looks like you need to manually tar rather than sdist, but I hope gary has more insight :)
[12:16] <gary_poster> henninge, yes, reasonably confident.  it is because setuptools has special magic for svn and not for any other rcs.  packages that rely on this don't have a MANIFEST.in and so break in this kind of situation. :-(
[12:16] <gary_poster> so, options...
[12:17] <gary_poster> 1) probably a manual tar would work, guessing at the right name for things...you might have to look for magic files.  Others might know about that; I've never done it.  That's because I do option 2:
[12:17] <henninge> ;)
[12:18] <gary_poster> 2) get the branch into svn.  I could commit it for you into Zope's svn if you'd like.  Then it would work for you.  I also sometimes do option 3:
[12:19] <gary_poster> 3) Write your own MANIFEST.in. You could quite likely steal the one from one of our lazr packages and it might work fine.  MANIFEST.in is quite underdocumented though, I'm afraid.
[12:19] <gary_poster> henninge, option 4: toss it to me to make it my problem :-P
[12:19] <gary_poster> I like the other options better, but I'm willing to play with that option :-)
[12:20] <henninge> gary_poster: option 2) sounds fine since I want to submit it upstream anyway.
[12:20] <henninge> gary_poster: can you get it into svn for me? Here is the lp branch:
[12:20] <gary_poster> henninge sure
[12:21] <henninge> https://code.launchpad.net/~henninge/zconfig/bug-481512-reopen-logs
[12:21] <henninge> gary_poster, wgrant: I implemented proper locking, btw, which was not that heard because the underlying logging.StreamHandler already has it, just gotta use it.
[12:22] <wgrant> henninge: Ah, great. Better than relying on GC implementation details.
[12:22] <gary_poster> cool
[12:23] <jtv> wgrant: what was that you said about manually tarring rather than sdisting?  Complete Greek to me, and I was always terrible at Greek.
[12:24] <jtv> (Not entirely undue to the fact that our books, in stark contrast to our Latin and German books and for reasons that never became entirely clear, consistently put the cases in order 1-4-2-3)
[12:25] <henninge> gary_poster: so, I hear back from you once my branch is in svn or do you need anything else from me?
[12:25] <gary_poster> henninge, I am doing it now.
[12:25] <henninge> cool, thanks.
[12:25] <henninge> ;-)
[12:27] <wgrant> gary_poster: We had to roll germanium back 12ish hours ago. I reverted the problematic revision in r13542, so it'd be great if someone in your squad could arrange a deployment of at least that rev once we are QA'd.
[12:27] <gary_poster> wgrant, ack, will do
[12:31] <gary_poster> henninge: ``svn co svn://svn.zope.org/repos/main/ZConfig/branches/LP-481512-reopen-logs`` is good to go
[12:33] <wgrant> gary_poster: Thanks.
[12:37] <henninge> gary_poster: thanks
[12:48] <henninge> gary_poster: that worked ;-)
[12:48] <gary_poster> henninge, cool :-)
[12:50] <gmb> abentley: Can you answer cjwatson's follow-up reply on this question? https://answers.launchpad.net/launchpad/+question/164657
[12:58] <deryck> Morning, all.
[12:59] <henninge> gary_poster: https://code.launchpad.net/~henninge/launchpad/bug-481512-reopen-logs/+merge/69643
[13:00] <henninge> Hi deryk!
[13:00] <henninge> Hi deryck! ;)
[13:00] <gary_poster> henninge, approved
[13:00] <henninge> gary_poster: thanks
[13:02] <henninge> gary_poster: ec2 test run makes no sense on a branch like that.
[13:04] <gary_poster> bigjools, on #launchpad GTRsdk is trying to upload thunderbird 6, and the orig source upload hangs at the last kilobyte.  Should he just be patient or is this indicative of something wrong, or do you have any other idea?  Also, is there anyone else I can bother about this right now?  I know you are busy.
[13:04] <gary_poster> henninge, eh, I think it does
[13:04] <gary_poster> adding a dependency is risky
[13:04] <henninge> um, ....
[13:04] <henninge> too late
[13:05] <gary_poster> henninge ok
[13:05] <henninge> but right
[13:05] <henninge> I was only thinking in term of changing that file
[13:05] <gary_poster> yeah
[13:05] <henninge> I'll start a test run in parallel
[13:06] <bigjools> gary_poster: it's a bug in a hardware router we think, this problem is happening in two completely different FTP server implementations we've done now.  He can work around it by using sftp instead.
[13:07] <gary_poster> many thanks bigjools
[13:07] <bigjools> gary_poster: I'll explain to him
[13:07] <gary_poster> thanks again :-)
[13:13] <abentley> allenap, jcsackett: could you please review https://code.launchpad.net/~abentley/launchpad/json-serialization/+merge/69519 https://code.launchpad.net/~abentley/launchpad/reload-cache/+merge/69527 and https://code.launchpad.net/~abentley/launchpad/translations-sharing/+merge/69531 ?  They are a series.
[13:14] <allenap> abentley: Sure, I was just looking at the first one...
[13:14] <abentley> allenap: thanks!
[13:36] <deryck> http://lpqateam.canonical.com/
[13:53] <abentley> bac: I've got my changes up for review now.  When the last in the series, "translations-sharing", is approved, I plan to land it.  This will effectively merge all prerequisites, including getnewcache.
[13:53] <bac> abentley: ok, great!
[13:54] <abentley> bac: So you don't need to do anything, but if you have any outstanding getnewcache revisions, please push 'em.
[13:54] <bac> abentley: latest have been pushed
[13:55] <bac> abentley: please let me know when it lands, in case i miss it
[13:55] <abentley> bac: Sure thing.
[14:25] <jcsackett> allenap: can i add https://code.launchpad.net/~jcsackett/launchpad/decouple-privacy-notifications/+merge/69174 and https://code.launchpad.net/~jcsackett/launchpad/extend-privacy-notification-to-comments/+merge/69655 to your queue? i can take over anything else that pops up in the review queue today since i figure that would take you to EOD.
[14:27] <jelmer> jcsackett: in that case, can I perhaps add something to your queue?
[14:27] <jelmer> https://code.launchpad.net/~jelmer/launchpad/upgrade-stderr/+merge/69225
[14:29] <abentley> jelmer: Heya.  Noticed you touched a baz-import bug.  Is it relevant to you?
[14:30] <allenap> jcsackett: I'm doing one of abentley's branches right now, but I'll probably have time for one of those at least before closing if you take abentley's other branch.
[14:32] <jelmer> abentley: no, I was mainly just looking at all the New bugs on http://bugs.launchpad.net/bazaar/+bugs
[14:33] <abentley> jelmer: cool, cause I have no plans to work on baz-import ever again :-)
[14:34] <jelmer> abentley: heh, ok :)
[14:34] <jcsackett> allenap: i can certainly take abentley's remaining branch.
[14:35] <abentley> jelmer: funny thing is, baz is no longer in Ubuntu, but tla is.
[14:38] <jelmer> abentley: I guess tla is still used (and maintained) by somebody in Debian
[14:40] <jelmer> abentley: ah, actually. tla is orphaned, so there is a good chance it will disappear soon too
[14:41] <bigjools> jcsackett: helleau.  Can I add this to your queue please: https://code.launchpad.net/~julian-edwards/launchpad/sync-email-from-addr-bug-817102/+merge/69659
[14:42] <jcsackett> bigjools: absolutely, i'll take a look when i finish abentley's branch.
[14:42] <bigjools> jcsackett: cheers, it's not big (~100)
[14:42] <jcsackett> bigjools: cool.
[14:58] <abentley> jcsackett: thanks.
[14:58] <jcsackett> abentley: thank you for the work.
[14:59] <jcsackett> bigjools: looks like jtv is reviewing your branch?
[14:59] <jtv> jcsackett: looks like that, yes
[14:59] <bigjools> jcsackett: help me.  help me now.
[14:59] <abentley> jcsackett: np.  I wrote the original code, so I was pretty comfortable cleaning it up.
[15:00] <jcsackett> bigjools: i think you're in fine hands. :-)
[15:00] <bigjools> jcsackett: Didn't know he was going to pick it up, sorry.
[15:00] <jcsackett> bigjools: no worries at all. it's a pleasant surprise to turn to a task and find someone else doing it. :-)
[15:01] <bigjools> jcsackett: if only life was more like that
[15:02] <bigjools> I fear that your gain is my loss though :)
[15:02]  * jcsackett laughs.
[15:11] <jtv> bigjools: I _told_ you I could review it.  And I did.
[15:11] <bigjools> jtv: I figured you were busy with the publisher ...
[15:12] <jelmer> jcsackett: if there is a free spot in your queue, is there any chance you could have a look at https://code.launchpad.net/~jelmer/launchpad/upgrade-stderr/+merge/69225 ?
[15:13] <jtv> bigjools: the publisher is busy.  It seems to be getting on fine without my further help.
[15:13] <jtv> Anyway it didn't hurt much did it?
[15:13] <bigjools> jtv: I dunno, how many nits do I have in your review? :)
[15:14] <jtv> Go look.
[15:14] <jtv> Come on.
[15:14] <jtv> I know you want to.
[15:14] <jcsackett> jelmer: looking now.
[15:14] <jcsackett> jelmer: so, if i read your comment right, we only have ~60-100 imports that would be upgraded?
[15:15] <bigjools> jtv: bloody hell :)
[15:15] <bigjools> jtv: thanks
[15:15] <jtv> This is what restraint looks like.
[15:15] <bigjools> lol
[15:15] <bigjools> jtv: yes, lots of setup :(  Welcome to Soyuz.
[15:16] <jelmer> jcsackett: yes, and those are all disabled at the moment because of the regression this branch fixes
[15:16] <jelmer> jcsackett: so we could re-enable them gradually
[15:17] <jcsackett> jelmer: ok.
[15:17] <abentley> allenap: I'm happy to add comments on the tests, but there are separate tests for the contents already: test_wrap_resource_nested_mapping, test_wrap_resource_nested_array, test_wrap_resource_null.  The "creates" tests are just to show that the array or mapping is a new object, not reused.
[15:18] <jcsackett> jelmer: to my understanding, this looks good, so r=me.
[15:19] <allenap> abentley: Yeah, I understand; the itemsAreSame() assertion would be repetition for the sake of clarity. If a comment makes it clear enough then stick with that.
[15:20] <abentley> allenap: I think that repetition would make the purpose of the test less clear.
[15:20] <jelmer> jcsackett: thanks!
[15:20] <allenap> Okay, cool.
[15:27] <jtv> I just introduced my father to Zombo.com.  It was time.
[15:38] <gary_poster> abentley, deryck, we have three remaining non-assigned open LP questions, and they are all code related.  could I assign them to abentley to either act on, or give another CHR person an idea of what to do?
[15:39] <deryck> gary_poster: I'm fine with that, if abentley doesn't mind, of course. :)
[15:39] <gary_poster> cool, thank you deryck.  waiting for abentley's blessing, curse, or alternate suggestion then
[15:39] <abentley> gary_poster: I see two questions.  "	Please remove my comment" doesn't look code related.
[15:40] <gary_poster> abentley, it is a MP comment
[15:41] <abentley> gary_poster: Oh, okay.
[15:52] <abentley> bac: landed.
[15:52] <abentley> gary_poster: I've taken those questions.
[15:53] <bac> abentley: great
[16:24] <jcsackett> allenap: thanks for the review; that actually explained an intermittent failure i *thought* i had fixed, but clearly is still intermittent. but now i have some idea what to do.
[17:00] <gary_poster> thank you abentley
[17:07] <henninge> gary_poster: test suite passed, so nothing to worry about ;-)
[17:08] <gary_poster> :-) cool henninge
[17:08] <henninge> bye, back on Monday
[17:12] <LPCIBot> Project db-devel build #763: STILL FAILING in 6 hr 14 min: https://lpci.wedontsleep.org/job/db-devel/763/
[17:46] <mtaylor> so - with bug imports ... I got things rejected because I didn't have an email address associted with the bug
[17:47] <mtaylor> if I don't HAVE an email address from my source - would it be better to just include a bogus email address? what if I _do_ have that person's launchpad id and it doesn't match the email address in their profile?
[18:35] <abentley> jcsackett: I can has review? https://code.launchpad.net/~abentley/launchpad/mark-dup-empty/+merge/69704
[18:35] <jcsackett> abentley: you can haz.
[18:43] <jcsackett> abentley: you can also has r=me.
[18:44] <abentley> jcsackett: kthxbye
[19:43] <benji> jcsackett: do you have a moment to look at a small JS branch? https://code.launchpad.net/~benji/launchpad/bug-pre-search-2/+merge/69710
[19:44] <jcsackett> benji: looking at it now.
[19:44] <benji> cool
[19:51] <jderose> mrevell: jkakar said you're the one to ping about getting a project group for novacut :)
[19:53] <jkakar> Hiya. :)
[19:53] <mrevell> Hi jderose! Would you mind dropping an email to feedback@launchpad.net? I'm not officially here at the moment. Sorry to be a pain.
[19:53] <jkakar> mrevell: You're going to learn to hate me for sending people your way all the time. ;b
[19:54] <mrevell> jderose, Also, I wanted to interview you about Novacut for the Launchpad blog some time, if that's cool with you.
[19:54] <mrevell> jkakar, Hey, not at all :)
[19:54] <jkakar> :)
[19:55] <jderose> mrevell: oh, would be awesome to do interview, thanks! :)
[19:55] <jderose> mrevell: i'll drop an email, sure, np ;)
[19:56] <mrevell> jderose, It looks like an interesting project. Also, I saw one of you was in Longmont, CO. I visited there three years ago for work :) Okay, thanks for the email, one of us will reply over the next 24 hours.
[19:56] <jderose> no rush :)
[20:08] <cr3> how is the python-twisted-web dependency pulled in the launchpad development environment? I really can't find how it gets pulled from apt-cache rdepends --recursive python-twisted-web even though launchpad-developer-dependencies is listed :(
[20:12] <LPCIBot> Project devel build #927: STILL FAILING in 6 hr 40 min: https://lpci.wedontsleep.org/job/devel/927/
[20:14] <jcsackett> benji: sorry for the delay, encountered some issues with my computer.
[20:15] <jcsackett> benji: this all looks good, but i do have one question. is it necessary to have the option to pass in a bug_id? it doesn't look like that option is used anywhere.
[20:29] <benji> jcsackett: sorry, I was on a call; being able to pass in the bug ID makes testing easier
[20:29] <jcsackett> benji: dig.
[20:33] <jcsackett> benji: r=me.
[20:34] <benji> jcsackett: cool, thanks
[21:11] <deryck> Later on, everyone.
[22:53] <poolie> ** Branch linked: lp:~benji/launchpad/bug-pre-search-2
[22:53] <poolie> oh you legend
[22:54] <benji> heh
[22:54] <poolie> that will be a nice time saver
[22:54] <poolie> we could do so much more there though
[22:55] <poolie> through a kind of time and motion study around choosing a bug through to proposing a fix
[22:56] <benji> yeah that'd be nice (and nice in general); Huw had several good ideas about ways to further improve that task too
[23:05] <sinzui> wgrant, mumble?
[23:18] <StevenK> sinzui: http://pastebin.ubuntu.com/654051/