[00:12] wgrant: ok :( [00:12] Yes :( [00:49] wgrant: community-contributions; can you sudo to lpqateam ? [00:49] if so, you could run it from that service accounts crontab [00:54] lifeless: I can't. [00:54] I don't think many can. [00:55] its available on request, if you want it [00:58] 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] jelmer: Yeah ;/ [00:58] :/ [01:32] Project devel build #925: STILL FAILING in 5 hr 44 min: https://lpci.wedontsleep.org/job/devel/925/ [05:09] Project db-devel build #761: STILL FAILING in 5 hr 38 min: https://lpci.wedontsleep.org/job/db-devel/761/ [06:31] stub: \o/ [06:34] *\o/* *_o_* *\o/* [06:35] :) [06:36] want to see if the internets are working and do a catchup call ? [06:40] lifeless: sure. gimme a tick for the caffine to kick in. === stub1 is now known as stub === stub1 is now known as stub [06:51] wgrant: do you know -why- or ui gets broken by having series tasks w/no non-series 'parent' task ? [06:51] wgrant: like, was it oversight? deliberate? ...? [06:53] 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] As series tasks have only the series name. [06:53] Not the Distribution/Product/DSP [06:53] the original wasn't like this [06:53] As in most cases they would just be massively duplicating information. [06:54] Mmmm, it hasn't been changed much since 2006's release management rework. [06:54] Which introduced conjoinment. [06:54] I'm old skool [06:54] I didn't really use series tasks before then. [06:58] Hi StevenK. [06:59] lifeless: So, until we redesign the UI and or model... [06:59] I may be wrong, but it seems shallow to me. [06:59] It requires a major redesign of a piece of UI which was thoroughly designed in 2006. [07:00] 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] 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] b/launchpad/dsd-creation-multiple-parents-bug-815775/+merge/69407 [07:00] StevenK: https://code.launchpad.net/~rvb/launchpad/dsd-creation-multiple-parents-bug-815775/+merge/69407 [07:00] wgrant: I'm sure we could do a major redesign, I don't see that one is needed. [07:00] lifeless: How do you propose to fix it? [07:01] up 2 lines. [07:01] I'm not sure it's worth it, given it will hopefully all be redesigned soon. [07:01] Oh. [07:02] Could do, I guess. [07:02] thats what the bug boils down to isn't it? 'series task on its lonesome is missing context description' [07:02] rvba: You only need one loop: for series in derived_series.getParentSeries() + derived_series.getDerivedSeries(): [07:03] other than conjoined tasks we don't have special business rules or cross-task conditional logic. [07:03] rvba: I thought may_require_job() did the child stuff? [07:03] -> out [07:04] StevenK: Thanks. [07:06] lifeless: Yeah, true. It's just a bit ew. [07:06] But this possibly makes it a bit less ew. [07:08] I think this is a shallow oversight in that earlier work, rather than a big issue. [07:09] Possibly. [07:09] Not sure how to make it clear that it's not a real task. [07:10] But I guess we'll find out. [07:10] well it is a real task isn't it ? [07:10] the only real special logic needs to be conjoined - when the user sees one task, we need to move two. [07:11] Do you propose to show the project/distro/DSP in the series task, or as a ghost parent? [07:11] I assumed the latter. [07:12] oh, I see what you mean [07:12] I was proposing a line, like a task line, but with no status importance assignee milestone fields [07:12] That's what I thought. [07:12] Just need to make it clear it's not a real task. [07:12] sure [07:12] Conjoinment already confuses people with fake tasks. [07:13] huwshimi may have some ideas. We could do what conjoinment does - no worse. [07:18] Project devel build #926: STILL FAILING in 5 hr 45 min: https://lpci.wedontsleep.org/job/devel/926/ [07:34] stub: caffeinated ? [07:36] lifeless: for now :) [07:42] good morning [07:57] 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] Not sure what to say. [07:57] Since I don't think we're allowed to talk about tasks. [07:58] wgrant: I think it would be fine with no blah blah blah [07:58] Possibly. [07:59] I guess it's going to be fairly rare. [07:59] Reviewer in the house? https://code.launchpad.net/~jtv/launchpad/bug-816833/+merge/69597 [07:59] wgrant: yeah [07:59] 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] Hello === almaisan-away is now known as al-maisan [08:42] hi mrevell [08:43] Hallo jtv [09:01] could someone please review https://code.launchpad.net/~jml/launchpad/create-private-ppa-814567/+merge/69539 [09:06] jml, is that going to stay a commercial admin-only operation? [09:06] james_w: bigjools often expresses a desire to change it. [09:07] james_w: although I've not actually heard an outline of an alternative. [09:07] james_w: why do you ask? [09:08] We need a PPA admin celeb [09:09] if this is for appdevelopers then we're not going to make them commercial admins [09:09] there's a software center celeb for that [09:09] it has permission to make private PPAs [09:11] but that doesn't necessarily fit the desired workflow though [09:12] right [09:12] the workflows are ill defined [09:17] this is a specific instance of a more general entitlement problem [09:17] permission to create private X, and the means by which those permissions are acquired [09:19] jml: in your branch did you consider refactoring the check for commercial admin, somehow? [09:20] I'm not sure how I'd do it tbh :( [09:20] 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] jml: I'm just wary of duplicating the check, that's all. Been there, picked up the pieces :( [09:22] bigjools: yeah. I can put a note in the new code & the zcml if you'd like, pointing one to the other. [09:22] jml: fair enough, thanks [09:26] bigjools: clear enough? http://pastebin.ubuntu.com/653641/ [09:26] jml: perfect [09:27] 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] jml: ! [09:27] wth [09:27] allenap: Are you OCRing today? [09:27] gmb: Yes. === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap | Critical bugs: 240 - 0:[#######=]:256 [09:27] jml: set a commit msg [09:27] bigjools: I left ~canonical-launchpad. lifeless & flacoste have yet to re-establish the broader launchpad committer policy. [09:27] gmb: I've just done one of yours. [09:28] jml: I am sure we have other internal committers [09:28] allenap: Ah, magico. Thanks. [09:28] bigjools: they are in ~launchpad [09:28] bigjools: jml jumped, he was not pushed :P [09:29] yeah. [09:29] wanted to be clean. [09:29] gmb: Fwiw, I think that would have been fine as a self-review. [09:29] dirty :) [09:29] & also to not get sucked back into LP stuff too much, thus doing a disservice to my new overlords [09:29] allenap: Agreed. But I always forget I can do those until after I've asked. [09:34] jml: your branch is hitting ec2 now, thanks for your contribution :) [09:34] my pleasure :) [09:49] anybody with buildout foo around? [09:52] henninge: I hesitate to say this, but I have a little. What's up. [09:53] gmb: I am trying to get my own version of ZConfig build. [09:54] hackinglazrlibraries ? [09:54] allenap: may I add that to you queue? https://code.launchpad.net/~rvb/launchpad/dsd-creation-multiple-parents-bug-815775/+merge/69407 [09:55] *your [09:55] gmb: I am following the instructions in doc/buildout.txt [09:55] rvba: Certainly :) [09:55] allenap: Thanks ;) [09:55] gmb: so, I have the modified source tree and did "setup.py egg_info sdist" which gave me a tarball in dist [09:56] gmb: I put that tarball into the download-cache, updated version.cfg and ran bin/buildout. [09:56] gmb: that gives me this error: [09:57] Getting distribution for 'ZConfig==2.9.1dev-20110728'. [09:57] error: NEWS.txt: No such file or directory [09:57] 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] henninge: Just for clarity, did you put the tarball in download-cache or download-cache/dist? [09:57] henninge: How did you get the version suffix? [09:57] gmb: so two possible questions: Why does NEWS.txt not get included in the tarball? [09:57] henninge: You didn't rename the tarball manually? [09:57] gmb: in dist [09:58] wgrant: no, sorry, I used "-d" on setup.py [09:58] Ah, good. [09:58] -d, or -b? [09:58] * henninge checks [09:58] wgrant: the one that does it automatically [09:59] -d [09:59] Right. [09:59] henninge: Lickily for you, the Oracle of Melbourne has arrived. [09:59] Luckily, even. [09:59] second possible question: Why does buildout expect NEWS.txt to be in there? [09:59] gmb: ;-) [09:59] henninge: It must be in the manifest of the tarball. [10:00] jtv, allenap, danilos: Need any help with QA? There's a germanium cowboy that I'd like to squash ASAP. [10:00] henninge: Is this tarball in lp-sourcedeps yet? [10:00] Lickily sounded eerily appropriate [10:00] I need to run publish-ftpmaster. [10:00] wgrant: I'll take a look at mine. [10:00] wgrant: yes, it is [10:00] Let me see. [10:00] jtv! Let's do it [10:00] jtv, allenap: Thanks. [10:01] jtv: I guess you should also test cron.publish-ftpmaster, or maybe just pretend that everything will be OK. [10:01] Since it's not exactly a controversial change. [10:01] Yes, good point — I can run the existing cron.publish-ftpmaster. [10:01] That's assuming I can. [10:01] Worth a try. [10:01] wgrant: Done. [10:01] But not worth a vast quantity of effort if it proves non-trivial. [10:02] wgrant: I'd still like to be able to run the new script separately later today though, and get verifiable results. [10:02] True. [10:03] wgrant, I need help with CHR, will get to QA asap :) [10:04] henninge: I'm not sure ZConfig is set up well enough that you can use setup.py to build a tarball. [10:04] henninge: I suspect you may need to hack the version and tar it up manually. [10:04] Since setup.py references NEWS.txt in the cwd without asking for it to be installed. [10:05] Hmm, but 2.7.1 still has egg_info... [10:06] You may need to invoke gary or similar, I fear. [10:06] ZConfig is a little strange. [10:07] wgrant: gary sent me down this path ... ;-) [10:08] I wonder if adding NEWS.txt to MANIFEST.in would work. [10:09] let me see what I get when I build from the 2.7.1 source [10:11] wgrant: Actually, I need to spend some more time looking at r13538. [10:12] wgrant, my rev is qa-ok [10:13] danilos: Thanks. [10:14] wgrant: bigjools just told me we can test the existing publish-ftpmaster script now. [10:14] henninge: you've tracked the rotation segfault to zconfig ? [10:15] lifeless: yes, it simply closes and opens the files with no logging whatsoever. [10:15] s/logging/locking/ [10:15] \o/ [10:15] gary suggested a simple fix to simply not close the file. GC will do that ones all processes are done with it. [10:16] s/ones/once/ [10:16] I hope upstream won't accept that. It's not very portable. [10:16] why not? [10:16] portable accross python version? [10:16] CPython's reference counting is an implementation detail. Relying on GC for managing external resources like that isn't a great idea. [10:17] eg. will behave differently in Jython and PyPy. [10:17] I see what you mean [10:18] also on windows [10:19] on windows you can't replace open files under all conditions [10:19] (not that I care about windows) [10:19] henninge: do you mean 'threads' or 'processes' ? === al-maisan is now known as almaisan-away [10:23] lifeless: it's threads AFAIUI [10:23] it should not be too hard to implement proper locking [10:23] the logging module does that, too. [10:25] 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] 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] henninge: or something-like-that [10:27] 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] lifeless: I had been thinking along those lines at first, too, but hoped for a simpler solution ... [10:28] oh, that is a nice idea, too. [10:30] bigjools: can I just run cron.publish-ftpmaster on dogfood then? [10:31] And allenap… thanks! [10:31] jtv: doit [10:31] And given that you're speaking French today… [10:31] "must" [10:32] :) [10:32] jtv: allez [10:37] 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] danilos: I have not, no. [10:38] danilos: I just told him that it would need some and that it looks like there are more bugs hidden there.# [10:39] henninge, right, fair enough, I'll see if I can get some dedicated time to look into it tomorrow-ish then [10:39] 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] 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] 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] danilos, Okay, no problem. [10:42] danilos, I can talk now. [10:42] mrevell, excellent [10:42] * danilos shuts the music down and switches to headset [10:42] mrevell, how about skype? :) [10:42] danilos: thanks [10:43] * mrevell engages the Skypotron [10:43] bigjools, wgrant: cron.publish-ftpmaster isn't really supposed to complete within the minute, is it? [10:43] depends how much work there is. got a log? [10:44] but generally no :) [10:45] rsync: change_dir "/srv/launchpad.net/ppa/ubuntu-partner/dists" failed: No such file or directory (2) [10:45] heh [10:46] log: http://paste.ubuntu.com/653691/ [10:47] jtv: just make the dir [10:48] seems like the PPA repo purge I did blew away DF's partner archive [10:48] /srv/launchpad.net/ppa/ubuntu-partner is empty… mkdir /srv/launchpad.net/ppa/ubuntu-partner/dists? [10:48] yes [10:48] Erm, /srv/launchpad.net/ppa? [10:48] Oh. [10:48] You need to hack the script. [10:48] publisher doesn't need it but that script does [10:48] I remember this from last time. [10:48] It checks if the config is right or something. [10:49] And if not uses /srv/launchpad.net/ppa, because why not. [10:49] that directory is served on Apache, it's useful for testing [10:49] if [ "$LPCONFIG" = "$PRODUCTION_CONFIG" ]; then ARCHIVEROOT_PARTNER=/srv/launchpad.net/ubuntu-archive/ubuntu-partner [10:49] Ah. [10:50] the script is fine [10:50] Fine, perhaps. But still crazy :) [10:50] except rsync hates it when dists is missing [10:50] So we'll give it one. [10:50] yes [10:53] (haven't mentioned it but it's running) [10:58] Project db-devel build #762: STILL FAILING in 5 hr 48 min: https://lpci.wedontsleep.org/job/db-devel/762/ === almaisan-away is now known as al-maisan [11:14] mrevell: ping [11:14] Hi cjohnston [11:14] Want to setup a time? [11:15] cjohnston, Yes please. How does 14.00 UTC sound? [11:16] ~3 hours from now? [11:16] I guess 2 hours 45 minutes from now [11:17] cjohnston, Yeah. [11:17] Sounds good [11:18] Great, thanks cjohnston, speak to you later. [11:24] 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] bigjools: Hmmmm. For which bit? [11:34] StevenK: it calls fetch_information which always returns from_addr that way [11:34] the syncs we did yesterday had "From:" as the Debian uploader [11:35] bigjools: Yes, but the notification to changed-by, or the announce? [11:35] StevenK: both [11:35] Hmmmmm. [11:35] This is difficult. [11:35] Agreed [11:35] For the announce list we really want the author of the change. [11:36] For an Ubuntu upload that's Changed-By. [11:36] For a sync, that's the requester... not necessarily the blamer, but perhaps we can just use the blamer there. [11:36] We can't just unconditionally use the blamer. [11:36] ok [11:36] the old code used katie as a sign it was a sync [11:36] Yes :/ [11:36] feck sake [11:37] in fact wasn't that the chnaged-by? [11:37] If it's from PCJ, the requester is the blamer. [11:37] indeed [11:38] bigjools: katie was for autosyncs. [11:38] It's in Changed-By in that case. [11:38] right [11:38] For manual syncs, katie is not involved. [11:38] is sync-source mangling anything ? [11:38] For manual syncs, Changed-By was the requester [11:38] I *think* [11:38] exactly [11:38] bigjools: Yes. [11:39] sync-source puts the requester in Changed-By. [11:39] https://launchpad.net/debian/sid/+source/gedit-plugins/3.0.5-1 [11:40] I think Gina has a bug, can you spot it? :) [11:40] Yes. [11:40] Also, it's using Debian URLs in emails. [11:40] yeah I know [11:40] I guess it's asking for the SPR's canonical_url, rather than the DSPR, perhaps. [11:40] It does use the SPR [11:40] bigjools: Oh, you're using changelog_entry in notify()? [11:40] That's not really suitable. [11:41] when you say "you're" .... [11:41] We need to parse changelogs. [11:41] "you're" == red [11:41] == StevenK :) [11:41] Not my code any more [11:41] ha [11:41] it's all our code but since you wrote it you don't get to escape [11:41] I waved StevenK's code through with the understanding that it was an initial refactoring to be tested and made suitable later :( [11:42] Since there was lots of refactoring :( [11:42] And so far, we've discovered that the one missue of it was due to PCJ suckage [11:42] bigjools: I don't get to fix it either [11:43] StevenK: dude, I am just asking for some info, not a fix [11:43] Which you have -- sync-source does Wierd Shit[tm] [11:44] so, the code as it is works fine, except for syncs where we want From: to be the blamer [11:44] yes? [11:44] bigjools: I believe so. [11:44] thanks [11:45] easy enough to fix [11:47] Let's hope. [11:47] It's faaaairly well-factored now. [11:47] And even somewhat tested. [11:50] 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] Pass in the override [11:50] Simplest, easiest way [11:51] And won't effect the existing tests [11:51] It shouldn't know about syncs, so is_sync is out. [11:51] Possibly a from_blamer, or some similar flag like that, though... [11:51] Rather than having to calculate the address yourself. [11:52] well it should pass in a Person [11:52] From may not be a Person [11:53] it should be [11:53] so that the preferred email stuff is all dealt with inside the notify code [11:53] notify() doesn't take a from_addr [11:53] it will do in 5 minutes [11:53] Ew [11:54] notify() has too many arguments already :-) [11:54] shit happens [11:54] Perhaps a trust_changed_by=True argument, or something. [11:54] Otherwise you are going to have to inspect the SPR's people. [11:55] eh? [11:55] the from_person will default to None [11:55] It just feels fairly dirty for the callsite to have to get the people itself. [11:55] I disagree on that - it's just an override and used in special cases, like syncing. We already know the person. [11:56] and this is feeling like bikeshedding [11:57] It is not quite bikeshedding, but close, true. [11:57] we already pass blamer, I don't see the problem with knowing the person who sends the email [11:58] Yeah, maybe. [11:58] I'm just worried that this could end up turning into a bigger mess than it was before :) [11:58] Still, at least it won't have katie celebrities this time. [12:00] yeah, when sync-source stops getting used we can throw that bit of code away [12:01] thank you for your input gentlemen [12:02] Killing celebrities is a favourite pasttime of mine. [12:04] hmm interesting, the email to blamer would end up being the config.uploader.default_sender_address) [12:04] from the* [12:04] That's how it tends to be, yes. [12:04] guess that's ok [12:04] 'Launchpad PPA' or 'Ubuntu Installer' have historically sent the non-announcement emails. [12:04] indeed [12:10] jtv: cron.publish-ftpmaster's not yet blown up? [12:10] No, sorry [12:10] 2011-04-18 10:59:36 INFO Done with ubuntu natty. [12:10] .0.1-1 [12:10] Getting ancestry for 3depict - 0.0.2-1 [12:10] Getting ancestry for gdc-4.4 - 1.063-4.4.5-2ubuntu1 [12:10] Getting ancestry for gdc-4.4 - 1.063-4.4.5-2 [12:11] Actually, maybe it's blown up and just not told anybody. [12:11] It hasn't produced any new output for a while. [12:11] gary_poster: Hi! [12:11] jtv: I would not put that past it. [12:12] Hmm can't find the process. [12:12] So that sounds dead. [12:12] 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] But what is that? [12:12] germinate? [12:12] hey henninge [12:12] LP doesn't print that sort of message. [12:12] gary_poster: qastaging doesn't have mailman. [12:12] gary_poster: But staging does, and got the rev a while ago. [12:12] wgrant, I was afraid of that [12:12] oh ok excellent [12:12] thanks wgrant [12:12] gary_poster: And successfully resynced, and I created a new list and it was created after it resynced. [12:12] So it seems to be OK. [12:12] wgrant, heh, you rock! [12:13] thanks also for the email about the OOPS wgrant [12:13] Sorry I didn't chase that up earlier. [12:13] np at all [12:13] gary_poster: I am almost there but I have a problem with building the egg using the egg_info command. [12:14] and, bigjools, thanks for your email. I'll rerun that query after I get a few other things handled [12:14] yup [12:14] Pretty much all the runtime seems to be 20 minutes of just this. [12:14] henninge ok (egg_info just modifies egg data; sdist makes the sdist) [12:14] gary_poster: it does not include the file NEWS.txt althogh that is mention in setup.cfg. Any idea why? [12:14] gary_poster: ok, then it's sdist [12:15] I did not realized those were two chained commads [12:15]