#launchpad-dev 2009-05-11
<andrea-bs> Hello! Can you tell me why all the classes in the lazr package don't inherit from ``object``?
#launchpad-dev 2010-05-17
 * thumper is back
 * thumper EODs
<adeuring> good morning
<mrevell> Good morning
<thumper> jelmer: hey
<jelmer_> thumper: Hi!
<thumper> jelmer_: what's the status of bzr-git and dulwich?
<thumper> jelmer_: I'd like to rollout updates
<jelmer_> thumper: I've fixed the issue with http last week and we now import HEAD branches again, we should be able to rollout current dulwich and bzr-git's roundtrip branch.
<thumper> so tips of both?
<jelmer_> thumper: (did I mention 'bzr serve --git' works in a native bzr branch now?)
<thumper> jelmer_: I think I saw your 'dent about it
<thumper> jelmer_: how efficient is it?
<jelmer_> thumper: It's very quick on small (small as in inventory) branches, very slow on large inventory branches
<thumper> jelmer_: do you know why it is slow?
<thumper> jelmer_: fixable?
<jelmer_> thumper: Creating the Tree objects from inventories on the fly is very slow and O(size-of-tree)
 * thumper nods
<jelmer_> thumper: We need to cache those Tree objects, should be able to do so once jam's work on packs lands.
<jelmer_> thumper: I'm merging the roundtrip branch into trunk atm with roundtripping itself disabled for the moment.
<jelmer_> (it's got a lot of other improvements but I don't want to be tied to the current syntax for roundtripped data)
<thumper> ok
<thumper> jelmer_: just send me an email when it's ready with revnos for lp:dulwich and lp:bzr-git
<thumper> jelmer_: and I'll get them updated
<jelmer_> thumper: will do
<thumper> jelmer_: thanks
<deryck> Morning, all.
<wgrant> jelmer_: bzr serve --git crashes for me :(
<wgrant> AttributeError: 'BzrBackend' object has no attribute 'object_store'
<wgrant> bzr-git/dulwich 0.5.0.
<bigjools> morning deryck
<jelmer_> wgrant: you need a newer dulwich, bzr-git from lp:~jelmer/bzr-git/roundtrip
<kfogel> mrevell: it looks like RT 39801 has been done, meaning that our help and dev wikis are now editable only by members of ~launchpad-doc (for spam protection).  I'm planning to a) announce this in the appropriate places, b) document it likewise, and c) approve the currently pending team members at https://edge.launchpad.net/~launchpad-doc/+members#active.  Thoughts?
<mrevell> kfogel, Thanks for handling that. Your plan looks ideal to me. I have two questions: do you think it's worthwhile contacting each existing member of the team directly to explain the new meaning of their membership? Also, do you think there's now a role for the team mailing list? I think "Yes" to the first and I'm not sure about the second.
<kfogel> mrevell: I agree.  "Yes" to the first, but for the second, let's just direct people at #launchpad-dev and the other usual places if they have questions.
<kfogel> mrevell: oh, looks like I'll need to be a team administrator.  Really, anyone in ~launchpad could be an admin.  Can we do that?
<mrevell> kfogel, ~launchpad is now an admin of that team
<kfogel> mrevell: fast action, sir.
<mrevell> kfogel, :) As for contacting members directly, to tell them of the team's altered role, I don't think everyone in the team is a member of the ML
<mrevell> kfogel, but the membership is fairly small so we can easily contact them directly
<kfogel> mrevell: I was just going to mail them individually.
<mrevell> cool
<mars> jml or allenap, ping, would either of you be available to help debug a possible hang in some Unix IPC code using the subprocess module?  I have a few questions about a 40 LoC block I'm studying.
<allenap> mars: I'll have a look.
<mars> thanks allenap, I'm pasting it now
<mars> allenap, http://pastebin.ubuntu.com/434980/
<maxb> line 13, comment is lying
<maxb> that's where you end up if the TIMEOUT runs out
<mars> maxb, ok, that's why I asked other people :)
<mars> maxb, so STDOUT could still be open, but the select() has timed out?
<maxb> yes
<mars> ok
<mars> allenap, ^
 * mars changes the comment
 * maxb wonders why the code uses os.read(blah.fileno())
<allenap> mars: Yes, I noticed that. What were your questions?
<allenap> mars: Is it working?
<mars> maxb, allenap, fwiw, I'm trying to figure out why the test suite is hanging with the ec2 testrunner.Â  This code should kill the entire test suite.  But it might not be.
<mars> allenap, I'm wondering if something in this timeout code is buggy in such a way that the test suite could hang, but this code doesn't catch and kill it.
<mars> allenap, my XXX comments are where I would start.  They ask basic Unix programming questions that I have, that I can not answer.
<mars> Without reading "Advanced Unix Programming".  I need the fix a bit faster than that.
<mars> hmm
<mars> maxb, if what you say is true...   During a hang, the test suite has stopped printing output.  That means the select() is timing out, right?
<maxb> yes
<mars> so that narrows the bug down to that branch of the conditional.
<mars> so the hang is in this code path, or this code is running correctly, and the fault happens after this entire script has exited (test_on_merge.py exits correctly, but fails to send mail or something).
<mars> maxb, allenap, is the XXX on line 17 a valid concern?
<allenap> maxb: subprocess.Popen._communicate() does the fileno() thing. mars: Might be worth looking there and copy that select() loop as closely as possible.
<mars> allenap, yeah, I was wondering why they didn't use .communicate().
<allenap> mars: If proc.poll() is not None then the process has definitely terminated.
<allenap> mars: .communicate() only returns the result at the end. Don't want to wait that long while running the test suite :)
<maxb> Line 17 could be hit if the test process exited but a subprocess spawned by the test process still retained the open stdout file descriptor
<mars> allenap, ah, "is not None" means it's absolutely dead.  Ok.
<mars> I just re-read the docs, you are correct.
<mars> maxb, oh, that is something
<mars> it *does* do that
<mars> the process tree on a hung server has a few defunct processes
<mars> well, maybe
<allenap> mars: Yeah, line 28 will kill the child, but if its children are still alive and holding a reference to proc.stdout then line 31 will hang.
<mars> here, more info
<mars> maxb, allenap, process tree from a hung server.  Everything is still alive!  http://pastebin.ubuntu.com/434986/
<mars> the code never got to the killem() line :(
<allenap> mars: The firefox has not been collected by the parent :-/
<mars> kill_hung_process_with_a_series_of_brutish_instruments() was never called.  It will eventually SIGKILL the process in question.
<mars> allenap, yes, on my local system I had a sort of the same thing.  I had to send SIGHUP to Python itself in order for it to get collected.
<mars> kill -1 python-parent-process-id
<sinzui> mrevell, which project did you have the milestone problem with?
<mrevell> sinzui, launchpad, malone, rosetta, launchpad-registry and launchpad-foundations, so far
<sinzui> always 10.10?
<sinzui> ie 10.11 is always fine
<mars> allenap, firefox was started by the windmill testrunner.  I don't see it in the tree.  That means that it died or was killed.
<mrevell> sinzui, Yeah. Always 10.10. Everything else from 10.06 to 10.12 have been fine.
<sinzui> mrevell, I see them, how did you create 10.10 milestones?
<mars> allenap, maxb, that would leave the zombie processes.  So would the process tree I posted somehow lead the timeout code to hang?
<mrevell> sinzui, I refreshed the page so that the error message was replaced by a link to a new 10.1 milestone (which I hadn't created but appeared instead of the 10.10 milestone), then went in and changed the name of the 10.1 milestone to 10.10
<sinzui> okay thanks.
<maxb> What is the process actually being Popen-ed here?
<mars> maxb, line 1 of http://pastebin.ubuntu.com/434986/.
<maxb> Did the [[[print ("\nA test appears to be hung. There has been no output for"]]] actually occur?
<mars> allenap, maxb, here is the current code, uncommented http://pastebin.ubuntu.com/434992/.  This makes no sense:  line 19 and 23 must have run.  The processes are still alive!
<maxb> And just what is kill_hung_process_with_a_series_of_brutish_instruments?
<mars> maxb, that function is a rewrite I did of lines 19 through 23 of http://pastebin.ubuntu.com/434992/
<mars> maxb, just for clarity.  The code I just pasted is what is actually run by the server, but it was too dense for me to understand.  So I rewrote and commented it before posting.
<maxb> What is killem?
<mars> hmm
<maxb> It would be interesting to add some logging to see what PIDs it's *actually* sending signals to
<mars> if we had console output for the log to write to :/
<mars> or python standard logging installed and running in this script...
<mars> maxb, I can add logging if that would help.
<maxb> Well, I'm a bit baffled, so I'm clutching on to the fact that if the process is still running, a SIGKILL can't have really happened.
<mars> maxb, here is the killem() function: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head:/test_on_merge.py#L189
<mars> maxb, allenap, killem() runs os.killpg(), not os.kill().  Does that matter?
<mars> (I suspect it might?)
<mars> hmmm
<mars> column 3 of http://pastebin.ubuntu.com/434986/ is the process group ID
<mars> oh
<mars> line 6
<mars> firefox <defunct> is part of a different process group.  But that doesn't make sense.  Could the windmill testrunner have been the target of the process group kill?
<mars> maxb, I think you are right.  The best next step is probably to add some logging to the code to see what it is killing, and why.
<maxb> Clearly we have an issue if the kill code is expecting the entire tree to be just one process group, but it isn't
<allenap> mars: Where does the select() loop run? Is it in the test runner? If so, then it's running in pid 15177 and 20962.
<allenap> mars: Ah, it's in test_on_merge.py
<mars> allenap, sorry, I don't understand?  the select() loop is in test_on_merge.py, which... hey, if test_on_merge.py is still running, shouldn't it be in the process tree as well?
<mars> allenap, the first column of http://pastebin.ubuntu.com/434986/ is the PPID.  Notice that it is '1' for a few of those?
<maxb> hahahahahaha
<allenap> mars: Yes, it should!
<maxb> By killing the process group in this way, the supervisor script is killing itself :-)
<mars> blah
<allenap> maxb: Is it?
<maxb> I tried typing out a few key lines in an interactive python
<maxb> and that's what it seems to indicate
<maxb> proc = Popen('sleep 3600', stdin=PIPE, stdout=PIPE, stderr=STDOUT, shell=True)
<maxb> os.killpg(os.getpgid(proc.pid), 9)
<allenap> maxb: But isn't it doing os.killpg(proc.pid)?
<allenap> maxb: Scratch that.
<allenap> Doh.
<allenap> maxb: There's a comment in killem saying "Note that bin/test sets its process to a process group leader".
<mars> allenap, os.killpg(os.getpgid(pid), signal)
<maxb> allenap: oh, ok
<maxb> hrm
<allenap> maxb: The process tree bears that out I think.
<allenap> mars, maxb: The Popen call has shell=True; killem() is killing the shell.
 * allenap has to restart router
<mars> allenap, back?
<mars> nope, still away
<allenap> mars: Hi. If you said anything between my last message and "allenap, back?" then I missed it.
<mars> :)
<mars> nope!
<mars> allenap, thought of something
<mars> possible cause then
<mars> so normally, killing the shell would take everything with it
<mars> but I have observed that Python can get deadlocked(?) on the windmill process.  Python won't respond to a SIGTERM even.  You have to SIGHUP it.
<mars> So, if we have the windmill/Python deadlock, the suite hangs.  test_on_merge says "Oops, better kill it!", and kill the shell.  But Python ignores the shell's SIGTERM, and keeps running, along witheverything in the tree under it.
<mars> allenap, maxb ^ does that make sense?
<allenap> mars: That makes a lot of sense. So, perhaps send HUP or QUIT before KILL.
<allenap> mars: Alternatively, get the Popen call to work without shell=True
<mars> allenap, should HUP walk the process tree maybe?  This code assume that killing the shell is enough.  Obvious that is not a thorough approach.
<allenap> mars: Or make cmdline = "exec " + cmdline
<allenap> mars: Maybe it should, but see if this works first.
<mars> exec would terminate the test_on_merge code path, wouldn't it?
<allenap> mars: No, it would mean that the test process replaces the shell used to invoke it, so that killpg kills the test process group.
<mars> oh!
<mars> yes
<mars> allenap, awesome, thank you
<allenap> mars: But, I'm not sure the shell=True bit is necessary anyway.
<mars> allenap, well, you were wondering if the entire select() loop was needed instead of just using .communicate(), so I can't say if any of this code should stay.
<mars> allenap, they may have used their own select() loop to save .communicate() from buffering too much output.
<mars> there is a warning in the module docs about that
<allenap> mars: No, you definitely shouldn't use communicate(); but Popen._communicate() does have an implementation of a similar select() loop that I thought was worth studying. For example, it has an exception handler around select() to catch EINTR. Actually, other than that it's very similar.
<allenap> mars: In any case, it doesn't look like the problem lies in that direction anyway.
<mars> right
<mars> well, this is one huge step closer to getting things working again
<mars> maxb, allenap, thank you for all the help!
<allenap> mars: You're welcome. I hope it works now :)
<kfogel> mrevell: I think I'd like to actually deactivate the launchpad-doc@ mailing list entirely.  Its original purpose is now obsolete.  Any objections?
<mars> leonardr, something you may find interesting: http://factoryjoe.com/blog/2010/05/16/combing-openid-and-oauth-with-openid-connect/
<mrevell> kfogel, None at all
<kfogel> mrevell: thanks.  Also, should I update https://help.launchpad.net/DocTeam to say it's obsolete?
<mrevell> kfogel, Please, if you don't mind.
<kfogel> mrevell: no problem.
<mrevell> Night all
<sinzui> OMG. I made staging much faster that edge.
<cody-somerville> how?
<thumper> sinzui: how??
<sinzui> thumper, I used memcached tales directives on milestone and portlets. I may have fixed another issue doing this, https://staging.launchpad.net/libpng/main/+index loads faster on staging then edge for me
<thumper> sinzui: please write it up for the list - I'm not sure how to use the memcached tales directives
<thumper> sinzui: oh you did already
<sinzui> thumper, I will if my branch lands. I am sure engineers will love all the broken browser tests that caching created
<sinzui> for me
<mars> gary_poster, ^
<gary_poster> sinzui, yay! :-)
<gary_poster> sinzui, that was for memcached
<sinzui> thumper, I have not. written up what I did, yet, I just submitted the review. I want to cache some of our tales formatters if it proves to be faster than db lookups
<sinzui> gary_poster :)
<mars> sinzui, I wonder how many of those requests are for breadcrumbs...
<mars> sinzui, probably not as big a payoff.  What you found is huge.
<sinzui> mars, indeed that too crossed my mind. the header of pages can be cached. project/person displayname changes are rare.
<lifeless> gary_poster: leonardr: ping - mod_compress
<gary_poster> lifeless: pong, hi
<lifeless> I'm a little surprised that you didn't just fix apacge
<lifeless> blah, apache
<lifeless> I wanted to check my facts at the source :)
<leonardr> lifeless: nothing we would consider to be 'fixing apache' is acceptable to apache upstream
<gary_poster> lifeless: :-) I'd be +1 on fixing it in apache, but from what I understood of Roy Fielding's response to the bug, the proper fix is a new filter.
<lifeless> leonardr: oh! thats surprising
<leonardr> see https://issues.apache.org/bugzilla/show_bug.cgi?id=39727#c31 for example
<gary_poster> leonardr: couldn't we have made a new filter?  Or did I misunderstand Roy Fielding's suggestion?
<lifeless> roy specifically says
<lifeless> If mod_deflate modifies
<lifeless> ETag on the way out, then its corresponding later requests must
<lifeless> be reverse-modified (etags and request content) on the way back.
<lifeless> which is completely consistent with my view, and the source of the issue [that mod_compress or whatever we're using *is violating* that MUST]
<gary_poster> Ah, I was misrembering just a bit.  This was the line I was trying to remember:
<gary_poster> The best solution is to implement transfer-encoding as an
<gary_poster> http protocol filter module.
<lifeless> well, thats TE
<leonardr> yeah
<lifeless> which is different
<gary_poster> yeah
<leonardr> that's what we tried to do, but the intermediaries stripped it
<gary_poster> that was the misremembering part
<leonardr> roy also rejects the solution i thought would work:
<leonardr> Preprocessing all incoming conditional headers to remove
<leonardr> a -gzip suffix before the request is processed won't work.
<leonardr> In a chain of Apache servers, we won't know which server
<leonardr> set the suffix and how many caches have stored the modified
<leonardr> ETag versus the unmodified ETag.
<lifeless> so
<lifeless> a latter comment addreses that, though you have to be prescient to parse it
<lifeless> (have each server uniquely add its suffix, and have the sysadmins be responsible for ensuring a matching back-path)
<lifeless> I think that Apache would accept a patch which strips the -gzip, when an option is set.
<lifeless> there are lots of special-case vs general case situations in surrogates vs http as a whole
<leonardr> there is already a patch that strips the -gzip always
<lifeless> ok
<lifeless> I suggest we: get that applied to our apaches
<lifeless>  say in the review for that patch that we need it, and discuss whats required to get it in mainline
<leonardr> ok, what's the process for patching our apache?
<gary_poster> so, lifeless, I have to go half an hour ago, but is this the position:
<lifeless> also, in #squiddev I'm asking hno what he thinks the situation is
<gary_poster> - the gzip suffix could eventually be customized
<lifeless> [henrik nordstrom from thast bug report]
<gary_poster> (per server)
<gary_poster> - at that point the underlying concerns could be addressed, because that specific server's suffix could be targeted
<lifeless> leonardr: in a chroot/vm of hardy which is what we have deployed, do an apt-get source apache2, apply the patch using whatever patch system its building with, and make sure it builds, then file an RT ticket, and include the debdiff
<gary_poster> - meanwhile we have a hard-coded suffix.  We could have a flag to remove the suffix, whatever it is; at this point it is particularly easy, because it is hardcoded
<lifeless> gary_poster: precisely. making it customised might be a way to get apache upstream to let useful code into their code base
<gary_poster> lifeless: ok, thank you for the clarification.  I'm happy with that if the LOSAs are happy with that (as I expect they would be).
<gary_poster> thank you
<gary_poster> need to run
<lifeless> U1 has patched their apache
<lifeless> with a different patch, but similar sort of situation [though theirs was a simple backport]
<lifeless> gary_poster: ciao
<leonardr> implementing this is outside my area of competence, but if you and the losas are happy with changing apache to handle this problem, that's good news for me
<lifeless> losa: ^ cross-check please
<lifeless> thumper: I'm curious (as a test framework writer) what prompted lp:~thumper/launchpad/fix-factory-ids-in-tests
<mwhudson> lifeless: a test failed in launchpad because it depended on exact values returned by the factory and miscellaneous refactoring changed that
<mwhudson> so i changed the factory to return different values and ran the entire test suite and filed a bug with the failure
<mwhudson> s
<lifeless> ah
<lifeless> I guess I meant
<lifeless> 'why change from using the unique stuff'
<lifeless> not 'why did some tests fail'
<lifeless> mwhudson: ^
<mwhudson> i haven't looked at the branch itself
<elmo> leonardr/lifeless: I really don't want to carry a patch to apache forever; I accepted the U1 patch because it's an upstream patch
#launchpad-dev 2010-05-18
<lifeless> elmo: ok
<lifeless> so we need to discuss with apache a bit more
<elmo> leonardr/lifeless: unless we can guarantee the patch will go into upstream or at least ubuntu, I'd need to be convinced the maintenance cost would be justified
<leonardr> lifeless: in the meantime, would you mind if i applied my lazr.restful-based workaround?
<lifeless> leonardr: of course; I think I wouldn't have asked these questions though, if you'd had a reference to the upstream state of discussion in the patch.
<lifeless> e.g. bug <url> is tracking the issue and apache are currently undecided about whether to fix this or not
<leonardr> lifeless: fair enough. i did link to the apache bug in my lazr.restful branch, but i didn't discuss it in any detail, and also there are two branches
<lifeless> elmo: I'd like to see it go into Ubuntu regardless; its nuts to do a half-job the way it does.
<thumper> lifeless: hey
<thumper> lifeless: voice would probably be easier if you have skype
<lifeless> I do
<lifeless> popping out to the doctors to register here etc, back soon
<lifeless> ok
<lifeless> thumper: so, skype?
<thumper> lifeless: in a kiwipycon committee meeting right now
<lifeless> ok
<lifeless> this arvo perhaps, then.
<lifeless> its really just curiosity about what worked/didn't work with the unique stuff for you.
<thumper> yep
<thumper> mwhudson: where do we update the rev numbers of the sourcecode dirs?
<mwhudson> thumper: utilities/sourcedeps.conf
<thumper> ta
<thumper> bzr uncommit; bzr shelve; bzr pull ../db-devel -r ancestor:../production-devel/ --overwrite
<lifeless> sounds like you wanted rebase?
<thumper> probably
<thumper> it didn't work anyway
<thumper> lifeless: what should I use?
<lifeless> what are you trying to do ?
<thumper> I created the branch from devel -r ancestor:production-devel
<thumper> but what I wanted was db-devel -r ancestor:production-devel
<thumper> so now I have a branch which I want to replace the history of
<lifeless> IIRC
<lifeless> make the new branch
<lifeless> use replay with a -r selector to replay your revisions from the branch you want to redo
<thumper> it is one revision which I could trivially recreate
<thumper> I was just thinking there'd be a way
<wgrant> Yeah, it's easy with rewrite as lifeless says. 'bzr rebase -r-1.. ../production-devel' should do it.
<wgrant> replay sort of goes the other way.
<thumper> wgrant: from the bzr-rebase plugin I take it
<lifeless> bzr-rewrite
<wgrant> But the package is bzr-rebase.
<thumper> gee that isn't confusing is it
<lifeless> blame jelmer
<thumper> lifeless: call now?
<lifeless> sure
<thumper> mwhudson: going to land https://code.edge.launchpad.net/~mwhudson/launchpad/unregister-bzr-git/+merge/24279 ?
<mwhudson> thumper: it failed tests
<mwhudson> so um, maybe?
<thumper> ah
<lifeless> mwhudson: what fails ?
 * thumper back later tonight to talk to europeans
<adeuring> god morning
<thekorn> hi adeuring, bryceh: is it possible to get a typo fixed before https://code.edge.launchpad.net/~bryceharrington/launchpad/api-doc-fixes/+merge/24786 gets merged?
<thekorn> line 10 of the diff has 'whcih'
<bryceh> hrm
<bryceh> thekorn, the ec2 instance to land the change just now completed
<bryceh> (not sure what that means in terms of being able to make changes)
<adeuring> bryceh: did you run "ec2 land" or "ec2 test -s"? in that case, your branch should soon appear in PQM
<thekorn> ah ok
<bryceh> adeuring, I ran ec2 test earlier today (with no -s), and then did ec2 land
<adeuring> bryceh: ok; in this case, the branch should be in PQM. Or have passed PQM
<bryceh> if it's too late to include the spelling fix this time through, I do plan on doing another docs fix and can include that fix with it
<noodles775> q bryceh
<noodles775> :)
<wgrant> Can someone please ec2 land https://code.edge.launchpad.net/~wgrant/launchpad/diffs-in-queue/+merge/25135 and https://code.edge.launchpad.net/~wgrant/launchpad/bug-558905-get-archive/+merge/25300? They both disappeared overnight.
<wgrant> Although I see that WindmillLayer has been killed off now, so these runs should work!
<noodles775> wgrant: sure.
<wgrant> noodles775: Thanks.
<mrevell> Morning
<noodles775> wgrant: did you have a third one? The first one wasn't approved yet so I'm guessing it didn't disappear overnight?
 * noodles775 switches it to approved and sends off.
<noodles775> And 'morning mrevell.
<jml> good morning Launchpadders
<wgrant> noodles775: Interesting. It was apparently sent off, so maybe neither of them were.
<noodles775> wgrant: ok, both sent now.
<wgrant> noodles775: Thanks.
<deryck> Morning, all.
<zyga> hello
<zyga> how hard would it be to deploy something like librarian outside of launchpad>
<mrevell> A bloke's here to change my electricity meter, so I'll be offline for 40 mins or so but working on laptop battery.
<deryck> gmb, hi.  So I think we need to do something this cycle about calculate-bug-heat runs causing us problems.
<gmb> deryck, Agreed.
<deryck> gmb, do we know why it hung yesterday?
<gmb> deryck, This particular problem is because it didn't run for a while during the rollout
<gmb> And whilst we fixed that last week all we ended up doing was deferr the problem for a week.
<gmb> So once again it's got too many jobs to deal with.
<gmb> deryck, The quick solution is to cancel all the existing jobs and randomize the heat_last_updated dates of all the bugs over, say, a 48 hour period, so that they don't get all bunched up.,
<deryck> gmb, ah, right.  So it's the offline run where we try to decrease heat on bugs that haven't been touched for awhile?  We end up with too many bugs needing to be touched, so too many jobs?
<gmb> But what we actually need to do is make calculation much more efficient, say with a stored procedure.
<gmb> deryck, Yes, exactly.
<deryck> gmb, I think we should focus on efficiency, not stop-gaps.  Though a band-aid today to get us running again is fine.
 * deryck looks for a bug....
<gmb> deryck, Agreed. I think we're going to have to do the calculation as a stored procedure.
<gmb> The Jobs system can't cope with the volume if we stop doing the work for 24 hours.
<deryck> gmb, is this bug 521447?  Or really we need a new bug about number of jobs created?
<mup> Bug #521447: Uninformative error message <error-handling> <errors> <javascript> <ui> <LAZR Javascript Library:Triaged> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/521447>
<deryck> oops :-)
<deryck> gmb, meant bug 557252
<mup> Bug #557252: Creating CalculateBugHeatJob is very slow <story-bug-heat> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/557252>
<gmb> deryck, I think it's a new bug altogether. I'll file one, and once that bug's fixed it will invalidate 557252.
<gmb> deryck, Basically, whilst it's nice that we try to do heat calculation in python, it's just not feasible for large numbers of bugs.
<gmb> (Because we do it iteratively).
<gmb> If come up with a stored proceedure which does the same job then we can use that for both decay and on-change re-calculations.
<deryck> gmb, and this is a trade, right?  So we move the calculation out of python and into the db?  We won't have to do this in two places, will we?
<gmb> deryck, Right. If we're going to do this we need to do it such a way that it completely supersedes the Jobs system work, though there could be a transitional period where we use both for the sake of developer sanity :)
<gmb> (Or we could have the Jobs system call the stored procedure rather than use BugHeatCalculator)
<deryck> maybe so.  But I think just doing it all on trigger is better.
<deryck> gmb, if we do this, this would also make bug 571730 invalid, too, right?
<mup> Bug #571730: garbo-daily should prune CalculateBugHeatJobs <story-bug-heat> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/571730>
<gmb> deryck, Yes.
<deryck> gmb, ok, so let's do this then...
<deryck> gmb, please file a bug about the new work to be done, then mark 571730 and 557252 invalid, citing the new bug.  Then add the new bug to the bugs backlog on the board where the card for 571730 currently is.  Sound cool?
<gmb> deryck, Yep, WFM.
<deryck> gmb, thanks!
<gmb> np
<gmb> deryck, bug 582195
<deryck> gmb, great, thanks.
<gmb> Thanks for nothing, mup.
<wgrant> noodles775: Any idea what happened to the second branch? The errors look... unrelated.
<wgrant> Not a set that I've seen before, either.
 * jml off to lunch
<jml> wuu, cafe internet works.
<noodles775> wgrant: yeah, the failures in the second branch look unrelated. Let me know when you've pushed the fix for the first branch and I'll resend it.
<noodles775> jml: so enjoy it and read some stuff you've wanted to read ;) (btw: are you using an android irc app? or a computer)
<jml> noodles775, I'm using my computer.
<jml> noodles775, and compiling notes from UDS, which I don't really need to be online for
<BjornT> jml: how do i use subunit to list all failed tests in a test run (i have a log file from ec2)
<jml> BjornT, pipe them through subunit-filter
<jml> BjornT, there's a bug in subunit-filter where it lets timestamps through
<BjornT> jml: i've figured so much out, but i can't get it to work. oh, that would explain it....
<BjornT> jml: any way to work around it?
<jml> BjornT, grep, I think
<jml> BjornT, as in, grep -v "time: ", or something similar.
<jml> BjornT, https://bugs.edge.launchpad.net/subunit/+bug/567150
<mup> Bug #567150: subunit-filter doesn't understand time <subunit:Triaged> <https://launchpad.net/bugs/567150>
<BjornT> jml: right. any way to list only the names of the test, not including the tracebacks?
<jml> BjornT, | subunit-ls
<BjornT> cool, thanks
<jml> crap. I didn't meet adiroiban while I was at UDS :(
<noodles775> Hi abentley, I'm just at the point where I'm ready to refactor IBuildFarmJob to refer (and delegate) to IJob, but wanted to run a few things past you...
<abentley> noodles775, sure.
<noodles775> Initially, it will really be only date_create, date_started and date_finished that benefit (and I'll need to add indexes on IJob for these)...
<noodles775> IJob.log vs. IBuildFarmJob.log is a bit of an issue - the former being Text, the latter a LibraryFileAlias reference
<noodles775> (we could rename IBuildFarmJob.log to log_file I guess, but we'd probably want to do IBFJ.upload_log -> upload_log_file too then).
<abentley> noodles775, we haven't really used the log field yet, AFAIK.
<noodles775> oh.
<noodles775> In which case, we *could* rename IJob.log -> log_tail?
<abentley> noodles775, I think so.
<noodles775> abentley: OK, thanks.
<abentley> noodles775, any thoughts on status?
<abentley> noodles775, I've been thinking that IJob.status maps pretty well to Build.buildstate, except that Build.buildstate describes failures much better.
<noodles775> abentley: I had planned for the moment to simply override it on IBuildFarmJob.status (as we have a lot of filtering on this field), but if you think it would be better to move them completely to IJob now, I can do that?
<bigjools> that scares me
<wgrant> This was the main point that my initial diagrams did not solve.
<wgrant> I am leaning towards letting each job type have its own failure states.
<wgrant> But using IJob.status for everything else.
<abentley> wgrant, me too.
<wgrant> Since it covers most of it.
<wgrant> But, well, it's slightly awkwarded, which is why I didn't propose it initially.
<wgrant> Woah. Awkward.
<abentley> noodles775, were you planning on implementing IJob.status in terms of BuildFarmJob.status ?
<noodles775> wgrant: how would we filter for all builds where the set of statuses for the filter are on different tables?
<adiroiban> jml: eh. there will be other UDS-es :) I also missed the LP meeting
<noodles775> (well, ok, it'd be possible, but seems overly complex)
<wgrant> noodles775: Therein lies the awkwardness.
<noodles775> Which is why for the moment I wasn't goin to try to merge the statuses, but continue with IBuildFarmJob.status defining all the statuses we need.
<bigjools> I think job status and build state are somewhat orthogonal
<wgrant> Everything else is easy.
<wgrant> bigjools: They only appear to diverage once the build is complete.
<wgrant> And then only upon failure (at the moment, at least)
<bigjools> for all of our build types?
<wgrant> Yes.
<bigjools> and future types? :)
<wgrant> I can't think why not, but it is something to think about.
<abentley> bigjools, I don't see how they can be orthagonal.  They can't disagree about whether the build failed, succeeded, or hasn't been attempted.
<wgrant> Exactly.
<bigjools> you're making the mistake that they represent the same thing
<wgrant> At the moment they do.
<bigjools> I am playing devil's advocate to some extent, but I'm kinda wary of having a one-size-fits-all status
<wgrant> There are, I guess, statuses like ABORTING and ABORTED that we probably need.
<wgrant> I wonder how that would be implemented or map onto this.
<abentley> bigjools, Jobs are intended to be general.  If there is a state that they can't represent in general terms, we should add it.
<bigjools> yeah, I want a new build status that represents an admin terminating it
<noodles775> wgrant: ABORTING and ABORTED would be such new JobStatus items.
<wgrant> noodles775: I guess they could be.
<wgrant> Since they are general.
<bigjools> abentley: should we have a massive list of states, and change the state transitions depending on the job type?
 * jml hates human computer interfaces
 * bigjools hates humans and computer interfaces
<abentley> bigjools, I don't think we should.  The idea with Jobs was that the general states would be represented by Job.status, and failure modes would be specified in Job.reason
<noodles775> OK, but that would be a bigger change than I can afford right now for package builds.
<wgrant> abentley: Is that a string?
<abentley> noodles775, sure.
<abentley> wgrant, yes, and actually, I may be wrong about that.
<wgrant> Hmmm.
<wgrant> Is that another thing that isn't used anywhere yet?
<abentley> The comment on reason suggests it's the reason the job was created, not the reason it failed.
<wgrant> Ah.
<abentley> bigjools, I also notice that the comment on Job.status mentions "cancelling" and "cancelled" as possible statuses.
<noodles775> So, fwiw, the only way forward I can see for the moment is to have all status represented by JobStatus.
<noodles775> (or leave the IBuildFarmJob is an IJob for later).
<wgrant> I'd really just shadow IJob.status for now.
<wgrant> Ah.
<noodles775> wgrant: yes.
<wgrant> This change is already massive enough...
<noodles775> +1, over 7k lines at the moment, that I want to land as soon as we've tested on dogfood.
<wgrant> Oouch.
<abentley> noodles775, yes, I just asked your thoughts on status.  Doesn't have to be now.
<BjornT> danilos, henninge: can anyone help me with understanding a test failure in test_getPOTMsgSetBySequence (lp.translations.tests.test_shared_potemplate.TestTranslationSharingPOTemplate)?
<henninge> BjornT: Show me. ;)
<danilos> BjornT, are you, by any chance, changing sampledata?
<BjornT> henninge, danilos: http://paste.ubuntu.com/435535/
<BjornT> danilos: no. i am however changing the sequence number
<danilos> BjornT, how are you changing it?
<BjornT> danilos, henninge: it seems that i get this when if factory.getUniqueInteger() returns 1, but the test doesn't contain any guards against it, so i'm not sure what the right thing to do is
<danilos> BjornT, setSequence call doesn't do any checking because it assumes you know what you are doing (for performance reasons)
<BjornT> danilos: i changed factory.getUniqueString() not use factory.getUniqueInteger()
<danilos> BjornT, let me take a look at the test then
<danilos> BjornT, I'd have to see the branch to see where the problem is, because test seems sane otherwise
<danilos> BjornT, i.e. it depends on what's going on: what the names for self.devel_template and self.stable_template are etc.
<danilos> BjornT, the test shouldn't depend on getUniqueString at all
<danilos> BjornT, except maybe person creation and such
<BjornT> danilos: you could apply this patch: http://paste.ubuntu.com/435540/
<BjornT> danilos: it doesn't depend on getUniqueString directly, it just depends on getUniqueString() calling getUniqueInteger(), so that getUniqueInteger() won't return 1
<BjornT> at least as far as i can see
<bigjools> jml: is there a standard way of doing diagrams to show chains of Deferreds?
<jml> bigjools: not really. See http://twistedmatrix.com/documents/current/core/howto/defer.html http://twistedmatrix.com/documents/current/core/howto/gendefer.html http://twistedmatrix.com/documents/current/core/howto/deferredindepth.html
<danilos> BjornT, yeah, that does sound likely, you can simply fix it by setting the sequence to 2 instead, or, what's probably better, use getUniqueInteger in setUp instead (though, that will needlessly get different sequence ids for each of the tests, but not a big deal)
<jml> bigjools: in general, it's an implementation thing, not an interface thing, so there's rarely a reason to draw such a diagram
<bigjools> jml: ok, I want to draw the decision tree for the buildd-manager
<mars> rockstar, BjornT, I landed the branch that disables the windmill suite on ec2.  ec2test should work again.
<jml> bigjools: then just draw a flowchart
 * jml in a call
<bigjools> jml: that's what I was doing until I stopped and wondered if there was a Twisted Way :)
<bigjools> thx
<jml> bigjools: np
<BjornT> danilos: ok. i think i will hard code it, because it's hard coded in other tests, so using getUniqueInteger() in setUp() might make other tests fail.
<danilos> BjornT, sure, makes sense
<jml> bigjools: btw, I looked up the deferred implementation. There's already some code that does "if isinstance(result, failure.Failure)"
<bigjools> jml: ah precedence is wonderful
<jml> bigjools: no, as in, the check has already been performed by the time it gets to your custom check :)
<jml> bigjools: another diagrammatic tool that people use sometimes is state machines
<bigjools> yes
<bigjools> jml: it would be nice to have a state machine internally instead of this mishmash of code
<bigjools> but I want to re-work it anyway
<wgrant> bigjools: Are you also planning to rework the internal bits of code that think they are synchronous, but really aren't?
<wgrant> Or is that out of scope?
<bigjools> wgrant: which bits do you mean?
<wgrant> bigjools: dispatchBuildToSlave and other bits and pieces around that where make synchronous calls to RecordingSlave.
<wgrant> RecordingSlave then forges successful XML-RPC responses, so it can execute the real calls later.
<bigjools> I think that's just an artefact of RecordingSlave
<wgrant> So people tend to assume that they will get real results in those methods... when in fact methods will fail without anybody noticing.
<wgrant> Right.
<bigjools> that's how it's designed to work
<bigjools> which is fine for now
<wgrant> I imagine it was only built that way so slavescanner would continue to function.
<bigjools> I aim to attack 2 things:
<wgrant> But slavescanner is dead now.
<bigjools> 1. make build uploads asychronous by throwing them in a queue and forgetting about them
<wgrant> \o/
<bigjools> 2. throw away the global scan, and have a scan interval on each builder instead
<wgrant> Right. A separate state machine for each builder. Yay.
<wgrant> That will fix just about everything.
<bigjools> at that point we'll have solved most of the scalability issues
<bigjools> then we can start making the rest of the code nicer
<wgrant> Yep.
<bigjools> the design of the b-m was influenced too much by the slave scanner really
<wgrant> Well, it had to not break slavescanner.
<bigjools> that's separate
<bigjools> I mean the global scan
<wgrant> Ah.
<bigjools> we could have done separate scans on each builder right from the start
<wgrant> Mm, yes, I guess so.
<BjornT> mars: about your branch to disable windmill tests on ec2. did you land that one through ec2tests? :)
<mars> BjornT, nope, ironically
<BjornT> mars: maybe you should have :) looking at your patch, it looks like you've now enabled the mailman tests, haven't you?
<mars> BjornT, ?  I did not touch that code.
<BjornT> mars: but you changed which layers are run
<BjornT> mars: it used to be !MailmanLayer. now it's !WindmillLayer. no?
<mars> BjornT, yes.  I added another --layer switch to disable the windmill tests.  bin/test adds yet another layer switch on its own to disable mailman.
<BjornT> mars: i don't think so. the defaults are there, in case no --layer is specified only
<mars> BjornT, ah, so I misread the code in bin/test then.  Either way, I doubt I would have noticed the mailman tests running on ec2.
<wgrant> Well... the mailman tests normally mostly fail.
<wgrant> So you probably would have.
<BjornT> mars: well, what wgrant said :)
<mars> :)
<wgrant> OK, so, yes, it looks like MailmanLayer is running :(
<wgrant> That explains the odd failures that one of my branches had.
<mars> BjornT, so is there anything that needs to be fixed outside of adding the explicit --layer=!Mailman ?
<BjornT> mars: nope, adding the explict !Mailman is the right thing to do, i think. i would use --layer=!(MailmanLayer|WindmillLayer) just to be sure, though. i don't think using --layer=!MailmanLayer --layer=!WindmillLayer will work
<mars> BjornT, ok, will do so as soon as rf-get completes
<abentley> noodles775, what is the relationship between BinaryPackageBuild.is_virtualized and BuildQueue.virtualized ?
<abentley> noodles775, err, not BuildQueue.  SomethingJob.virtualized
<noodles775> abentley: so currently BinaryPackageBuild.is_virtualized just returns whether the associated archive is virtualised, which isn't great, which is why the new schema adds a virtualized attribute to BuildFarmJob.
<noodles775> abentley: which I'm guessing you saw yourself... do you have a suggestion?
<mars> wgrant, look at the bright side: at least the ec2 server didn't hang
<wgrant> mars: True!
<abentley> noodles775, I'm just trying to understand the various attributes.  Seems like virtualized returns is_virtualized, which returns archive.virtualized.
<abentley> noodles775, if we have all these attributes, I would expect them to vary.
<noodles775> abentley: IBuildFarmJob.virtualized is a Bool db attribute... (and I've not yet removed IBinaryPackageBuild.is_virtualized, but intend to)... or did I miss something?
<abentley> noodles775, No, that sounds like a sane plan.
<noodles775> abentley: great. Let me know if you spot anything else.
<obergix[work]> flacoste: Hi. Just sent you some request again about presentation @OWF... in case you missed previous emails and could ACK me
<obergix[work]> jml: as I didn't get any response from you about presenting @OWF, I just resent a query to Francis, but of course, I'd appreciate if you responded too ;)
<adiroiban> what is the prefered way for naming the Y.namespace variable ? In the current code we have the folowing http://paste.ubuntu.com/435636/
<zyga> does launchpad use storm as the ORM layer or is there some other piece of tech involved?
<rockstar> We're in testfix?
<rockstar> zyga, yes, storm is our preferred ORM.
<zyga> rockstar, are you aware of any django-on-storm projects?
<rockstar> zyga, yes, Ubuntu One uses storm and django.
<zyga> rockstar, can I (canonical) get a peek at the code to see how to piece django and storm in a sensible way?
<zyga> anything that you might share would be beneficial to me
<rockstar> zyga, you're asking the wrong person.  You should probably ask someone on the U1 team.
<zyga> rockstar, #? #ubuntu-one?
<rockstar> zyga, no idea, actually.
<zyga> ok, I'll check, thanks
<rockstar> zyga, I believe jamesh made a storm mailing list post about using storm and django as well.
<rockstar> adiroiban, var namespace = Y.namespace('lp.<app>.<app-specific-namespace>'); is correct.
<adiroiban> rockstar: thanks!
<jml> good night Launchpadders
<jml> rockstar, grats on your dementating!
<rockstar> jml, I had to stop and think about that.
<rockstar> jml, I thought you knew more about my mental health than I did...  :)
<rockstar> (although that wouldn't surprise me)
<jml> I have orbs.
<adiroiban> rockstar: is this wikipage still valid https://dev.launchpad.net/JavaScriptBuildSystem ?
<mars> adiroiban, the part about new script files is correct.  Plenty of examples in base-layout-macros.pt
<mars> adiroiban, the CSS story is different.
<mars> adiroiban, look at buildout-templates/bin/combine-css.in to see how the different CSS files are pulled together.
<adiroiban> mars: there is also utilities/lp-deps.py
<adiroiban> and it looks like in base-layout-macros.pt, the JS files must be manualy added for devmode
<adiroiban> or I am missing something ?
<mars> adiroiban, when you add a file to the devmode block, lp-deps will pick it up as a new dependency.  It will be automatically rolled into launchpad.js.
<adiroiban> mars: ok. but what is the recommended way for incliding JS files: in base-layout-macros.pt or in each templates?
<mars> adiroiban, that depends where the JS is used.  What did you add?
<adiroiban> mars: I'm moving the translation js files from canonical/launchpad/javascript to lib/lp/translations/javascript
<mars> adiroiban, then they are probably listed in base-layout-macros.pt
<adiroiban> one file is in  base-layout-macros.pt while others are in other templates
<adiroiban> but the file included in base-layout-macros.pt is only used in 2 other templates
<mars> adiroiban, how heavy are the other files?  Are they all used on only one page?
<adiroiban> mars: yes. they are used on only one page
<adiroiban> but in production, all js files are merged into launchpad.js. right?
<mars> I believe that is the case if and only if they are listed in base-layout-macros
<mars> lp-deps.py does not scan every template file in launchpad
<mars> adiroiban, to my knowledge the other applications combine everything together into one JS file, then have it all in launchpad.js
<mars> regardless of whether it is used on one page, or on many
<mars> it works because the vast majority of the JavaScript for LP is in the YUI Core.  Our apps are very thin on top of that.
<adiroiban> mars: that is correct. and if in production, all js code is merged in launchpad.js, then why not put all js file include statements in base-layout-macros ?
<mars> adiroiban, I do not know why translations chose to do it otherwise.
<mars> also, I can not guarantee that those files are minified
<mars> if they aren't in the JS rollup
<adiroiban> mars: how do I know if a file is minified?
<mars> adiroiban, simplest way is to visit that page on staging.launchpad.net, View Source
<mars> see if it looks like jibberish :)
<mars> adiroiban, if you tell me a URL to check, I can do so for you
<adiroiban> https://translations.edge.launchpad.net/ubuntu/lucid/
<adiroiban> mars: sorry. https://translations.edge.launchpad.net/ubuntu/lucid/+imports
<adiroiban> lib/lp/translations/templates/translation-import-queue-macros.pt has an javascript include tal condition for devmode
<adiroiban> mars: it should be build/translations/translations.js
<mars> adiroiban, it looks like everything on production has been properly rolled into launchpad.js
<adiroiban> mars: then it would make sense to put the include statements in base-layout-macros. or not?
<mars> It sounds like it, yes.
<adiroiban> mars: and then maybe we can add a note on the wikipage that js includes can be put in base-layout-macros, rather than in templates using tal conditions for devmode
<mars> yes, that would help
<adiroiban> ok. righ now we have âTo add a new YUI3 dependency, just add a new <script> line to the main site template.â
<adiroiban> but for me âYUI3 dependencyâ does not mean âa new js file used for Launchpadâ
<mars> s#main site template#lib/lp/app/templates/base-layout-macros.pt#
<adiroiban> mars: yep
<mars> good point
<mars> that is not clear
<adiroiban> mars: can you please change the wikipage. I don't think I was accepted yet into the LP-documentation team
<mars> ok
<adiroiban> thanks!
<mars> adiroiban, better? https://dev.launchpad.net/JavaScriptBuildSystem
<mars> I dislike the asymmetry between the CSS and JS build chain.
<mars> Would be nice if you could just type "make clean_static && make static"
<mars> or something :/
<mars> web_resources?
<mars> assets?
<adiroiban> mars: much better :)
<mars> "make assets"?
<adiroiban> after changing utilities/lp-deps.py, i had to do âmake cleanâ
<mars> adiroiban, good!
<adiroiban> and make js_clean & make jsbuild
<adiroiban> had not created the symlinks
<adiroiban> but utilities/lp-deps.py should only be changed once per each lp application
<mtaylor> the "Find" link on the Assign to: field on +filebug doesn't open up a popup, it takes you to a whole new page - this can be troubling...
<wgrant> mtaylor: Bug #513591
<mup> Bug #513591: Assignee selector on +filebug has lost its JavaScript <story-ajaxify-dupe-finder> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/513591>
<mtaylor> wgrant: awesome.
<lifeless> gary_poster: I realise you're probably gone; just letting you know that I'm chatting to apache, I hope:  https://issues.apache.org/bugzilla/show_bug.cgi?id=39727#c34
<bdmurray> could somebody help me out with the following error message when running a test?
<bdmurray> http://pastebin.osuosl.org/32810
 * thumper looks for jelmer
<thumper> bdmurray: you are missing a login
<thumper> bdmurray: I take it this is in a page test?
<bdmurray> thumper: yes, thanks
<thumper> bdmurray: in the story page tests you need an interation, which you get from login()
<thumper> or login_person
<thumper> bdmurray: often login(ANONYMOUS) is enough
<thumper> also, to get the ubuntu distro, probably easier to use getUtility(ILaunchpadCelebrities).ubuntu
#launchpad-dev 2010-05-19
<mtaylor> thumper: see, so you talk about me, and then you run away
<thumper> mtaylor: sorry forgot about you :)
<mtaylor> thumper: it happens
 * mtaylor wants a tool that will connect to launchpad, grab all the users in a team and their ssh keys and make local users for each of them
<wgrant> I think my script for that is gone.
<wgrant> I had one a couple of years ago, though. But there is now a tool floating around to create a user with keys from an LP username, so it'd be easy to script up.
<wgrant> Plus... the API makes it nice and easy.
<wgrant> No more screenscraping.
<lifeless> mtaylor: why not pam_launchpad ?
<lifeless> static is so 1970's
<mtaylor> lifeless: speed?
<lifeless> premature optimisation:)
<mtaylor> lifeless: ha!
<mtaylor> lifeless: I was also thinking of a hudson security module which would delegate to launchpad ... but seeing as how I'm two plugins behind, I think perhaps adding another one is also premature
<wgrant> mtaylor: OpenID?
<mtaylor> wgrant: yeah, that would be part of it
<mtaylor> wgrant: but I was thinking similar to above- if in hudson I said "hey, deal with launchpad project X"
<mtaylor> wgrant: and it knew how to do tarmac stuff with that project, but also would use launchpad user/team info to grant people hudson access to build related stuff for that project...
<mtaylor> see, I think entirely too large
<lifeless> you'll want to see my stalled openid patch, in that case.
<adeuring> good morning
<jml> good morning Launchpadders
<bigjools> b'jour
<noodles775> BjornT or otherwise: to run launchpad with postgresql8.4, do I just install it, update the ports so 8.4 is running on 5432, stop 8.3 and run launchpad-database-setup?
<deryck> Morning, all.
<thumper> jelmer: ping
<jelmer> thumper: otp
<thumper> jelmer: ack
<jelmer> thumper: hi
<thumper> jelmer: got any idea why dulwich is leaving behing uncollectable garbage in the test suite?
<jelmer> thumper: no
<jelmer> thumper: which files?
<thumper> jelmer: see BjornT's email about the import tests
 * thumper looks
<thumper> [<dulwich.pack.PackData object at 0x9e06e50>] (referenced from [(<dulwich.pack.PackData object at 0x9e06e50>,), [<dulwich.pack.PackData object at 0x9e06e50>], {'_basename': '/tmp/tmpFhvH-A/.git/objects/pack/pack-120fc662d24725ba18915fe0c17eea6644adc3fe', '_data': <dulwich.pack.PackData object at 0x9e06e50>, '_idx_path': '/tmp/tmpFhvH-A/.git/objects/pack/pack-120fc662d24725ba18915fe0c17eea6644adc3fe.idx', '_idx': <dulwich.pack.PackIndex1
<thumper>  object at 0x9e06e90>, '_data_path': '/tmp/tmpFhvH-A/.git/objects/pack/pack-120fc662d24725ba18915fe0c17eea6644adc3fe.pack'}])
<BjornT> noodles775: yes, more or less. following the manual step (replacing 8.3 with 8.4) in https://dev.launchpad.net/DatabaseSetup works. haven't tried launchpad-database-setup, but please let me know whether it works
<wgrant> I've done it by purging 8.3 and installing 8.4. But dropping the 8.3 cluster and installing 8.4 should be just as effective
<wgrant> Then launchpad-database-setup works fine.
<noodles775> BjornT, wgrant: yes, it worked fine... I just modified the config so 8.3 isn't started. I had to install some extra 8.4 packages, but other than that launchpad-database-setup worked fine.
<wgrant> Launchpad should really fix the Referer thing.
<james_w> it's to prevent XSRF?
<wgrant> Yes.
<james_w> yeah, not ideal
<wgrant> I suggested it, since i knew the real fix wouldn't be scheduled for a decade, unless there were enough complaints about the Referer check.
<wgrant> Since one me complaining about security holes is probably easier to ignore.
<james_w> I'm frequently surprised by how few frameworks come with built-in XSRF protection.
<james_w> or at least convenience methods for doing it
<wgrant> Indeed.
<wgrant> It shouldn't be terribly difficult for LP, since all/most JS requests go through the JS API wrapper
<james_w> not the easiest thing to apply to every form from a framework, but at least suggesting that people use it wouldn't be hard
<wgrant> Right.
<wgrant> JS-less Django apps can use middleware.
<wgrant> (see c-i-p)
<james_w> it could even be just thrown in memcached I guess?
<wgrant> Possibly.
<wgrant> But there is no good way to fix XSRFs :
<wgrant> (
<wgrant> All of them are broken in various ways.
<noodles775> http://docs.djangoproject.com/en/dev/releases/1.2/#improved-csrf-protection
<james_w> really?
<james_w> \o/ for django
<wgrant> Referer checking is broken, as we've seen.
<wgrant> And throwing a token into every form means that distributing or caching that HTML is dangerous.
<james_w> ah, I see, I thought you meant that it was consistently possible to beat the probabilities
<wgrant> (plus forms probably have to time out)
<g4tsu> Hi
<g4tsu> I've installed my own launchpad and I want to know how to include my .deb packages
<g4tsu> Because the documentation says that we have to use dput with .dsc .changes .orig.tar.gz etc and we haven't this type of file
<g4tsu> Hello mars, it's ghostoyo
<gary_poster> thank you lifeless
<deryck> adeuring or intellectronica -- could I get a review from one of you?  Should be very easy.
<adeuring> deryck: yure
<deryck> adeuring, thanks!  https://code.edge.launchpad.net/~deryck/launchpad/subscribe-to-bug-mail-twice-577768/+merge/25532
<g4tsu> nobody can help me ?
<adeuring> deryck: r=me
<deryck> adeuring, thanks!
<maxb> g4tsu: It seems to me that if you're uncertain of how to use dput, then attempting to set up your own Launchpad instance is a matter of attempting to run before you can walk
<bac> reviewers meeting starting now.
<mars> sinzui, please let me know if you see another ec2 suite hang.
<sinzui> okay
<mars> sinzui, otherwise, the situation was well-covered by Gary and the mail I sent the list yesterday.  It should NOT hang now.
<mars> g4tsu, I think maxb's advice is wise.  Best to understand how packaging works before you attempt to set up your own private LP-hosted repository.
<mars> g4tsu, to my knowledge, you would also be best off talking to maxb and wgrant about running a private LP repository that way.  They know worlds more about it than I do.
<maxb> g4tsu: Also, I have to ask... you're aware about the bit of the Launchpad licence which demands you replace all the images and icons if you create a private installation of any kind?
<adiroiban> any idea what is causing and how can I fix this make link warning
<adiroiban> warning: Not importing directory '/usr/share/pyshared/lazr': missing __init__.py
<adiroiban> s/link/lint/
<g4tsu> maxb> yep I'm aware of that
<mars> maxb, allenap, your investigation yesterday makes perfect sense: the killem() function was killing the wrong process group.  Here is a healthy process tree before killem gets to it (note the PGIDs): http://pastebin.ubuntu.com/436221/
<allenap> mars: Woohoo :)
<adiroiban> danilos, henninge: is there a XPI template in the testing/demo LP database?
<danilos> adiroiban, it's constructed from a bunch of files for testing
<danilos> adiroiban, see lib/lp/translations/utilities/tests/xpi_helpers.py
<adiroiban> danilos: so the sample database does not contain such a file?
<danilos> adiroiban, no, and you shouldn't use it for tests either :) anyway, you should probably not worry about exporting source_file property right now
<adiroiban> danilos: it is easy to export
<danilos> adiroiban, (you shouldn't use sampledata for tests is what I mean)
<adiroiban> but it looks like all POTemplates
<adiroiban> don't have an associated source_file
<danilos> adiroiban, sure, but the branch grows and you slow down the review for something that is not critical for what you set out to do (i.e. you are widening the scope without really needing to)
<danilos> adiroiban, right, we don't extend sampledata at all anymore
<adiroiban> danilos: ok. I was just curious about the usage of the source_file attribute. I will not export it in this branch :)
<danilos> adiroiban, oh, it's also only used for XPI files so far
<adiroiban> danilos: in the sample data, all source_file attributes for potemplates are null
<danilos> adiroiban, there are no imported XPI files in the sample data :)
<adiroiban> danilos: I see, and I was wondering why it is not used for other templates
<danilos> adiroiban, it would take up space in the librarian (they could not be deleted after import), and we don't need them; we need en-US.xpi files to be able to re-construct translated XPI files (though we never got far enough with implementing that)
<danilos> anyway, I'm leaving now
<adiroiban> danilos: thanks. have a nice evening :)
<danilos> adiroiban, cheers :)
<mrevell> Night all
<Darkpsy> Is it best to go through the launchpad setup procedure as root or non-root?  I tried it both ways and Apache is throwing errors.  One error states it can't find /var/tmp/archive
<adiroiban> Darkpsy: just create that folder ... but rocketfuel-setup should take care of everyhing
<Darkpsy> adiroiban:  in that case, what folder should hold the main part of launchpad?
<adiroiban> devel branch
<Darkpsy> ok
<Darkpsy> I'm now getting this error: http://paste.ubuntu.com/436367/
<adiroiban> Darkpsy: have you uploaded your ssh key on LP ?
<adiroiban> can you use bzr with LP ?
<Darkpsy> i have uploaded my ssh key to LP, this is the first time i've used bzr with LP since I didn't need to before
<Darkpsy> i think i found the problem.  one sec
<Darkpsy> got it working now.  turns out I imported the wrong key
<mwhudson> mars: so i guess i should make my backtrace thingy a project really
<mars> mwhudson, well, a setup.py would be a great start :)  I thought of writing one, but didn't need it.
<mars> mwhudson, if it was a project with a setup.py, then we could roll it into the Launchpad distribution.  I might do that anyway.
<mars> mwhudson, the other problem is detecting if debug symbols are available.  Without them I get a GdbError - maybe there is some way to gracefully detect if things are wrong.
<mars> ahead of time
<mwhudson> mars: those both sound like good ideas, they should be bugs ... which means setting up a project :)
<mars> heh
<wgrant> Um.
<wgrant> What's the memcached work that landed this morning?
<wgrant> It seems far, far, far too aggressive.
<wgrant> To the point of making at least the milestone view almost useless.
<wgrant> sinzui: Was it insufficient to cache each bugtask row?
<wgrant> Even that is too aggressive for that view, but it's not quite so bad.
<wgrant> I imagined that memcached would be used for caching links and non-critical "Latest [blah]" sort of things.
<wgrant> Not for major sources of time-critical data like milestone listings.
<sinzui> wgrant, it speed up the listing of milestone pages on staging. It was very impressive.
<wgrant> sinzui: Yes, but it also makes them much more confusing and less useful.
<sinzui> wgrant, the milestone view is one the top timeouts and the cause is the bug privacy and the number of bugs
<wgrant> Of course it's going to make them much faster.
<wgrant> I want my milestone view to not lie to me.
<wgrant> I use it frequently.
<sinzui> wgrant, yes, that is why I landed it eary in the cycle
<lifeless> do we still use SQLOS in any way?
<sinzui> wgrant, cool can you fix it for me then? you will be the 4th developer to wortk on this
<wgrant> When my team is triaging a milestone, we refresh frequently and need to see each other's changes immediately.
<wgrant> I am thinking about how best to do it.
<wgrant> Is the query for finding visible bugs really that bad?
 * wgrant must have a look at some point.
<sinzui> we can adjust the cache time.
<sinzui> wgrant, I too refresh often. We do not have tools to invalidate cache. I would have used them if they existed
<wgrant> I think until we can invalidate, we can't safely cache that sort of thing. Top contributors, latest bugs, latest uploads, sure.
<sinzui> wgrant, on cache rule is to only cache anonymous. We can switch to that and make bots happy. For users, they will still get timeouts
<wgrant> Aspects of the bug rows on that page (tags, for example, that caused problems when they were temporarily switched on a while ago), maybe.
<wgrant> But entire bug task rows won't work sanely yet.
<sinzui> wgrant, I have considered everything you have mentioned. You are correct, but I have timeouts I am responsible for ending. I will adjust the rules as best I can, and will add and removed them as needed.
<mwhudson> mars: https://code.edge.launchpad.net/~pygdb-hackers/pygdb/trunk
<mwhudson> mars: it's based on a bzr-svn import of the pygdb upstream, so you'll need to recreate your branches i'm afraid
<mwhudson> mars: rebased the branch again i'm afraid
<mwhudson> (i'll stop this now)
#launchpad-dev 2010-05-20
<poolie> spm, there's some russian spam in https://answers.edge.launchpad.net/launchpad-code/+question/13796
<poolie> i guess i should file a question?
<spm> poolie: questions, even more so than bugs; yes. that's a hand  crafted sql task.
<poolie> https://answers.edge.launchpad.net/launchpad/+question/111646 fwiw
<cody-somerville> "This change is completely inert when not using XYZ" doesn't sound quite right at this hour. I have a feeling I'm actually looking to use a different, more appropriate word but can't think of it at the moment.
<lifeless> A better word than is? Try etre.
<cody-somerville> lol
<cody-somerville> lifeless, was referring to 'inert'. :P
<lifeless> You have a double negative
<lifeless> I suggest a single positive.
<cody-somerville> plus, etre is the verb 'to be'. I think you meant to recommend 'est'. :P
<lifeless> "This change only takes effect when using XYZ."
<lifeless> same word :)
<lifeless> you need more practice at conjugation ;)
<cody-somerville> conjug...
 * cody-somerville was going to say conjugation is important :P
<lifeless> http://www.wordreference.com/conj/FRverbs.asp?v=etre
 * cody-somerville doesn't dispute his French could use a lot of work in many areas.
<cody-somerville> lifeless, anyhow, thanks. :)
<lifeless> de nada
<adeuring> good morning
<spm> noodles775: ta. I'm often not quite sure which sub group a bug belongs to; when it doubt, let you lot figure it out. :-)
<noodles775> spm: no probs.
<mrevell> Morning
<lifeless> can Storm handle sets ? We have a comment about SQLObject failing on them in sqlbase.py
<lifeless> and a workaround we could proably delete now
<deryck> Morning, all.
<deryck> BjornT, ping
<BjornT> hi deryck
<deryck> BjornT, hi.  I'm starting work on bug 418659 and you have some comments there about your previous work on this...
<mup> Bug #418659: Reporting duplicate bugs leads to receiving notifications for every duplicate of the original bug <ubuntu-qa> <Launchpad Bugs:In Progress by deryck> <https://launchpad.net/bugs/418659>
<deryck> BjornT, and I'm looking at your work in:  https://code.edge.launchpad.net/~bjornt/launchpad/bug-46237/+merge/8886
<deryck> And I wonder if I'm reading your intent right....
<deryck> BjornT, was your work to ensure that Bug A subscribers are *not* notified when Bug B is marked a dupe?  Or that Only Bug A subscribers are notified when Bug C is marked a dupe and Bug B subscribers via dupe are not notified about bug C?
<deryck> if that makes sense :-)
<BjornT> deryck: i think some clarification is needed :) in my example Bug B was the master bug
<BjornT> deryck: might be easier if we take real example, e.g. bug 46237, which has a few duplicates
<mup> Bug #46237: fine-tune delivery of duplicate notification mails <email> <Launchpad Bugs:Fix Released by bjornt> <https://launchpad.net/bugs/46237>
<deryck> yeah, good idea.
<deryck> BjornT, So when Bug #91212 was marked a dupe of that bug, should direct subscribers to bug 46237 be notified of this?
<mup> Bug #91212: people subscribed to bugs that are duplicates shouldn't receive notifications of new duplicates to the master bug <email> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/91212>
<mup> Bug #46237: fine-tune delivery of duplicate notification mails <email> <Launchpad Bugs:Fix Released by bjornt> <https://launchpad.net/bugs/46237>
<BjornT> deryck: no. only the ones that are subscribed to bug #91212 should be notified about it.
<mup> Bug #91212: people subscribed to bugs that are duplicates shouldn't receive notifications of new duplicates to the master bug <email> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/91212>
<deryck> BjornT, ok.  Which should cover the second case of subscribers to 91212 being notified when the master add yet another bug marked as a dupe of it.  right?
<deryck> s/add/had/
<BjornT> deryck: right
<deryck> BjornT, and people were generally in agreement that direct subscribers on the master do not want to know via email about dupes being added?
<mars> sinzui, rockstar, is one of you working on the broken build?
<sinzui> mars, I am trying to understand it
<mars> ok.  Thanks sinzui.
<BjornT> deryck: yes. they said that even though it's somewhat useful to get notified for the developers, decreasing the number of e-mails sent was more important.
<deryck> BjornT, right, that makes sense, given the two choices.
<deryck> BjornT, and the only test for this is in test_bugchanges.py?
<BjornT> deryck: i think so, yes
<deryck> BjornT, ok, great, thanks for helping me understand.
<sinzui> mars, is the build really broken? I think my pre-emptive fix was not really run until gary restarted it?
<mars> sinzui, I assume you can not reproduce this locally?  If you suspect is not broken, maybe you can throw a null [testfix] in there and see if it breaks again?
<sinzui> mars, to force a build to see if the failure was spurious or real?
<mars> sinzui, that of course assumes that a null testfix will force a full suite re-run without adding changes from the queue - I don't know if that is the case.
<mars> sinzui, yes, to force a rebuild
<sinzui> I can always reformat a test :)
<mars> BjornT, ^ will that work?
 * mars is still learning about the pqm part of the build system
<BjornT> mars: i'm not sure what the question is :)
<mars> BjornT, sinzui suspects the failure is suprious.  Can he submit an empty [testfix] to PQM to have it clear the flag and force a rebuild of just his and Paul's changes?
<BjornT> sinzui: which failure?
<BjornT> mars: ^^^
<sinzui> faq-views in failed devel (ran on the wrong layer). I did a preemptive fix, while it was building
<jelmer> jml: whoops, didn't mean to make you angry!
<BjornT> sinzui: right. and that fixed it, no?
<jml> jelmer: only blogging-angry
<jelmer> jml: is that a good kind of angry?
<jml> jelmer: it's the kind of angry that hurts no-one except my keyboard and maybe some people's bandwidth
<sinzui> BjornT, but it was (reported) failed again  when gary forced it to restart. it is not clear if by forcing to to restart, my fix was in it so we saw a second failure?
<jelmer> jml: ah, good
<mars> sinzui, BjornT, fwiw, I was just looking for the "kick it again and see" answer here :)
<mars> sinzui, BjornT, I just don't know the right way to give the test system said kick
<BjornT> sinzui: if you look at build 900, you see that it's testing up to r10892. your fix was r10895. as far as i can see, buildbot is all green.
<BjornT> mars: why kick it? the last build succeeded
<sinzui> BjornT, thanks for seeing that! mars, I think db-devel has already played the test
<mars> BjornT, ah, ok.  So I was confused because it got fixed without any mail to the list saying "Everything is good again".
<mars> So I said "Oh, it must be broken"
<BjornT> mars: yeah, we should teach people to always reply to build failures, so that others don't waste time trying to fix something that has already been fixed
<bac> hi matsubara
<matsubara> bac, hi
<bac> matsubara: i'm getting the message rejection email when i submit a MP even though i am subscribed to launchpad-bugs.  does mesh with your understanding of the problem?
<matsubara> bac, I'm looking at the subscribers list and your email is parenthesized which means: Parenthesized entries have list delivery disabled.
<matsubara> maybe that's the reason?
<bac> no
<bac> i just talked to barry and he said i should be able to post still
<bac> matsubara: i think the problem is canonical-ubuntu-platform is subscribed to devel
<matsubara> I'm not even sure if the hypothesis is true anymore, since ~launchpad is configured to not receive any email from devel
<matsubara> bac, but then email to that team would go to: mdz-ubuntuplatform@alcor.net
<matsubara> s/email/emails/
<bac> matsubara: ok, so maybe that's not it
<bac> matsubara: but launchpad-bugs is not the culprit, i don't think
<bac> it's really annoying
<matsubara> bac, AFAICT, there can be only one team in LP using the launchpad-bugs@lists.ubuntu.com email address
<matsubara> and that's ~launchpad
<bac> matsubara: right but we don't really know that list is the culprit
<matsubara> hmmm, unless we have another team with launchpad-bugs@lists.canonical.com
<bac> matsubara: and that list has been the contact email forever
<mwhudson> morning
<thumper> morning
<jelmer_> 'moin mwhudson, thumper
<thumper> hi jelmer_
<thumper> I saw in passing last night that you had tweaked dulwich
<thumper> jelmer_: I can't seem to reproduce the original failure locally :(
<jelmer_> Things that involve reference loops and the garbage collector never seem to be predictable :-/
 * thumper does school run
<mars> abentley, still online?
<abentley> mars, sure.
<mars> abentley, have a moment to look at that test suite problem you encountered?
<abentley> mars, OTP
<mars> abentley, ok, whenever you have a moment then
#launchpad-dev 2010-05-21
 * thumper has lunch calling
<lifeless> gary_poster: ping, if you're around
<lifeless> gary_poster: I'd like https://bugs.edge.launchpad.net/launchpadlib/+bug/552419 to be addressed by squelching the warning; we can do it in bzrlib but really doing it in launchpad would be closer to the source
<mup> Bug #552419: Multiple module import warning from ubuntu-bug <apport-bug> <i386> <lucid> <launchpadlib :Invalid> <python-launchpadlib (Ubuntu):Confirmed> <https://launchpad.net/bugs/552419>
<thumper> hmm...
<thumper> where to general launchpad bugs live?
<thumper> as in cross app ones?
<thumper> ah ha
<thumper> launchpad-web
<adeuring> good morning
<mrevell> Morning!
<leonardr> lifeless, i woke up very early--if you're around and want to talk about web service things, let me know
<lifeless> hey
<lifeless> I'd love to know enough to get useful traces of behaviour for you
<lifeless> I like some of the things you're talking about
<leonardr> traces of behavior == my plan?
<lifeless> traces of behavior == what requests are made by launchpadlib when do something that uses API's
<lifeless> s/when do/when I do/
<leonardr> ah
<lifeless> like you pasted in your email
<lifeless> you know precisely whats going on and going wrong
<leonardr> sure
<leonardr> the simplest way to do it is:
<leonardr> import httplib2
<leonardr> httplib2.debuglevel = 1
<lifeless> how would you feel about that being in the docstring for launchpadlib/__init__.py ?
<leonardr> sounds good
<lifeless> would you like me to propose a merge for that ?
<lifeless> or do you want to JFDI ? :)
<leonardr> sure. i can also put timing information in lazr.restfulclient that's controlled by httplib2.debuglevel or a separate debuglevel
<leonardr> httplib2's debuglevel won't give your elapsed time
<lifeless> ok
<lifeless> is there a PPA with latest (launchpadlib and deps) ?
<lifeless> maybe not nightlies, but something moving faster than lucid :)
<bigjools> we have this great search facility for PPAs
<bigjools> *cough* :)
<lifeless> bigjools: we do?
<bigjools> https://edge.launchpad.net/ubuntu/+ppas/
<bigjools> you can also vist the source package page and it lists PPAs with the same source
<lifeless> bigjools: so, I visited https://launchpad.net/ - no links towards PPAs there
<leonardr> i don't have a ppa--i know pretty much nothing about building debs. if i can get a script from james_w or something i can run it as part of my release process
<lifeless> leonardr: we can hook you up with a script, for sure.
<lifeless> bigjools: the problem here is that I want social data, not machine data.
<lifeless> bigjools: teasing you about discoverability aside.
<bigjools> lifeless: they're linked to distros, but it seems the link from the Ubuntu page has disappeared :/
<lifeless> bigjools: also, https://edge.launchpad.net/+search?field.text=launchpadlib  is pretty useless (global search)
<bigjools> oh wait, top right of https://edge.launchpad.net/ubuntu/
<lifeless> bigjools: it would be nice for global search to say 'this package is in X PPAS [-> for more]'
<bigjools> indeed
<lifeless> need a bug ?
<bigjools> I think PPAs should be linked from the front page too
<bigjools> yeah, file it on foundations
<bigjools> the latter on registry I think?
<lifeless> what is the latter?
<bigjools> [09:58:23] <bigjools> I think PPAs should be linked from the front page too
<bigjools> I wonder what mrevell thinks about that one actually?
 * mrevell reads up
<mrevell> bigjools, Yeah, I agree. We get complaints that Ubuntu isn't always that easy to find from the LP home page, which is kinda related.
<mrevell> bigjools, What do you have in mind, other than the link we have already?
<lifeless> mrevell: on the home page?
<bigjools> mrevell: PPAs should generally be more prominent I think
<mrevell> lifeless, In the list below "Launchpad is a software collaboration platform that provides:" ... that you didn't see it suggest it's a failure...
<lifeless> mrevell: https://launchpad.net/
<lifeless> mrevell: where is that text on that page ?
<bigjools> I don't see it either
<mrevell> bigjools, We need to redesign the home page generally, I think, so that it's easier to get stuck into some work, as well as just a promotion for LP.
<mrevell> lifeless, bigjools: Damnit, I'm looking at the "not logged in" version.
 * mrevell logs in
<lifeless> mrevell: perhaps you have a super secret launchpad instance ?
<bigjools> mrevell: yeah, the front page has sucked for years :(
<mrevell> lifeless, bigjools: I have a call just now but I'd love to talk about this some more later.
<lifeless> mrevell: bug 583707
<mup> Bug #583707: show a link to PPAs on the launchpad home page <Launchpad Registry:New> <https://launchpad.net/bugs/583707>
<lifeless> leonardr: I'll file a couple of small bugs for you re what we just chatted about
<mrevell> thanks lifeless
<leonardr> lifeless, great
<lifeless> leonardr: I think that generally things are heading in a good direction; I appreciate that you have a gargatuan challenge; I see and get your concerns about manpower and API management.
<bigjools> lifeless: anyway did you find the PPA using the search?
<lifeless> bigjools: no
<bigjools> has
<lifeless> I've been filing bugs
<lifeless> LP from NZ man.
<lifeless> bigjools: are you saying there is one ?
<bigjools> https://edge.launchpad.net/ubuntu/+source/python-launchpadlib
<bigjools> open the expander at the bottom
<leonardr> lifeless: supposedly i have another person coming on to the team soon, but even so we don't really have any option but to put a facade on top of what already exists in launchpad
<lifeless> leonardr: well, thats certainly true while your separate team is totally responsible for the web api
<lifeless> leonardr: I'm not suggesting that that should change, just noting that its not the entire space of ways-to-structure-the-problem
<leonardr> agreed
<lifeless> bigjools: so there are some ppas. That doesn't tell me which are reliable, and which track what leonardr does ;)
<leonardr> the main alternative is to delegate the work to the launchpad team as a whole. that's what we did for the initial implementation, and it worked out okay
<leonardr> certainly it was the solution that got us a working web service the fastest
<leonardr> but, apart from any quibbles i have about the way it was done, i don't think it's reasonable to be able to call on a certain amount of work from everyone on the launchpad team whenever we need to make a web service change. and not all the changes can be rolled out gradually as the different teams schedule work for it
<lifeless> I kind of feel that your role should be an empowerment one
<bigjools> lifeless: those ones are sorted by karma
<lifeless> to help the team scale out
<bigjools> I think we suck at packaging lplib
<lifeless> bigjools: which is interesting but doesn't tell me tiether of the things that I need to know.
<lifeless> leonardr: bug 583710 about some docs
<mup> Bug #583710: debugging docs <launchpadlib :New> <https://launchpad.net/bugs/583710>
<leonardr> i would like to take on that role as well. the web service needs an 'audit' to make it self-consistent, but after doing that audit i may be able to step back a bit
<lifeless> in that each team appears keen to garden their part of the API already
<bigjools> lifeless: we'll be adding PPA download stats and ratings as part of the software centre work
<lifeless> bigjools: what I want is the answer to '<project lead>, what PPA do you recommend?'
<leonardr> but in that role i would like to say, here's a new tool and how to adapt your part of launchpad to use it, rather than direct the creation of entire alternate apis. even distributed over the launchpad team, alternate apis are a lot more work for everyone
<bigjools> lifeless: what did <project lead> say? :)
<lifeless> bigjools: he said 'hook me up with daily buidls'
<bigjools> heh
<lifeless> leonardr: yup, if everything else is equal that is obviously massively preferrable. And stays preferrable even when many things aren't equal.
<lifeless> https://bugs.edge.launchpad.net/launchpadlib/+bug/583712 for PPA packaging
<mup> Bug #583712: nightly / release builds in a PPA? <launchpadlib :New> <https://launchpad.net/bugs/583712>
<lifeless> its actually pretty easy, but you'll want oh, 3-4 hours set aside to come up the learning curve.
<leonardr> all right
<lifeless> leonardr: or someone may take pity and give you a little script to put in your tree and run to do an upload. However I think its advantageous to you to know how to get releases 'up there'.
<lifeless> On the u1 team, they take responsibility for packaging all the way to Ubuntu for their products.
<leonardr> even if i get a little script i'll need to hack the script for lazr.restfulclient
<leonardr> where most of the code lives
<lifeless> I think this is a good model, for all that it has some overhead, it makes understanding how the distro hangs together (and thus what the crazy folk over there want :P) easier.
<lifeless> naturally.
<deryck> Morning, all.
<lifeless> leonardr: around? (Pdb) mp.all_comments[-1]
<lifeless> *** ValueError: Collection slices must have a nonnegative start point.
<lifeless> leonardr: is that by design or by time ?
<lifeless> if the latter, where should I file the bug.
<leonardr> hmm
<lifeless> I want to 'show the user the most recent review comment'
<leonardr> it's by time in that we don't have any fundamental desire to not have that feature
<lifeless> mp is a branch_merge_proposal
<leonardr> but, making it work in general is pretty difficult
<lifeless> sure, but lets go step by step;)
<lifeless> is the all_comments collection sorted by anything at the moment /
<lifeless> nothing seems to indicate any which way, that I can see
<leonardr> i don't know, that's up to the database implementation
<lifeless> ok
<lifeless> so separate concerns: is -1 useful for what I need, and how to make -1 work at all, assuming it would be useful.
<leonardr> right
<leonardr> so let's assume -1 is what you want
<leonardr> first step is to find out how big the collection is
<lifeless> why ?
<lifeless> actually, where should I record this ? lazr.restful ?
<leonardr> that depends on the answer to 'why?', actually
<lifeless> heh, ok.
<leonardr> we could fix this on the server side or the client side
<lifeless> [or both?]
<leonardr> but file it against lazr.restfulclient, because there will definitely be a client component
<leonardr> let me start over
<leonardr> in the easy case, all the comments will fit on one page
<leonardr> so, the client will get /mp/comments and get back a collection that has no next_link
<leonardr> then it can just give you the last one
<lifeless> so what we see as a colletion is a series of pages [in the VM sense] with a forward pointer ?
<leonardr> yes
<leonardr> you can simulate this with [x for x in mp.comments][-1], since it's unlikely a merge proposal will have a huge number of comments
<lifeless> right
<lifeless> I'm just doing 'is there a better way' analysis
<leonardr> yeah
<lifeless> well, you're doing it.
<lifeless> I'm joe schmo asking silly questions :)
<leonardr> let's consider what happens when there are too many items to fit on one page
<leonardr> let me say something and then we can optimize it
<leonardr> we can make a request for /mp/comments. we'll get back a document full of useless comments, but we will also get back the total size of the collection
<leonardr> let's say it's 780
<lifeless> thats pages or items ?
<leonardr> items
<leonardr> we can then calculate 780-1=779 on the client side
<leonardr> and make a second request for /mp/comments?ws.start=779
<leonardr> that will give us -1
<leonardr> that will work without changing the server, but it requires two requests, one of which will send a lot of useless data
<lifeless> sure
<lifeless> server side could accept -1 though, right? and give us a 'last page'
<leonardr> yes, that's what i was thinking of
<leonardr> the client could make a request to /mp/comments?ws.start=-1 and get back a collection of one item
<leonardr> one request, less bandwidth
<lifeless> or perhaps, assume negative iteration, and give the last page-count items
<leonardr> that would make ws.start mean different things--a page if the number was negative, an offset if the number was positive
<lifeless> RTT dominates bandwidth I'd expect here. Clearly tunable later though, which ever way
<lifeless> leonardr: ah, I see what you mean.
<lifeless> leonardr: I was thinking the vector would invert for a -value
<lifeless> so it would mean the same thing
<lifeless> go 'X' away from the origin
<lifeless> if we consider the collection a circle
<lifeless> consider this:
<leonardr> ok
<lifeless> collection[-1]; collection[-2]; ....
<lifeless> wouldn't want to send us all the things we have every time.
<lifeless> OTOH the client could cater for that and supply absolute values after the first one
<lifeless> as well as a ws.stop
 * lifeless guesses at parameter names
<leonardr> ws.size
<leonardr> it's the same as we use internally, i think
<leonardr> in launchpad
<james_w> well, if lazr.restful sees -1 and sends the last page lazr.restfulclient would still handle that wouldn't it?
<james_w> you don't get one element if you do collection[0]
<james_w> or at least, could handle it
<lifeless> leonardr: that seems to be pretty easy actually ;). Anything else I should capture ?
<leonardr> yes, but i still think it would be inconsistent for lazr.restful to see -1 and send the last *page*
<lifeless> james_w: I would think so, yes.
<james_w> why?
<leonardr> if you do collection[0] lazr.restful gets a page _starting_ at 0
 * lifeless waves the I have a bug open flag
<leonardr> lifeless: what we have now is fine
<lifeless> leonardr: thanks! brain dump completed, your ticket number is bug 583761, have a nice day.
<leonardr> i guess lazr.restfulclient could get the largest possible page that _includes_ the item you want
<mup> Bug #583761: collection[-1] raises an error : *** ValueError: Collection slices must have a nonnegative start point. <lazr.restfulclient:New> <https://launchpad.net/bugs/583761>
<leonardr> but without other changes, that wouldn't buy us anything. we don't cache collections client-side because we have no idea of a max-age for the cache and no algorithms for invalidating the cache
<leonardr> the most efficient thing to do when given a single-item slice is to make a request for that specific item--anything else uses more bandwidth without reducing the number of http requests
<leonardr> (at least i'm pretty sure that's how it works)
<lifeless> ok
<lifeless> so [0] only gets one item as well ?
<james_w> no [0] gets a page
<james_w> and that page will be reused if you then to [1] I believe
<lifeless> hang on, thats inconsistent
<lifeless> with not caching collections client-side
<james_w> actually, that's a bit general
<leonardr> let me find out what actually happens
<james_w> if you do [X] then it gets a page
<james_w> but [X+1] will not re-use that page and do a new GET
<leonardr> so the current behavior uses more bandwidth than it should, given how many http requests it makes
<james_w> however, there is a special case, if on the first request you get a representation then that is stored, and any request from that page will re-use it
<leonardr> james_w, do you have a line number handy?
<james_w> 722 resource.py
<james_w> http://paste.ubuntu.com/437272/
<leonardr> so we only keep one 'page' (the first page) in memory
<leonardr> this has all the problems of client-side caching
<leonardr> an app could run for 3 days, contain inaccurate data, and the client would never know
<leonardr> but in most ordinary cases it's not a big deal
<james_w> yes
<leonardr> however, if we start getting serious about this, caching the 'last' page or any other pages of the collection, it would become a bigger deal
<lifeless> I really need to track /usr/lib/pymodules/python2.6/lazr/uri/__init__.py:19: UserWarning: Module launchpadlib was already imported from /usr/lib/pymodules/python2.6/launchpadlib/__init__.py, but /usr/lib/pymodules/python2.6 is being added to sys.path
<lifeless>   import pkg_resources
<lifeless> it is tres annoying
<leonardr> it may make sense to limit our caching of the first 'page' to the results of named operations, which are very expensive, always deliver a single 'page' of results, and are represented as ad hoc collections rather than as things you can get to by dereferencing attributes of launchpad
<lifeless>  down
<leonardr> lifeless, gary might be able to help, if james_w can't
<lifeless> oh, he has mail ;)
<james_w> I have NFI, I've briefly looked previously
<lifeless> james_w: do you see it ?
<james_w> the message is kind of silly anyway
<james_w> yeah
<lifeless> spiv doesn't
<james_w> can't remember what from though
<lifeless> he's on lucid too
<lifeless> james_w: try hydrazine, bughugger, pqm ?
<lifeless> lp-propose
<james_w> don't think it was them
<leonardr> so, summary: once we have some standards for client-side cache, it would make sense to have lazr.restfulclient ask for a whole page when you try [-1]. until that point, it makes sense to have lazr.restfulclient ask for a page just big enough to handle whatever slice it's given
<lifeless> could you try 'bzr lp-propose' somewhere ?
<lifeless> hmmm
<lifeless> that was unexpected
<lifeless>   File "/usr/lib/pymodules/python2.6/lazr/restfulclient/resource.py", line 860, in __getitem__
<lifeless>     raise KeyError(key)
<lifeless> KeyError: u''
<lifeless> bzr bug, not lp - don't bother looking for it
<matsubara> bac, ping
<james_w> lifeless: I don't get it from lp-propose
<lifeless> interesting
<lifeless> what if you run from source?
<james_w> I am running from source
<lifeless> ok
<lifeless> so its not the packaged status
<lifeless> and its not the python code itself, as lp-propose does it for me
<lifeless> :!echo $PYTHONPATH
<lifeless> /home/robertc/lib/python:/home/robertc/local/lib/python2.6/dist-packages/
<lifeless> anyhow, getting close to 1am, sleeeeeeep
<deryck> BjornT, hi.  Did we ever support +bugs-text for a person context in the past?
<BjornT> deryck: hmm. can't remember. if we don't today, then probably not.
<deryck> BjornT, yeah, this is my impression, just on glancing at the code.  That we don't and likely never did.
<didrocks> hey,
<didrocks> I got some issues when trying to branch: $ bzr branch lp:~ubuntu-branches/debian/sid/evince/sid/ debian
<didrocks> bzr: ERROR: Invalid http response for https://xmlrpc.edge.launchpad.net/bazaar/: Unable to handle http code 503: Service Unavailable
<didrocks> (for the last few minutes)
<didrocks> ah, this time it's ok, temporary issue so :)
<adiroiban> henninge: merged and pushed
<adiroiban> lp:~adiroiban/launchpad/bug-525992
 * jml is gone
<lifeless> gary_poster: hi
<gary_poster> lifeless, hi
<gary_poster> saw your question on bug
<gary_poster> haven't gotten around to answering, but
<lifeless> I was wondering, since I seem to be awake at 5am, if we could talk about that warning
<gary_poster> :-)
<gary_poster> basic answer is two parts:
<gary_poster> - This is typically a packaging issue, not a software issue
<gary_poster> - I'm happy to help.  I haven't looked at the bug again to see if there are instructions to dupe but was going to
<lifeless> ok
<lifeless> so I appreciate that it may well be a 'what some distro dude did' cause, but....
<gary_poster> (Also, in regards to bug about packaging, yes, would like to have launchpadlib et al in a PPA)
<lifeless> on all our products, we're judge by how they deploy, not how they run on our machines :)
<lifeless> s/judge/judged/
<lifeless> I'm glad you're happy to help.
<gary_poster> yup
<lifeless> that makes me happy, because otherwise I suspect it would bitrot
<lifeless> now, for reproduction
<lifeless> it seems to be spotty
<lifeless> e.g. spiv doesn't see it
<lifeless> I see it reliably
<lifeless> james westby sees it occasionally and can't remember where from
<gary_poster> typical for these things :-/
<lifeless> When it first occured I dug down and looks at the setuptools code in question - ugh  :(
<gary_poster> often means there's either a package installed on your system causing an interaction
<gary_poster> or an old package that left stuff around on an upgrade or deletion
<gary_poster> yeah, ugh :-/
<lifeless> ok, so one posibility is a stale pth file or similar ?
<lifeless> uhm
<lifeless> perhaps makign sys.path a smarter object in site.py would be a good way to test?
<lifeless> get a traceback on every change made to it
<gary_poster> meh, maybe
<lifeless> well, we don't know whats triggering
<gary_poster> yeah I know
<gary_poster> It's just...there's probably going to be a lot of noise
<lifeless> oh, sure.
<gary_poster> but I don't have a better idea.  thinking,
<lifeless> but we can filter for the path we care about in the first instance
<lifeless> and if that doesn't help go broader
<gary_poster> lemme see the bug, how's that for a crazy idea
<lifeless> \o/
<gary_poster> ok got it
<james_w> .pyc files from older versions aren't out of the question when packages have been installed and upgraded
<james_w> in other locations I mean
<gary_poster> heh, yeah, these are always fun.  "import pkg_resources" is the trigger, with lazr.restfulclient not doing anything else.  this isn't lazr.restfulclient's problem (and possibly not even the problem in the packaging) but your system + setuptools (+ our Ubuntu python dances?  not sure).
<gary_poster> lifeless, if it were on my system, I'd put a pdb where that UserWarning is raised.  /usr/lib/python2.6/dist-packages/pkg_resources.py:2334 .  Then I'd see if I could see what's going on.
<gary_poster> There's a high probability that the problem has already occurred at that point.  Your site.py idea might help then, though...there might be a nicer place to hook into the process in site.py.  looking there, one sec
<gary_poster> Maybe instrumenting site.addpackage?
<gary_poster> And if that isn't informative enough, site.addsitedir
 * gary_poster wonders if python -v would help
<gary_poster> nah, doesn't look like it
 * gary_poster goes back to regularly scheduled programming until he is pinged again
<lifeless> -v gives http://pastebin.com/PgizKBdY
<lifeless> for the curious
<lifeless> this is interesting
<lifeless> # /usr/lib/pymodules/python2.6/launchpadlib/__init__.pyc has bad mtime
<lifeless> but may be from me fiddling
<lifeless> moving the file doesn't fix it, its noise
<lifeless> running feed-pqm as root doesn't magically fix it either
<lifeless> actually I lie
<lifeless> it did
<lifeless> for the next run.
<lifeless> so a) definitely something stale and b) I can't tell you what, now.
<gary_poster> ok
<gary_poster> um
<gary_poster> so the problem has gone away, entirely, after running as root?  Or it did not occur when you ran as root?
<lifeless> occured as root, and is now gone
<lifeless> I'm doing a find for modified files
<gary_poster> ok
<cody-somerville> weird. I just did a merge of a branch from an MP and the changes are dramatically different from the diff in the MP.
<cody-somerville> ah
<cody-somerville> my branch wasn't up2date :)
<lifeless> someone intimate with launchpad lib needs to check if much of bzrlib.plugins.launchpad.lp_api is still needed
<james_w> lifeless: LAUNCHPAD_API_URLS can probably be dropped, you can now pass 'edge' etc. to the factory methods
<james_w> it's taking something that isn't a plain string though
<james_w> I don't know that the chmod that is in login() is in launchpadlib yet?
<james_w> the rest looks like it is still needed
<lifeless> thanks
#launchpad-dev 2010-05-22
<thumper> :(
<thumper> looks like every single windmill test is broken
<wgrant> thumper: Hm?
<thumper> wgrant: in the buildbot
<wgrant> Awesome.
<wgrant> This is why disabling them in ec2test is awesome.
<lifeless> yes
<lifeless> disabled tests are broken tests
<thumper> :(
<thumper> I feel they will be fixed soon
<thumper> otherwise there'll be hell to pay
<thumper> as in windmill fixed in ec2test
<deryck> gah.  These test failures are driving me crazy.
<adiroiban> deryck: Hi. Were you able to reproduce them?
<deryck> adiroiban, hi.  yeah, I can now.  Had to do a make clean && make but then I do get complete Windmill failure.
<deryck> adiroiban, rolling back to prior to our 3 changes and I get a pass.  So trying to work out which rev introduced the pain.
<adiroiban> deryck: start by rolling my branch, as it was the only one touching some js code
<deryck> adiroiban, I'm just bzr up'ing from the last known working rev.  one by one until I get fail.
<adiroiban> ok. and can you also run a single test and it is failing ?
<deryck> adiroiban, yeah, even a single test fails for me.
<deryck> adiroiban, so it does seem to be your rev.
<deryck> adiroiban, seems js is not hooked up properly in testing, so maybe a problem loading something you wrote when not in devmode?  Just a guess.
<adiroiban> adiroiban: after, make clean ; make
<adiroiban> I am also able to reproduce them
<deryck> ah, yeah.  so if you run the dev server with devmode off, you can reproduce the js not being hooked up properly locally.
<deryck> z is not defined. ?
<adiroiban> deryck: uh...
<adiroiban> at the end of pofile.js
<adiroiban> there is a âzâ char
<adiroiban> it should be deleted
<deryck> adiroiban, yeah, thanks.  I see it now.  Fixing up a branch to submit for testfix now.
<adiroiban> deryck: my fault. It looks I have accidentaly commited it while merging devel.
<deryck> adiroiban, no worries.  Can you reply to the list about the fix and that I am submitting a testfix branch for it?
<adiroiban> deryck: lp-dev list?
<adiroiban> or will you moderate my post to  canonical-launchpad@lists.canonical.com
<deryck> adiroiban, ah, right.  Sorry, I'll reply then.
#launchpad-dev 2010-05-23
<magcius> argh why is loggerhead so slow
<lifeless> magcius: what branch is it slow on?
<magcius> lifeless: something like this: https://code.launchpad.net/~twisted-dev/twisted/trunk
<magcius> lifeless: takes around 30 seconds for me
<magcius> oh wait it's borked again
<magcius> yay loggerhead broke
<magcius> also, I submitted about 3 or 4 bugs for Loggerhead about a month, maybe two ago. I never got a single reply on any of them
<magcius> Sorry, I submitted 2
<lifeless> we're sorry about that, folk have be variously: overseas, sick, changing teams
<lifeless> jam is working on loggerheads plumbing at the moment, fwiw
<lifeless> it seems reasonably fast to me
<magcius> lifeless: sorry about what? (just clearning ambiguity, not snarkiness)
<lifeless> sorry that you haven't heard back on those two bugs
<magcius> lifeless: okay. Is this a plumbing issue or not?
<lifeless> performance is
<magcius> argh, I pasted the wrong URL
<magcius> but it's working now, and a little faster
<magcius> http://bazaar.launchpad.net/~twisted-dev/twisted/trunk/files
<magcius> that's what I meant to paste
<lifeless> rendered in 7 seconds
<magcius> okay
<lifeless> which is suboptimal but not glacial
<magcius> lifeless: could just be that I was the first one to hit it, and it was cached
<lifeless> I'm clicking around
<lifeless> it seems to be working
<magcius> hm
<magcius> lifeless: second, is there a chance you could put a link somewhere on the registry page that links to the main branch, or at least have http://bazaar.launchpad.net/twisted resolve to lp:twisted?
<lifeless> 'registry page' ?
<magcius> lifeless: I was told that the main "landing page" is called the Launchpad Registry
<magcius> like http://launchpad.net/twisted
<lifeless> for me that has a link to http://bazaar.launchpad.net/~twisted-dev/twisted/trunk/files
<lifeless> left side, blue i icon below 'development focus'
<lifeless> 'View the branch content'
<magcius> oh heh
<magcius> is that new? I never saw that before.
<mwhudson> it's fairly new i think
<magcius> but yeah, that's very useful
<magcius> Thanks.
<magcius> third, I'd really like the "tables" you have to be JS-sortable
<magcius> in fact, I don't think they're sortable at all
<lifeless> in loggerhead or lp ?
<magcius> oh wait, it's that little combobox next to the search
<magcius> lifeless: lp
<magcius> okay, the combobox isn't obvious atall
<lifeless> I'm lost
<magcius> lifeless: hm?
<magcius> yeah, that was /msg-ing out loud
<lifeless> I don't know what you're referring to now
<magcius> lifeless: simple example of a "table": https://bugs.launchpad.net/bzr
<magcius> lifeless: right now the combo box next to the search entry is the "sort" specifier, not really obvious
<lifeless> thats true
<magcius> lifeless: what about JS-sorting the tables? The combobox has more columns, but I think that a sort of something that isn't visible isn't helpful
<lifeless> in fact, there is no reason that the column headings couldn't cause an ajax refresh with a different order, and/or switch page [of the search results] to one with the same first bug on it
<magcius> lifeless: sorry, didn't quite follow you there
<lifeless> magcius: many listings are conceptually hundreds of pages long, and there is a disconnect between 'change the order of the shown items' and 'change the overall sort of the listing'
<magcius> lifeless: yeah, that's what I thought
<lifeless> we used to have JS sorting of the shown items
<lifeless> and it confused the hell out of people
<magcius> lifeless: so the quick hack was the combobox, gotcha
<magcius> lifeless: a better placement, or a different style would be nice
<lifeless> well the combobox allows you to choose the global sort you'll get
<lifeless> when you do a search
<magcius> I guess.
<lifeless> I'm not guessing ;)
<lifeless> when you submit the search form
<magcius> Well yeah.
<lifeless> that combobox tells launchpad the order to sort the results in
<magcius> Yeah. I got that.
<lifeless> ok ;)
<lifeless> what would make the placement better for it ?
<lifeless> its right between the text you search with and the button to submit
<magcius> I was thinking "Sort by: Bug Number | Last Updated | Importance" links directly above the table on the right or left
<lifeless> would that refer to the shown items ?
<lifeless> If so, I could see 'Sort this page by <drop down>' (the sort orders available are numerous)
<lifeless> would you like to file a bug asking for that ?
<lifeless> bbiab organising food for family
<thumper> morning
<poolie> hi thumper
<thumper> hey poolie
<poolie> are you coming to the epic?
<thumper> yes
<thumper> there's no show without punch :)
<poolie> :)
#launchpad-dev 2011-05-16
<wgrant> lifeless: Successful builds don't send email.
<wgrant> Except for recipes.
<wgrant> But that's about to be fixed.
<wgrant> maxb: I see the bug on +commentedbugs if I change the filter to not exclude closed bugs.
<maxb> Whoops! I didn't even notice that there was a filter
<wgrant> It's the same default one everywhere.
<wgrant> There's probably a four-digit bug about that.
<lifeless> wgrant: is https://bugs.launchpad.net/launchpad/+bug/570846 still in progress?
<_mup_> Bug #570846: Archive freeze should not affect Partner <boobytrap> <lp-soyuz> <partner> <trivial> <Launchpad itself:In Progress by jelmer> < https://launchpad.net/bugs/570846 >
<wgrant> lifeless: No.
<wgrant> lifeless: You still can't repro the rabbit failure?
<wgrant> It fails on both trunks here, but not lucid_lp, so it's something local.
<wgrant> (I also had problems running this in U1, which is possibly relevant)
<wgrant> it seems to start OK.
<wgrant> erm
<lifeless> wgrant: I can't repro
<wgrant> It was /etc/hosts.
<wgrant> 127.0.0.1 has to resolve to the hostname, not localhost.
<wgrant> Which is not the default config.
<wgrant> It starts fine on localhost, but then something tries to connect to the node @realhostname instead of @localhost, which fails.
<wgrant> s/socket.gethostbyname()/localhost/ in fq_nodename works fine.
<wgrant> But hmmm.
<wgrant> We should talk to U1, I suppose.
<wgrant> So, to unblock things let's get pilinut fixed?
<StevenK> wgrant: I wonder if 127.0.1.1 <realhostname> works too
<wgrant> No.
<wgrant> That's there by default.
<StevenK> Network-manager seems to add <IP> <hostname> to the top of /etc/hosts
<wgrant> It does some evil stuff, but not that (at least for my wired desktop)
<wallyworld_> wgrant: you know a bit about package build stuff, right?
<wgrant> wallyworld_: Indeed.
<wgrant> What's up?
<wallyworld_> wgrant: bug 732343
<_mup_> Bug #732343: Recipe source builds failing because of "Could not build because of missing dependencies" do not send notification email <recipe> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/732343 >
<wgrant> aaaaaa
<wallyworld_> wgrant: there's a unit test for notifications for dependency issues and i can't see why it would be failing
<wallyworld_> by it, i mean the prod code
<wallyworld_> i'm sure the test would pass
<wgrant> wallyworld_: You're looking at a recipe build, not binary builds?
<wallyworld_> wgrant: ah that may be it. i think i've got myself confused
<StevenK> So, situation normal, then?
<wgrant> This stuff has that effect on people.
<wallyworld_> :-P
<wallyworld_> so i need to find a sourcepackagebuild class analogous to the binarypackagebuild class?
<wgrant> sourcepackagerecipebuild.
<wallyworld_> right. i'm sad that extends a storm class and has all this business logic in it :-(
<wgrant> That's how LP works :)
<lifeless> wgrant: u1 or landscape
<wallyworld_> wgrant: i think you meant to type :-(
<wgrant> No, no, a forced smile of the "I cannot let myself realise how terrible this is or I will surely die" variety.
<wgrant> zomg, armel is about to catch up.
<wgrant> 272 builds left.
<wallyworld_> wgrant: sort of like when your old aunty gives you a cardigan for xmas and you say "oh how lovely" through a forced smile
<StevenK> I never had that problem -- it was usually my mother giving me clothes
<wgrant> wallyworld_: Right.
<lifeless> maxb: bug 5977
<_mup_> Bug #5977: Person's Bugs pages do not show closed bug reports <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/5977 >
<wgrant> That's the one.
<wgrant> lifeless: So, lucid_db_lp needs sorting out. Can you look at that?
<StevenK> wgrant: rabbitmq likes neither 172.0.1.1 or the builder's IP <hostname> in /etc/hosts
<StevenK> Er, 127.0.1.1
<wgrant> StevenK: I had 127.0.0.1 localhost <hostname>. 127.0.0.1 <hostname> localhost unbreaks it.
<StevenK> Hmm, that doesn't help.
<wgrant> What's the error?
<StevenK> FAILED - check /var/log/rabbitmq/startup_log, _err
<wgrant> Need more than that.
<wgrant> Erm, is this the system rabbit?
<wgrant> Not the fixture?
<lifeless> that looks like the system rabbit
<StevenK> Tis
<lifeless> which is going to be running shite wrapper scripts
<wgrant> Yes.
<StevenK> The fixture rabbit does not require the system rabbit to be running?
<wgrant> No.
<wgrant> It starts its own.
<StevenK> Ah
<lifeless> makes a homedir for it, unique nodename (by allocating a tmpdir in /tmp) etc
 * StevenK branches devel on this builder so he can test
<thumper> the dx channel is much quieter during my work day :-|
<StevenK> thumper: That's what you get!
<thumper> :)
 * thumper moves away from coffee shop
<lifeless> thumper: what are you hacking on atm?
<cjohnston> Is 7 merge proposals for my very first day of looking at the launchpad code too much? ;-)
<wgrant> Yes.
<cjohnston> lol
<lifeless> it shows great enthusiasm
<lifeless> I hope that any stuff the reviews may need will be shallow
<cjohnston> about half were pet peeves
<cjohnston> and i learned at uds how to get into the code.. so that was a start
<lifeless> can has review https://code.launchpad.net/~lifeless/launchpad/rabbit/+merge/61057
<lifeless> lunch,then some analysis
<wgrant> lifeless: Analysis of why the build is broken, I hope.
<lifeless> regressions
<lifeless> whats up with the build?
<wgrant> lucid_db_lp is permanently broken by rabbit.
<wgrant> Please fix it.
<lifeless> hmm, otp not coming up
<wgrant> wallyworld_: Any luck with the recipe notification thing?
<wallyworld_> wgrant: https://code.launchpad.net/~wallyworld/launchpad/recipe-build-missing-dep-email/+merge/61058
<lifeless> would windmill have caught bug 781460?
<_mup_> Bug #781460: bugttask_index.js hide_assignee_team_selection handling broken <javascript> <qa-ok> <regression> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/781460 >
<wgrant> lifeless: No.
<wgrant> There was no test.
<wgrant> But there is now.
<wgrant> wallyworld_: So, that's not ideal.
<wgrant> wallyworld_: Since it affects binary package builds too.
<wgrant> wallyworld_: And they are automatically retried.
<wallyworld_> wgrant: ok. i thought we wanted to send the email both times
<wallyworld_> but i guess if they retry
<wallyworld_> then no need for binary builds
<wgrant> Right.
<wallyworld_> ok. will fix. thanks
<wgrant> Some have argued (eg. bug #218261) that depwait should notify after a time.
<_mup_> Bug #218261: uploaders should get emails/notifications for packages in depwait mode <email> <lp-soyuz> <soyuz-build> <Launchpad itself:Triaged> < https://launchpad.net/bugs/218261 >
<wgrant> But doing it every time would be bad.
<wallyworld_> wow, that's an old bug
<wgrant> Although we don't have common depwait loops any more, so it might be workable soon.
<lifeless> wgrant: would that have ever worked ?
<lifeless> wgrant: #781460: I mean
<_mup_> Bug #781460: bugttask_index.js hide_assignee_team_selection handling broken <javascript> <qa-ok> <regression> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/781460 >
<wgrant> lifeless: Yes, but it broke during a YUI upgrade.
<wgrant> lifeless: Bug #728059
<_mup_> Bug #728059: Manually editing the URL for a private branch allows user to access +new-recipe form <exploratory-testing> <recipe> <Launchpad itself:Triaged> < https://launchpad.net/bugs/728059 >
<wgrant> You say it's critical because it exposes the existence of private branches.
<wgrant> But we don't try to hide private branches.
<lifeless> we do
<lifeless> why do you say we don't?
<wgrant> Because +index gives a 403, as most private objects do.
<wgrant> In fact, that page 403s for normal users.
<wgrant> Not critical.
<wgrant> If you want private branches to 404, that's another bug.
<lifeless> hmm
<lifeless> I'll talk to flacoste I think
<lifeless> wgrant: why was 714527 a regresion ?
<wgrant> Bug #714527
<_mup_> Bug #714527: owned widget structured strings render as bits of quoted html <qa-ok> <regression> <Launchpad itself:Fix Released by sinzui> < https://launchpad.net/bugs/714527 >
<wgrant> lifeless: sinzui fixed some bug that I don't recall, which ended up breaking that.
<wgrant> So, it was a regression.
<wgrant> I think it was when he fixed the XSS in the item widgets that I reported in December.
<lifeless> spiv: are you still working on 717094 ?
<wgrant> Bug #717094
<_mup_> Bug #717094: InvalidURL OOPS in translatePath because of URL containing non-ascii chars, again <oops> <regression> <Launchpad itself:Triaged by spiv> < https://launchpad.net/bugs/717094 >
<lifeless> thumper: what made 721134 a regression ?
 * wallyworld_ does the school pickup run
<lifeless> wgrant: bug 732442 looks like fallout not a regression
<_mup_> Bug #732442: disable_existing_builds compares series name to display name <recipe> <regression> <ui> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/732442 >
<lifeless> wgrant: I mean - was something actually broken, or was it just never correct?
<wgrant> lifeless: It was actually broken.
<wgrant> Note that a test failed.
<lifeless> and windmill was disabled at the time ?
<wgrant> yes.
<wgrant> lifeless: Bug #728789 was a regression.
<_mup_> Bug #728789: "Request build" dialog indicates builds are pending when they are not and doesn't allow new builds <qa-ok> <recipe> <Launchpad itself:Fix Released by wallyworld> < https://launchpad.net/bugs/728789 >
<wgrant> People were unable to request builds that they could previously request.
<wgrant> Because the new check was buggy.
<lifeless> was there no previous check ?
<wgrant> Correct.
<lifeless> mmm
<lifeless> so during dev of a beta feature
<lifeless> I'm torn
<wgrant> It was a Google beta.
<lifeless> kindof
<lifeless> lp-beta-users only
<wgrant> It was in beta for 12 months.
<wgrant> It was not a major user-affecting regression.
<wgrant> But does that mean it wasn't a regression?
<lifeless> thats not what I meant
<lifeless> there was an arc of development
<lifeless> during that arc things were tightened up to enforce new policies
<lifeless> and some of those changes had bugs
<wgrant> Yes.
<wgrant> And they broke some functionality.
<wgrant> => regression
<lifeless> they broke two things
<lifeless> one that unlimited builds in a day could be done manually
<lifeless> and second that the logic for detecting that was flawed
<lifeless> which is why I'm saying that I'm torn
<wgrant> Erm, what's this about unlimited builds in a day?
<wgrant> This is unrelated to the quota.
<lifeless> maybe I'm misunderstanding the exact circumstances
<wgrant> The check was to prevent people from requesting builds that were already queued.
<wgrant> Unrelated to the silly 5-a-day quota.
<wallyworld_> the request builds popup dialog was new and when deployed, there was a bug found, so not a regression
<wallyworld_> it was a bug in a new feature
<wgrant> wallyworld_: Hm? Users were unable to request builds manually where they could before.
<wgrant> The AJAX form replaced the non-AJAX one, which worked fine.
<wallyworld_> the request build popup was totally new - before that it was html without ajax
<wgrant> Sure.
<wgrant> It was a new UI,.
<wgrant> Replacing an existing UI.
<wgrant> And breaking part of that functionality.
<wgrant> If I replace apt-ftparchive with NMAF, we lose a lot of functionaliaty. It's totally new, but still a regression.
<wallyworld_> the old one was still available. but my view is that a bug in a new feature is not a regression
<wgrant> There was an unobvious workaround, sure.
<wgrant> (one which is itself a bug)
<wallyworld_> i guess it depends on the definition of regression. imo, regression means a break in existing code
<wgrant> Users don't care about code.
<wgrant> They care about functionality.
<wallyworld_> not all workj arounds are obvious, but htere was one
<StevenK> Existing *functionality&
<StevenK> s/&/*/
<wgrant> Before the change: users could request a manual build by clicking the "Request builds" link.
<wgrant> After the change: users were erroneously prevented from requesting a manual build by clicking the "Request builds" link.
<wallyworld_> agreed. but it was a bug in totally new code. so i can see both sides :-)
<wgrant> Users do not care about code!
<wgrant> If I delete all of our code, it is not a bug in the code!
<wgrant> But it is still a regression.'
<wallyworld_> replace "new code" with "new functionality"
<wallyworld_> it was new functionality
<wallyworld_> in a sense
<wgrant> It was a replacement interface for existing functionaliaty.
<wallyworld_> for a feature that was still under development in beta
<wgrant> Very late beta.
<wallyworld_> but technically not officially released
<wallyworld_> we should be down the pub having this discussion over a beer :-)
<wallyworld_> i'm just stirring the pot a bit :-)
<wgrant> Heh.
<StevenK> wallyworld_: Just because the feature isn't released doesn't mean it isn't a regression.
<wgrant> It is less important.
<wgrant> But not not a regression.
<wallyworld_> i'll go away now. in all honestly, i don't really care one way or the other. just going a bit stir crazy
 * StevenK hits wgrant with the double-negative stick
<lifeless> wgrant: why was 766874 a regression ?
<wgrant> Bug #766874
<_mup_> Bug #766874: Inline bug assignment for non-contributors broken in Firefox 3 <javascript> <qa-ok> <regression> <ui> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/766874 >
<wgrant> lifeless: wallyworld had fixed another regression (I forget the number... the one about inline assignment to a non-contributor not giving a warning), and it was borked in Firefox 3.
<wgrant> Windmill caught it.
<wgrant> But was disabled at the time.
<lifeless> what about bug 768336
<_mup_> Bug #768336: Subscribing to a bug doesn't show display name on FF4 <qa-untestable> <regression> <story-better-bug-notification> <Launchpad itself:Fix Released by benji> < https://launchpad.net/bugs/768336 >
<wgrant> I wasn't involved in that one. I don't know if it was related to the new subscription work.
<lifeless> I really wish I could click on links after viewing the merge diff
<wgrant> Hmmm, I saw that once locally.
<wgrant> Last week.
<wgrant> Thought it was a browser glitch.
<wgrant> But I guess not.
<lifeless> wgrant: what makes bug 780429 a regression (other than being a daft change)
<_mup_> Bug #780429: CopyChecker.checkCopy uses check_permission badly <lp-soyuz> <regression> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/780429 >
<lifeless> wgrant: was it functionally wrong, or just high risk / would break if we changed other assumptions?
<wgrant> lifeless: The fact that it called check_permission was high risk.
<wgrant> The fact that it always used the primary archive was a security vulnerability.
<lifeless> ok
<lifeless> https://dev.launchpad.net/Regressions2011#preview
<wgrant> You win lots of points for doing that, but lose several for unreadability.
<StevenK> That page is barely readable
<lifeless> yes
<lifeless> its a draft
<StevenK> And 780429 should be badtest
<wgrant> notest sideffect 777766 the list of subscribers for gtk bugs is empty
<wgrant> badtest, surely.
<lifeless> StevenK: there was a test for permissions on different archives?
<StevenK> There certainly was a few testcases for rvb's work, I can't recall what they did
<wgrant> A relevant test was added at the time of the change.
<wgrant> But it had the same misunderstanding.
<lifeless> so
<lifeless> uhhm
<lifeless> if you know better, please fix
<lifeless> I intend badtest to be when the test intent would cover the thing that was faulty
<wgrant> Ah.
<lifeless> so a test whose intent was to check something funky
<lifeless> and it successfully checked that
<lifeless> is not a badtest
<lifeless> the real problem had no test aiming to cover it
<lifeless> and the tests have to exist before the change
<lifeless> otherwise its notest
<lifeless> I'll add some prose to that effect after dinner
<wgrant> notest sideeffect 754089 launchpad only remembers alternate landing targets in merge proposal creation page for one day
<wgrant>   [r=jcsackett,
<wgrant>   	sinzui][ui=none][bug=541713] Skip targets from old proposals.
<wgrant> Looks more deliberate than a sideeffect.
<lifeless> it was meant to clean up after a while
<lifeless> the knob is wrong
<wgrant> Hm.
<wgrant> That rev set it to 90 days.
<wgrant> rofl
<lifeless> could be badtest
<wgrant> No, it *says* it set it to 90 days.
<wgrant> But it set it to 1.
<wgrant> The relevant line (with days=1) was last changed in r12165.1.2, with a commit message of "The widget for selecting merge targets ignores proposals older than 90 days"
<wgrant> So, not a side-effect, nor really a badtest, because the relevant test was only added then.
<wgrant> Perhaps reviewfail.
<lifeless> well
<lifeless> I think I'd argue badtest
<lifeless> the test that the thing is preserved doesn't really keep the user story intact
<lifeless> anyhow, please fix it up
<lifeless> I put it on the wiki deliberately :)
<wgrant> Yeah.
<wgrant> Well.
<wgrant> I'm fixing the bug instead :)
<lifeless> as for the sideeffect
<lifeless> there was a bug that they accumulated forever
<lifeless> with no way to edit/fix
<lifeless> this regression was added while fixing that bug
<wgrant> That is cutting it very fine.
<wgrant> But OK.
<wgrant> lifeless: Bug #778847 broke notifications for everybody for any bug that had an affected subscriber.
<_mup_> Bug #778847: Muting a bug subscription for a team with a contact address crashes getRecipientFilterData <oops> <story-better-bug-notification> <Launchpad itself:In Progress by yellow> < https://launchpad.net/bugs/778847 >
<wgrant> It was probably the most critical regression we have had in months.
<wgrant> It was only by very good luck that it didn't became a serious incident.
<wgrant> If any regression this quarter needs analysis, it is that one.
<wgrant> Ahh, that MP target test was flawed in a couple of other ways, too.
<wgrant> killall launchbag
<adeuring> good morning
<jtv> hi adeuring
<adeuring> hi jtv!
<lifeless> wgrant: so, it could only affect muted teams, which could only happen to beta users
<wgrant> lifeless: No.
<lifeless> wgrant: no?
<wgrant> lifeless: It affects all notifications to anyone from bugs which might have sent notifications to a muted team.
<wgrant> The mute breaks recipient calculation for the whole bug.
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build #719: FIXED in 5 hr 30 min: https://lpci.wedontsleep.org/job/devel/719/
<wgrant> !!!!!
<wgrant> Well done StevenK.
 * StevenK takes a bow.
<lifeless> StevenK: cool
<lifeless> StevenK: thanks!
<lifeless> is bug 740584 a regression as well?
<_mup_> Bug #740584: Build lacks a corresponding source publication <oops> <regression> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/740584 >
<lifeless> ah yes
<lifeless> win
<wgrant> Yes :(
<StevenK> That bug makes me sad
<lifeless> wgrant: could you add to https://dev.launchpad.net/Regressions2011#preview ?
<wgrant> The rationale given for the assertion was false.
<wgrant> Sure.
<wgrant> Done.
 * wgrant stabs bug heat.
<wgrant> DIE
<lifeless> wgrant: what triggered that outnyurst
<StevenK> Clearly, bug heat did *something*.
<wgrant> lifeless: Timing out on DF.
<wgrant> In particular, selecting the maximum heat for a context.
<wgrant> But it is horrible on qas as well.
<wgrant> When updating.
<mrevell> Hallo
<lifeless> spiv: are you still working on bug 717094 ?
<_mup_> Bug #717094: InvalidURL OOPS in translatePath because of URL containing non-ascii chars, again <oops> <regression> <Launchpad itself:Triaged by spiv> < https://launchpad.net/bugs/717094 >
<spiv> lifeless: I don't think I ever started working on that, so no :/
<lifeless> spiv: it is assigned to you
<lifeless> spiv: by poolie
<spiv> Yeah, I see the bug history
<lifeless> :)
<bigjools> wgrant: do you remember if there are bugs filed about the soyuz uploader oopses that are not oopses?
<poolie> hi all
* henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: henninge | https://code.launchpad.net/launchpad-project/+activereviews
<bigjools> lifeless: how much longer are you around?
<lifeless> I'm not at all, but I can be if needed, if that makes sense.
<bigjools> not urgent, I just wanted to fill your head with something I learned at UDS
<bigjools> some nice architecture that the Landscape guys use, which I also want to use
<lifeless> the notification server?
<bigjools> yarp
<lifeless> yeah
<lifeless> I'm aware of that
<bigjools> ahy coolio
<lifeless> we have a few things we'd need heavy lifting on to start using it
<lifeless>  - need to arrange open sourcing of it
<bigjools> totally
<lifeless>  - need a long-poll infrastructure w/rabbit
<lifeless> bah
<lifeless> s/rabbit/haproxy
<bigjools> right
<lifeless>  and need someone to put the effort in to get familiar with it and work out how it all hangs together.
<lifeless> I'm totally supportive if you/your team want to do that; whether it should be a notification server or a subscription-with-callbacks server is an interesting question but not one that should impede adopting an improvement on what we have
<bigjools> lifeless: well my first iteration is to make a job get initiated by rabbit instead of cron
<lifeless> yah
<lifeless> I think thats quite self contained
<bigjools> since we're blocked on open sourcing that component ...
<lifeless> signal after commit in the webserver
<wgrant> bigjools: Yes.
<wgrant> Finding...
<lifeless> have the job be a daemon not a script
<bigjools> wgrant: they are easy criticals :)
<wgrant> bigjools: But there's only two of them.
<lifeless> and the message just needs to be 'poll now dammit'
<wgrant> But yes, I was going to look at them in my last week.
<bigjools> lifeless: right.
<lifeless> so if a message doesn't get through, the next message sent will trigger all the jobs anyway
<wgrant> But that code is terrible :(
<poolie> o/ wgrant, bigjools
<wgrant> Evening poolie.
<bigjools> hey poolie
<lifeless> bigjools: at least, thats whats in my head
<lifeless> bigjools: I'm sure there are other ways that would be equally fine
<bigjools> lifeless: same as my head
<bigjools> needs to be a daemon at the least, zopeless startup cost is stupid
<bigjools> talking of which, I'd really like to split up the zcml so we don't need to load it all for simple scripts
<wgrant> Oh, Landscape has a rabbit-based long-poll server?
<bigjools> yes
<wgrant> !!
<lifeless> if it was zopeless it might not be so slow :P
<wgrant> Mine, now.
<bigjools> well, twisted + rabbit
<lifeless> wgrant: hah :)
<wgrant> I should try landscape at some point.
<lifeless> I'm pretty sure they brought it up in one of hte first perf tuesday mails
<bigjools> lifeless: yes "zopeless" is the worstest name evar
<lifeless> I've known about it for a while
<lifeless> bigjools: it was accurate, once.
<wgrant> Hmm, only 107 bad builds.
<poolie> wow, multiple new community patches
<poolie> superb
<wgrant> poolie: Yes!
<wgrant> :( but 69 of them have binaries.
<poolie> ?
<poolie> i meant the lp mps from christjohnston
<wgrant> The binary comment was about the 107 bad builds.
<wgrant> The swarm of cjohnston MPs is undoubtedly a great thing :)
<poolie> if only lp karma was correlated with actual moral karma
<poolie> someone came up to me at uds and said "wow, you have so much karma"
<wgrant> Heh.
<bigjools> lifeless: have you had any ideas about better searching in LP?
<bigjools> I need to improve the stuff we've done for derived distros
<poolie> i wonder if i could get hi to fix the mp breadcrumbs so that they include the list of all mps
<poolie> which is https://bugs.launchpad.net/launchpad/+bug/487893
<_mup_> Bug #487893: mp breadcrumbs should link back to list of merge proposals <code-review> <lp-code> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/487893 >
<wgrant> WTF
<wgrant> bigjools: What sort of DB surgery history to ppa:ubuntu-security/ppa have?
<wgrant> s/to/does/
<poolie> jml: hi, you'd be welcome to drop by our sprint if you feel like it
<lifeless> bigjools: lucene/lucandra
<wgrant> Because there's some stuff here that I don't think could have occurred naturally.
<bigjools> wgrant: what?
<wgrant> bigjools: BPB 690398 (a kernel build from May 2010) has an armel build in ppa:ubuntu-security/ppa.
<bigjools> lifeless: I need to add the capability to search for more different types of data.  I don't want a form like the advanced bugs search form and wondered if you'd got something we can implement this cycle?
<wgrant> Sorry, BPB 1758733, SPR 690398
<wgrant> But that SPR has no publications!
<wgrant> Anywhere.
<wgrant> I suspect someone hacked them out of the DB.
<bigjools> wgrant: yes, they asked for a publication to be removed
<bigjools> since they uploaded a bogus version
<lifeless> bigjools: so the advanced bugs form is just fugly
<wgrant> à² _à² 
<bigjools> lifeless: putting it lightly
<lifeless> bigjools: uhm
<lifeless> bigjools: so there are a few things that are pretty low hanging
<lifeless> one is a search language
<lifeless> like
<lifeless> binaryname:foo
<lifeless> package:bar
<lifeless> etc
<bigjools> so far so good, that's what we thought of
<lifeless> this is pretty easy to do
<lifeless> something that can make that discoverable is an advanced for which generates the search using that scheme
<lifeless> this is what google's advanced search pages does, for instance.
<lifeless> s/for/form/
<wgrant> baaaah
<lifeless> another possibility is to implement a small facet engine
<wgrant> Partner import fail.
 * wgrant kicks gina.
<wgrant> Someone clearly didn't test it at all before running it :(
<wgrant> It imported all the -commercial builds into the primary archive, while the sources correctly ended up in partner.
<bigjools> ha
<lifeless> bigjools: you're familiar with facets?
<bigjools> lifeless: in what context?
<lifeless> searching
<bigjools> I know less than fuck all about searching
<StevenK> wgrant: Should we remove the builds?
<bigjools> I am here to be edumacated!
<lifeless> http://www.google.com/search?sourceid=chrome&client=ubuntu&channel=cs&ie=UTF-8&q=facet+search
<lifeless> first two hits look sane
<bigjools> yeah
<lifeless> bigjools: basically you divide up your data into a bunch of dimensions and then offer click/dropdown/checkbox selection for filters by each dimension
<bigjools> oh one more thing
<bigjools> (right)
<bigjools> they want to search using substrings :/
<lifeless> bigjools: so you start with some sort of default that makes sense, and folk can click filters off, or on.
<lifeless> bigjools: when do you want to be finished?
<bigjools> before Dublin
<lifeless> bigjools: what size is the corpus?
<bigjools> lifeless: I suspect a few thousand packages
<lifeless> as long as we have the package names normalised we can do that tolerably fast:
<lifeless> select * from sourcepackagename where name like '%foo%';
<lifeless> Time: 23.916 ms
<lifeless> the reason the bug one is fail is because its not normalised
<bigjools> what do you mean by normalised, exactly?
<lifeless> each unique string should be assessed only once
<lifeless> there are substring capable engines for postgresql
<lifeless> using trigrams and so forth
<lifeless> but we don't have any in production yet
<lifeless> I think its high risk to make your work contingent on getting that into prod
<lifeless> IM BW
<bigjools> I'll make it optional anyway, forcing substring has other issues
<lifeless> is there a LEP about the search facilities needed?
<bigjools> no, this is something that came up at UDS
<lifeless> I could read up and then we could have a call to look for issues
<bigjools> I need to add my writeup to the LEP
<wgrant>    id   | sourcepackagename |   version    | upload_archive | count | count
<wgrant> --------+-------------------+--------------+----------------+-------+-------
<wgrant>  206708 |             41329 | 2.6.15-51.66 |              1 |    12 |    12
<wgrant>  207390 |             41329 | 2.6.15-51.66 |              1 |     0 |     6
<wgrant> Why are there two different sources with the same version, both with builds, one with two sets of builds, and the latter without any source publications? :(
<lifeless> bigjools: drop me a note when its in there ?
<bigjools> lifeless: yuuuuuup
<bigjools> wgrant: nfi.  what is the exact problem here?
<jml> poolie: thanks. I'll probably be in Wed & Fri
<wgrant> bigjools: Someone reuploaded the same kernel version, and then the DB surgery to remove it was incomplete.
<wgrant> There are 14 invalid builds from bad DB surgery.
<wgrant> 55 from gina being crap.
<bigjools> wgrant: let me re-phrase, what are the symptoms of the problem?
<wgrant> bigjools: Bug #740584
<_mup_> Bug #740584: Build lacks a corresponding source publication <oops> <regression> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/740584 >
<wgrant> BPB.current_component (quite reasonably) expects each build to have a corresponding source publication.
<wgrant> The production data throws reasonable expectation out the window.
<bigjools> ok
<bigjools> the db surgery was only done in the PPA
<bigjools> IIRC
<wgrant> There are three or four PPAs and this one source in the primary archive.
<wgrant> Same version accepted twice.
<bigjools> :/
<bigjools> that sounds like a deeper bug
<wgrant> I'm hoping that the binaries were never published.
<wgrant> This was years ago.
<bigjools> ok
<wgrant> If they were indeed never published, we can just blow the builds away.
<wgrant> And the world will be happy again.
<bigjools> wgrant: rather than the code change I'd prefer data was fixed
<bigjools> we also need a script to nuke unwanted versions in case some PPA user *cough* comes crying again
<wgrant> Yeah.
<wgrant> It's going to be a non-trivial endeavour to repair it all, but I will try it tomorrow.
<wgrant> The stuff imported from dak is going to be bad, though :/
<wgrant> There were binaries without sources in the initial Ubuntu import.
<wgrant> They might put an end to this attempt :(
<jml> have I misread something, or has cjohnston submitted 7 bug fixes?
<nigelb> i think he has
<jml> excellent!
<bigjools> mrevell: https://dev.launchpad.net/LEP/DerivativeDistributions#Round%202
 * mrevell looks
<mrevell> bigjools, I'd say that was most certainly a success.
<bigjools> :)
 * bigjools heads for pain killers and caffeine
<cjohnston> mornin jml :-)
<jml> cjohnston: good morning!
<jml> cjohnston: thank you so much for those patches
<cjohnston> np :-)
<cjohnston> I'm fixing the issues with them right now
<nigelb> jml: can we repharse your pie on face to 2-digit critical bugs? ;)
<jml> nigelb: only if the first digit is zero.
<jml> (guess what the second digit has to be)
<nigelb> you mean 0200 is fine? :p
<wgrant> cjohnston: If you set a commit message on your approved MPs I'm sure lots of us will gladly rush to land them for you.
<danilos> lifeless, hi, you don't have a problem with me landing https://code.launchpad.net/~danilo/launchpad/proper-bug-muting/+merge/60615 as-is? (i.e. worrying about team mutes separately)
<cjohnston> heres a discussion then.. imo, if a person doesn't add a commit message to the MP, then it should inheret the commit message from bzr commit when there is one
<wgrant> cjohnston: Mmm, possibly. But in a lot of cases that will just be "Lint" or "Address review comments" or something like that.
<cjohnston> gotcha...
<danilos> lifeless, I am assuming you don't, and you have whatever time it takes ec2 to run tests through to complain before it hits pqm :)
<jml> cjohnston: also, I have to ask, have you signed the contributor agreement?
<wgrant> Ah, that too.
<cjohnston> jml: I did.. waiting to be added
<jml> cjohnston: cool. thanks :)
<wgrant> Did you send it to flacoste?
<cjohnston> yes
<nigelb> shoulda just poked him at uds
<nigelb> we both did talk to him at some point
<nigelb> ("Are you a launchpad guy? Could you help us with something?")
<wgrant> nigelb: I don't see any branches from you yet!
 * wgrant cracks the whip.
<nigelb> wgrant: I'm STILL at work!
<cjohnston> lol yay!
<cjohnston> I took vacation yesterday to submit launchpad patches!
<wgrant> Excuses, excuses.
<cjohnston> +1 wgrant
<wgrant> that's the spirit.
<nigelb> I can't just install launchpad to work laptop :\
<wgrant> nigelb: Use a VM :)
<wgrant> There are instructions on the dev wiki.
<nigelb> wgrant: Every time I try to develop on launchpad, I get stuck at the setting up VM state
<cjohnston> I think nigelb was the one who wanted the VM image
<nigelb> Its happened thrice now
<nigelb> yeah, it was me
<cjohnston> in the LP session
<StevenK> nigelb: If you get stuck, ask questions here?
<nigelb> StevenK: no no, I get stuck at the VM stage
<nigelb> I'm guessing my computer just stuck at VMs
<StevenK> What are you using for the VM?
<bigjools> lifeless: https://dev.launchpad.net/LEP/DerivativeDistributions#Round%202 - see bug 783423
<_mup_> Bug #783423: Derived distros diffs pages need a more comprehensive search <Launchpad itself:New> < https://launchpad.net/bugs/783423 >
<nigelb> StevenK: virtual box
<poolie> henninge, or someone, could i have a review of my patch for bug 778437
<_mup_> Bug #778437: Recipe build success sends emails, please stop doing that <email> <recipe> <Launchpad itself:In Progress by mbp> < https://launchpad.net/bugs/778437 >
<poolie> despite there is probably some shallow twisted leakage
<cjohnston> Just to be clear, does 'Resubmit' for review mean that someone has requested a resubmit, or that the code is being resubmitted?
<StevenK> nigelb: And how does it fail?
<henninge> poolie: I will look at it.
<nigelb> StevenK: hrm, I don't remember, but it was mostly virtualbox thing instead of launchpad
<henninge> Hi cjohnston! ;)
<nigelb> like running out of space and being lazy
<cjohnston> hey henninge.. I'm workin on them
<cjohnston> henninge: https://code.launchpad.net/~chrisjohnston/launchpad/728192/+merge/61046
<henninge> cjohnston: cool. I think there was one more I had not finished yet
<cjohnston> ok
<cjohnston> fwiw jml I also got the link to the contributor agreement on http://www.canonical.com/contributors fixed ;-)
<jml> cjohnston: heh! thanks.
<poolie> thanks
<poolie> hi cjohnston
<poolie> i think i filed a bug about that
<poolie> or do you work on the canonical web site?
<cjohnston> I know the people who work on the canonical website.. and where to file the bug. I dont get access to anything :-/
<cjohnston> poolie: if you can find the bug you filed, I'll dupe it on mine since mines already fix released
<poolie> it was https://bugs.launchpad.net/bugs/778334
<_mup_> Bug #778334: broken link on contributor agreement page <Canonical Website:New> < https://launchpad.net/bugs/778334 >
<cjohnston> ty
<poolie> thank _you_
<cjohnston> henninge: https://code.launchpad.net/~chrisjohnston/launchpad/197793/+merge/61053 I believe the first one is dor duplicate bug subscription, and the second one is if you are subscribed to the original bug
<cjohnston> I need to make the kids food, and in an hour we are going to go outside and watch the shuttle, but I'll double check it
<henninge> cjohnston: would that have influence on the wording, thouhg?
<henninge> cjohnston: sure, lunch is close for me, too.
<cjohnston> It is defining why you are described.. which is how it currently does it.
<cjohnston> Which I personally like to know if I'm subscribed to the bug or to a duplicate... butt hat's me
<wgrant> poolie: Ah, great to hear that you're looking at updating bzr.
<wgrant> in LP.
<jml> Running errands. Back soon.
<benji> https://dev.launchpad.net/ | On call reviewer: henninge, benji | https://code.launchpad.net/launchpad-project/+activereviews
<benji> heh
* benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: henninge, benji | https://code.launchpad.net/launchpad-project/+activereviews
<henninge> Hi benji:
<benji> hi henninge, are all the reviews on +activereviews available for me to look at?
<henninge> benji: yes but maybe you could take poolie's that I already claimed as I am off to lunch now.
<henninge> https://code.launchpad.net/~mbp/launchpad/778437-sprb-spam/+merge/60360
<benji> sounds good
<henninge> benji: cool, reassigned.
<benji> enjoy your lunch
<henninge-lunch> thanks
<mrevell> Can anyone remind me of the page in Launchpad that lists of the graphical elements we use? It's something like launchpad.net/@@/icons
<wgrant> +graphics?
<wgrant> http://launchpad.net/+graphics
<benji> poolie: is https://code.launchpad.net/~mbp/launchpad/778437-sprb-spam/+merge/60360 ready for review?  The last comment about the Twisted test error being persistent suggests that I should wait on reviewing it.
<mrevell> Thanks wgrant
<poolie> benji: i think the twisted fix will be shallow so i'd like a review on the other bits
<benji> poolie: cool, thanks
<poolie> wgrant i was just thinking the other day it would be nice if lp changed /people/+me to /~
<wgrant> Hmmm.
<wgrant> That might indeed be nice.
<wgrant> And trivial.
<poolie> i can never remember the current abbreviation
<poolie> similarly whether it's /+bugs/ or /+bug etc
<poolie> other people there commented on this at ud
<poolie> *uds
<poolie> benji thanks
<benji> my pleasure
<wgrant> poolie: It's both!
<poolie> no, really?
<poolie> anyhow pad.lv fixes that issue, but it's an istance of the general thing of some of these shortcuts being a bit too cryptic to be truly helpful
<wgrant> We really need to sort out the whole domains and URLs thing.
<bigjools> wgrant: can you remember if bug 243252 is actually fixed?
<_mup_> Bug #243252: P-a-s (lists of forbidden architectures) should apply to rebuild archives <derivation> <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/243252 >
<wgrant> I don't think so.
<wgrant> But let me check.
<wgrant>         for pubrec in sources_published:
<wgrant> That would be a no.
<wgrant>             builds = pubrec.createMissingBuilds(
<wgrant>                 architectures_available=architectures)
<wgrant> packagecloner doesn't provide a pas_verify.
<lifeless> gary_poster: I'm halting() for the night, but I would -dearly love- that feedback during your day. I would like to start wider circulation later today.
<gary_poster> lifeless, ack.  It will be done.
<lifeless> gary_poster: thanks, I really appreciate it!
<lifeless> night all
<gary_poster> night
<wgrant> Night lifeless.
<wgrant> And thanks for all your work on that.
<deryck> henninge-lunch, ping for standup
<henninge> Hi deryck! Sorry for missing the call ...
<deryck> henninge, it's ok
<LPCIBot> Project windmill-devel build #83: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/83/
<nigelb> \o/
<nigelb> rocketful-setup running :)
<jml> yay
<nigelb> I just realized this is really a spare system
<nigelb> I can brick this as much as I want :)
<LPCIBot> Project windmill-db-devel build #280: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-db-devel/280/
<sinzui> deryck: I think your team will find project review easier. There is one page to see and drive to zero now
<sinzui> https://launchpad.net/projects/+review-licenses
<deryck> sinzui, ah, nice.  thanks
<deryck> sinzui, yes, that is much better.
<sinzui> There are tool tips that explain what I am thinking about for the sections of content
<deryck> sinzui, also, I updated the wiki page here:  https://dev.launchpad.net/MaintenanceRotationSchedule but maybe you guys are off maintenance next week?
<sinzui> Unless flacoste/jml say otherwise, Teal will be working on disclosure next week
<jml> deryck: see also, https://dev.launchpad.net/Squads.
<jml> sinzui: I'm unlikely to say otherwise.
<jml> sinzui: btw, I do want to have a call this week, but won't have time to today.
<deryck> jml, ah, nice page.  thanks.
<sinzui> jml: fab
<deryck> jml, sinzui -- so yellow is on maintenance next week then?
<jml> deryck: starting 23rd.
<deryck> jml, rockin' thanks!
<jml> (so that's a yes. had to check a calendar)
<benji> henninge: I'm taking https://code.launchpad.net/~wallyworld/launchpad/fix-test_inline_recipe_daily_build/+merge/61050
<henninge> benji: that's fine
<jcsackett> what determines which js files get compiled into launchpad.js?
<nigelb> Its seems my branching of launchpad is sort of stuck. The size hasn't changed in a while
<jml> nigelb: is there network access?
<nigelb> yeah, I'm on IRC, so sure
<nigelb> but there may have been a 1 sec break in between
<jml> nigelb: I mean, does System Monitor show activity for network that's more than the usual for being on IRC
<nigelb> ah
<nigelb> fluctuating
<jml> nigelb: also, you could try tailing ~/.bzr.log to see if anything is going on
<jml> nigelb: it might just be bzr doing something CPU intensive and not networky
<nigelb> so, its stuck at this point --> - 104595KB    23KB/s | Fetching revisions:Inserting stream
<nigelb> tail shows me 17.881  fetch up to rev {launchpad@pqm.canonical.com-20110516135527-bdxtzfll8ydxwio2}
<nigelb> is there a way I can tell bzr to start again without doing the whole rocketfuel again?
<jml> nigelb: hmm.
<abentley> henninge or benji: could you please review https://code.launchpad.net/~abentley/launchpad/branch-empty/+merge/61132 ?
<benji> abentley: sure
<jml> nigelb: if you really wanted to, you could stop rf-setup, bzr pull, hack rf-setup to skip the steps before bzr pull, then run it again.
<nigelb> jml: 400-line shell script, I'm not so sure if I want to do that.  New job wanted me to write a set up script and I wrote a 200 liner, I know how shell can be hard sometimes
<jml> nigelb: not sure if there's any other way.
<nigelb> I figured. I just read through the script. I guess I can comment everything but assigning the variables bit
<jml> yeah. that'd make sense.
<nigelb> hrm, wait.
<nigelb> The script is awesome. It does figureout if its being run the second time
<benji> abentley: I'm done with https://code.launchpad.net/~abentley/launchpad/branch-empty/+merge/61132
<henninge> benji: I just claimed https://code.launchpad.net/~wallyworld/launchpad/has_matches-opps-querystring/+merge/61095
<henninge> That was easy.
<henninge> benji: have you already picked another one?
<LPCIBot> Project windmill-devel build #84: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-devel/84/
<henninge> benji: I am on https://code.launchpad.net/~wgrant/launchpad/bug-750607/+merge/61069
<abentley> jml: How can I figure out where this exception is being raised? https://bugs.launchpad.net/launchpad/+bug/740674
<_mup_> Bug #740674: ConnectionRefusedError from code puller <branch-puller> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/740674 >
<jcsackett> sinzui: any notions what i should poke at if a js file isn't being included in launchpad.js on jsbuild?
<sinzui> yes
<sinzui> jcsackett: sorry, no, It was in lib/lp/app/templates/base-template-macros.pt It is not gone
 * sinzui see Lp is still loading a google maps keys
<sinzui> jcsackett: The compressor script used to read the js files in that template. I think we need to re-read the code that does the compression
<jcsackett> sinzui: thanks. i'll start looking at that.
<henninge> benji: next is https://code.launchpad.net/~wgrant/launchpad/expose-bpph-indep/+merge/61077
<jml> abentley: I don't really know, except maybe by code inspection. PullerMaster.unexpectedError in scheduler.py looks a likely culprit
<sinzui> jcsackett: I think the rules are in the Makefile now. I see JS_LP
<jml> abentley: isn't tellurium a staging service?
<abentley> jml: You may be right.
<jml> hmm.
<henninge> benji: ok, all the easy ones are done. Now I stop. ;-)
<jml> actually, because it's a Twisted client connection error, it'll almost certainly be the XMLRPC service.
<henninge> benji: sorry to have flooded you ...
* henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | https://code.launchpad.net/launchpad-project/+activereviews
<benji> henninge: no problem, I'm eating lunch
<henninge> benji: enjoy it ;)
<abentley> jml: The XMLRPC used to implement the bzr transport?
<jml> abentley: I was thinking of the XMLRPC used to tell the database what we're doing: mirrorFailed etc.
<jml> calls to self.codehosting_endpoint.callRemote
<abentley> jml: Ah.  Yes, could be that.
<jml> abentley: Twisted won't be used for the bzr transport in this case
<jml> maybe a sensible strategy is to check to see if the error is still happening, instrument a little more around the likely causes and then check the logs a little after it's rolled out
<abentley> jml: I think the assessment that this should not be reported as an oops assumed that the ConnectionError was happening when attempting to retrieve the remote branch.
<jml> abentley: agreed.
<jml> abentley: we almost certainly want oopses if we fail to communicate to our local servers.
<abentley> jml: I dunno, those XMLRPC servers do go down from time to time...
<jml> abentley: hmm.
<jml> abentley: but it's always OOPS-worthy if they become inaccessible while the puller is running, I think.
<jml> there's always one appserver up during a nodowntime rollout, and I'm guessing we shut down the puller during a downtime rollout
 * jml has to go
 * nigelb cries
<nigelb> lp branch keeps getting stuck, but at different points :
<nigelb> :(
<LPCIBot> Project windmill-devel build #85: STILL FAILING in 48 min: https://lpci.wedontsleep.org/job/windmill-devel/85/
<poolie> benji, hi?
<poolie> nigelb: tell me more?
<benji> poolie: hi
<poolie> hey
<poolie> i'm just trying to debug the failing twisted tests with spiv
<nigelb> poolie: well, I stopped it and restarted, seem to have better luck this time!
<nigelb> poolie: Pulling pqm now, I guess that's a good sign
<poolie> please put 'debug_flags = hpss, bytes' into your bazaar.conf
<nigelb> if it fails again?
<poolie> benji: i think those tests were essentially not running before
<poolie> because of ignoring the defered result
<poolie> nigelb: actually it's useful to add anyhow
<poolie> but if it does fail again, it will give us some more data
<nigelb> okay, doing so now
<benji> poolie: sounds plausible
<LPCIBot> Project windmill-db-devel build #281: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-db-devel/281/
<timrc> I'm trying to setup a LP development environment.  I've just run ./rocketfuel-setup and it failed with a Permission Denied (https://pastebin.canonical.com/47500/)... Off hand this seems like a bug in the script? But maybe I'm just reading the output wrong
<timrc> e.g. "It's okay if this errors"... it then errors, and the script execution terminates
<jelmer> timrc, hi
<jelmer> timrc, do you have a launchpad user set up with the matching ssh key in your home directory?
<jcsackett> benji: could you look at https://code.launchpad.net/~jcsackett/launchpad/consolidate-spam-js/+merge/61151? it's near the 800 limit, but a lot of that is deletion.
<timrc> jelmer, doh :) nice first question, this is a VM and now that I think about it, I did not setup with my ssh key
<timrc> jelmer, that did the trick.  ty
<poolie> benji: ok with a little help from my friends i think it's ok
<poolie> https://code.launchpad.net/~mbp/launchpad/778437-sprb-spam/+merge/60360
<benji> poolie: cool, I'll take a look in a minute
<LPCIBot> Project windmill-devel build #86: STILL FAILING in 48 min: https://lpci.wedontsleep.org/job/windmill-devel/86/
<nigelb> YES!
<nigelb> Finally, I rocketfuel is done :)
<poolie> way to go!
<poolie> now, to patch it!
<benji> poolie: I'm done with https://code.launchpad.net/~mbp/launchpad/778437-sprb-spam/+merge/60360
<jcsackett> sinzui: feel like chatting? (now or later today)
<sinzui> now is good
<jcsackett> superb. :-)
<poolie> thanks benji
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build #552: FIXED in 5 hr 38 min: https://lpci.wedontsleep.org/job/db-devel/552/
<poolie> that was a bit of struggle
<benji> my pleasure
<poolie> i would appreciate your insights on https://code.launchpad.net/~mbp/launchpad/uniqueid-clue/+merge/61153 the follow on
<poolie> and so good night
<gary_poster> lifeless, fwiw, I've been working on the feedback, and will continue doing so.  I expect to be done in 30 min.
<sinzui> jcsackett: bug 427397 only affects blueprints now. I think it is trivial
<_mup_> Bug #427397: Search triggering error in tsearch query again <blueprints> <bugs> <oops> <search> <sprints> <Launchpad itself:Triaged> < https://launchpad.net/bugs/427397 >
<nigelb> hrm, is the make schema bit supposed to take a lot of time?
<sinzui> jcsackett: The dupe as an example: https://bugs.launchpad.net/launchpad/+bug/777357
<_mup_> Bug #777357: Searches containing a percent sign generates an oops <Launchpad itself:Triaged> < https://launchpad.net/bugs/777357 >
<sinzui> jcsackett: OOPS-1962AQ339 happend just a few hours ago
<cjohnston> jml: my 7 MP on my first day wants to be the contributor that throws the pie. ;-)
<LPCIBot> Project windmill-devel build #87: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-devel/87/
<sinzui> jcsackett: I dedupped bug 777357 because it really is just about the %. There have been no tsquery oopses in 8 months
<_mup_> Bug #777357: Searches containing a percent sign generates an oops <Launchpad itself:Triaged> < https://launchpad.net/bugs/777357 >
<jcsackett> sinzui: dig.
<jcsackett> and i see you marked the other bit fix released. was just about to ask about that.
<nigelb> I found myself an easy bug to work on, bug 645825
<_mup_> Bug #645825: "bzr push" examples in UI say to push to trunk <easy> <lp-code> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/645825 >
<lifeless> gary_poster: thanks!
<nigelb> should I be discussing this bug in -reviews before I start?
<lifeless> nigelb: here is fine
<nigelb> okay, so I think this is just going to be a one or two line fix
<nigelb> apply the name of the series in where trunk is hardcoded currently
<cjohnston> sinzui: ping
<sinzui> did you get hate mail from the testrunner too?
<cjohnston> ya
<cjohnston> I'm not totally sure what it is wanting
<sinzui> The issue is not your branch. I will merge it once I verify the build is not broken
<lifeless> nigelb: that sounds fine in principle
<lifeless> nigelb: I haven't [yet] looked at that bug
<cjohnston> ok.. so I'm just getting hate mail for fun
<nigelb> lifeless: just trying to figure out how to refer to the variable like things on zope, having fun with tracebacks :)
<sinzui> cjohnston: Your branch is indeed fine. I expect to get a message shortly confirming your branch is merged
<cjohnston> ok.. very cool
<nigelb> yay tracebacks :)
<sinzui> benji: do you have time to review https://code.launchpad.net/~sinzui/launchpad/product-release-traversal/+merge/61168 ?
<benji> sure
<lifeless> statik: hi, are we on today?
<cjohnston> Could someone take a look at https://code.launchpad.net/~chrisjohnston/launchpad/197793/+merge/61053  to me, it is showing subscribed to a duplicate bug vs subscribed to the main bug.. but maybe im missing something in what Henning said.
<sinzui> cjohnston: https://code.launchpad.net/~chrisjohnston/launchpad/255024/+merge/61038 is merged. I will QA it once it is deployed to qastaging.
<cjohnston> sinzui: I'm not sure quite what that means... I was just getting ready to ask what the process is now that its merged
<sinzui> cjohnston: Lp's devel and db-devel branch will be tested without your changes. When both pass, your work is deployed to https://qastaging.launchpad.net . The bug will be tagged qa-needstesting which will tell me it is ready for me to verify it
<sinzui> cjohnston: I will change the tag to qa-ok, which will signal that the change can be deployed, which may be tomorrow
<cjohnston> hmm.. interesting.. very different than anything I'm used to.. will it be deployed straight to lp.net for all or just beta first?
<benji> sinzui: I'm done with https://code.launchpad.net/~sinzui/launchpad/product-release-traversal/+merge/61168
<nigelb> okay, I just tried a while and I can't figure out how to get the tal:. thing for productseries name
<nigelb> <tal:series replace="context/productseries/name" /> doesn't seem to work :\
<sinzui> cjohnston: it will go directly to lp.net from qastaging. Beta is a mechanism mostly for features were to support multiple behaviours until we choose to end to to complete the release of the other
<cjohnston> gotcha
<sinzui> nigelb: that will show the lp Id of a product's series. is context a product, or do you want the displayname?
<nigelb> sinzui: I'm trying to get name of a productseries
<nigelb> in an attempt to fix bug 645825
<_mup_> Bug #645825: "bzr push" examples in UI say to push to trunk <easy> <lp-code> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/645825 >
<sinzui> nigelb: can you paste the traceback at pastebin.ubuntu.com ?
<nigelb> sinzui: http://paste.ubuntu.com/608640/
<sinzui> ah, that nasty LocationError. nigelb That error type is hiding the real error. I believe it is an Attribute/key error.
 * sinzui reads impl
<lifeless> cjohnston: once its merged it goes through a CI system (buildbot at the moment)
<nigelb> sinzui: which means I'm calling the wrong attribute?
<deryck> hi lifeless.  got a sec?
<lifeless> cjohnston: then deploys to a staging area where sinzui will check its ok before changing that tag he mentioned
<lifeless> cjohnston: and after that it goes live
<lifeless> deryck: sure
<cjohnston> sweet.. ty
<deryck> lifeless, so I'm looking at bug 701246.
<_mup_> Bug #701246: missing bug dereference generates OOPS <oops> <Launchpad itself:In Progress by deryck> < https://launchpad.net/bugs/701246 >
<sinzui> nigelb: possibly, or the permissions are wrong. I think anyone can access the name attr
<deryck> lifeless, and I cannot repro this.  using launchpadlib 1.9.7.  We raise KeyError now.
<nigelb> yeah, that's what I felt too
<lifeless> deryck: do you get an x-lazr-oopsid in the response?
<deryck> lifeless, nope
<nigelb> sinzui: How do I figure out if "context/productseries/name" is correct?
<lifeless> deryck: or an oops written to disk ?
<lifeless> (look under /var/tmp/lperr/ for a new file in todays dir)
<deryck> ok, let me see to make sure....
<sinzui> nigelb: I really think it is correct. The TB clearly shows the object is a ProductSeries and I know the name attribute is always public because it is in the URL
 * sinzui looks at the template
<jcsackett> deryck: are you trying to reproduce via test?
<deryck> jcsackett, well test led me to question the issue, so I fired up a Python console against qastaging/staging.
<deryck> jcsackett, lifeless -- so I'll run against dev server now and see if it generates an OOPS.
<jcsackett> deryck: dig. i've found when using launchpadlib in unittests you can get keyerrors when you get other errors running the actual client against a server.
<jcsackett> i've never dug into it, but it's tripped me up.
<sinzui> nigelb: looking at the template in the my copy of the tree, context is not a product, it is a product series. Does context/name work?
<nigelb> sinzui: ah, it does :)
<deryck> jcsackett, yeah, I did get a KeyError in test, but I also get one with launchpadlib against staging.
<nigelb> sinzui: how do I figure out the correct context in the future?
<sinzui> nigelb: context is always ambiguous. It essentially is like "this" where "this" is the subject we started with
<jcsackett> deryck: interesting. i wonder if my issue was just that the lplib used in tests was a more recent version than the one i was using when connecting manually...
<nigelb> sinzui: oh boy
<nigelb> sinzui: sounds like fun
<nigelb> anyway, do I commit on my devel branch and propose merging or create a new branch with rf-setup?
<sinzui> nigelb: In this case, the template and its view are only initialised with a ProductSeries, so you can be confident conext/name will give the the productseries.name
<nigelb> aha
<sinzui> nigelb:  I always branch my devel branch, make my changes, then push to lp
<deryck> jcsackett, lifeless -- ah, so indeed it was still oopsing, even though the client behavior is different from the bug report.
<sinzui> nigelb: let my collect my routing and paste it for you
<nigelb> sinzui: yes, that'd be awesmoe
<sinzui> nigelb: this is what I do every day http://paste.ubuntu.com/608652/
<nigelb> sinzui: ah, so no need to use RF for the branch stuff
<sinzui> nigelb: I can just type bzr info because my ~/.bazaar/locations.conf knows about my devel branch. I cannot remember if rocketfuel-setup does that for you
<lifeless> deryck: thanks for being thorough
<deryck> no worries.
<sinzui> nigelb: you can use `bzr merge --committed ../devel` to copy any changes made in the devel branch to the branch you want to submit
<nigelb> :-)
<lifeless> or commit, push them over and pull --overwrite in devel to sync it up again [TMTOWTDI]
<lifeless> flacoste: hi
<flacoste> hey lifeless
<cjohnston> hey flacoste!
<flacoste> hey cjohnston!
<flacoste> thanks for your typo fixing spree!
<cjohnston> lol
<cjohnston> :-)
<flacoste> that's very much appreciated!
<cjohnston> the blueprints one will help me alot!
<lifeless> flacoste: we're up!
<lifeless> flacoste: I need 2 minutes first though (oops :P)
<flacoste> lifeless: we are, skype?
<flacoste> lifeless: skype me when you are ready
<lifeless> ok
<nigelb> okay, proposed merge at https://code.edge.launchpad.net/~nigelbabu/launchpad/645825-ui-example/+merge/61175
<nigelb> Is there something I need to know or do before it gets reviewed?
<nigelb> I've already signed the contributor agreement
* benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<jml> nigelb: everything you need to know is on the "Submit a patch" page
<jml> nigelb: keep making noise until someone reviews your branch. west coasters should be around now, and Aussies turn up in 2 hrs.
<jml> g'night.
<lifeless> night jml
<nigelb> I need to head to bed too, 3 am
<nigelb> g'night all. I shall prod someone in the am.
<ajmitch> jml: nice incentive for people to fix lp bugs
<huwshimi> Morning
#launchpad-dev 2011-05-17
<sinzui> wgrant: mumble?
<lifeless> it is used to generate a new proposal with the same metadata
<lifeless> bah
<lifeless> cjohnston: ^ very-late-reply :P
<wgrant> erm.
<wgrant> PQM is broken.
<wgrant> star-merge succeeded at Mon May 16 21:21:35 2011 (0:00:33.523987)
<wgrant> "Exception processing merge: 'str' object has no attribute 'set_revision_history'"
<wgrant> And ever since it has kept trying to merge but said "nothing to do"
<lifeless> whhhhhhhe
<wgrant> You're it.
<lifeless> sinzui: hi
<lifeless> sinzui: are you still running a script that assigns milestones?
<lifeless> sinzui: if so, can you remove the milestoning from it ?
<lifeless> (inspired by the change on bug Bug 736011)
<_mup_> Bug #736011: ProductRelease:+rdf timeout <timeout> <Launchpad itself:In Progress by sinzui> < https://launchpad.net/bugs/736011 >
<wgrant> lifeless: Do you want to reassign with-without-datetime to ~launchpad-committers, or pull lp:~wgrant/storm/with-without-datetime?
<wgrant> (my DISTINCT ON changes are in trunk now)
<lifeless> wgrant: just push a fresh one to either ~launchpad-committers or your own namespace
<wgrant> k
<timrc> Trying to setup a Launchpad development environment.  I've been following the instructions at https://dev.launchpad.net/Running, and now when I try to access my instance I get the following? https://pastebin.canonical.com/47513/
<mwhudson> timrc: pastebin.ubuntu.com next time? :)
<timrc> mwhudson, ah sorry force of habit
<wgrant> timrc: How are you trying to access it?
<wgrant> It looks like you're poking the XML-RPC server.
<timrc> wgrant, the console log shows http://pastebin.ubuntu.com/608736/
<timrc> perhaps it's a hostname problem..
<wgrant> No, that's fine.
<wgrant> Which URL are you using?
<timrc> Locally, http://192.168.1.67:8085/
<mwhudson> ah
<mwhudson> that won't work
<lifeless> don't do that :)
<mwhudson> hostname based vhosting woo
<timrc> lol
<wgrant> timrc: You're running it in a VM, then?
<timrc> wgrant, Correct...
<timrc> So I just need to make launchpad.dev point to the right place?
<lifeless> https://dev.launchpad.net/Running/VirtualMachine
<wgrant> What lifeless said.
<wgrant> And yes.
<timrc> lifeless, wgrant: Thanks.  Looking now
<Ursinha> lifeless, hello
<lifeless> Ursinha: tudo bem!
<Ursinha> hehe
<Ursinha> lifeless, tudo
<Ursinha> lifeless, why is bug 667390 still needed for you? did you see how the dashboard puts all fixed bugs in wiki format and in a single row?
<_mup_> Bug #667390: provide wiki syntax bug links in deployable revision reports for easy copying to the LPS report <qa-tagger:Triaged by ursinha> < https://launchpad.net/bugs/667390 >
<lifeless> Ursinha: folk deploy off of the report though
<Ursinha> hm
<Ursinha> how bad is it to check the dashboard instead of the report to do the deployment?
<lifeless> whats the dashboard url?
<lifeless> my browser has forgotten it :(
<Ursinha> lifeless, http://lpqateam.canonical.com/
<lifeless> Ursinha: way too little information
<Ursinha> lifeless, what else do you need?
<lifeless> Ursinha: I would not be comfortable with myself or others deploying where they cannot see all the revisions being deployed.
<lifeless> because the system isn't perfect, seeing what will be deployed is a key piece of information
<lifeless> Ursinha: its things like seeing the commit message which has told be of the bugs in determining which bug links are found, for instance.
<Ursinha> right.
<Ursinha> I fixed that bug, btw, but I got your point
<lifeless> thank you
<lifeless> (for fixing the bug)
<wgrant> That is a very nice page.
<Ursinha> :)
<wgrant> Ursinha: Is it easy enough to show the current state of devel/db-devel, so we can see how many revs are not yet in *stable?
<Ursinha> wgrant, it's doable with not much effort, I believe
<LPCIBot> Project devel build #722: FAILURE in 5 hr 12 min: https://lpci.wedontsleep.org/job/devel/722/
<wgrant> + spph data model is confusing (records exist where they were built, not where they have been copied to)
<wgrant> I am confuse.
<wgrant> The build records exist where they were built.
<wgrant> The SPPH is the copy.
<lifeless> oh, my misunderstanding
<lifeless> please correct it
<lifeless> what I intended was to say:
<lifeless>  - the behaviour matches our model
<lifeless>  - our model is confusing
<lifeless>  - its low priority
<lifeless>  - and not specific to oneiric or ppas
<LPCIBot> Project windmill-devel build #88: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/88/
<timrc> lifeless, thanks, https://dev.launchpad.net/Running/RemoteAccess got me through the rest :)
<cjohnston> Question.. I got a buildbot thing, but am not allowed to access the details page.. Seems odd to me?
<wgrant> Yeah, that's a bit unfortunate.
<lifeless> now we don't do production branches thats fixable
<wgrant> It was a success, though, so you don't have to worry about it.
<lifeless> RT it
<wgrant> lifeless: Last I heard there was also an XSS.
<wgrant> But that was nearly two years ago.
<lifeless> oh freaking yay
<cjohnston> was just curious wgrant since I got it.. heh
 * lifeless vents
<lifeless> cjohnston: we did have good reasons for having it private. Some may still apply.
<wgrant> cjohnston: Yeah, I had to put up with it for 18 months, I know the annoyance :(
<cjohnston> so lifeless, rt saying that I'm getting an email from buildbot but don't have access to view the details?
<lifeless> no
<lifeless> wgrant will have a fiddle at some point
<lifeless> if we can open it, we will
<lifeless> or we may finish obsoleting it in one of a few ways
<cjohnston> ok.. so just bug wgrant .. lol kiddin
<cjohnston> g
<cjohnston> Do either of you have time to look at a review comment that was made and maybe explain it to me?
<wgrant> Sure.
<cjohnston> https://code.launchpad.net/~chrisjohnston/launchpad/197793/+merge/61053
<cjohnston> I don't really understand his comments... One is for duplicates and one is for subscribing to the main bug.. And its diferentiating why a user is subscribed afaik
 * cjohnston got a job today!
<cjohnston> heh
<cjohnston> or another job today.. or something
<wgrant> cjohnston: On line 24 of the diff, it doesn't say what they are a subscriber to.
<cjohnston> so on line 24 add to the bug report?
<cjohnston> "to the bug report"
<wgrant> This bug probably already existed, but the target of "is a direct subscriber" is a little more obvious than "is subscribed"
<wgrant> I'm not sure whether "bug" or "bug report" is better.
<wgrant> But yes.
<LPCIBot> Project windmill-db-devel build #282: STILL FAILING in 1 hr 14 min: https://lpci.wedontsleep.org/job/windmill-db-devel/282/
<cjohnston> seems from other bugs that people are wanting bug report since they are "reports of bugs"
<cjohnston> and not actual bugs
<cjohnston> Ok.. pushed that.. Hopefully that will be another one that can be closed
<cjohnston> Since I don't seem to have access, can someone fix #7 in https://dev.launchpad.net/PatchSubmission please
<StevenK> cjohnston: Done.
<cjohnston> ty StevenK
<lifeless> \o/
<lifeless> wgrant: https://code.launchpad.net/~wgrant/launchpad/bug-740584/+merge/61060 - got a minute
<wgrant> lifeless: Hi.
<wgrant> What about it?
<lifeless> > They were, 5 years ago. They should all be unpublished and removed from the librarian by now.
<lifeless> Do they serve any purpose for us then?
<lifeless> wgrant: do they?
<wgrant> lifeless: Other than being a historical record, no.
<wgrant> But it's a historical record that has traditionally never been erased.
<wgrant> To erase it would be a change of policy.
<lifeless> but these were never built
<lifeless> they were imported from dak, you are saying
<wgrant> Right.
<wgrant> But to erase them would mean erasing part of Ubuntu's publication history.
<lifeless> so its not a historical record; its a historical fiction
<wgrant> For deleting the BPBs implies deleting the BPRs, and therefore their corresponding BPPHs.
<lifeless> thats true, but we don't know about bpph's before soyuz anyway
<lifeless> we know about these by happenstance, more or less.
<wgrant> Sure.
<lifeless> I think we should get some specifics
<lifeless> put it in context
<lifeless> and ask on u-d
<lifeless> It seems weird to have a data model axiom and then not enforce it
<lifeless> what do you think?
<wgrant> It would be a no-brainer to enforce it if it didn't require unprecedented history erasure.
<lifeless> Well, I'm framing it as precendented - the dak import already lost it
<wgrant> That is true.
<wgrant> However.
<wgrant> It is possible that some of these are still published in Dapper.
<lifeless> in which case its a gpl violation, no ?
<wgrant> Yes.
<lifeless> so, we should get the details regardless.
<wgrant> Sure.
<wgrant> I'm looking at cleanup for the easier ones first.
<lifeless> cool
<lifeless> should the mp be made wip / rejected?
<lifeless> pending the outcome of the data cleanup effort?
<wgrant> I will WIP it.
<LPCIBot> Project windmill-devel build #89: STILL FAILING in 1 hr 18 min: https://lpci.wedontsleep.org/job/windmill-devel/89/
<lifeless> thanks
<lifeless> bombs away
<wgrant> Oh?
<wgrant> Ah.
<lifeless> yes indeed
<wgrant> cjohnston: Still around?
<wgrant> lifeless: Could you mentor https://code.launchpad.net/~wallyworld/launchpad/poppy-sftp-gpgconf/+merge/60454?
<lifeless> found an oversight ;)
<LPCIBot> Project windmill-db-devel build #283: STILL FAILING in 50 min: https://lpci.wedontsleep.org/job/windmill-db-devel/283/
<LPCIBot> Project windmill-devel build #90: STILL FAILING in 50 min: https://lpci.wedontsleep.org/job/windmill-devel/90/
<StevenK> wgrant: O hai, Mr. OCR.
<wgrant> So I am.
<wgrant> I can hardly review that.
<wgrant> But OK.
<StevenK> wgrant: Well, sure. I can prod lifeless until he squirms, if you prefer.
<wgrant> He'll be mentoring anyway, so I will do it.
<wgrant> Some of these DB surgery fix queries are a little long :(
<nigelb> hello! can someone review https://code.launchpad.net/~nigelbabu/launchpad/645825-ui-example/+merge/61175 for me?
<StevenK> nigelb: Done.
<nigelb> StevenK: yay, thanks :)
<nigelb> StevenK: oh, test changes and additions, hrm, could guide me through those or link me to some place that would guide me through those
<StevenK> nigelb: So you've changed the template -- there is likely to be a test (or a number of them) that create a view of that template.
<nigelb> windmill test?
<StevenK> I hope not. :-)
<nigelb> ah, the tests I find in lib/lp/registry/tests?
<StevenK> That is some of them
<StevenK> The view tests are more likely to be in lib/lp/registry/browser/tests
<StevenK> However, I'm having trouble finding a relevant test for ProductSeriesView
<StevenK> lib/lp/registry/browser/tests/productseries-views.txt that looks promising
<nigelb> I'm scrolling through that one already
<StevenK> nigelb: Can you run that test on your branch by 'bin/test -vvt productseries-views.txt' ?
<nigelb> okay, running
<nigelb> I'm failure sure I might have to write new ones because I don't find any checking this particular situation.
<StevenK> I've been thinking about that -- I doubt that the tests don't exist, but the only way to be sure is a fairly large hammer -- bin/test -vvm registry
<StevenK> Either that, or wgrant or lifeless could offer suggestions?
<nigelb> I'm running the productseries-views.txt one, I'll wait for more suggestions to fix it.
<nigelb> aha "Ran 2 tests with 0 failures and 0 errors in 13.684 seconds."
<wgrant> StevenK: Reviewed.
 * StevenK watches for 'Needs Fixing'
<LPCIBot> Project windmill-devel build #91: STILL FAILING in 50 min: https://lpci.wedontsleep.org/job/windmill-devel/91/
<StevenK> wgrant: No, but both the packagecopier and the overrides want Archive
<StevenK> wgrant: And since we're using UbuntuOverridePolicy(), a component will always be returned.
<nigelb> StevenK: Now that those 2 ran successfully, but may not be related to the code I touched, should I be trying to figure out how to write new tests?
<wgrant> StevenK: We are using UbuntuOverridePolicy at the moment.
<wgrant> StevenK: Nothing in the interface says a policy has to return a component.
<wgrant> Indeed, that doesn't make sense and is already violated by FromExistingOverridesPolicy
<wgrant> StevenK: I evisage that primary archives will use a chain of UnknownComponentOverridePolicy and FromExistingDestinationOverridesPolicy, while PPAs might use MainOnlyOverridePolicy and FromSourceOverridesPolicy, and copy archives might use FromSourceOverridesPolicy and FromExistingPrimaryOverridesPolicy
<wgrant> Er, last case is the wrong way around. FromExistingPrimaryOverridesPolicy and FromSourceOverridesPolicy
<wgrant> StevenK: Do you see what I'm aiming at here?
<StevenK> wgrant: I do
<StevenK> That my work is a jumping off point, and not the end result.
<wgrant> That's correct. This is a complex issue which you are taking nice initial bites out of.
<StevenK> wgrant: http://pastebin.ubuntu.com/608827/ is the uglyness that results from moving the circular import you commented on.
<wgrant> And it has to be somewhat complete before we can turn it on.
<wgrant> Because copies are used for security updates and moving from -proposed to -updates.
<wgrant>   File "/home/steven/launchpad/lp-branches/copies-use-overrides/lib/lp/soyuz/model/queue.py", line 97, in <module>
<wgrant>     from lp.soyuz.scripts.packagecopier import update_files_privacy
<wgrant> Can you move that import into whatever uses it?
<wgrant> It's in a condemned code path anyway.
<StevenK> Yes, thank $DEITY.
<StevenK> wgrant: Round two: http://pastebin.ubuntu.com/608831/
<wgrant>   File "/home/steven/launchpad/lp-branches/copies-use-overrides/lib/lp/soyuz/model/archive.py", line 198, in <module>
<wgrant>     from lp.soyuz.scripts.packagecopier import do_copy
<wgrant> Move it into syncSource(s).
<wgrant> Hm.
<wgrant> In fact there's a single underlying method you can put it into.
<wgrant> I forget what it's called.
<wgrant> _copySource or something.
<wgrant> _copySources
<StevenK> Right
<wgrant> That is also condemned.
<wgrant> As copies are going async.
<StevenK> Success!
<wgrant> Also, refactor + behaviour change in a single commit == strangle
<StevenK> Ha
<wgrant> Yay, DISTINCT ON replacement branch worked.
<StevenK> \o/
<StevenK> Does that replace all uses of it?
<wgrant> There are some fully string-based SELECTs that I haven't fixed.
<wgrant> But all those that use the hack ("DISTINCT ON (foo, bar) 0 as ignore") are gone.
<StevenK> \o/
<StevenK> It's landed?
<wgrant> No.
<wgrant> Passed ec2 except for a typo.
<wgrant> Not reviewed yet.
<StevenK> Would you like one?
<wgrant> I've not written the description yet.
<StevenK> wgrant: That sound be quick. "Now that Storm supports DISTINCT ON, make use of it instead of a SQL() hack."
<wgrant> It was.
<wgrant> But then it took 3 minutes to generate a diff.
<wgrant> https://code.launchpad.net/~wgrant/launchpad/native-distinct-on/+merge/61199
<StevenK> wgrant: Can the distinct_on in lib/lp/registry/model/distroseriesdifference.py be expressed only once?
<jtv> wallyworld_: I'd be honoured.  Just not today, because it's a holiday.  :)
<wallyworld_> jtv: awesome. thanks!
<jtv> (Also in a somewhat bad mood due to a combination of bugs costing me hours of work)
<StevenK> wgrant: And should bug 374777 be linked to the MP?
<wgrant> StevenK: It could be, but it doesn't seem terribly valuable as they are doing different things.
<_mup_> Bug #374777: DISTINCT ON queries <Storm:Fix Committed by wgrant> < https://launchpad.net/bugs/374777 >
<wallyworld_> jtv: been there, done that :-(
<StevenK> Ah, I see.
<wgrant> StevenK: Not really. That's a Storm bug.
<jtv> wallyworld_: that in its way is a small consolation, thanks
<StevenK> wgrant: Thank you for proving I can't read, again. r=me
<wgrant> Thankyou sir.
<wallyworld_> jtv: so what's the holiday? king's brother's cousin's birthday?
<StevenK> Haha
<jtv> wallyworld_: sssshhh carefulâjoke about that and the police is obliged to investigate.  We're talking 3â15 years in a hotel that Amnesty International has been giving consistently bad reviews.
<jtv> This is merely one of the main religious holidays.
<wallyworld_> jtv: yeah i know. that's why i made sure i was all the way over here when i said it :-D
<jtv> I _would_ have laughed out loud at this point but I'm not in a place where it's very safe to show too much independent thought.  :)
 * wallyworld_ wishes we had more religion here to get all their holidays
 * jtv wishes Santa would finally hurry up and get that heatstroke while visiting Australia, ridding the rest of us of his nonsense.
<jtv> FTR, his dying day (which is what you celebrate with saints; I'll refrain from commenting) is December 6, not 25.
<jtv> Did I mention that bad mood I was having?
<jtv> Ironic thought: I'm not just in a place where it's not safe to show independent thought; I'm in a place where I've been told so in urgent but hushed tones.  And it happens to be right outside the most prestigious university.
<LPCIBot> Project windmill-devel build #92: STILL FAILING in 50 min: https://lpci.wedontsleep.org/job/windmill-devel/92/
<jtv> lifeless: loved the email pointing to the Services Analysis.  Q about that document though:
<jtv> It looks as the "It's relatively difficult to have cascading failures" (as a benefit of the existing design) is mostly making the opposite case.  Is there anything positive under this header that we'd risk losing by changing to a different design?
<StevenK> wgrant: And thank you for the hint for of "use a tuple" -- I disliked the two loops over binaries anyway
<wgrant> StevenK: How are you going with the rest of the points.
<wgrant> They were, uh, a little extensive.
<wgrant> Apply question marks to taste.
<StevenK> wgrant: 1-3, 5, 6, 9-11
<StevenK> Or so
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build #723: FIXED in 5 hr 35 min: https://lpci.wedontsleep.org/job/devel/723/
<LPCIBot> Project windmill-db-devel build #284: STILL FAILING in 2 min 26 sec: https://lpci.wedontsleep.org/job/windmill-db-devel/284/
<StevenK> Uhhh
<LPCIBot> Project windmill-devel build #93: STILL FAILING in 49 min: https://lpci.wedontsleep.org/job/windmill-devel/93/
<LPCIBot> Project db-devel build #554: FAILURE in 6 hr 12 min: https://lpci.wedontsleep.org/job/db-devel/554/
 * StevenK smashes Zope.
<StevenK> Returning an override policy from IArchive seems to give me a proxy-wrapped object
<wgrant> StevenK: As it should.
<StevenK>     override = policy.calculateSourceOverrides(
<StevenK> ForbiddenAttribute: ('calculateSourceOverrides', <lp.soyuz.adapters.overrides.UbuntuOverridePolicy object at 0xedd0b50>)
<StevenK> :-(
<wgrant> Right, you'll need an interface and security declarations.
<StevenK> Bugger
<nigelb> StevenK: do you have anything more for me on https://code.launchpad.net/~nigelbabu/launchpad/645825-ui-example/+merge/61175
<StevenK> nigelb: Sorry, I got distracted.
<nigelb> StevenK: np :)
<StevenK> Perhaps someone else knows which tests exercise the code you changed.
<nigelb> hrm, so basically, bug more people to look at it? :-)
<StevenK> wgrant: Doesn't the fact that the code is in adapters mean that an interface is not needed?
<wgrant> StevenK: No.
<adeuring> good morning
<LPCIBot> Project windmill-db-devel build #285: STILL FAILING in 51 min: https://lpci.wedontsleep.org/job/windmill-db-devel/285/
<nigelb> Anyone's familiar with test cases that I could modify / write to make get this merge accepted? https://code.launchpad.net/~nigelbabu/launchpad/645825-ui-example/+merge/61175
<poolie> hi all
<poolie> nigelb: you probably need to look for some tests in a 'browser' directory that touch the same page
<poolie> hopefully you can adapt them
<nigelb> poolie: I'll be honest, I've very little experience with unit testing. I've written them, but not for an app this scale :)
<poolie> lifeless: hi?
<lifeless> hi
<poolie> i really liked your perf tuesday mail
<poolie> also, congratulations on the content
<poolie> that's quite a fabulous practice you've created there
<mrevell> How do?
<lifeless> mrevell: hi
<lifeless> poolie: practice?
<poolie> mrevell: habit
<poolie> bah
<poolie> lifeless: "habit"  or pattern or whatever
<poolie> is good.
<lifeless> ah :)
<lifeless> stubbornness :P
<poolie> well, celebrating progress
<lifeless> hows londinium
<poolie> very good
<poolie> lifeless: if you have any more cycles i'd like your opinion on https://code.launchpad.net/~mbp/launchpad/uniqueid-clue/+merge/61153
<jkakar> Sometimes I think Launchpad suffers because it tries to have a one-size-fits-all solution... which means the obvious things that would for 98% of the projects and users can't be done because they don't work for 2% that are complex.
<jkakar> For example, the project home page is pretty hard to use... it's really hard to find things like the active reviews page, for example.  Or whether or not the project has associated PPAs.
<jkakar> I wonder if we need to ditch the idea that we have a single view for all projects and instead have a perfect view that degrades (or mutates) as projects get more complex.
<wgrant> jkakar: Projects don't have associated PPAs :(
<jkakar> wgrant: I know.  It's dumb.
<jkakar> wgrant: The team/project model in Launchpad is broken.
<jkakar> wgrant: I know it's uber flexible and makes all kinds of use cases possible... but it also makes the obvious ones very hard to achieve.
<jkakar> wgrant: I find myself consistently educating users about very basic aspects of Launchpad.
<jkakar> wgrant: It should be easier for people to figure out how it works and what it does.
<jkakar> wgrant: I hope there's some budget for UI improvements this year... Launchpad is slipping behind the competition and it's so much better in so many ways.
<jkakar> Anyway, I guess the burden created by technical debt is slowly being beaten down... it sounds like things have improved *a lot* in the last year, which is excellent.
<wgrant> Launchpad slipped behind the competition about 4 years ago.
<wgrant> jkakar: The maintenance squads are currently working solely on removing the pile of critical bugs.
<wgrant> In the last month we have made significant progress.
<wgrant> I expect it will be done in another 2 or 3 months.
<wgrant> Then Launchpad can improve, as there will be people dedicated to doing non-feature work like unbreaking the UI.
<jkakar> wgrant: Yep, it can definitely improve and the team is smart and capable.
<jkakar> wgrant: It also rocks today, despite it being hard for newcomers to realize that.
<wgrant> Functionality-wise it rocks.
<jkakar> wgrant: Yes, exactly.
<wgrant> UI-wise, it, uh....
<jkakar> wgrant: Yeah. :)
<poolie> i'm wondering about trying to spike a timeline view at the rally
<jkakar> poolie: DO IT! :)
<jkakar> poolie: Also, integrate lp:kanban while you're there. ;b
<jkakar> Speaking of which, I really want to find more time to work on it.
<poolie> (kthxbye? :-)
<poolie> me too
<jkakar> Hehe
<jkakar> poolie: I want to port it to Go... but I guess that wouldn't be as good a use of my time as landing some of the improvements we've discussed.
<jkakar> But I'm very excited about Go... I've been playing with it on and off and its really nice.
<poolie> me too
<jml> jkakar: as nice as C++?
<jkakar> jml: C++ is not nice in any way.
<jml> jkakar: aww, you'll hurt its feelings
<jkakar> jml: It's much better than C++, from what I can tell so far.
<jkakar> jml: Good. :)
<jml> heh heh
<jkakar> jml: Actually, I love C++... the way you have to think... the weird crap that comes up that is completely unrelated to your problem... template metaprogramming...
<jkakar> jml: But I never ever ever want to maintain a real system written in C++ (I've done it, I know how much it sucks).
<poolie> it is far smaller
<poolie> at least one order of magnitude less complexit in the language, probably two
<poolie> of course it is younger
<rvba> lifeless: wgrant Hi, I've recently used the new (to me that is) "RECURSIVE WITH" SQL feature ... and I did this with store.execute(...) ... Is there a way to do this properly with Storm? (I saw only raw sql statements using RECURSIVE WITH in the existing code)
<jkakar> poolie: Yes, that's a nice way to put it.  It is younger, but it already has a very nice set of libraries (both builtin and community contributed).
<jkakar> poolie: It's also cool that they're still evolving the language and not promising backwards compatibility... things are moving, it's not a dead language.
<rvba> This is the branch in question FYI https://code.launchpad.net/~rvb/launchpad/distro-overlay2-bug-758908-dependencies/+merge/61110
<wgrant> rvba: lib/lp/blueprints/model/specification.py
<wgrant> rvba: the WITH query still has to be raw SQL at the moment.
<wgrant> rvba: But the rest can be Storm.
<poolie> jkakar: i'v been wondering what will bring erlang-like ideas to the mainstream
<poolie> this may be it
<rvba> wgrant: ok thanks. Since my query is only a RECURSIVE WITH query, it will stay the way it is now then.
<poolie> wgrant: if it's not too late i'd appreciate your thoughts on https://code.launchpad.net/~mbp/launchpad/uniqueid-clue/+merge/61153
<poolie> i guess specifically if it's likely to overall help worth the trouble
<wgrant> poolie: Er, tests depend on the format? Ew.
<poolie> doctests stab stab
<wgrant> How many?
<poolie> becasue of course if you have
<poolie> >>> thing.name
<poolie> generic-....
<poolie> then you will get a decent error if it fails whereas
<poolie> >>> thing.name == expected
<poolie> True
<poolie> then it says nothing useful
<wgrant> Ah, yes.
<poolie> oh not that many
<poolie> 7 failures, 5 errors
<wgrant> I think you should remove those contract violations and land it :)
<jkakar> poolie: Indeed.
<poolie> thanks
<poolie> in particular "if something unexpected happens just die" as a strong default makes so much sense
<lifeless> rvba: store.with_
<lifeless> rvba: its in our storm branch
<lifeless> poolie: it looked ok to me
<lifeless> poolie: a measurement of the overhead would be useful
<rvba> lifeless: thanks, I'll take a look at this.
<lifeless> grep for '\<with_\>'
 * rvba is doing precisely this.
<lifeless> oh, I see wgrant helped you out already
<rvba> yes :)
<lifeless> jkakar: so, I found go slower than pypy in the weekend :)(
<lifeless> jkakar: not enough data to draw conclusions on
<LPCIBot> Project windmill-devel build #94: STILL FAILING in 50 min: https://lpci.wedontsleep.org/job/windmill-devel/94/
<lifeless> jkakar: but if pypy gets a free threading model, it would be a real serious language IMO
<lifeless> jkakar: if you have any thoughts on https://dev.launchpad.net/ArchitectureGuide/ServicesAnalysis I would appreciate them!
<poolie> lifeless: go vs pypy on what sort of a benchmark?
* gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | https://code.launchpad.net/launchpad-project/+activereviews
<poolie> nigelb: if you get stuck, i for one will try to help you
<poolie> i'm sure the ocr (currently gmb) will too
<poolie> fairly sure ;-)
<poolie> o/ gmb
<lifeless> poolie: lmirror journal tokenising
<lifeless> poolie: string splitting a 74MB null delimited file
 * gmb waves
<poolie> interesting
<poolie> using go slices?
<nigelb> poolie: I'm just stuck at the sheer size of it and limited time I have to figure things out, but I shall be back later to take a poke at things
<jkakar> lifeless: Ah, very interesting.
<lifeless> poolie: yes
<lifeless> jkakar: intro to it is on the launchpad-dev list
<jkakar> lifeless: Cool, will check it out.
<poolie> nigelb: so one thing could be to just kick off './bin/test' and see if anything does currently fail
<poolie> if it does' you know what to fix
<nigelb> I did a test but not the whole thing
<poolie> it takes a while though, like 4h on a decent machine
<nigelb> poolie: what I ran is "bin/test -vvt productseries-views.txt"
<poolie> i would probably try 'bin/test -m registry'
<nigelb> hrm, okay.  I'm on my work box now, should be home in a few hours to fix that
<lifeless> jkakar: on UI, I think LP needs to focus on lean somewhat ;)
<lifeless> portlets are  a poor way to summarise and present useful info IMNSHO
<lifeless> (great for overview stats though)
<poolie> lifeless: i wonder if someone could make kind of science fiction screenshots for lp
<poolie> like they did with unity
<poolie> to exemplify that kind of concept
<jkakar> lifeless, poolie: Yes, agreed.  I'd like to see science fiction screenshots... I've been thinking about doing it myself... but time. :/
<lifeless> mmm
<lifeless> perhaps
<lifeless> mockups are a great way to communicate the visual nature
<jkakar> The way we did the Landscape UI revamp was very nice.
<jkakar> We focused on information architecture first, to understand what it was we wanted to communicate...
<lifeless> I think the key thing is someone with the: a) time, b) mandate [assumed or granted, I don't care], c) knowledge and d) communication skills overhauling things
<lifeless> jml has been doing this with his review on what we do and why
<jkakar> Then from there we started to think about workflows, primary and secondary use cases, etc.
<lifeless> and his highlighting of things that are not core - and these things cost
<jkakar> lifeless: Yes, agreed.
<lifeless> like answers, it /costs/ a lot - links to other parts of the system, UI realestate on the home page etc etc
<lifeless> jkakar: so it seemed to me while you revamped that the folk doing the visuals had to come to grips with what the system does
<lifeless> in a fairly thorough fashion
<lifeless> jkakar: or did I misperceive?
 * jml tries to think about bug 772754, but drowns in text
<_mup_> Bug #772754: After better-bug-notification changes, list of bug subscribers is confusing <story-better-bug-notification> <Launchpad itself:Triaged by yellow> < https://launchpad.net/bugs/772754 >
<jml> will tackle other emails first.
<gmb> jml: I feel your paint.
<gmb> Er.
<gmb> Pain.
<jml> gmb: it's smooth and contains no added lead.
<gmb> So many rejoinders, so few of which are actually appropriate for a public channel.
<lifeless> gmb: bad bad bad bad bad man
<jml> A deliberate move on my part.
<gmb> I'm that bad that I made lifeless think bad thoughts (with jml's help). I win at badness.
<jml> There need to be terms for repartÃ©e of the same ilk as chess terms
<gmb> ... Hm, also, might want to rephrase "I make lifeless think bad thoughts" to something where it sounds less like he wants me for his cuddle toy.
<gmb> Shuttingupnow.
<jml> I guess "zugzwang" might actually just work.
<lifeless> heh, cloudbees have adverts 'hudson is now jenkins'
<lifeless> its on!
<wgrant> It's not off yet?
<gmb> Is `Not(Something.attribute == None)` the correct Storm way to say "Something.attribute IS NOT NULL"?
<gmb> Or am I better off using SQL() for that
<gmb> ?
<wgrant> gmb: != None?
<gmb> wgrant: I thought there were issues with the != operator.
<wgrant> I use it all the time.
<wgrant> So I hope not.
<gmb> Fair point, then :)
<jkakar> lifeless: Yes, that was definitely the case.  We worked together, starting by giving the designers an overview of the system, and from there we worked together to clarify the ideas they came up with.
<wgrant> You shouldn't do != None normally,.
<gmb> No.
<wgrant> But for Storm expressions it's fine.
<gmb> Okay.
<gmb> wgrant: Thanks, I'll give that a shot.
<jkakar> lifeless: A big factor during the whole process was also deciding what we could reasonably achieve.  Some of their ideas were fantastic but unrealistic in terms of implementation difficulty and cost.
<jkakar> lifeless: I'm pretty proud of how things turned out.  Landscape is *much* better now than it was.
<jkakar> lifeless: And we came up with nice patterns that make putting new things in place easier.
<lifeless> cool
<lifeless> thats excellent
<jkakar> lifeless: Yes, it was a lot of fun.
<jkakar> lifeless: Something that was hard though, was that we had to do *a lot* of work before we could release anything...
<lifeless> yeah, that hurts
<jkakar> lifeless: We were iterating with the designers, but we had a broken system for a long time.  It was a bit hard.
<jkakar> lifeless: I'm not really sure what we could have done differently, but focusing on deliverable milestones is very important.
<LPCIBot> Project windmill-devel build #95: STILL FAILING in 50 min: https://lpci.wedontsleep.org/job/windmill-devel/95/
<cjohnston> wgrant: mornin
<wgrant> cjohnston: Hi. Your blueprint essential checkbox fix is on production now.
<cjohnston> I see that! Yippie!
<cjohnston> Thanks wgrant
<wgrant> Maybe I should unbreak community-contributions.py
<cjohnston> uh oh
<wgrant> https://dev.launchpad.net/Contributions still thinks I don't work for Canonical.
<cjohnston> a couple of my other branches are now listed as approved, I guess they just need to go through the merging process! yippie!
<cjohnston> Off to work for a few hours... Be back this afternoon.
<lifeless> jml: I'm not coordinating the project setup sabdfl has asked for at this point; if you want me to say so and I'll get on it tomorrow.
<jml> lifeless: will be talking to flacoste about it later today.
<lifeless> great
<lifeless> I shall happily purge it from my mind :>
<jml> lifeless: will keep you posted.
<jml> good good.
<lifeless> gnight!
<jml> lifeless: g'night.
<gmb> allenap: Of https://bugs.launchpad.net/launchpad/+bug/783948: I'm going to open a second bug to track the fact that somehow bug page rendering has been broken.
<_mup_> Bug #783948: Entering a comment returns an error <Launchpad itself:Triaged> < https://launchpad.net/bugs/783948 >
<gmb> Sound sane to you?
<allenap> gmb: Sure, I don't mind :) It's likely to be the same underlying bug though.
<gmb> allenap: Weeee-ll. I see two: 1) We should still be able to render the page in the presence of slightly funky data (which is what I assume is going on here) and 2) We shouldn't accept the funky data in the first place.
<allenap> gmb: Cool.
<gmb> Well, hiding the comments doesn't make the page render.
 * gmb waits for the OOPS.
<wgrant> LocationError: (<zope.browserpage.metaconfigure.SimpleViewClass from /srv/launchpad.net/production/launchpad-rev-13053/lib/lp/bugs/browser/../templates/bug-portlet-subscribers.pt object at 0xfe1d610>, 'current_user_mute_class')
<wgrant> Huh.
<gmb> wgrant: Are you looking at the bug linked to in bug 783948 too?
<_mup_> Bug #783948: Entering a comment returns an error <Launchpad itself:Triaged> < https://launchpad.net/bugs/783948 >
<wgrant> Thankyou TALES for your awesome exception suppression.
<wgrant> gmb: No, I looked at the OOPS linked in the bug.
<wgrant> It doesn't OOPS for me.
<gmb> wgrant: Oh really? Now that is interesting.
<wgrant> I even tried muting it.
<gmb> Curious.
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build #555: FIXED in 5 hr 28 min: https://lpci.wedontsleep.org/job/db-devel/555/
<wgrant> Note that I am in ~ubuntu-bugs.
<wgrant> So I have a subscription to mute.
<gmb> Aaah.
<wgrant> Both to the distro and through the dupe.
<gmb> So, this could be another regression due to my fix for bug 772609, maybe. Poo.
<_mup_> Bug #772609: bug subscription mute link is not shown for membership in a team with a direct or structural subscription <bad-commit-13003> <story-better-bug-notification> <Launchpad itself:In Progress by gmb> < https://launchpad.net/bugs/772609 >
<poolie> how do i select a single doctest file to run?
<gmb> poolie: bin/test -ct doctest-filename.txt
<poolie> with the full path?
<gmb> poolie: No, just hte filename will work.
<gmb> s/will/should/
<jml> poolie: it does a regex match on the calculated doctest id, which is, I think, lib/lp/bugs/doc/thingy.txt
<jml> (it used to be lib/lp/bugs/tests/../doc/thingy.txt)
<wgrant> gmb: Do you have any idea what's going on here? We may want to revert the deployment.
<gmb> wgrant: Working on it now, but that's my thinking too.
<wgrant> allenap: Is it still broken for you?
<wgrant> If so, we should probably try accessing that view property in a harness to get the real exception.
<allenap> wgrant: Arr, t'is.
<wgrant> allenap: With that same locationerror?
<allenap> wgrant: Yep.
<gmb> wgrant, allenap: I'm going to give this some looking at for the next hour or so; I can't be certain that my revision caused this breakage, but if I can't find a cause in the next hour we'll roll it back and hope that that fixes it.
<allenap> gmb, wgrant: Renders fine if I'm logged out.
<wgrant> gmb: We can trivially roll back to 13045 in a few minutes if required.
<gmb> wgrant: Hmm. If it's trivial then maybe we should give it a shot.
<gmb> (I always have my work reverted overnight)
<wgrant> Sorry, my QA was obviously crap this time :/
<gmb> wgrant: There are only so many permutations you can check for.
<gmb> This is more of a notest problem.
<gmb> (or badtest)
<deryck> Morning, all.
<poolie> hi deryck
<deryck> henninge, ping for standup
<henninge> deryck: coming
<deryck> cool
<poolie> does launchpad actually retriage all High bugs every four months?
<wgrant> The intention is to do that.
<poolie> mrevell: ^^, but aside from that the page looks really good
<wgrant> But it's all a bit chaotic at the moment.
<wgrant> Like Criticals.
<mrevell> Thanks for taking a look. I meant to ask in my email to the list if that was something we were actually doing.
<poolie> it was just curiousity
<poolie> until the critical queue is drained it's probably not worth doing
<danilos> gmb, hi, can you please take a look at https://code.launchpad.net/~danilo/launchpad/bug-772763-remove-nothing/+merge/61251?
<gmb> danilos: Sure
<danilos> gmb, thanks, the diff is likely to show up only in 5 mins or so :)
<gmb> danilos: Works for me. I need a cup of coffee anyway :)
<danilos> gmb, diff is up so whenever the coffee is brewed... :)
<gmb> danilos: Looking now.
<nigelb> hey gmb, do you have a moment to help me proceed with https://code.launchpad.net/~nigelbabu/launchpad/645825-ui-example/+merge/61175.  I seem to be stuck not knowing how to deal with test cases
<gmb> danilos: r=me. I particularly approve of your removal of tests (yes, I know they would have broken, but it warms my heart to see a test file a bit shorter).
<gmb> nigelb: Sure, I'll take a look.
<nigelb> gmb: thanks
<gmb> nigelb: Do you know if any tests break as a result of your changes (I know it's not exactly a trivial think to run all the LP tests on your own machine...)
<nigelb> gmb: hang on, let me show you what I did run
<gmb> k
<nigelb> gmb: I ran "bin/test -vvt productseries-views.txt" which ran successfully
<nigelb> I'm okay to write new tests for this if you can explain where they need to be written
<gmb> nigelb: Okay. Let's try and work out what needs to change...
<nigelb> awesome :)
<poolie> benji: if you're here, could i get a wee little incremental review on https://code.launchpad.net/~mbp/launchpad/778437-sprb-spam/+merge/60360
<benji> poolie: sure
<benji> poolie: there are conflict markers in the diff
<poolie> yeah i just discovered that
<poolie> this is getting kind of messy
<poolie> istm this ought to be split out into some kind of pubsub filter rather than doing it inline here
<gmb> nigelb: The following might fail now: `bin/test -ct xx-upload-directions`
<nigelb> gmb: where do you reckon I should start?
<gmb> nigelb: Well, run that test.
<gmb> If it fails then you know to update it.
<gmb> If not, you *still* need to update it
<gmb> (The file is here: lib/lp/code/stories/branches/xx-upload-directions.txt)
<nigelb> heh, ok
<gmb> nigelb: If it doesn't fail, ping me and I'll see if I can walk you through adding the necessary changes.
<nigelb> gmb: okay!
<nigelb> gmb: that didn't fail
<gmb> Poo.
<nigelb> heh
<gmb> nigelb: Okay, bear with me whilst i take a look at the test
<gmb> nigelb: Still looking - got distracted by a failing RAID disk.
<nigelb> np, I'm looking at these tests to figure out how they work
<poolie> o/ nigel
<poolie> thanks benji
<benji> np
<gmb> Oh, that's annoying.
<nigelb> o/ poolie
<nigelb> nigelb: persistently trying to fix my first bug on Lp :)
<gmb> nigelb: I think you can probably add something to xx-upload-directions.txt
<gmb> (As in, that seems like a sane place for it to be).
<nigelb> ok, but I have't understood how the tets in that file work
<nigelb> >>> name12_browser.open(branch_page)
<gmb> OTOH pagetests are horrible and need to die, so...
<gmb> nigelb: Are you familiar with doctests at all?
<nigelb> ^^ is that the bit where the actual test happens?
<gmb> Yes.
<gmb> nigelb: Think of the >>> do_something() bits as being stuff exectued in the Python CLI.
<nigelb> aha
<gmb> The bits inbetween are the documentation.
<nigelb> and the data is assumed to be the default data?
<gmb> nigelb: Yes. That's why we don't usually like to add to these tests unless we can help it.
<gmb> nigelb: But if you can think of a way to exercise your code using the sampledata then that's not a bad place to start at all.
<nigelb> well, for testing this, we'll have to change the data I think, or is there a project in the default data that has more than one series?
<gmb> nigelb: I don't know.
<gmb> nigelb: But you could use the testing factory to create one.
<gmb> nigelb: e.g.:
<gmb> >>> product = factory.makeProduct()
<gmb> >>> ...
<gmb> (I *think* the factory is available in all the doc and pagetests now)
<nigelb> found one
<nigelb> https://launchpad.dev/alsa-utils
<gmb> Aha.
<nigelb> bah
<nigelb> that has branch linked
<nigelb> here's another https://launchpad.dev/a52dec/failedbranch
<jml> gmb: is this bug closed? https://bugs.launchpad.net/launchpad/+bug/674815
<_mup_> Bug #674815: When a bug is marked as duplicate, you are invited to subscribe to the master bug <lp-bugs> <story-better-bug-notification> <Launchpad itself:Triaged> < https://launchpad.net/bugs/674815 >
<gmb> jml: I don't know off the top of my head.
<gmb> nigelb: I think you'd be best-off using the factory to create a new project
<gmb> And then adding the necessary number of series to that.
<nigelb> wow, that's a lot of test code to write o.O
<gmb> nigelb: Really? Let me look...
<nigelb> gmb: well, use factory to create a project, create a new series, and then test, and then tear down.
<gmb> nigelb: You don't need to tear down.
<gmb> It's done automatically.
<gmb> It should be something like:
<gmb> >>> product = factory.makeProduct()
<gmb> >>> series_1 = factory.makeProductSeries(product=product)
<gmb> >>> series_2 = ...
<gmb> Then you can do something like
<gmb> >>> user_browser.open('$URL_TO_WHATEVER_PAGE')
<gmb> and check that the text you're looking for appears in that page.
<nigelb> okay, let me take it step by step :)
<gmb> nigelb: Unless I'm missing something; I don't know codehosting well.
<gmb> nigelb: Sure thing.
<wgrant> (note, though, that writing more doctests is likely to invoke hitherto unknown demons)
<nigelb> wgrant: I thought touching launchpad did that anyway.
<wgrant> :(
<nigelb> so, I start by making a product using product = factory.makeProduct()
<nigelb> then I make a new series in that product using the series_1 line above
<gmb> wgrant: Agreed. nigelb: This should probably go in a unit test, thinking about it
<gmb> nigelb: So let's back up a step here and find somewhere suitable for it...
<nigelb> gmb: ah
<nigelb> gmb: pause for now
<nigelb> lib/lp/registry/tests/test_productseries.py?
<wgrant> It'll be in lib/lp/*/browser/tests
<nigelb> ah
<gmb> nigelb: Hmm. It's a view test so it should go in lib/lp/registry/browser/tests
<gmb> And there isn't a producteseries one in there.
<gmb> So we need to create one.
<gmb> nigelb: You can copy the test boilerplate from standard_test_template.py in the root of the LP tree.
<gmb> call it lib/lp/registry/browser/tests/test_productseries_views.py
<nigelb> okay, done
<nigelb> http://pad.ubuntu.com/lp-productseries-test
<nigelb> I'm guessing I should import TestCaseWithFactory instead of DatabaseFunctionalLayerDatabaseFunctionalLayer
<gmb> Aha!
<gmb> Good idea that man.
<nigelb> heh
<gmb> nigelb: No, you need to import it instead of TestCase
<nigelb> ah, ok
<gmb> nigelb: We need LaunchpadFunctionalLayer since we want to actually render a View
<gmb> So...
<nigelb> gmb: and we don't want database since we're going to use factory right?
<gmb> nigelb: No, you need the database (it's implicit)
<nigelb> ohh, okay
<gmb> Horrible admission: We always use a live DB instance, even when we use the factory
<wgrant> gmb: Not DatabaseFunctionalLayer? I'm not sure this will need the librarian.
<wgrant> And that takes ages to start, so nice to avoid it where possible :)
<gmb> wgrant: If that provides the UI, then sure. I thought it didn't.
<gmb> I'm happy to be wrong.
<nigelb> gmb: okay, I did the SetUp bit, does that look right? (I looked at one of the poll tests)
<wgrant> gmb: IIRC LaunchpadLayer just provides librarian and memcache. But this is an entirely confusing mess.
<gmb> nigelb: Actually, you can do it in the test.
<nigelb> gmb: oh, okay, I'll just rename the thing
<gmb> ok
<wgrant> Lots of browser tests are DatabaseFunctionalLayer.
<gmb> wgrant: Fair neough. Let's just do that and fix it if it breaks.
<wgrant> That's how I tend to choose layers, yeah :/
<nigelb> heh
<gmb> nigelb: You can drop the self.* stuff too when you're creating your variables in-test.
<nigelb> now how I open the url to one of those.
<nigelb> gmb: ah, so much learning :)
<gmb> nigelb: I think you can just use create_initialized_view. Hang on...
<wgrant> Indeed. view = create_initialized_view(series, '+whateverview'); self.assertThat(view(), Contains('whatever string you are looking for in the output'))
<wgrant> (Contains is imported from lp.testing.matchers; create_initialized_view from lp.testing.views)
<gmb> wgrant: I like this thing where you're always one step ahead of my typing.
<gmb> Saves me a job.
<nigelb> gmb: that leaves me with one question, how do I build the string based on name of lp user, product and series
<gmb> nigelb: Something like this...
<nigelb> basically I need to build "lp:~name16/productname/seriesname"
<nigelb> etherpad is so much fun for pair coding :)
<gmb> Yeah.
<gmb> It rocks.
<gmb> I'd totally forgotten about it.
<gmb> (And I've always been burned by Gobby)
<nigelb> heh, this UDS, we had a good time with it (minus the spam)
<gmb> I can imagine
<nigelb> I think you've written the test completely, and I've learned how to write a new one now :)
<gmb> Heh.
<nigelb> now, how do I test this beast? :)
<nigelb> gmb: ^^
<gmb> nigelb: You should just be able to run `bin/test -ct test_productseries_views`
<gmb> And that should JustWork.
<nigelb> famous last words
<nigelb> ;)
<sinzui> gmb: do you have time to review https://code.launchpad.net/~sinzui/launchpad/language-add-admin/+merge/61267
<gmb> Sure
<poolie> i wonder if it is worth doing some stats on what kind of change in lp needs a rollback
<poolie> and perhaps that could guide us to put flags on that type of change beforehand
<poolie> (or even perhaps to not make problem changes, but hey)
<nigelb> gmb: ah, it failed.  The user isn't logged in. Is there a way to create a way where the user we created is logged in?
<gmb> nigelb: There is, yes.
<gmb> nigelb: I'm just reviewing sinzui's code, so I suggest grepping for "with person_logged_in" in lib/lp
<gmb> Should help.
<nigelb> will do, thanks
<gmb> person_logged_in comes from lp.testing, IIRC.
<gmb> sinzui: r=me
<sinzui> fab
<sinzui> thank you very much
* gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<nigelb> bah, traceback
<nigelb> gmb: got a huge traceback :(
<poolie> benji, i don't understand when lp reviews get into approved state
<gmb> nigelb: Paste it for me
<poolie> specifically can i just flip https://code.launchpad.net/~mbp/launchpad/uniqueid-clue/+merge/61153 myself
<poolie> or what should i do?
<poolie> no ocr now?
<gmb> poolie: I'm still here.
<benji> poolie: yep, you can flip it yourself; most reviewers leave the over-all status alone
<gmb> poolie: If it's reviewed and approved, feel free to flip the flag
<benji> The idea is that if you need more than one review (ui, db, etc.) then you should decide when it's sufficiently approved
<nigelb> gmb: http://paste.ubuntu.com/609048/
<gmb> nigelb: Can you update the EP session with your current test?
<nigelb> gmb: erm, EP session?
<gmb> EtherPad
<nigelb> ah, etherpad
<nigelb> done; http://pad.ubuntu.com/lp-productseries-test
<gmb> Hmm.
<gmb> Okay, gimme a sec
<gmb> nigelb: I've changed the test so s/+index/+code-summary/
<gmb> ]
<gmb> Don't know if that'll work, but give it a shot.
<gmb> (since that's the page you changed)
<nigelb> okay, I'll take a shot
<nigelb> gmb: failed again :(
<nigelb> http://paste.ubuntu.com/609051/
<gmb> !
<gmb> nigelb: [36m        No revision control details recorded for[0m
<gmb> [36m        <em>Product-name738808 generic-string738812 series</em>.[0m
<gmb> Might have something to do with it
<LPCIBot> Project windmill-db-devel build #286: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-db-devel/286/
<nigelb> gmb: hrm, the slashes didn't turn up?
<gmb> nigelb: No, I just think we need to do something extra to the series to make this work.
<gmb> Just not sure what.
<nigelb> gmb: heh, what can I do at this point?
<gmb> nigelb: Try person = product.owner
<gmb> Instead of using self.factory.makePerson()
<nigelb> okay
<gmb> (It seems thtat message only appears if you don't have edit rights).
<gmb> Not that that will fix it, but it's a step along the road.
<gmb> Aaah
<gmb> nigelb: You need to have an SSH key for person.
 * benji looks.
<nigelb> gmb: ahh.
<gmb> nigelb: I've tweaked the EP doc.
<nigelb> gmb: \o/ Trying again :)
<nigelb> gmb: IT WORKED!
 * nigelb does happy dance
<gmb> WEWT
<gmb> nigelb: Commit it, push it, ping me and I'll review it.
<nigelb> that's the hardest I've worked to fix a bug.
<nigelb> gmb: https://code.launchpad.net/~nigelbabu/launchpad/645825-ui-example/+merge/61175
<gmb> nigelb: Welcome to our world. I've been doing this for four years.
<gmb> No wonder I'm going bald.
<nigelb> gmb: heh.
<gmb> nigelb: Argh. One thing I should have said: The test needs a comment at the start of it that states the expected behaviour. e.g.:
<gmb> "# The LP branch URL displayed to the user on the +code-summary page for a product series will relate to that series instead of to the default series for the Product.
<gmb> :
<gmb> (Wrapped to 78 characters, obviously)
<gmb> nigelb: But that aside, I'm happy for this to land.
<gmb> Can you add that comment and push it? I'll run it through EC2 for you when you have done.
<nigelb> gmb: I can do that right away
<gmb> Cool
<nigelb> gmb: could you glance at the etherpad again to see if its fine :)
<gmb> Sure...
<nigelb> ahhh, gmb = Graham Binns, now I realize :-)
<gmb> nigelb: Ah, not at the start of the Testcase, at the start of the test. So:
<nigelb> aha
<gmb> nigelb: Yup. I couldn't be bothered thinking up an imaginative nick, so I just used my initials.
<nigelb> gmb: heh, neither can I ;)
<gmb> :)
<gmb> nigelb: Anyway, let me know when that's pushed and I'll run it through EC2 for you.
 * benji is very imaginative.
<gmb> Heh
<nigelb> gmb: its pushed, I'm waiting for lp to show updated branches
<benji> gmb: are you off the OCR clock for the day?
<gmb> benji: Depends. How big is the branch?
<benji> gmb: not teeny: 469 line diff; I bet I can persuade one of the yellow guys to do it
<gmb> benji: No, I'll tkae that.
<gmb> It'll take me to EoD.
<gmb> :)
<benji> ok, here you go https://code.launchpad.net/~benji/launchpad/bug-777786/+merge/61274
<gmb> Ta
<nigelb> gmb: Thanks a bunch for the help :-)
<gmb> np
<gmb> benji: r=me
<benji> thanks
<LPCIBot> Project windmill-devel build #96: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-devel/96/
<LPCIBot> Project windmill-db-devel build #287: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-db-devel/287/
<LPCIBot> Project windmill-devel build #97: STILL FAILING in 47 min: https://lpci.wedontsleep.org/job/windmill-devel/97/
<LPCIBot> Project windmill-devel build #98: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/98/
<lifeless> morning
<cr3> in terms of development, what's the difference between using schroot and kvm?
<cjohnston> mornin lifeless
<lifeless> hi cjohnston
<lifeless> cr3: ip addresses I suspect
<lifeless> flacoste: hi
<flacoste> hi lifeless
<lifeless> flacoste: nvm, I remembered what it was - grouping criticals
<cjohnston> hey flacoste
<flacoste> hi cjohnston
<lifeless> poolie: thanks for the feedback
<soren> I just thought of something... jml said in his UDS lightning talk that you were adding a bunch of new headers to e-mail for easier filtering.. Some of us use GMail, and it doesn't let you filter on arbitrary mail headers (because it doesn't index those, presumably). Is anyone considering that use case?
<soren> i.e. copying the mail headers in the body in a way that is searchable/filterable (or something else that makes filtering with gmail suck less).
<lifeless> I don't think so
<lifeless> there is a bug about this though
<lifeless> http://www.readwriteweb.com/cloud/2011/04/5-graph-databases-to-consider.php
<mwhudson> lifeless: have you read the 'release it' book?
<lifeless> mwhudson: yes
<mwhudson> cool
<lifeless> a bit light weight, but some good clear explanations
<lifeless> I think most web devs should read it
<mwhudson> i thought i could detect various release it thoughts in https://dev.launchpad.net/ArchitectureGuide/ServicesAnalysis
<lifeless> mmm, possibly
<mwhudson> plenty of other sources for that sort of thing though
<lifeless> I last looked at it > a year back
<mwhudson> there are only two things i really remember from the book -- one is the idea of 'integration point' and the other is "SQL IS NOT AN INTEGRATION STRATEGY"
<lifeless> :)
<lifeless> the things I thought was nicest in the book was the pattern for handling occasionally failing services
<lifeless> the ratcheting-alert-thingy
<mwhudson> ah yeah
<lifeless> mwhudson: what do you think of the proposal
<mwhudson> related to the integration point thing was the thought of why it's so important to always attach errbacks to deferreds in twisted
<mwhudson> because if you get a deferred, it's generally something that will take some time to complete
<mwhudson> and that's actually really strongly correlated with 'something that you cannot rule out failing'
<mwhudson> (i.e. an integration point)
<mwhudson> lifeless: i think it makes sense mostly, i'm only about halfway in
<lifeless> jcsackett: bug 784273
<_mup_> Bug #784273: InvalidURIError generated by unescaped search on frontpage <Launchpad itself:New> < https://launchpad.net/bugs/784273 >
<lifeless> jcsackett: the url in the exception is a lie
<mwhudson> there are some sentences that i think aren't really clear, i'll be sending an email about that in due course :)
<lifeless> jcsackett: if you look at the request variables you can see the actual query string and path - I've pulled that out into the bug description for you (and it oopses if I click on the  link)
<lifeless> mwhudson: cool, thanks!
<lifeless> jcsackett: also, please triage-when-you-file :)
<jcsackett> lifeless: ack, on the triage, i got distracted. :-)
<jcsackett> and thanks for the updates.
<lifeless> no probs
<lifeless> I was intruiged by it not oopsing so I went fiddling :)
<lifeless> mwhudson: if you know what the sentence means, feel free to edit
<mwhudson> lifeless: will do
<lifeless> I wonder if we should prevent users putting in a one-line summary of their problem
<lifeless> make that a developer only field
<lifeless> + apport field
<lifeless> (because very very very few users put the problem in the field vs their preferred solution)
#launchpad-dev 2011-05-18
<wallyworld_> wgrant: can you hear me?
<wgrant> wallyworld_: No.
<wallyworld_> bugger
<wallyworld_> sidnei: here but my mike is broken
<wallyworld_> sinzui: ^^^^
<sinzui> wallyworld_: I had to mute/unmute from sound preferences this morning to make my mic really work
<wallyworld_> sinzui: wgrant: skype works, but not mumble :-(
<mwhudson> sigh, what i really want is just to be able to attach comments ajaxily to the wiki page
<lifeless> mwhudson: that would rock
<mwhudson> maybe we can make thumper add that to wikkid :)
<thumper> sup?
<thumper> attach comments?
<lifeless> I think WYSIWYG editing without bring up the full edit widget
<lifeless> e.g. change one paragraph only
<lifeless> or add an annotation to the text
<wgrant> wallyworld_: Hi.
<wallyworld_> wgrant: hello
<mwhudson> why does my brain always pop up 'cucumber' when i'm really trying to remember 'celery'
<wgrant> wallyworld_: Can you QA your recipe build emails thing on staging?
<wallyworld_> wgrant: yes. just going through my emails now and saw that one is still todo
<wgrant> I'm doing the gpghandler thing.
<wallyworld_> wgrant: not sure how to qa it though
<lifeless> mwhudson: because they are both terrible project names
<mwhudson> lifeless: +1
<wgrant> wallyworld_: Create one successful build, one depwait build, see what happens?
<wallyworld_> wgrant: that's the point. i'm not sure how to create a buidl with a dep issue
<wgrant> wallyworld_: Branch an existing package, add 'fewfwefwefwew' to the Build-Depends field, build.
<wallyworld_> wgrant: ok. i'm a total packaging noob you realise :-)
<wallyworld_> wgrant: on qastaging, i assume there are logs we can look at to see what email would have been sent
<wgrant> wallyworld_: You can check the staging mailbox.
<wgrant> Have you accessed that before?
<wallyworld_> nope :-(
<wgrant> Let's see if I can find the wiki page.
<wallyworld_> if it's on the wiki, i'll find it
<wgrant> https://wiki.canonical.com/InformationInfrastructure/OSA/LPHowTo/ConnectToStagingMailbox
<wgrant> But the password says to ask a LOSA.
<wgrant> That's false.
<wallyworld_> excellent thanks
<wgrant> You will need a reasonable mail client.
<wgrant> The mailbox can be several hundred thousand messages.
<wallyworld_> wgrant: can you send me the password? what do you consider to be a reasonable client?
<wgrant> wallyworld_: I PM'd it to you internally.
<wgrant> wallyworld_: I don't know how Kmail is these days.
<wgrant> Last time I tried it with IMAP it was rather segfaulty.
<wallyworld_> wgrant: ah thanks. didn;t see the pm, sorry
<mwhudson> lifeless: dammit email half-written and i need to go
<mwhudson> will finish later :)
<lifeless> mwhudson: no worries
<wallyworld_> wgrant: well i'm trying kmail now. thunderbird refuses to connect (could be because i'm using a recent (buggy) snapshot to get better unity integration)
<wgrant> qa-ok!
<wgrant> It is poppy-fixing time.
<wgrant> Well, once asuka gets its act together.
<wgrant> Oh, the mailbox is tiny now.
<wgrant> I guess because question emails aren't being sent.
<wallyworld_> bugger, qastaging is down
<wgrant> It'll be back in a couple of minutes.
<wgrant> There we go.
<wgrant> Just took a while to update WADL.
<wallyworld_> cool
<wgrant> Hm.
<wgrant> Not actually back yet.
<wgrant> But the appserver is started.
<wgrant> There.
<cody-somerville> How interesting...
<cody-somerville> you can be logged into launchpad.net as one user and login.launchpad.net as another
<cody-somerville> which for those not familiar with login.launchpad.net is very confusing when trying to access branches via codebrowse
<lifeless> an openid feature
<lifeless> :>
<cody-somerville> hmm... but logging out of login.launchpad.net and logging in as a new user doesn't fix it
<cody-somerville> how do I 'logout' of codebrowse?
<lifeless> there is a logout button on the launchpad site
<lifeless> use it
<cody-somerville> but I'm logged in as the correct user on launchpad already? I have to relogin again?
<wgrant> The launchpad.net logout button will you log you out of both launchpad.net and bazaar.launchpad.net.
<wgrant> (by a hideous redirect via bazaar.launchpad.net)
<cody-somerville> ah
<cody-somerville> k
<wallyworld_> #@%!@%@!&^ qastaging. every url i navigate to times out :-(
<wgrant> Probably bug heat.
<wallyworld_> wgrant: i'm having trouble figuring out how to get to a page that let's me see (and edit) the Build-Depends field for any particular package. can you point me in the right direction?
<wgrant> wallyworld_: It's in the branch.
<wgrant> wallyworld_: Edit debian/control.
<wallyworld_> .me looks
<wgrant> wallyworld_: Hm, nevermind, staging is too old anyway.
<wgrant> We'll have to do it on mawson.
<wallyworld_> wgrant: by "the branch", do you mean code.qas.lp.net/project or code.qas.lp.net/ubuntu/+source/xxxx or ??
<wgrant> wallyworld_: It needs to be a branch with packaging metadata. lp:ubuntu/hello, for example.
<wallyworld_> wgrant: so i go to lp.net/ubuntu, search for a project eg firefox, and then go to lp.net/+source/firefox. is that correct?
<wgrant> wallyworld_: Easiest way to get the branch is just 'bzr branch lp:ubuntu/hello'
<wallyworld_> wgrant: fair enough. i was curious though how to find it via the gui.
<wgrant> I don't know how to search for packages effectively.
<wgrant> I always go straight to https://launchpad.net/ubuntu/+source/SOMESOURCE
<wallyworld_> wgrant: right. i got to that by seaching from lp.net/ubuntu. it seems to work well if you know the project you are looking for
<wallyworld_> wgrant: so mawsom = dogfood right? but do we have access to it's mailbox?
<wgrant> wallyworld_: It sends mail to the staging mailbox.
<wallyworld_> ah ok
<wgrant> wallyworld_: I've scheduled a few builds of various sorts.
<wgrant> Will probably take like half an hour to build them.
<wgrant> At least.
<wgrant> rubidium is slow :(
<wallyworld_> wgrant: ok. i was just messing with a local branch of ubuntu/hello
<wallyworld_> i'll see what turns up in the inbox
<wgrant> Subject: [DOGFOOD] [recipe build #36909] of ~wgrant hello-lololol-daily in natty: Dependency wait
<_mup_> Bug #36909: clicking on bug filters does nothing <lp-foundations> <Launchpad itself:Triaged by bradb> < https://launchpad.net/bugs/36909 >
<wgrant> wallyworld_: ^^
<wallyworld_> wgrant: looks like it worked :-)
<wallyworld_> thanks
<wgrant> And there was no notification from the succesful build.
<wgrant> So we are good.
* StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | https://code.launchpad.net/launchpad-project/+activereviews
<StevenK> wgrant: When you're back, can you look at https://code.launchpad.net/~stevenk/launchpad/copies-use-overrides/+merge/61195 again? I think I've addressed almost all of your concerns.
<wgrant> à² _à²  massive commits again
<cjohnston> StevenK: have a moment to look at a couple of my merge proposals?
<lifeless> mwhudson: thanks for that feedback
<lifeless> good questions
<mwhudson> oh good, i was worrying i rambled a bit :)(
<wgrant> You rambled a bit, but it was still excellent :)
<wgrant> Anything like this is bound to be rambly.
<StevenK> cjohnston: Sure, link me up, and I'll review them after I have reviewed my lunch.
<wgrant> StevenK: Reviewed.
<StevenK> wgrant: ZCML does not like inheritence
<StevenK> I played with it last night
<wgrant> StevenK: Upsetting.
<wgrant> Still, IBaseOverridePolicy -> IOverridePolicy.
<StevenK> wgrant: No argument from me about that
<cjohnston> StevenK: https://code.launchpad.net/~chrisjohnston/launchpad/728192/+merge/61046 https://code.launchpad.net/~chrisjohnston/launchpad/627628/+merge/61055
<cjohnston> https://code.launchpad.net/~chrisjohnston/launchpad/197793/+merge/61053
* jtv changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: StevenK, jtv | https://code.launchpad.net/launchpad-project/+activereviews
<jtv> hi wallyworld_, I'm in
<wgrant> 196 Critical bugs
<wgrant> Yay
<jtv> wgrant: less talking, more fixing or you don't get fed
<wgrant> But archiveuploader killed my cat.
<jtv> Okay, you've got me.  How?
<wallyworld_> jtv: hello
<lifeless> jtv: hi
<jtv> hi
<lifeless> jtv: I saw your comment yesterday in irc you were offline by the time I saw it
<jtv> cool, thanksâI was just reading the email thread
<StevenK> cjohnston: All of those MPs are Approved by Henning?
<cjohnston> StevenK: thats correct
<StevenK> cjohnston: So why do you need me? :-)
<cjohnston> He hasn't done anything with them since approving them, so I wasn't sure if he wasn't able to merge or something
<StevenK> cjohnston: Ah. I'll approve all 3 and toss them at ec2
<StevenK> cjohnston: If you want to set a commit message on all three?
<cjohnston> done
<StevenK> cjohnston: The commit message on 728192 isn't really clear. Perhaps "IArchive:+index no longer has a form in a heading." ?
<cjohnston> ok
<lifeless> statik: thats quite an endorsement for the proposal.. thanks
<nigelb> oh no, my commit had a build failure :(
<wgrant> nigelb: An ec2 failure?
<wgrant> That's a "Test results: FAILURE" email.
<nigelb> wgrant: Test results: 645825-ui-example => devel: FAILURE
<StevenK> cjohnston: Will you be around in roughly four hours?
<nigelb> wgrant: yeah, test failure
<cjohnston> StevenK: no.. I need to go to bed soon. :-/
<wgrant> nigelb: How many errors?
<nigelb> 6 errors
<wgrant> Is the problem clear?
<StevenK> cjohnston: Fair enough -- all three of those branches are currently having ec2 instances created for them, you'll get e-mails from them in about four hours telling you what happened.
<cjohnston> cool... t
<cjohnston> t
<cjohnston> y
<StevenK> Haha
<nigelb> wgrant: looks like "AttributeError: 'TestProductSeriesHelp' object has no attribute 'oopses'"\
<StevenK> I've seen that before ...
<StevenK> Er
<mwhudson> that could be a setUp method failing to upcall
<StevenK> I've *not* seen that before
<nigelb> want a full paste of the entire mail?
<nigelb> I didn't have a setUp method.
<wgrant> nigelb: That would be helpful.
<StevenK> wgrant: Can you also glance at https://code.launchpad.net/~rvb/launchpad/distro-overlay2-bug-758908-dependencies/+merge/61110 please?
<nigelb> wgrant: http://paste.ubuntu.com/609335/
<StevenK> Suspcious
<wgrant> I have seen this before. It was something fairly obscure.
<wgrant> But I cannot recall the details.
<StevenK> Right, running ec2 land & in a for loop was a stupid idea.
<nigelb> a for loop?
<wgrant> Oh.
<StevenK> A shell for loop. for i in foo bar  ; do echo $i ; done
<wgrant> nigelb: You call your superclass' setUp method in your test method.
<wgrant> That's *not* going to go well.
<wgrant> 28+        super(TestProductSeriesHelp, self).setUp()
<wgrant> Delete that line.
<nigelb> wgrant: ah
<nigelb> mwhudson: ah, a setUp method failing to upcall. Now I get what you meant.
<nigelb> wgrant: commit and push again?
<wgrant> nigelb: Right.
<wgrant> In this case it was setUp doubly upcalling, so the OOPS handler was registered twice.
<wgrant> Then tearDown unregistered it only once.
<mwhudson> ah so my crystal ball was only a little cloudy
<jtv> lifeless: a concern about service fakes... you mention running the real service's tests against the fake.  But the gains have to come from somewhere; in the FakeLibrarian for instance we had to sacrifice multi-process access.  Won't a single canonical fake for a service imply something very close to the real thing?
<wallyworld_> lifeless: (or someone else smarter than /me): there's a bug report with an Object NotFound oops for urls of the form "translations.lp.net/inactiveproject" and "bugs.lp.net/inactiveproject" yet when I test that on lp.net the page renders fine. any idea why?
<wgrant> wallyworld_: ~registry can see disabled projects.
<nigelb> wgrant: pushed again --> https://code.launchpad.net/~nigelbabu/launchpad/645825-ui-example/+merge/61175
<wallyworld_> wgrant: oh ok. so on the page where such links are rendered, we may want to see if the user is a member of ~registry before we decide not to print the links?
<wallyworld_> of do we just want to not print them in all cases?
<wgrant> wallyworld_: I'm not sure that there's value in showing them to ~registry.
<wallyworld_> easier to do the latte
<wallyworld_> latter
 * jtv goes for a latte
<wallyworld_> cool. so i'll take the easy road :-)
<wallyworld_> jtv: 2 sugars for mine please
<jtv> wallyworld_: here you go â â
<wallyworld_> lol
<wallyworld_> but where's the sugar?
<nigelb> hehe
<nigelb> wgrant: will you be landing it in ec2?
<wgrant> nigelb: I will.
<nigelb> wgrant: Thanks :)
<wgrant> nigelb: The instance is running now.
<nigelb> wgrant: great, thanks :)
<nigelb> aha, UDS photos are up.  There's a lot of photos of that guy with blue hair :p
<wgrant> I haven't been able to find one yet.
<wgrant> Do you have a link?
<wgrant> I went looking last week.
<wgrant> But failed.
<nigelb> http://photos.pixoulphotography.com/Events/UDS-Oneiric/17103699_kzzLF6/1/1296058796_HdrLgVm#1296058440_N4fmvNv
<nigelb> wgrant: I have a bunch in my fb album, but these are much better
<wgrant> Subtle.
 * mwhudson goes looking for the pictures of beuno harassing charlieS
<nigelb> haha
<beuno> it was more like stalking
<wgrant> Oh?
<mwhudson> beuno: once you'd pinned in the corner with your rapidly waving hands, it wasn'
<mwhudson> beuno: once you'd pinned in the corner with your rapidly waving hands, it wasn't stalking any more :)
<beuno> true
<mwhudson> pinned HIM
<mwhudson> i should give up on typing for today
<mwhudson> can't find any photos of that anyway
<beuno> it started off as stalking, then came the beer
 * StevenK grumbles at publishBinaries
<wgrant> StevenK: Hm?
<wgrant> It fit its original purpose very well.
<StevenK> It's ignoring the component I'm passing it
<wgrant> It probably overrides it to main if it's a PPA.
<StevenK> (Which it isn't)
<wgrant> That is probably no longer appropriate.
<wgrant> It probably is.
<wgrant> What's it doing?
<StevenK> The copied binaries continue to keep the original binaries component.
<wgrant> I doubt that's publishBinaries' fault.
<wgrant> Unless you've touched it in bad ways.
 * StevenK dumps the query it runs
<StevenK> Bleh, which doesn't help
<wgrant> It's a very pretty query :)
<LPCIBot> Project windmill-db-devel build #288: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-db-devel/288/
<lifeless> jtv: much of the cost of real services from integrity or encryption
<lifeless> jtv: e.g. fsync, transactions, multiuser syncronisation
<lifeless> jtv: a network fake doesn't need to do any of those, can pretend to do gpg etc
<jtv> lifeless: but then we'd still have to exempt the fakes from those aspects of testing, right?  Maybe separate "interface" tests from "quality of implementation" tests?
<StevenK> It's so comforting that windmill continues to utterly fail on Jenkins
<wgrant> StevenK: They're all bitrot failures.
<wgrant> 7 or so are easy to fix.
<lifeless> yes, but then how can you tell if a db fsyncs something *when you're talking over the network to it* ?
<lifeless> so the external contract really can't talk about those aspects anyway
<jtv> Ah, so that's already not a part of the service's tests as such.
<lifeless> we'd want 3 sets of tests of a service
<lifeless> external contract
<lifeless> details-of-the-fake-test-support-api
<StevenK> wgrant: :-(
<lifeless> details/internals-of-the-real-version
<lifeless> this is what bzr has
<lifeless> and it works very very well
<StevenK> wgrant: And publishBinaries() was doing the right thing after all
<wgrant> StevenK: Of course.
<lifeless> the external contract tests run against both implementations
<lifeless> the other two sets against only one
 * StevenK bites back a barb
<StevenK> wgrant: And I didn't address the arch-indep bit because I have no idea how to
<StevenK> Hm, perhaps that will work
<StevenK> wgrant: I can't have cBO just return the archtag passed in?
<wgrant> StevenK: You can.
<wgrant> If you can reliably map back to it.
<StevenK> The bother is returning None if it's arch-indep
<StevenK> When I can't trust the destination, and all I have is the BPN
<StevenK> I'm able to deal in copyBinariesTo(), since I have the source BPPH, and that is trust-worthy
<wgrant> Right. You may recall that I suggested a strategy last week to overcome that.
<wgrant> Joining against DAS.
<StevenK> wgrant: Right, and that works fine for returning the archtag, but it won't return None if it's arch-indep.
<wgrant> StevenK: It will if you make it return None.
<StevenK> wgrant: Uh? How can I make Storm do that?
<wgrant> StevenK: If it's arch indep, add a DistroArchSeries.id == None constraint.
<wgrant> Hmm, although that may need to be in a join condition. Difficult.
<StevenK> And calculate_target_das() already tosses back the NAI
<wgrant> So?
<StevenK> It isn't making any sense how to implement this.
<wgrant> You constrain BPPH.distroarchseries to NAI.
<wgrant> But you don't actually join against DistroArchSeries yet.
<wgrant> I suggest that you do a left join against DistroArchSeries such that you get the archtag back for arch-dep, and None back for arch-indep.
<StevenK> make_package_condition() already does BPPH.distroseries == das
<wgrant> Yes, but it doesn't join against DAS.
<wgrant> It just compares the fk with a precalculated value.
<wgrant> lifeless: Could you please try it on another browser, then?
<wgrant> It is not a bug unless it occurs on browsers that don't have unstable daily build warnings on them.
<StevenK> FROM LEFT JOIN ... WTF, Storm?!
<wallyworld_> jtv: translations question concerning recent activities on a person's translation page (getTranslationHistory). i'm trying to find a test for this. no luck so far, just about finished running all tests under translations/*. i want to find a test which calls into ActivityDescriptor.  But more to the point, i need to find a way to filter getTranslationHistory so that it ignores POFiles associated with inactive projects.   if i can
<wallyworld_>  navigate to the pofile sourcepackage->product attribute i may be able to check for is_active but the product attribute desc says "The best guess we have as to the Launchpad Project...". Best guess? Is there a definitive association?
<StevenK> wgrant: I'm clearly missing something vital: http://pastebin.ubuntu.com/609354/
<wgrant> StevenK: You have a left join there.
<wgrant> But you're not joining onto anything.
<wgrant> You're just joining DistroArchSeries onto nothing.
<StevenK> So I need BPPH, DAS, condition?
<wgrant> Roughly.
<jtv> wallyworld_: use POFile.potemplate to get to the POTemplate.  From there it's either POTemplate.product, or POTemplate.{distroseries, sourcepackagename}.
<wallyworld_> jtv: thanks. that should be doable in storm. any idea why there appears to be no test coverage for the recent activies stuff on the view? there's a doc test for person.translation_history but nothing for the rendering of that info onto the page. or am i missing something?
<jtv> wallyworld_: I was almost certain there was.
<wallyworld_> jtv: yeah, i would have thought so. but a complete run of all translations/* tests didn't hit my breakpoint :-(
<jtv> wallyworld_: let me just look at the code you're talking about...
<wallyworld_> jtv: thanks. ideally i wanted to write or extend an existing test and then do the code
<jtv> Naturally.
<lifeless> wgrant: ajax log?
<wgrant> lifeless: Check what the vocab AJAX request returns.
<StevenK> wgrant: I think I have the join working. But how to get it to return None?
<wgrant> StevenK: That's where my plan falls apart slightly. You may need to have it in the join condition, not the where clause.
<wgrant> 'cause you don't get a NULL row if there are any matches.
<wgrant> Always disliked that inconsistency.
<StevenK> wgrant: But the DAS itself is in *candidates?
<jtv> wallyworld_: can't find it eitherâand I'm pretty sure I spent quite some time writing up tests for this in Barcelona.
<StevenK> And is already the NAI by that time anyway
<wallyworld_> jtv: well that sucks balls :-(
<jtv> wallyworld_: hope I didn't end up forgetting to "bzr add" the tests or something...
<wallyworld_> jtv: so you're off to check your hard drive? :-)
<jtv> Yes, it sucks balls and circumstances were difficult due to time pressure etc.
<wallyworld_> for uncommitted branches?
<jtv> Nope, it's not on this hard drive, the backup drive this would be on is probably one that died, or maybe it's on the predecessor which also died, and the machine itself is behind a UPS that had a nervous breakdown and I still have to figure out whether it's really the power or the UPS itself.
<jtv> So not much chance of that.  :(
<jtv> wallyworld_: we could probably dig up the MP, but it's not likely to be worth the trouble.  I fear this will take new tests.
 * wallyworld_ sobs siliently
<jtv> Can you sob _re_siliently?  That'll help.
 * wallyworld_ can't type
<spm> jtv: there's a request from danilo up on lps, is that still relevant do you know?
<wgrant> It is.
<wgrant> He said was going to get to that when he was on maintenance.
<wgrant> Which is next week.
<spm> ah k, we'll let it ride for now then; ta
<StevenK> wgrant: I still think I'm missing something. http://pastebin.ubuntu.com/609367/
<StevenK> gmb: nigelb bought up the failures here, and wgrant helped him fix it.
<StevenK> gmb: It's currently running through ec2 again.
<nigelb-work> gmb: I did remove the super().setUp and wgrant landed it in ec2 again
<StevenK> It's probably got another 3 hours to go
 * StevenK prods wgrant more
<nigelb-work> how many hours does it take anyway? o.O
<StevenK> nigelb-work: About 4
<wgrant> ~4h
<nigelb-work> so, its about half way through by now I guess
<wgrant> $ utilities/ec2 list
<wgrant> 645825-ui-example => devel  [OK]     (up for 2:21:13.892062)
<wgrant> Summary: running: 1
<wgrant> Yup.
<nigelb-work> btw, there were one or two easy bugs I thought could be just closed off
<nigelb-work> like there was a bug which said, If LP is linking to bugs not existing and showing a tool tip that it does not exist, then it shouldn't link the bug at all
<nigelb-work> But I don't think we show any such tooltip anymore, at least I didn't see it.
<nigelb-work> that's bug 4595 (yeah, OLD)
<_mup_> Bug #4595: Don't auto-linkify non-existent bug reports <easy> <lp-web> <tales> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/4595 >
<nigelb-work> and another one, bug 337848, I can't find examples of what's mentioned in the bug report
<_mup_> Bug #337848: IRC links on profile page are asked the wrong way <easy> <irc> <lp-registry> <ui> <users> <Launchpad itself:Triaged> < https://launchpad.net/bugs/337848 >
<wgrant> lifeless: Hah.
<wgrant> Have you considered that 123 might be a few too many teams?
<wgrant> I wonder what they all are.
<lifeless> wgrant: no
<wgrant> I was only in 95.
<wgrant> Greated 25 new ones, fine.
<lifeless> poor form
<wgrant> Created one more.
<wgrant> Boom.
<wgrant> undefined.
<wgrant> Does not like more than 20 pages, apparently.
<lifeless> ha ha ha ha ha ha ha
<lifeless> wgrant: browser version my shiny metal ....
 * StevenK gives up on arch-indep
<StevenK> Too hard
<wgrant> lifeless: Nobody else is insane enough to have that many teams :)
<lifeless> wgrant: many folk are
<wgrant> And it hadn't been seen outside a daily build of a browser...
<StevenK> wgrant: Are you going to push back on the arch-indep thing?
<wgrant> StevenK: Not if you can prove to me that it's OK.
<StevenK> And the tests don't do that?
<wgrant> No, those tests don't cover much at all.
<StevenK> They're the 3 use cases we discussed?
<wgrant> They are the three basic cases, yse.
 * StevenK pushes up 5 revs
<wgrant> !!
<wgrant> lifeless: There are 42 people with 120 or more teamparticipations.
<wgrant> Close enough to nobody else :P
<lifeless> wgrant: I'm not even top 10
<wgrant> Yes, but your Person.id is 2, so all suggestions of exceptionality are valid and reasonable.
<nigelb-work> who's 1?
<nigelb-work> sabdfl?
<wgrant> Yes.
<lifeless> yes
<wgrant> sabdfl is #14
<wgrant> lifeless #24
<wgrant> Not good enough.
<lifeless> wgrant: #9
<lifeless> for sabdfl
<wgrant> "SELECT person.name, COUNT(*) FROM teamparticipation JOIN person ON person.id = teamparticipation.person GROUP BY person.name HAVING COUNT(*) > 120 ORDER BY COUNT(*) DESC;" was what I did.
<lifeless> yeah
<lifeless> 149
<lifeless> is what I see
<StevenK> wgrant: There, 5 more revisions on the MP. Be shocked.
<wgrant> StevenK: I am shocked and saddened.
<StevenK> Saddened?
<wgrant> Saddened.
<StevenK> Why?
<wgrant>  sabdfl          |   152
<wgrant> StevenK: I will need to find something else to harrass you about.
<wgrant> If you've started committing regularly.
<StevenK> Haven't you harrassed me enough about this branch?
<wgrant> It's a very dangerous branch.
<wgrant> So no.
<StevenK> My frustration is peaking
<wgrant> In its current state it will break pocket copies in at least two ways.
<wgrant> Your frustration may peak, but it still won't land :)
<StevenK> I'm willing to state that it needs more tests, but if you're just going to say "It's dangerous" and not point out which particular cases need more care, then I'm just going to get more frustrated.
<wgrant> I pointed out some of the cases in my first comment.
<StevenK> And reviewing a branch isn't supposed to be a battle of wills.
<wgrant> It's not a battle of wills.
<wgrant> So, my worries are:
<wgrant>  1) This is now used in copies, forrealz.
<StevenK> At the moment it feels like it.
<wgrant>  2) It only finds overrides within the pocket, which means that pocket-copies eg. from -proposed to -updates will end up in the wrong place.
<StevenK>         # When we copy source/binaries from one pocket to another, their
<StevenK>         # overrides are respected.
<wgrant>  3) I don't know how well it's going to handle partner and copy archives and stuff.
<StevenK> ^ That is the case you're concerned about?
<wgrant>  4) This changes a lot and could have severe consequences on several untested processes, so no caution is undue.
<wgrant> "their overrides are respected" is unclear, but that could be it.
<StevenK> wgrant: I don't care about landing, I care about personally feeling that I'm making progress. At the moment it feels like The Immovable Object versus The Unstoppable Force
<wgrant> You are making progress. But this is a big change with a lot of cases that need to be covered before it's safe.
<StevenK>         # When we copy source/binaries from one pocket to another, the
<StevenK>         # overrides are unchanged from the source publication overrides.
<wgrant> I have made specific statements about the things that concern me.
<wgrant> StevenK: It may be better to phrase (and code) that as just picking the latest overrides, regardless of pocket.
<LPCIBot> Project devel build #728: FAILURE in 14 min: https://lpci.wedontsleep.org/job/devel/728/
<StevenK> Uh oh
<StevenK> bzrlib.errors.InvalidHttpResponse: Invalid http response for https://xmlrpc.launchpad.net/bazaar/: Unable to handle http code 502: Bad Gateway
<wgrant> That's not meant to happen when there's no rollout going on.
<lifeless> its not meant to happen period
<stub> What does it mean if a derived distro is an overlay over a parent distro ?
<wgrant> lifeless: Wasn't it an accepted downside of the current nodowntime process?
<StevenK> stub: It inherents all of the parent's packages, except for those are explicity published in it.
<StevenK> stub: Think PPA, except for Distributions
<wgrant> stub: The derived series doesn't have the parent's packages in its own archive. Its builds' sources.lists refer to the parent series' archive.
<wgrant> Like PPAs, right.
<lifeless> wgrant: interrupted requests yes, bad gateways no
<wgrant> lifeless: Isn't that a bad gateway?
<stub> StevenK: So what does it means if it doesn't have that set? I had assumed that behaviour for derived distros.
<wgrant> lifeless: It's not a 503 or a 504, so it's probably a 502.
<StevenK> stub: If it isn't an overlay, it is just a derived series
<stub> Why would you have a derived distro that doesn't inherit the parents packages?
<StevenK> stub: Because you only want a subset
<StevenK> For instance
<stub> So you would have to manually specify all the packages to pull in? Whitelist rather than blacklist?
<StevenK> Yes
<stub> ok.
<lifeless> stub: debian -> ubuntu is non-overlay
<lifeless> stub: ubuntu -> oem is overlay
<stub> I see.
<lifeless> with overlays clients have both archives in their sources.list
<lifeless> with non-overlay they have only the derived distro
<stub> Will a PPA become a non-overlay derived distro?
<wgrant> An overlay derived distro.
<StevenK> With multiple parents too, whee
<lifeless> a single parent overlay derived distro is roughly equivalent to a PPA
<lifeless> but with better management of packages
<stub> Cool. So we could, say make our own personal Ubuntu variant overlay ubuntu, overlay the Launchpad PPA, Bazaar PPA etc.
<lifeless> it should probably nuke all ppas in favour of such overlays eventually
<wgrant> lifeless: That's Julian's intention.
<StevenK> It's also a long-term goal
<stub> YouBuntu :-)
<StevenK> stubuntu
* StevenK changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: jtv | https://code.launchpad.net/launchpad-project/+activereviews
<adeuring> good morning
<henninge> Hi adeuring! ;)+
<henninge> s/+//
<adeuring> moin henninge
<stub> So I just approved a patch to the DistroSeriesParent table, which is not yet in use I think. The new columns - did we not realize they were needed when we initially created the table, or do we need to tweak something to avoid unnecessary landings on db-devel ?
<StevenK> stub: Julian rushed the DistroSeriesParent creation
<StevenK> Effectively
<lifeless> stub: http://www.readwriteweb.com/cloud/2011/04/5-graph-databases-to-consider.php
<rvba> stub: I think the whole parent/child overlay thing was not completely thought through when the DSP table was created.
<stub> k. As long as everyone is aware we need to do the db stuff upfront when possible. Was wondering if two people got tasked with different parts of the same feature and we ended up with two patches in different cycles because of that.
<stub> Right.
<jtv> The requirements for multiple parents and all the rest weren't discovered until we'd already started developing.
<jtv> The feature's design got a bit hectic as a result, and we have some grand plans for simplifying it but we can't afford to do that now.
<stub> Yeah, I was expecting we learnt they were needed part way through.
<stub> I don't think we can avoid that entirely.
<stub> lifeless: Might want that sooner than later - losas raising disk space warnings again and we can't rely on the SAN arriving in time for that.
<lifeless> stub: what service are they raising that on ?
<spm> wildcherry, but all
<stub> all three db nodes
<lifeless> ah
<lifeless> where are we at on the branchrevision shrinkage
<stub> chokecherry has space, but two copies of the database. If we ran out now, I'd need to switch to single master running on chokecherry.
<StevenK> How can I get bzr shelve to show what is stored in an id?
<wgrant> bzr unshelve --preview ID
<stub> lifeless, jtv: I think we are down to one remaining glitch in hacking the internal tables to drop the id column. There might be a redundant index we can drop right now.
<jtv> That'd be nice.
<jtv> What's the glitch?
<stub> lifeless, jtv: If we want, we might be able to punt this to 3rd party support and let them chase through the hidden dependencies in the catalog.
<lifeless> how much space are we expecting to save
<jtv> stub: sounds good... may send them into a panic though.
<jtv> lifeless: order of 20GB last I looked.
<lifeless> if its enough to save us, then we should escalate it, yes.
<stub> jtv: IIRC the index we are using as the new primary key is still linked to a unique constraint on the table. That needs to be broken.
<stub> jtv: We end up with a database schema that can be dumped, but the restore fails.
<lifeless> win
<stub> jtv: https://code.launchpad.net/~stub/launchpad/drop-branchrevision-id/+merge/55480
<stub> lifeless: I think I'd get them to go over it anyway - more eyes, less chance of blowing off our foot.
<lifeless> in this case, entire leg
<lifeless> :)
<jtv> stub: any particular part you'd like me to look at?
<stub> jtv: If you have time, run that patch, do a dump restore, and see if the problem that demonstrates is obvious to fix. I think you are more familiar with these internals as you have talked it over more with the core devs. Maybe it is just a silly mistake I introduced working from your notes?
<StevenK> stub: Your patch number is 62, but you insert 99 into the DB
<jtv> stub: I don't have that much time right now :(  Especially with the holidays I'm way behind on Feature stuff.
<stub> StevenK: There is also deliberate syntax error in there - I don't want this to accidentally land anywhere :)
<StevenK> stub: Heh, I missed that
<stub> lifeless: We can also consider switching the data partition to RAID 5 for the extra space. Need to benchmark on similar hardware to see if that copes with our current write load (I suspect it would).
<lifeless> I seem to remember a few GB we can save by repacking some indices
<lifeless> I'll also talk with elmo about options on thursday
<lifeless> neo4j.org does look interesting
<LPCIBot> Project windmill-devel build #99: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/99/
<poolie> gmb, hi
<poolie> i liked your post
<poolie> could i persuade you to put it on the lp blog?
<gmb> poolie: Thanks. I've already got that on my todo list for today.
<poolie> :)
<mrevell> Morning
<poolie> gmb it's so great to see new non-canonical contributors
<poolie> and such an advantage for launchpad compared to the other leading brands
<nigelb> \o/
<nigelb> It worked :)
<gmb> Definitely
 * nigelb hugs gmb, wgrant, and StevenK :)
<gmb> :)
<StevenK> nigelb: You're welcome! Wait until your change is on production. :-)
<wgrant> With a bit of luck that will be tomorrow morning.
<nigelb> \o/
<nigelb> Now, on to find another candidate bug to fix.
<wgrant> Faster!
<jml> soren: sort of.
<jml> soren: we generally try very hard to help GMail users, they make up a huge percentage of our users
<jml> soren: in this case, a lot of the web-side filtering is a work-around for GMail brokenness
<wgrant> Same with all the textual cruft in the emails :/
<soren> I see.
<henninge> err, what is this?
<henninge> description = IBug['description']
<henninge> never seen an Interface used like that.
<wgrant> henninge: Interfaces are not classes. Their members appear as items, not attributes.
<henninge> wgrant: but what does this give me?
<henninge> There is no instance involved
<henninge> I didn't know that, btw.
<wgrant> henninge: It should give you the interface field.
<henninge> ah, obviously
<henninge> so that is written confusingly. It should not call the value "description" but "description_field"
<henninge> wgrant: thanks
<wgrant> Hmm? Why?
<wgrant> Oh, right.
<wgrant> Yeah, I guess.
<LPCIBot> Project windmill-db-devel build #289: STILL FAILING in 1 hr 11 min: https://lpci.wedontsleep.org/job/windmill-db-devel/289/
<jtv> rvba: Q about the +localpackagediffs page
<jtv> rvba: for various reasons we'll want to disable or replace the checkboxes for some of the DSDs we display.
<rvba> jtv: yes?
<jtv> Do you have any quick ideas of where in the code to look for those?
<jtv> (This is where advanced frameworks always get to me... you can't grep because it's all implicit)
<rvba> jtv: right now this is controlled by canPerformSync (grep for that)
<jtv> rvba: excÃ©llent, thank you!
<rvba> but of course it's a global thing.
<jtv> How global?
<jtv> I may affect Inuits when I mess with it?
<rvba> ;) it either all the checkboxes are displayed ... or none.
<jtv> Oh!
<jtv> _That_ global.
<jtv> Then I can't use that right now.
<jtv> But canPerformSync will probably still get me closer to where I need to be.
<jtv> And perhaps save a few Inuits.
<rvba> Perhpas you could compute the ids of the DSD for which the checkbox should not be displayed in the view with a method to query that, then use the method in the template.
<jtv> Just chatted with J and we both had examples where the checkbox shouldn't be displayed: child version > parent version, and package is already being sync'ed.
<rvba> Right.
<jtv> I'd rather annotate the DSDs.  There may be more than just a boolean: when there's a sync job pending, I'd like to replace the checkbox with a "please wait" clock.
<rvba> jtv: I know I don't have to tell you this ... but beware of the dreaded one query per DSD thing ;).
<jtv> Oh yes, thank you, this database stuff is all very new to me.  :-)
<rvba> jtv: ;)
<jtv> (This morning I found myself wondering about prefetching Zope navigations in SQL, which should tell you something about how much I care!)
<rvba> jtv: anyway, greping for canPerformSync will give you all the right spots.
<jtv> You know: https://launchpad.net/ubuntu/natty/ could fetch Ubuntu and Natty in 1 query.
<jtv> That's a great help.  Thanks again!
<rvba> jtv: Glad to help.
<jtv> allenap: while I'm at it, maybe I should just fix IPlainPackageCopyJob.getActiveJobs to check for job status?
<rvba> (jtv: I think allenap is not here today.)
<jtv> oh
<gmb> Vexed. Going to get food.
<poolie> jtv , hi
<poolie>  jtv, i was wondering if you could pilot james's long-outstanding approved mp
<jtv> poolie: what MP is that?
<poolie> it' the top one on activeeviews
<poolie> https://code.launchpad.net/~james-w/launchpad/more-matchers/+merge/32057
<jtv> thanks
<poolie> nearly 6m old
<jtv> I hope it'll still work then!
* jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<jtv> poolie: I'm a bit under the weather and not thinking too clearly... all it seems to need now is to be landed, right?
<poolie> apparently so
<poolie> tested and landed that is
<LPCIBot> Project windmill-devel build #100: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/100/
<jtv> OK
<poolie> thanks
<jtv> poolie: riddled with conflicts now.  :(
<jtv> Thanks for picking that up though.  We need to get used to checking for this.
<poolie> yes
<poolie> if nly there was a page that showed you all the outstanding reviews :)
<poolie> actually the +mps page could be better about showing ones that need help
<jtv> poolie: this is weird... when I try to merge that branch into a fresh devel, I get conflicts on files that the branch (going by the MP diff against devel) did not touch.
<poolie> that is strange
<poolie> i'll try it when my meeting's over
<poolie> there's also one from cjwatson that may now be able to proceed
<poolie> would be worth pinging it
<wgrant> poolie: That's waiting on python-apt fixes from Platform.
<wgrant> And jelmer's has a few test failures that I was going to look at this week.
<cjwatson> yeah, I need to check with mvo about that
<jtv> thanks poolie...  there's nothing more I can do today I'm afraid.
<poolie> just wasn't sure if it was still blocked
<poolie> i guess the conflicts may be that he newly added lib/lp/soyuz/testing?
<poolie> i'll merge it and see what i can do
<wgrant> Probably.
<jtv> Maybe I _should_ however take the time to file bugs for suspend, hibernate, battery time estimation, and Tomboy not saving my data for hours on end.  :(
<jtv> They combine so neatly into total data loss.
<barry> lifeless or flacoste this page times out for me 100% of the time now:
<barry> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=python27
<poolie> james_w: do you think you'll come back to this or do you want it piloted?
<barry> please, is there anything you can do to help me?
<james_w> it would be great if someone could land it for me
<wgrant> barry: Hm, worked second load for me.
<barry> wgrant: dang
 * barry rides the reload button
<gmb> barry: Annoyingly for you, works first time for me.
<wgrant> Maybe you have more teams than me or something.
<barry> could be, yeah
<wgrant> 8.49s, so it's very close.
<barry> wgrant: i'll keep hammering it.  maybe i'll get lucky and hit a warm cache ;)
<wgrant> barry: Do you have an OOPS ID?
<wgrant> We may work out it's just over the threshold and bump that page by a couple of seconds.
<wgrant> lifeless suggested it was far worse.
<wgrant> But the fact that it's a few hundred ms under for me suggests he may have ben mistaken.
<barry> (Error ID: OOPS-1964EA274)
<barry> and hey, a reload just got me the page!
<wgrant> Thanks.
<barry> wgrant: thanks
<wgrant> Hm, we should just increase the limit.
<wgrant> The main query was only 7.5s.
<wgrant> It was just doing the final rendering when it was killed :(
<barry> wgrant: related, if i do an advanced search to get also fixed released and tagged python27 i get another timeout:
<barry> (Error ID: OOPS-1964DV295)
<barry> https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter
<barry> er, http://tinyurl.com/6xyzrf3
<bigjools> our urls rock
<wgrant> 9s query :(
<jml> bigjools:
<jml> https://bugs.launchpad.net/launchpad/+bug/325982
<_mup_> Bug #325982: Search URL is long and hard to paste <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/325982 >
<bigjools> yeah I think I've seen that before
<bac> sinzui: i should know this but don't remember, did stevenk graduate as a reviewer?
<bac> oh, i guess i could ask StevenK directly...
* danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: danilos | https://code.launchpad.net/launchpad-project/+activereviews
<henninge-lunch> is the LP.cache meant to be included on anonymous pages?
<henninge> I am not sure what this is trying to achieve:
<henninge> <tal:cache condition="view/user|nothing"
<wgrant> That doesn't seem to make very much sense.
<wgrant> It would seem reasonable to include it sometimes, but I can't think of anything that needs it now.
<henninge> I think it is supposed to mean "Don't complain about missing user attribute, just make the condition False."
<henninge> wgrant: would this be correct:
<henninge> <tal:cache condition="view/user|false"
<henninge> ?
<wgrant> I don't think so.
<henninge> hm
<wgrant> 'nothing' is the correct thing to use there.
<wgrant> If view/user might not exist.
<henninge> but it seems to evaluate to true always
 * henninge checks  that
<wgrant> It should be None for anonymous requests...
<bac> hi mrevell
<mrevell> Hey bac
<danilos> anyone know anything about this failure on buildbot: https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/958/steps/shell_6/logs/summary?
<wgrant> rabbitmq failed.
<wgrant> Spurious.
<wgrant> Already forced.
<wgrant> I will talk to lifeless tomorrow and probably disable it.
<wgrant> Since it has been happening a lot.
<henninge> wgrant: I read that wrong. The LP.cache["context"] is unconditional. The tal:condition above works correctly.
<danilos> wgrant, ok, cool, thanks
<deryck> henninge, ping for standup
<henninge> yup
<henninge> deryck: trouble ...
<deryck> henninge, ok, we'll start and join us when you can
<wgrant> bigjools: Sadly, security updates sometimes do add new packages (thing Firefox and co.)
<wgrant> bigjools: Also, I suggested this yesterday or so:
<wgrant> 15:26 < wgrant> StevenK: I evisage that primary archives will use a chain of UnknownComponentOverridePolicy and FromExistingDestinationOverridesPolicy, while PPAs might use MainOnlyOverridePolicy and FromSourceOverridesPolicy, and copy archives might use FromSourceOverridesPolicy and FromExistingPrimaryOverridesPolicy
<wgrant> 15:27 < wgrant> Er, last case is the wrong way around. FromExistingPrimaryOverridesPolicy and FromSourceOverridesPolicy
<wgrant> Which seems to be a similar sort of idea to your PPA main overriding thingy.
<wgrant> I am glad we are thinking along similar lines.
* abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: danilos, abentley | https://code.launchpad.net/launchpad-project/+activereviews
<StevenK> bac: Indeed I did
<StevenK> bac: thumper sent out a mail about it
<sinzui> jcsackett: ping
<StevenK> bigjools: At the last comment of "Do our tests suck so much that made no difference?!" yes
<StevenK> bigjools: I was attempting to nail down a bug when I noticed that.
<wgrant> Eventually the copier will be split up enough that it's unittestable.
<bigjools> StevenK: *sadface*
<sinzui> abentley: Do you have time to review https://code.launchpad.net/~sinzui/launchpad/answers-api-3/+merge/61346
<abentley> sinzui: yep.  I was already reading it, in fact. :-)
<abentley> sinzui: I would prefer to write the new tests as unit tests.  r=me.
<sinzui> abentley: I understand. My intent is to document how the webservice works. I have full faith in the existing unit tests are correct
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build #729: FIXED in 5 hr 23 min: https://lpci.wedontsleep.org/job/devel/729/
<abentley> sinzui: ISTM that the web service you just added could not possibly be already unit-tested.
<sinzui> abentley: I only exposed the methods. So I wrote a documentation that verified the they were exposed, and explain to a user how to make a request to get the data
<jml> woot! sub 200 crit bugs in launchpad itself (22 in stuff like launchpad-buildd, lazr.delegates, qa-tagger etc)
<jml> sinzui: hi
<sinzui> abentley: What the methods do are already tested
<jml> sinzui: we have a call now
<wgrant> Does https://launchpad.net/~launchpad-hackers do anything these days?
<abentley> sinzui: Right.  The fact that they are exposed, and exposed correctly is not already tested, and I would unit-test that if it were me.
<jml> wgrant: don't know.
<sinzui> abentley: How are they not exposed correctly?
<jml> wgrant: also, I wonder how we could change Launchpad so you wouldn't have to ask.
<abentley> sinzui: I'm not asserting that they're not exposed correctly.
<abentley> sinzui: I'm saying that I would add unit tests to ensure that they were exposed correctly.
<wgrant> jml: I'm pretty sure that's just about in scope for next week.
<wgrant> Let's try deleting it in a transaction on dogfood and see what breaks.
<jml> wgrant: if you squint hard enough, yes.
<sinzui> abentley: I think that doc test does that. Since I changed an interface, I wanted that documented. I do not like writing duplicate tests, which I think a unittest would be in this case. I did not change the model.
<abentley> sinzui: I don't like writing duplicate tests, either, so I would not write the doctests.
<jml> wgrant: you've checked celebrities, I guess.
<sinzui> abentley: Interfaces are the only thing that needs documentation in Lp, And since I actually want users to read how to use answers of the API, doctests are the correct way to demonstrate what was exposed
<LPCIBot> Project windmill-db-devel build #290: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/290/
<jml> sinzui: I'll be back in a bit. am very keen to talk today.
<wgrant> jml: Yeah. It's all old pre-opensourceing private branch subscriptions.
<sinzui> jml: I am on mumble
<sinzui> didn't you hear me
<wgrant> And branch visibility policies for lp-dev-utils and bzrbuildbot... both of which should probably be canonical-launchpad-branches now.
<abentley> sinzui: I don't think interfaces need this kind of documentation.  I don't think it is really helpful.
<sinzui> I disagree. In fact. the first unit-test only tests of answers did not demonstrate how to use it. We had to land multiple fixes because we actually want to know how to write scripts a particular way.
<abentley> sinzui: oh, on line 59, you misspelled "IQuestionTarget".
<sinzui> Oh, yes, there is a good chance I that. I wrote this in bed last night.
<sinzui> I will spell check the changes
<wgrant> sinzui: How does a team merge handle memberships in the team that is to be destroyed?
<sinzui> wgrant: all membership are removed. Nothing is transferred because there is a high probability of hitting a CyclicTeamMembershipError
<wgrant> sinzui: That's what I hoped. Thanks.
<jcsackett> sinzui: pong.
<sinzui> jcsackett: I wanted to catchup in bugs, I am, or will be, in a meeting now. Maybe later
<jml> sinzui: no, I didn't. I'm not on mumble.
<sinzui> nothing again?
<jcsackett> sinzui: ok. i'll try to be more responsive on your next ping. :-)
<jml> sinzui: it's been having trouble connecting today.
 * jml will try rebooting. 
<sinzui> jml: I do not see you speaking. Did you hear me?
<jml> sinzui: I am not connected to mumble
<jml> sinzui: you see merely a figment.
<sinzui> My mumble sees you
<jml> sinzui: can I skype you or call your phone?
<sinzui> I will start skype
<jml> sinzui: thank you
<adeuring> deryck: could you please run the two queries in https://pastebin.canonical.com/47578/ on staging?
<LPCIBot> Project windmill-devel build #101: STILL FAILING in 47 min: https://lpci.wedontsleep.org/job/windmill-devel/101/
<deryck> adeuring, sure, I'll get them now.  Was on a call, sorry.
<adeuring> deryck: thanks!
<deryck> adeuring, also, I can take IRC on #launchpad now.  Sorry about being late.
<adeuring> no problem :)
<deryck> adeuring, https://pastebin.canonical.com/47580/  twice for each query.  once cold, once hot.
<adeuring> deryck: thanks!
<deryck> adeuring, np!
<jml> sinzui: ready when you are
<nigelb> \o/
<nigelb> So, buildbot succeeded with my changes
<nigelb> does that mean that rev lands into production soonish?
<LPCIBot> Project windmill-db-devel build #291: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-db-devel/291/
<jml> cjohnston's still got some unlanded branches. what's happening there?
<jml> nigelb: yes.
<jml> nigelb: it needs to be verified as not going to break production
<nigelb> jml: *whee* Now, I have to find more to work on.
<jml> tbh, I don't know how to do that, or what page to look at.
<nigelb> I'm just scrolling through the easy bugs and trying to figure out if there's something I can work on.
<jml> hmm. http://lpqateam.canonical.com/
<jml> but it's out of date
<SpamapS> interesting, I just got a chrome "ERR_SOCKET_NOT_CONNECTED" while spinning waiting on this page: https://launchpad.net/ubuntu/+source/munin
<SpamapS> not the first time I've had this issue.. refresh works very fast
<SpamapS> It seemed to spin for about 9 - 10 seconds .. I wonder.. is something cutting off the connection before the OOPS message appears?
<cjohnston> jml: one I still need to work on, the other I believe is ready
<jml> cjohnston: cool. I'm just worried about it getting stuck in "Approved" while we wait for a core dev to land it.
<cjohnston> So should I ping one of the reviewers?
<jml> cjohnston: a good idea. henninge is generally around in the .de day
<cjohnston> He is the one who approved it iirc.. Does he have commit access?
<jml> cjohnston: indeed.
<jml> cjohnston: although, huh, I guess it's a bit sub-optimal that you can't tell that easily from the website.
<cjohnston> Why would he approve it but not land it?
<jml> cjohnston: I honestly don't know.
<cjohnston> ok
<cjohnston> I pinged somone yesterday and got them to land 3.
<jml> cjohnston: one possibility is that he ran it through tests and they failed.
<cjohnston> so I'm up to 4 landed I think
<cjohnston> ok
<jml> cjohnston: however, the normal way of doing that would also result with you receiving an email
<cjohnston> I didn't get any hate mail from it.. but I dunno
<jml> right.
<jml> cjohnston: anyway, I'm being dragged away from my computer. will keep hassling to get them landed from my side, you should do the same.
 * jml is off
<cjohnston> Okie.. ty
<sinzui> Why the F do users keep linking  packages to /launchpad when the package does not contain Lp code? Don't these users know I can track them down and club them like a baby seal?
<abentley> deryck: I'd like to do a pre-imp call on bug 648075
<_mup_> Bug #648075: Automatic translations export fails intermittently <branch-scanner> <lp-translations> <oops> <Launchpad itself:Triaged by abentley> < https://launchpad.net/bugs/648075 >
<deryck> abentley, sure.  I have TL call in 20 minutes.  can we do it before, or should we catch up after?
<abentley> deryck: I think "before" works.
<deryck> ok, firing up mumble now
<sinzui> I see that since blueprints were re-enabled, users are using it to request features. I do not think any of the 286 blueprints I see are work we are undertaking.
<abentley> deryck: did you consider registering NotFound as a 404 error?
<deryck> abentley, it was already handled as a 404.  I just decorated it to not OOPS.  see: https://code.launchpad.net/~deryck/launchpad/404-bug-api-generates-oops-701246/+merge/61407
<deryck> well, not literally decorated it.
<abentley> deryck: I mean that you can specify an error status for a particular exception class, and that will always be used when that exception is raised.
<abentley> deryck: e.g. lp.soyuz.interfaces.archive.CannotCopy
<benji> deryck: so there was a bug in lib/canonical/launchpad/webapp/errorlog.py; good catch!
<lifeless> gary_poster: sinzui: flacoste: deryck: http://webnumbr.com/.join(launchpad-oops-bugs.all,launchpad-timeout-bugs.all,launchpad-critical-bugs.all)
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | https://code.launchpad.net/launchpad-project/+activereviews
<deryck> benji, thanks!  Yeah, that was a bit tricky to spot, but once I saw it was sooo clear. ;)
<deryck> abentley, sorry, was on TL call
<abentley> deryck: no worries, I thought so.
<benji> :)
<deryck> abentley, so NotFound is not an exception.  it's imported from zope.publisher and we have a view hooked up to it, which sets the status to 404.
<lifeless> deryck: heh, so we oops on 404 deliberately
<lifeless> deryck: but we filter it on the oops server if the url was non-local
<lifeless> deryck: so we see bad links that we generate (in principle) by depending on referer
<abentley> deryck: NotFound is an exception.  It derives from BaseException.
<rvba> I've fixed the stable -> db-devel conflict (Julian -> me conflict ;)). Should I submit it to pqm or someone wants to take a look at it first?
<deryck> abentley, are we both talking about zope.publisher.interfaces.NotFound?
<abentley> deryck: Yes.  We don't define it, but it is an exception.
<bac> abentley: can you have a look at a very simple branch:  https://code.launchpad.net/~bac/launchpad/bug-781987/+merge/61459
<abentley> bac: sure.
<deryck> abentley, ok, sure.  if you follow it back far enough.  my point though is that it really is already registered in a sense as 404, via zcml and the view it's hooked up to, no?
<deryck> my little fix has generated so much interest ;)
<jcsackett> sinzui: did you want to chat?
<abentley> deryck: Perhaps it's registered as a 404 in some sense, but I don't think the class is registered with lazr.restful as a 404.  If it was, you wouldn't need to call expose on its instances.
<deryck> lifeless, yeah, I meant "not raising an OOPS for any resource" when dealing with the webservice only.  I wasn't meaning for any request on launchpad itself.  sorry for the bad choice of language.
<lifeless> deryck: de nada, I should have read the diff more closelhy
<abentley> bac: r=me
<bac> thanks aaron
<deryck> abentley, ah, ok.  I see what you're suggesting now.  I arrived at this fix after chatting with benji, and thought this was the best way to fix this for the webservice.
<deryck> hmmm, I do think it's right.
<abentley> deryck: I think you could call expose on the class instead, and that would mean that all instances would be treated as 404s.
<sinzui> jcsackett: do you have time to mumble?
<deryck> abentley, what do you mean by client?  launchpadlib, lazr.restfulclient?
<deryck> something else?
<benji> you can declare that a class of exception is always the client's "fault" (using a different mechanism) and such it won't generate an OOPS, or you can decorate a particualar instance
<abentley> deryck: I don't think I said anything about clients.  Did I?
<deryck> abentley, doh, sorry.  misread class as client
<deryck> that's why it didn't make sense ;)
<abentley> deryck: ah.
<deryck> abentley, now which class do you mean?  NotFound ?
<abentley> deryck: yes.
<abentley> deryck: e.g. expose(NotFound, 404)
<deryck> abentley, so expose may be misleading.  it doesn't expose this as 404.  it sets a variable on the exception to 404, which the error handler uses to determine if we should log an OOPS.
<deryck> maybe IRC isn't the best for this discussion.
<deryck> abentley, should we mumble to save time?
<abentley> deryck: sure.
<rvba> I'm going to submit my fix to the pqm then. I hope you guys can cover up for me in case anything goes wrong.
<rvba> (it's a tiny fix so I'm not really worried)
<LPCIBot> Project devel build #730: FAILURE in 5 hr 31 min: https://lpci.wedontsleep.org/job/devel/730/
<magcius> jam, ping: re Loggerhead CSS?
<deryck> abentley, that branch is done, if you're up for giving me a proper review.  Though I'm EOD'ing very soon.
<abentley> deryck: sure
<deryck> abentley, thanks!
<abentley> deryck: r=me.  Your change at line 8/9 is probably not needed, but I think it's correct anyway.
<deryck> abentley, I'm fairly certain it is.  I can confirm.
<LPCIBot> Project windmill-devel build #102: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/102/
<abentley> deryck: the fact that expose exists implies that you should be able to attach a status to an instance, so I think it makes sense to honour that.
<deryck> abentley, ah, I see what you mean.  I'm patching the class, not the instance now.  and yeah, we should probably leave the change I added, so it is possible in the future.
<LPCIBot> Project windmill-db-devel build #292: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-db-devel/292/
<deryck> we should kill those windmill notices here.  no one is doing anything about it.
<deryck> Later on, everyone
* abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<mwhudson> wallyworld: define POPO pls?
<wallyworld> mwhudson: plain old python objects. ie ones with no infrastructure attributes or extending storm classes etc
<mwhudson> ah ok
<wallyworld> sorry for the confusion
<mwhudson> np
<mwhudson> i that case i think i agree with you
<mwhudson> (and am not going to spend half my day on that thread today given that i no longer work on launchpad :-p)
<lifeless> :)
<LPCIBot> Project windmill-db-devel build #293: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-db-devel/293/
* lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | Criticals: 210 [######=_]
* lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:210 - 0:[######=_]:256
<jcsackett> sinzui: after our discussion and some technical problems i have a test that replicates the problem. bad news is the simple fix we talked about doesn't seem to address it. http://paste.ubuntu.com/609782/ is what i've done.
<jcsackett> sinzui: any thoughts?
<lifeless> jcsackett: what are you trying to reproduce?
<jcsackett> lifeless: it's a permission bug on flag-membership-expired on relation account.
<jcsackett> lifeless: bug 783476
<_mup_> Bug #783476: Scripts failed to run: loganberry:flag-expired-memberships <easy> <regression> <teams> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/783476 >
<lifeless> jcsackett: have you run security.py to apply those permissions to the test db ?
<lifeless> (silly question I know, but still...)
<jcsackett> not so silly--i was under the impression that was done automatically either via make or the testharness.
<lifeless> its only done via 'make schema'
<lifeless> or manually
<lifeless> database/schema/security.py -d launchpad_ftest_template
<lifeless> is the invocation, IIRC
<jcsackett> i thought i did do make schema (what i meant when i said make). i'll try the direct invocation.
<jcsackett> lifeless: that worked. thanks a ton.
<lifeless> \o/
<sinzui> jcsackett: is all okay?
<jcsackett> sinzui: all is excellent. just wrote the MP.
<sinzui> jcsackett: sorry about not telling you about the security,py. I did that a lot when working on the job fixes. I know it is an obscure thing
<sinzui> jcsackett: You will need to remind the LOSA to run that to qa the work, and there will be warning about no permission assigned to out db functions. That is a non-issue
<jcsackett> sinzui: good to know. thanks. :-)
<sinzui> jcsackett: I approved your branch with a comment
<jcsackett> sinzui: i am making the change you suggest.
<sinzui> I am certain that bug 730393 can be fixed in less then an hour, but I have been away from the code for so long I do not remember how we suppress oopses for error pages we show users
<_mup_> Bug #730393: when a user urls hacks we can get InvalidBatchSize oopses <oops> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/730393 >
<sinzui> Maybe I should just update the oops reporting util. InvalidBatchSize, NotFoundError, and GoneError should only be reported as an oops when Lp is the referer
<lifeless> yes yes yes
<lifeless> yes yes
<lifeless> and finally yes
<sinzui> lifeless: was that to add an conditional list error classes to exempt without a referer, similar to what we do with Unauthorized?
<lifeless> without a referer or with a non .*launchpad\.net/.* referer
<sinzui> jcsackett: wgrant, wallyworld. I just got a message that I need rescue a child. I am going to miss the meeting in 15 minutes.
<wallyworld> sinzui: jcsackett: wgrant: i am ok to delay? or will it take too long to do what you need to do?
<jcsackett> sinzui: okay. i hope all is well. i can also wait for you.
<sinzui> wallyworld: maybe 15 minutes
<sinzui> late
<wallyworld> sinzui: ok. why don't you pings us when you are back
<sinzui> lifeless: i think only report oopses with .*launchpad\.net/.* as referer...those we can fix
<sinzui> wallyworld: okay I will
 * sinzui find car
<lifeless> sinzui: [of the NFE/DE cases - yes]
<lifeless> sinzui: IBS could be self inflicted
<lifeless> sinzui: perhaps we need to think about it more
<lifeless> sinzui: oh, IBS with referers that are not .*launchpad\.net/.* are not self inflicted and we can discard them too
<lifeless> sinzui: so yes, I agree
#launchpad-dev 2011-05-19
<lifeless> oh the irony - bug 784854
<_mup_> Bug #784854: Questions in Launchpad Answers should be checked for double posting. <Launchpad itself:New> < https://launchpad.net/bugs/784854 >
<lifeless> [yes, I know its not ironic. Pedants!]
<mwhudson> wgrant: you remember we talked about running a script to update all lp branches to be stacked on +brand-id/$id
<mwhudson> wgrant: did that happen?
<wgrant> mwhudson: A couple of batches were started.
<wgrant> spm and thumper hopefully know more.
<wgrant> One run died due to a 502 during a nodowntime, I don't know what happened after that.
<spm> oh bugger. I completely forgot to kick that again
<wgrant> Hmm.
<wgrant> I think the devel failure is spurious.
<wgrant> Passes locally, doesn't really make sense...
<wgrant> But I've never seen it before.
<mwhudson> spm: so what is the status ?
<mwhudson> spm: is there an rt i can subscribe to or something?
<spm> you know. I don;'t think there is. I shall create one - makes itless likely to be forgotten.
<mwhudson> woo process
<wgrant> How does one subscribe to an RT, anyway? We don't have separate accounts, so it doesn't seem to be possible.
<mwhudson> i think you just make a comment on it via email?
<mwhudson> i'm not really sure though
<mwhudson> definitely "rt user account" != "email address to send activity on a ticket to" as concepts though
<wgrant> LP's RT does SSO now... maybe the IS one should too.
<lifeless> lp's is the u1 one
<lifeless> is need to upgrade
<wgrant> Ah.
<lifeless> aiui
<lifeless> storeblob should move to the librarian directly I think
<wgrant> Possibly. But that requires that the librarian know about more than just LFA/LFC.
<lifeless> it already does
<wgrant> And TLT.
<lifeless> however I am thinking about what would be needed for a standalone blob store
<lifeless> it seems to me that apport should be doing: a) upload a tonne of data to a gcable non-accessible area, b) handing off the result of that to something that claims a reference to the data from a)
<wgrant> Right.
<lifeless> now, we could do this today using the one temporary blob table
<lifeless> with the insert from the librarian and then an update to set metadata from the appservers
<lifeless> and refactor later to one thing owned by the librarian and another owned by the appservers
<lifeless> if we change the gc implementation to be something like gcable = [blob for blob in store if none(map(methodcaller('references'), librarianclients))]
<lifeless> for obj in gcable: if obj.age > 30 days: delete obh
<lifeless> fin
<lifeless> that wouldn't let us do fast in-librarian usage reports
<wgrant> Yeah. I'm not entirely sure how the reference counting will work with an SOA, but it seems doable.
<lifeless> but it would let us do them from within each service
<lifeless> alternatively we have a 'service' concept in the librarian
<lifeless> and we attach blobs to services
<lifeless> and we can create a service for (e.g.) each distro
<wgrant> Hmm, I guess, yes.
<lifeless> for apport
<lifeless> etc
<lifeless> and ask for reports at the granularity of a service
<lifeless> like 'how much data does this service have' -> ppa quota report
<wgrant> We probably need arbitrary "tagging" for blobs, to get the groupings.
<wgrant> Yeah.
<wgrant> Like that.
<lifeless> gcing of services becomes an issue then
<lifeless> but it would be a much slower churn rate
<lifeless> and other ubuntu/Canonical projects could get api access to make and consume services in the same pool
<lifeless> interestingly if you look at s3
<lifeless> aggregate reports are not exposed
<lifeless> you can see what you used
<lifeless> but not get 'whats the size of my bucket delilah'
<lifeless> which suggests some possibilities about their internal model
<wgrant> Hmm.
<wgrant> I didn't realise that.
<lifeless> well, IMBW
<lifeless> I couldn't find anything in the api docs though
<lifeless> http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?BucketBilling.html
<lifeless> Fees for object storage and network data transfer are always billed to the owner of the bucket that contains the object unless the bucket was created as a Requester Pays bucket.
<lifeless> The reporting tools available at the Amazon Web Services developer portal organize your Amazon S3 usage reports by bucket.
<lifeless> so while I can see us doing blob-storage + blob-accounting (including gc) layered on top
<lifeless> I suspect amazon have blob-storage-and-accounting
<lifeless> with possible microservices that scale each function (storage,accounting) separately, but that are allowed to know about each other
<lifeless> e.g. callbacks on storage adding to the accounting service
<lifeless> ditto downloads/uploads
<lifeless> I think we should aim to be able to replace germanium with the librarian when we split it out
<wgrant> There's a spec for that.â¢
<wgrant> DisklessArchives on the old wiki.
<wgrant> Would make everything much simpler.
<lifeless> of course there is
<wgrant> and smaller.
<lifeless> well, a tradeoff - we'd make the impact of downtime even greater, so want to start adding in redundancy
<wgrant> Right, but a split-out librarian should be fairly easily redundant.
<lifeless> something like that :>
 * wgrant constructs a bonfire to dispose of archiveuploader.
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build #731: FIXED in 5 hr 12 min: https://lpci.wedontsleep.org/job/devel/731/
<lifeless> mtaylor: yo
<LPCIBot> Project db-devel build #561: FAILURE in 5 hr 36 min: https://lpci.wedontsleep.org/job/db-devel/561/
<lifeless> hmm
<lifeless> it seems like they fail on design
<lifeless> so no
<wgrant> Oh?
 * lifeless goes to the dark side and makes negative comments
<lifeless> 'The rsync daemon requires no authentication, so it should be run on a local, private network'
<wgrant> Have you seen the librarian lately?
<lifeless> crunchy shell security is a pretty big WTF for a multi-tenant system
<wgrant> Yeah.
<lifeless> wgrant: so I'm assessing this based on:
<wgrant> The db-devel failure is real; I am fixing.
<LPCIBot> Project windmill-devel build #103: STILL FAILING in 47 min: https://lpci.wedontsleep.org/job/windmill-devel/103/
<lifeless>  - testing story [I see no test fakes for us to use in their docs]
<lifeless>  - sanity [e.g. wtf count]
<lifeless>  - friction vs what we want [like diskless archives]
<lifeless> their building on rsync is itself a wtf for me
<wgrant> Hmmmmm
<wgrant> This test is duplicated.
<wgrant> Odd.
<lifeless> double landing? db-devel then devel + merged silent-wrong?
<wgrant> Doesn't look like it.
<wgrant> They are adjacent, but it's possible.
<lifeless> that matches the symptoms
<lifeless> log will know
<wgrant> Oh.
<wgrant> Not duplicate.
<wgrant> test_higher_radio_mentions_parent vs test_higher_radio_mentions_parents
<lifeless> also 'The listings are stored as sqlite database files'
<lifeless> doth NOT fill me with confidence
<wgrant> ahaha
<lifeless> I love sqlite
<lifeless> but if you want K:V its more than you need
<lifeless> and if you want SQL its less than you need for this size problem
<lifeless> these are relatively small things
<lifeless> But I'm finding it hard to love it
<lifeless> aahhahahahhaha
<lifeless> 'Currently it is recommended to use 3 (as this is the only value that has been tested). '
<mwhudson> lifeless: what are you talking about?
<lifeless> mwhudson: I'm doing some reading on alternative blob stores to the librarian
<mwhudson> ah ok
<lifeless> mwhudson: the librarian is starting to creak
<mwhudson> ceph!
 * mwhudson hides
<lifeless> thats a fascinating option
<lifeless> and one I think I've been talking about since ~ 2005
<lifeless> but
<lifeless> we need a layer on top of that
<mwhudson> for gc and such?
<lifeless> gc, accounting, url generation
<lifeless> not to mention actually adding and removing data
<mwhudson> huh, has "S3-compatible storage" now
 * mwhudson gets back to hiding
<lifeless> wheeee
<lifeless> http://ceph.newdream.net/wiki/S3-compatible_Gateway
<mwhudson> spm: did you make an rt about the branch-$id script thingy?
<spm> mwhudson: not yet, no.
<lifeless> http://ceph.newdream.net/wiki/RADOS_Gateway
<lifeless> mwhudson: some options are: - ocfs2 + multiple librarian front-ends
<lifeless>  - openstack swift
<lifeless>    - with accounting hooks etc implemented
<lifeless>  - ceph + a metadata service
<lifeless>    - though http://ceph.newdream.net/wiki/RADOS_Gateway notes that rados is slow
<james_w> what were you looking at with the rsync/sqlite/etc. stuff?
<lifeless> swift
<lifeless>  - we could do something like haystack
<lifeless>    - given our files are all immutable, regular fs overhead is uninteresting
<spm> mwhudson: actually, istr there was some problem with the run we did last week. will need to dig out details tho.
<wgrant> spm: Didn't it just die with a 502 during a nodowntime?
<spm> don't recall exactly. it may have been as simple as that
<mwhudson> spm: this is why there needs to be an rt :)
<spm> yes.
<spm> wgrant: the cause per-se didn't matter; as it got complex from there as the scripts don't handle an outage gracefully. basically abort. which makes doing 300+k branhces a little more time consuming.
<wgrant> Yeah :(
<mwhudson> i guess it has to look at every branch for each run?
<lifeless> yes
 * mwhudson goes through old tabs
<mwhudson> lifeless: didn't you say that you'd reword the "team participation / directory service" section of https://dev.launchpad.net/ArchitectureGuide/ServicesAnalysis a bit?
<mwhudson> no worries if you just decided not to bother
<wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/bug-784948/+merge/61503
<StevenK> wgrant: You can also dump the import of removeSecurityProxy
<wgrant> Silence.
<StevenK> :-(
<StevenK> Only trying to help
<wgrant> (but done)
<wgrant> I had noticed that, but then archiveuploader tried to stab me :(
<lifeless> mwhudson: in my queue
<wgrant> Nasty archiveuploader.
<lifeless> wgrant: why doesn't notification.send()
<lifeless> log
<lifeless> if logging is important ?
<wgrant> lifeless: For one thing the logger would have to be passed down another level.
<wgrant> I guess it might be useful to log the addresses, though.
<lifeless> that seems pretty mechanical
<lifeless> anyhow, I've commented along these lines and approved
<wgrant> I was going for minimal solution that will unblock deployments and let me get back to more important things.
<wgrant> Thanks.
<lifeless> as a variation, log the email if its available
<wgrant> (of course these logs go nowhere; the script is run with -q and no output redirection)
<lifeless> bbbbwah
<wgrant> Yes.
<StevenK> That should also be fixed
<wgrant> Yes.
<StevenK> Hmm, where did this heat come form?
<StevenK> *from
<StevenK> It's 21 degrees!
<lifeless>  wgrant how goes BFJ ?
<wgrant> lifeless: It needs table flattening and triggers added at the next DB deploy, so BPB's data can be populated. That's still three weeks away.
<wgrant> There are still ~2 methods that need fixing up.
<wgrant> But that can only be done after the migration.
<wgrant> Everything that can be done beforehand is done.
<lifeless> cool
<lifeless> and then a second db patch to tidy up?
<wgrant> I was counting on being on maintenance for a couple of weeks longer, and the deploy deploy not being a week late.
<wgrant> Right.
<wgrant> 1) DB patch with triggers and garbo.
<mwhudson> spm: did you make an rt about the branch-$id script thingy?
<wgrant> 2) Normal branches to migrate to flattened tables, with lots of queries being mechanically changed and two being rewritten.
<wgrant> 3) DB patch to drop old tables.
<wgrant> 2's branches are mostly prepared, except for the two general query rewrites.
<spm> mwhudson: I have opened a blank RT. what more do you want of me?!?!!?
<wgrant> And lots of that has already landed.
<mwhudson> spm: hey, if i can be cc:ed on updates to it, i'll shut up
<spm> heh
<spm> I want to believe
<mwhudson> well, at least a bit
 * StevenK gives up on OverridePolicy and merges in devel
<wgrant> StevenK: You're encountering difficulties?
<wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/bug-784948/+merge/61503, now with added logging.
<StevenK> wgrant: Yes.
<StevenK> And I want the storm distinct-on thing
<wgrant> Ah.
<StevenK> I've stopped it caring about pockets, but it still can't locate this upload for the new test case
<wgrant> :(
<StevenK> Which means it gets stuffed into universe, since FromExisting didn't return anything for that SPN
<StevenK> DAMN IT
<StevenK> I don't specify distroseries
<wgrant> Heh.
<StevenK> wgrant: I'll keep my +1 for that branch with the logging changes
<wgrant> StevenK: Thanks.
<lifeless> grrrr
<wgrant> Aha.
<lifeless> rabbit fail
<wgrant> archiveuploader is defeated.
<wgrant> lifeless: Again?
<lifeless> the layer
<lifeless> tests failed when run in the whole test suite
<lifeless> I suspect isolation fail
<wgrant> :(
<wgrant> It's still failing regularly in devel/db-devel.
<lifeless> that sucks
<lifeless> canonical.testing.ftests.test_layers.MemcachedTestCase.testRabbitWorking
<lifeless>  canonical.testing.ftests.test_layers.DatabaseTestCase.testRabbitWorking
<lifeless>  canonical.testing.ftests.test_layers.LibrarianTestCase.testRabbitWorking
<lifeless>  canonical.testing.ftests.test_layers.ZopelessTestCase.testRabbitWorking
<lifeless> erence: None != 'localhost:47565'
<wgrant> Lovely.
<lifeless> other layers use it
<lifeless> and None is the default in the schema
<spm> mwhudson: 45879 :-)
<mwhudson> spm: w00t
<lifeless> hey wow
<lifeless> 702  OOPS-1964O247   Sprint:+temp-meeting-export
<lifeless> our top count is under 1K now
<lifeless> thats pretty awesome
<mwhudson> let me guess, that will go away next week when it's not uds?
<lifeless> I think the temp is a lie
<lifeless> mwhudson: thats overnight
<lifeless> mwhudson: so no, its already post uds
<mwhudson> ah
<lifeless> 23 /   20  Sprint:+temp-meeting-export
<mwhudson> spm: do you have any idea how many branches have been processed?
<wgrant> It only started just before UDS, though.
<spm> mwhudson: we got about 23K done
<mwhudson> spm: heh ok
<wallyworld> lifeless: do you know the mechanism by which a particular url advertises to the browser that is can provide an rss feed and hence enable the rss button?
<lifeless> which rss button
<wallyworld> the one in the browser toolbar
<lifeless> <meta link rel= ...
<wallyworld> orange square
<wgrant> (which is gone from all modern browsers, FWIW)
<lifeless> though I think most browsers have stopped doing
<wallyworld> i've got a bug that says rss feeds need to be disabled for private bugs
<lifeless> thats not what it means :)
<lifeless> also the bug says it blows up for private bugs which is arguably different
<lifeless> but AIUI we haven't implemented authenticated feeds yet for some bizarre reason
<wallyworld> yes but the suggested solution is just to disable rss feeds for private bugs
<lifeless> so disabling it is probably the most reasonable expedient solution
<wgrant> 2 things: 1) the <link> shouldn't be there. 2) there should be no login link on feeds.
<mwhudson> feeds were designed to only be served out of squid
<lifeless> mwhudson: a mistake
<lifeless> :)
<mwhudson> is the specific bizarre reason
<lifeless> mwhudson: still a mistake, vary will let you handle authentication through squid just fine
<mwhudson> yeah well, blame your boss's boss
<mwhudson> lifeless: not defending it!
<lifeless> mwhudson: elliot?
<mwhudson> iirc
<lifeless> heh
<lifeless> anyhoo
<lifeless> We can and will solve it
<lifeless> I want to get reliable atom/rss available in the next 6-12 months, for all objects we index.
<lifeless> so we can pshb it up
<mwhudson> omg, someone used specificationfeedback on me!
<wgrant> KILL THEM
<mwhudson> wgrant: i will opt for education
<wgrant> There are international laws against that sort of thing.
<wallyworld> lifeless: so for now, if i look for a way to disable rss feeds for private bugs as per the suggestion in the bug report that will be ok?
<wgrant> Come on, soyuz-upload.txt...
<wgrant> Work please.
<wgrant> And don't take 140s.
<LPCIBot> Project windmill-db-devel build #294: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/294/
<lifeless> wallyworld: thats fine, of course. But please stay connected ;P
<adeuring> good morning
<LPCIBot> Project windmill-devel build #104: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/104/
<rvba> wgrant: thanks for fixing the test in test_distroseries.py earlier today.
<jtv> Do we have a good pattern for adding annotations to objects that views feed to templates, without adding them to the objects and without making them persistent?  I can think of: pass a tuple of (annotation, object); pass a wrapper that delegates to the original object; or pass just a dict of relevant data to the view.
<jtv> lifeless, any thoughts?
<mrevell> Hi
<jtv> hi
<lifeless> jtv: I think lazr.delegates was intended for this sort of thing, but its terribly heavyweight
<lifeless> jtv: another option you haven't enumerated is a lookup on the view - view/annotation/object (where annotation is callable)
<lifeless> bigjools: hi
<lifeless> bigjools: hi
<bigjools> howdy
<bigjools> howdy
<lifeless> bigjools: https://code.launchpad.net/~lifeless/launchpad/rabbit/+merge/61057 seems to have found a test isolation issue of some sort [it has the test Layer for you]
<jtv> lifeless: that's a good one, thanks...  I just managed to squeeze some work out of my lazy brain and got to "dict"
<jtv> lifeless: and delegates is definitely too heavyweight; I really didn't want to add ZCML for this!
<bigjools> lifeless: what's the isolation issue?
<lifeless> bigjools: looks shallow - something seems to be zapping the config back to the schema default (of None) when the full test suite is run (vs when just the new tests are run)
* allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:210 - 0:[######=_]:256
<jtv> allenap: something I expect to have to repeat rather a lot is "here's a DSD, what would be the package specification for a PlainPackageCopyJob that would resolve it?"  I'm about to write a function specify_dsd_package(dsd): return (dsd.source_package_name.name, dsd.parent_source_version) but did you perhaps have something for that already?
<lifeless> bigjools: anyhow I mention that test failure
<lifeless> bigjools: in the (vague) hope that allenap or yourself might want to land the branch
<bigjools> heh
<bigjools> you mean you want to offload it? :)
<allenap> jtv: No, I don't have anything for that. It might be nice to incorporate that into an alternative PlainPackageCopyJob.create() classmethod.
<lifeless> more that I don't want you guys blocked on me doing it
<bigjools> I doubt we're that close yet
<lifeless> I have a few balls to juggle right now, and while its important, its not top of the list
<jtv> allenap: not worth the bother if it's a simple helper call.  BTW I also filed a bug yesterday for two flaws in getActiveJobs: it doesn't sort and it doesn't filter for job status.
<allenap> jtv: I saw; sorry for creating the bugs in the first place :)
<jtv> I'm sure it felt like a worthwhile effort at the time.  :)
<jtv> I _would_ fix them en passant but am slightly too woozy right now.  Also, can't just fix it without tests.
<jtv> (Glad I didn't tackle this earlier since I just disposed my dead-end branch)
<jtv> WTF?  Why doesn't it show up as my last-reported bug?
<allenap> lifeless: I'm reviewer today, so I might have a go with that layer branch.
<lifeless> allenap: I'll forward you the ec2 output
<allenap> Thanks.
<LPCIBot> Project db-devel build #562: STILL FAILING in 5 hr 41 min: https://lpci.wedontsleep.org/job/db-devel/562/
<jtv> allenap, bigjools: bug 784515
<_mup_> Bug #784515: PlainPackageCopyJob.getActiveJobs should check job status <derivation> <Launchpad itself:Triaged> < https://launchpad.net/bugs/784515 >
<bigjools> jtv: yeah that's not good is it :)
<jtv> possibly not
<StevenK> allenap: Are you up for a reviewing an oversized branch?
<StevenK> allenap: It is effectively moving the code and massaging it to work
<allenap> StevenK: Yeah, okay.
<StevenK> allenap: https://code.launchpad.net/~stevenk/launchpad/announcements-copies/+merge/61516
<StevenK> allenap: The two methods at the top of notification that aren't exported are the end-goal
<allenap> StevenK: Okay, I assume I'll understand what that means when I read the code :)
<StevenK> Hopefully it does
<henninge> Does anybody see a potential hurt in piping LP.cache['context'] through obfuscate-email, like so? http://paste.ubuntu.com/609988/
<henninge> obfuscate-email is only applied on anonymous requests
<henninge> wgrant: ^ ?
<wgrant> henninge: Ugh.
<wgrant> henninge: I have no idea how to solve this.
<henninge> wgrant: what do you mean?
<henninge> it is solved
<henninge> I mean, that works
<henninge> I am just wondering if I missed any effect because this is a rather simple solution
<wgrant> Yeah, until it leaks somewhere we don't want and all the email addresses in the DB get erased.
<henninge> Ah
<henninge> wgrant: you said yesterday that the cache is not really needed on anonymous pages.
<wgrant> It seems perilous to be sending out bad data in a machine-readable format, when it looks fine in most circumstances.
<wgrant> Then someone writes a tool that uses it.
<wgrant> And goodbye email addresses.
<henninge> yes, I see the danger
<henninge> there are two general  solutions that I see
<henninge> 1- Not send out the data
<henninge> 2 - check all data for obfuscated email addresses
<henninge> all *received* data that is
<henninge> wgrant: yes, thinking about it the only general solutionwould be to reject all data on the the webservice that contains <email address hidden> because whoever is doing that is doing something wrong.
<StevenK> allenap: Still looking through it?
<lifeless> well
<lifeless> <email address hidden> is an invalid email address
<lifeless> won't pass the parsers
<lifeless> I like not calculating and sending data we don't need to calculate and send
<wgrant> lifeless: This is in stuff like bug descriptions.
<lifeless> wgrant: ahhh so
<lifeless> yes
<lifeless> henninge: rejecting incoming corrupt data would be a poor choice because how do you file a bug about it then ?
<wgrant> The correct term is "abandon all hope"
<wgrant> Exactly.
<wgrant> We can't reject it.
<allenap> StevenK: My laptop is deciding to sporadically reboot itself. Still going...
<wgrant> Despite the MP's apparent pointlessness, I support it as a first step :)
<StevenK> Haha
<allenap> StevenK: Done, at last.
<StevenK> allenap: The two things you said to ditch are the "end goal" method
<StevenK> allenap: As in things like the archiveuploader, the package copier will just call notification() and everything happens.
<allenap> StevenK: Oh, okay, so they're empty shells that will be filled later. Fine.
<StevenK> allenap: I will ignore your bug, since the next step is to refactor all this next.
<StevenK> allenap: Thank you for the review, and sorry for the over-sizedness
<wgrant> Ah, I see you raise the class argument that StevenK and I had earlier.
<wgrant> Why do you feel a class would be beneficial?
<wgrant> There is no state.
<allenap> StevenK: No worries :)
<bigjools> jkakar: perl? ew!
<jkakar> bigjools: I know.  Ugh.
<jkakar> bigjools: I'm trying to run some tests for a Fluidinfo client library... not getting anywhere... I did Perl years ago, but I've (thankfully) forgotten it all.
<bigjools> I have studiously avoided perl
<lifeless> wallyworld_: yes thats fine
<wallyworld_> ok
<StevenK> Nothing wrong with Perl.
<lifeless> StevenK: nothing ... right with it either
<lifeless> :)
<bigjools> StevenK: ... that high explosive won't fix
<wgrant> henninge: Are you guys keeping an eye on Answers? The backlog is approaching 36 hours.
<henninge> wgrant: thanks, I will look at it
 * henninge relocates first
<adeuring> allenap: could you please have a look at this mp: https://code.launchpad.net/~adeuring/launchpad/bug-739065/+merge/61555 ?
<allenap> adeuring: Sure.
<adeuring> thanks!
<mrevell> allenap, https://code.launchpad.net/~matthew.revell/launchpad/karma-help-bug93410 I have a particular question. Let me know when you have the branch running at lp.dev
<wallyworld_> sinzui: question for you if you are around
<jtv> allenap: busy review day?
<allenap> jtv: I can fit you in :)
<jtv> Great, thanks!
<jtv> It's https://code.launchpad.net/~jtv/launchpad/db-bug-781514/+merge/61557
<allenap> mrevell: Ready when you are.
<mrevell> Hello allenap. If you log in and go to your person overview page, I've put a help link beside the karma score. This links to the help page on help.lp.net but in a pop-up window. I'm not satisfied with that, it looks a bit odd to my eyes. But there's already a help link on that page and I think it'd also look odd if they behaved differently (i.e. the question mark mouse pointer only appears if the help link has a t
<mrevell> arget of "help"). Any thoughts?
<allenap> mrevell: You're right, it does look odd.
<mrevell> allenap, I could replace it with this: https://help.launchpad.net/YourAccount/Karma?action=print
<mrevell> allenap, I'm reluctant to create a new help text file in the tree if it's just gonna duplicate the contents of a help wiki page. Probably what I'll do is write a short help wiki pop-up and link it to the fuller wiki page.
<allenap> mrevell: I think you need to speak to a UX person really. I think they should all look the same :-/ I guess you could have a quick overview in the frame, with a link in there to the wiki with target="_top".
<mrevell> allenap, I'll do that ... quick overview and a link that targets _top. Thanks.
<allenap> mrevell: Tip top.
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap, jcsackett | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:210 - 0:[######=_]:256
<bac> matsubara: is the qabot not working currently?
<sinzui> wallyworld_: I am about, but I am decaffeinated.
<matsubara> bac, it should. what happened?
<matsubara> unless Ursula disabled it for a rollout or something
<bac> matsubara: bugs have been deployed but it hasn't done it's magic on them
<bac> the deployment report looks stale too
<wallyworld_> sinzui: the rss feed for private bugs; i've disabled it and also did the same for private branches. sadly, if you use the inline ajax editing to change the privacy status, the rss feed isn't toggled. i'm wondering if we want to land what's done and working and raise a new bug for the ajax work
<matsubara> bac, looking into it.
<bac> thx
 * deryck disappears for reboot but will brb
<sinzui> wallyworld_: I do not think that is an issue unless users actually experience the bug
<abentley> henninge: do you want to mumble about this bug a bit more?
<henninge> abentley: sure, but give me a few minutes. Say at :30 ?
<abentley> henninge: sure.
<henninge> thanks
<wallyworld_> sinzui: they will see the issue i think if a bug was public and is changed to private. the rss feed button will still be enabled and hence the situation will be as per the bug report. but my claim is that this is a corner case that will hardly ever eventuate. a page refresh will fix it up at this point also
<sinzui> wallyworld_: Then the bug is not fixed!
<sinzui> wallyworld_: RSS feeds cannot contain private information, They are intended for anonymous users
<wallyworld_> sinzui: no argument there. i was asking about landing the fix in two branches. but i'll do it in the one branch
<sinzui> wallyworld_: It is always okay, and desirable, to land multiple branches
<wallyworld_> sinzui: ok. will get the current branch in and do the ajax work separately. thanks.
<jcsackett> wallyworld_: your various reviewers will never complain about smaller branches to review, either. :-p
<wallyworld_> jcsackett: yeah. and i've had some large ones recently too
<abentley> wallyworld_: been meaning to ask: Why did you implement performDailyBuilds as a new method, rather than extracting it from makeDailyBuilds?
<mrevell> allenap: Where is the queue of people waiting for reviews now? it used to be in the channel topic.
<wallyworld_> abentley: give me a second to look at the code. it's been a while :-)
<mrevell> allenap, Or is it just the +activereviews you look at now?
<allenap> mrevell: There is no queue. I'm doing adeuring's review at the moment, and will be following up with jtv's.
<abentley> mrevell: We use +activereviews, but you should still request someone to look at yours.  They can claim the proposal on the web.
<mrevell> Thanks abentley.
<mrevell> jcsackett, allenap: Would either of you care to take a look at this? https://code.launchpad.net/~matthew.revell/launchpad/karma-help-bug93410/+merge/61566
<jcsackett> mrevell: sure.
<wallyworld_> abentley: makeDailyBuilds is called from the cron script and has logging and slightly different error handling to performDailyBuilds which is called from the ui via an ajax call
<henninge> abentley: I am ready now
<abentley> wallyworld_: I think it's a DRY violation, and it caused me to waste a bunch of time "fixing" the wrong method.
<mrevell> thanks jcsackett
<abentley> henninge: starting up.
<wallyworld_> abentley: sorry. at the time i thought there was enough of a difference (maybe i still do, not sure) to justify the separate implementations. they both call requestBuild but the calling environment and especially exception handling is different
<jcsackett> mrevell: r=me. martin has a comment on the MP that's probably worth considering, but i don't think it's a block to approval.
<mrevell> Thanks jcsackett
<LPCIBot> Project windmill-devel build #105: STILL FAILING in 48 min: https://lpci.wedontsleep.org/job/windmill-devel/105/
<matsubara> bac, it's now up to date. UrsulaJ is investigating why it stopped.
<bac> thanks matsubara
<nigelb> ok, the bug I fixed is in qastaging.
<nigelb> can I do the verification myself? Or someone else should be doing it?
<wgrant> nigelb: You can do it. Check that it works and doesn't break stuff, and tag the bug qa-ok.
<nigelb> wgrant: Awesome, thanks.
<nigelb> haha, I caused a timeout doing something else :p
<wgrant> :(
<nigelb> I realized the db in that is old, so I couldn't access the project.  I just wanted to see how old and clicked the branch.  BANG. Timeout.
<nigelb> wgrant: Okay, tested.  Worked.  Now remove qa-needstesting and make it qa-ok ?
<wgrant> nigelb: Right.
<nigelb> okay, done!
<nigelb> Now sit tight and wait till the rev gets deployed to production?
<wgrant> Probably in about 10 hours, unless stuff breaks overnight.
<deryck> nigelb, hey, welcome as a contributor to launchpad now!
<nigelb> deryck: \o/ :)
<nigelb> Its addictive, I'm already looking for another bug to fix.
<bigjools> I have loads you can do ;)
<nigelb> bigjools: beginner friendly? ;)
<bigjools> nigelb: you didn't specify that :)
<nigelb> heh
<rvba> I've got a strange error when I run "./utilities/ec2 land my-mp-url": http://paste.ubuntu.com/610096/
<rvba> Any idea anyone?
<nigelb> I'll admit I don't know enough zope to fix the more harder bugs.
<bigjools> nigelb: btw I'm sorry we didn't meet at UDS, unfortunately time was too short for me
<rvba> (The error itself is "AttributeError: 'Entry' object has no attribute 'queue_status'")
<nigelb> bigjools: wait, you were *at* UDS?
<bigjools> yes :)
<bigjools> for 1.5 days
<nigelb> Darn
<nigelb> I'm sorry I didn't find you
<nigelb> ahh
<bigjools> I am the freakishly tall dude
<bigjools> well, there's a few of us like that thinking about it
<nigelb> At this point, noodles is the freakishly tall dude I remember.
<nigelb> :P
<bigjools> yes we're the same height roughly
<nigelb> hah
<bigjools> he used to work in my team
<nigelb> If I do turn up at another UDS, I'll make sure I find you :)
<nigelb> I know, I did tell him I remember him from #launchpad
<bigjools> sure thing
<bigjools> rvba: seems like nobody wants to answer you! perhaps take it to the list
<rvba> bigjools: it's for landing my 2nd performance branch. I think I'll sleep on it first and focurs on getting something done on the overlay front today.
<nigelb> bug 4595 surely can't be fixed anymore.  I don't think there are tooltips anymore that the bug doesn't exit.
<_mup_> Bug #4595: Don't auto-linkify non-existent bug reports <easy> <lp-web> <tales> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/4595 >
<bigjools> rvba: it's a problem when it triest to get at the MP over the webservice.  It looks like the code is out of step with production, but that's just weird.
<bigjools> tries(
<rvba> I'll see if any of the libraries used is suspiciously recent.
<bigjools> I can't see anything obvious, I looked at the MP interface
<deryck> henninge, how's the question answering work coming?
<henninge> deryck: just started ;-)
<deryck> henninge, ah, ok.  np.  Just doing my duties as well and didn't want to conflict with you.
<henninge> deryck: yeah, better you pick something else
<deryck> np.  I'll do project review now.  I've just been working down the list.
<nigelb> ok, picked a new bug to fix, bug 203478
<_mup_> Bug #203478: Meeting attendees should be sorted by display name <easy> <lp-blueprints> <sprints> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/203478 >
<nigelb> hopefully, I can kick out the fix today, writing the tests though are an entirely different matter :\
<deryck> nigelb, you could start with the test.  I can chat with you about how to write a test for this, if you'd like.
<nigelb> deryck: Yes, I'd love that.
<deryck> nigelb, ok, let me look at the bug to make sure I know the problem.
<deryck> nigelb, ok, this shouldn't be bad.  I would probably add a test to lib/lp/blueprints/browser/tests/test_sprint.py
 * deryck is looking for an example of something similar to point nigelb at
<nigelb> makePerson and make two people
<nigelb> and then add them to the sprint
<nigelb> but hrm, how would I actually figure out that the name and display name are in different order
<deryck> nigelb, broadly you would use the factory to create people with some made up names, then sort those names and then compare to the list in the page.
<deryck> nigelb, look in lib/lp/registry/tests/test_mailinglist.py for test_getSenderAddresses_dict_keys for something similar.
<nigelb> okay
<deryck> nigelb, I imagine (I haven't looked) that the template has a view method that returns the list of people.  your test would assert that the expected name order matches what this method returns.
<nigelb> I know the method that returns the list of people.
<deryck> ok, great.
<deryck> nigelb, and this method is on the view class, yes?
<nigelb> no, its on the model class
<deryck> nigelb, ok.  so I would add the test to a different file, since you're testing the model not the view
 * deryck looks....
<nigelb> attendances in lib/lp/blueprints/model/sprint.py
<deryck> nigelb, ok, so I would add a new test file lib/lp/blueprints/model/tests/test_sprint.py and add a test case class with a test method that checks this.
<deryck> nigelb, there is a sample test file in the top of the tree, IIRC
<nigelb> yeah, I used that last time :)
<deryck> nigelb, awesome.  let me know if you need anymore help.  I don't mind.
<nigelb> deryck: let me see how far I can get without the temptation to headdesk.  At that point, I'll ping you :)
<deryck> nigelb, ok, sure. :-)
<jtv> thanks for the review, allenap!  I'll bother jcsackett for the next one.  :)
<jtv> jcsackett: speaking of which... Good morning!  Got room for this review?  https://code.launchpad.net/~jtv/launchpad/bug-785190/+merge/61594
<jcsackett> jtv: sure, i'll look at it in just a few.
<jtv> Thanks
<gmb> allenap, jcsackett: Can one of you take a look at this for me: https://code.launchpad.net/~gmb/launchpad/fix-oops-with-teams-bug-778847/+merge/61600
<nigelb> How do I run a test written in model/tests?
<gmb> nigelb: bin/test -ct test_filename should work.
<gmb> The test runner magically finds the tests.
<nigelb> magic! nice :)
<jcsackett> gmb: looking at your MP now.
<gmb> jcsackett: Tahnks
<nigelb> ok, this is strange. The didn't fail.
<nigelb> ah, it ran the test_sprint from lib/lp/blueprints/browser/tests instead of lib/lp/blueprints/model/tests
<jcsackett> gmb: r=me, with a small comment on the MP.
<gmb> jcsackett: Thanks.
* allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:210 - 0:[######=_]:256
<nigelb> gmb: "bin/test -ct test_sprint", but its running the browser test instead of model test, is there a way to specify I want to run the model test?
<gmb> nigelb: You could specify it as:
<gmb> bin/test -ct python.path.to.test_file
<gmb> (e.g.
<gmb> bin/test -ct lp.bugs.tests.test_bug.py
<gmb> )
<nigelb> ah
<gmb> s/.py//
<LPCIBot> Project windmill-db-devel build #295: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/295/
<jtv> thanks jcsackett
<nigelb> gmb: "bin/test -ct lp.blueprints.tests.test_sprint" and "bin/test -ct lp.blueprints.model.tests.test_sprint" didn't work :(
<gmb> Hmm.
 * gmb tries it
<gmb> nigelb: Is test_sprint a new file for you? I don't see it in my tree...
<nigelb> gmb: oops I should have told you.  I just wrote it
<gmb> nigelb: bin/test -ct blueprints.model.tests.test_specification works for me, for example.
<gmb> ah.
<gmb> nigelb: Can you paste the file in Etherpad for me? There might be something missing from it...
<nigelb> gmb:  http://pad.ubuntu.com/CSDp1HJN53
<gmb> nigelb: Ah, here might be the problem: You've got TestCaseWithFactoryImported but you subclass TestCase.
<nigelb> ahh
<nigelb> let me try with that fixed
<nigelb> gmb: *facepalm*
<gmb> Heh.
<nigelb> gmb: That isn't what went wrong.
<nigelb> its even more sillier than that.
<gmb> :)
<nigelb> gmb:  So, I was writing the test in the devel branch instead of my branch and running the test in my branch. *headdesk*
<gmb> nigelb: Haha. I've done that before too.
<gmb> Oh well.
<gmb> Anyway, working now?
<nigelb> copying over now
<gmb> Cool.
<nigelb> aha, now it explodes because its wrong.  Happier.
<gmb> Cool.
<nigelb> ok, I need help.
<nigelb> the method I thought I should assert with doesn't return what I thought it would, causing the test to fail.
<nigelb> and here's a paste of the failing test http://paste.ubuntu.com/610159/
<deryck> nigelb, you want to convert the list of objects to a list of names.  something like [person.displayname for person in obj.method()]
<nigelb> deryck: the one returned by sprint.attendances?
<deryck> oh wait
<deryck> nigelb, I didn't look close enough, sorry
<nigelb> the sprint.attendances is where I'm running into trouble
<maxb> URL forms like /+branch/projectname seem to work for bzr+ssh, web ui, loggerhead, but NOT for http branch access. Is this intentional? oversight? not-a-bug?
<deryck> nigelb, ok, so you have a list of person objects comparing to a list of attendees.  but I believe attendee.attendee_id should match person.id
<deryck> nigelb, so match the list of ids.
<nigelb> deryck: so sprint.attendances.id?
<nigelb> or sprint.attendances.attendee.attendee_id?
<deryck> that one ^^ attendee_id
<deryck> nigelb, and person may have this as well.  person_id or personID.  but even I get confused about which model classes use this.
<deryck> use which form I mean.  so I was just suggesting the direct look up on person to make it easier on you.
<deryck> nigelb, actually, never mind on that person_id thing. that's for related objects
<nigelb> oh
 * deryck is trying to multi-task and it shows
<nigelb> heh
<nigelb> so what should I be now to fix the test?
<deryck> nigelb, my orginal suggestion is still right.  I just meant to ignore my person_id comment.  so....
<nigelb> ah
<deryck> SprintAttendance.attendee_id == Person.id
<deryck> nigelb, ^^ so you need a list of attendee_id's and person ids and compare those lists.
<jtv> jcsackett: one more for the road?  https://code.launchpad.net/~jtv/launchpad/db-bug-782096/+merge/61612
<jcsackett> jtv: sure.
<jtv> thanks
<nigelb> deryck: okay, this is going to be vastly more efficient if I just show you what I have now and if you can point out what needs changing.
<deryck> nigelb, yes, probably so.  sorry :-)
<deryck> jcsackett, hi.  can you do a review for me?
<nigelb> deryck: heh, its okay. http://pad.ubuntu.com/CSDp1HJN53 is what I have.
 * deryck looks
<jcsackett> deryck: sure.
<deryck> nigelb, I think what I've added should work.  minor _id change, and then a little style change....
<deryck> nigelb, we don't use one letter variables, even in list comprehessions.
<deryck> jcsackett, thanks!  https://code.launchpad.net/~deryck/launchpad/keyserver-port-fix-785155/+merge/61609
<nigelb> deryck: okay, ah, didn't know about the style :)
<deryck> nigelb, no worries.  someone would have mentioned it in review, I'm sure.
<jcsackett> jtv: i see that your branch fixes the status issue. how does it solve the ordering issue?
<deryck> nigelb, we also indent functions calls differently.  I'll show you there, too....
<nigelb> aha
<jtv> jcsackett: I wrote an order_by... did that get lost somewhere?
<jcsackett> jtv: i don't see an order_by in the diff.
<deryck> nigelb, assuming I'm still in 79 characters, what I did should work.  make lint in the tree will tell you for sure.
<nigelb> deryck: attendee_id didn't work, but attendee.id did!
<nigelb> deryck: (well, it failed.  But that was the whole point ;) )
<deryck> nigelb, show me the failure in paste please?
<nigelb> okay
<nigelb> deryck: I haven't modified the code yet, so the failure I get now is expected failure I think.
<jtv> jcsackett: no idea where that went then... let me just restore it.
<jcsackett> jtv: ok. :-)
<nigelb> http://paste.ubuntu.com/610165/
<jcsackett> deryck: that's a very small branch, and a very good one. r=me.
<deryck> jcsackett, thanks.
<deryck> nigelb, yup, that looks good.
<LPCIBot> Project windmill-devel build #106: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-devel/106/
<bigjools> good night everyone
<nigelb> night bigjools
<jtv> jcsackett: the diff has finally updated
<jcsackett> jtv: r=me, with the return of the order_by. :-)
<jtv> thanks!
<nigelb> deryck: I changed the code that I was supposed to change to get it to work, still doesn't work :(
<deryck> nigelb, test fails in the same way?
<nigelb> deryck: yeah
<deryck> nigelb, can you paste a diff as it is now?
<nigelb> deryck: bah, ignore me. same problem as earlier. :/
<nigelb> Note to self: Never open devel branch ever.
<deryck> nigelb, ok, np
<nigelb> jcsackett: Hi, could you review https://code.launchpad.net/~nigelbabu/launchpad/203478-meeting-sort/+merge/61623 for me? :)
<jcsackett> sure, looking now nigelb.
<nigelb> Thanks :)
<jcsackett> nigelb: r=me, though i did leave one comment on your MP.
<nigelb> jcsackett: I'll fix that.  What does r=me mean?
<nigelb> jcsackett: (This is my second bug fix to LP :))
<jcsackett> nigelb, sorry, it means i approved your branch. :-)
<nigelb> ah
<jcsackett> when code is landed in lp, the commit is tagged with the reviewer name, (so your branch will land with r=jcsackett)
<nigelb> ah
<jcsackett> "r=me" has become shorthand for "i approve this."
<nigelb> do I need to place the commit message with that tag or is that done by whoever lands it?
<jcsackett> that's done automatically.
<jcsackett> the tags are just added to the commit message you give it in the mp, or the person landing provides.
<nigelb> jcsackett: aha.  anyway, I pushed with the change you mentioned in the MP.  Now I bug someone to land it? ;)
<jcsackett> nigelb: yup, all is good. i can go ahead and send it out, if you like.
<nigelb> jcsackett: please do :)
<jcsackett> nigelb: it's out to the full testsuite and from there to land.
<nigelb> jcsackett: Thanks!
<jcsackett> if it fails the testsuite you and i will both be notified via email.
<LPCIBot> Project windmill-devel build #107: STILL FAILING in 48 min: https://lpci.wedontsleep.org/job/windmill-devel/107/
<jcsackett> actually, you should be notified both for failure or success, but failure is the option requiring you to do more work. :-)
<jcsackett> nigelb, i would expect you to get the email either way in 4 to 6 hours.
<nigelb> heh
<nigelb> so, I shall wake up to an email :)
<abentley> gary_poster: around?
<gary_poster> abentley, hi, yes, but I have call in 7
<abentley> gary_poster: do you know where we configure the python logger to generate oopses?
<gary_poster> abentley, I'm not sure, though some python log configuration is in ./configs/development/launchpad.conf
<abentley> gary_poster: it's wacky, because it appears to be implemented by OopsLoggingHandler, but OopsLoggingHandler isn't used AFAICT.
<gary_poster> abentley, heh, I see what you mean
<LPCIBot> Project windmill-devel build #108: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-devel/108/
<bac> jcsackett: review?  https://code.launchpad.net/~bac/launchpad/bug-777789/+merge/61638
<jcsackett> bac: sure, just a moment.
<bac> jcsackett: thanks
<jcsackett> bac: r=me.
<jcsackett> today has been a number of short branches. i dig it.
<bac> jcsackett: thanks
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build #563: FIXED in 5 hr 34 min: https://lpci.wedontsleep.org/job/db-devel/563/
<LPCIBot> Project windmill-devel build #109: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/109/
<sinzui> jcsackett: do you have time to review https://code.launchpad.net/~sinzui/launchpad/suppress-url-hacker-oops/+merge/61617
<nigelb> http://justanothertriager.wordpress.com/2011/05/20/fixing-launchpad-bugs/ :)
<jcsackett> sinzui: looking now.
<lifeless> statik: hi ?
<lifeless> morning y'all
<jcsackett> sinzui: r=me.
<sinzui> thank you jcsackett
<LPCIBot> Project windmill-db-devel build #296: STILL FAILING in 1 hr 12 min: https://lpci.wedontsleep.org/job/windmill-db-devel/296/
<lifeless> sinzui: I think you are missing a test
<lifeless> sinzui: that may show a bug
<sinzui> oh
<sinzui> lifeless: What needs testing?
<lifeless> code.launchpad.dev
<lifeless> as well as launchpad.dev
<lifeless> we should ignore cross-vhost self links
<lifeless> sorry
<lifeless> we should *not* ignore cross-vhost self links
<sinzui> lifeless: I think the check is does that. I can add a test where the referer is bazaar.launchpad.net and verify that the oops is reported
<lifeless> please
<lifeless> I may be wrong, but it would be lovely to be sure
<sinzui> one moment
<lifeless> (and safe if someone else refactors)
<sinzui> lifeless: This test passes. Is it what you mean: http://pastebin.ubuntu.com/610261/
<sinzui> lifeless: indeed safety  from refactors is important.
<lifeless> ah, I see
<lifeless> so you check that 'launchpad.net' in 'bazaar.launchpad.net'
<lifeless> great.
<lifeless> and yes that test is the key
<lifeless> we could plausibly have one where the server url is code.launchpad.net and the referer 'launchpad.net'
<lifeless> for completeness. I don't know if thats really needed or not.
<sinzui> lifeless: okay, I will add that. Yes the check is  that the mainsite's root url is in the the referer, where I used urlparse to get the netloc of both
<deryck> jcsackett, hi again.  Can you do another smallish review for me?
<jcsackett> deryck: sure.
<deryck> jcsackett, oh, never mind.  lifeless did it already.
<jcsackett> cool. :-)
<deryck> lifeless, would the new low bug not be covered by your related bug 781854?
<_mup_> Bug #781854: oauth consumer banning bans tokens from all users with the same consumer label <Launchpad itself:Triaged> < https://launchpad.net/bugs/781854 >
<lifeless> deryck: well, 781854 might be closed if my analysis is wrong, and if so wouldn't fix the thing about user agent
<lifeless> deryck: *if* we do do 781854, then yes, it would be covered.
<deryck> lifeless, ack.  I'll open a new bug then.
<deryck> just to be safe.
<lifeless> deryck: Alternatively you could change your fix to just use a consumer key like 'anonymous client'
<lifeless> deryck: rather than the user-agent.
<lifeless> and nuke the bit of the test claiming that its needed.
<lifeless> deryck: but I don't want to suggest you do more work :) [OTOH it looks very easy to me]
<deryck> lifeless, yeah, if you don't think that would have unintended consequences, I don't mind making that change.
<deryck> it does look pretty straight forward.
<lifeless> deryck: I can't see any consequences we couldn't change in the future :)
<lifeless> deryck: and user-agent isn't a trustable field anyway
<deryck> lifeless, I meant more of the deryck-will-be-chasing-20-test-failures-tomorrow kind :)
<lifeless> deryck: ah. So we know the test suite passes today.
<lifeless> which means that we use a user agent, or authentication, on all api-exercising tests.
<lifeless> there may be other tests looking for the failure.
<lifeless> But there can't (by definition) be other tests that use the api dependent on the old behaviour - only the tests for the guts of the anonymous support [which consumer is used etc]
<lifeless> so there might be other tests of this behaviour scattered around, but I expect that all fallout would be very shallow
<lifeless> like 'delete that test' shallow
<deryck> lifeless, yeah, I'm okay to give this a try.  I can always revert to what you've approved if there is massive test fallout.
<lifeless> cool!
<james_w> http://blip.tv/ubuntu-developers/ubuntu-uds-o-budapest-friday-plenary-lightning-talks-5182944 at 18:00 is jml's lightning talk
<lifeless> thanks
<james_w> of particular interest to the yellow squad
<deryck> lifeless, how about now?  https://code.launchpad.net/~deryck/launchpad/dont-oops-on-api-without-user-agent-781262/+merge/61662
<deryck> I'm out now.  Later one everyone!
<lifeless> james_w: starts at 17:40
<lifeless> james_w: great applause in it though :)
<sinzui> jcsackett: r=me with the addition of a second test for half-escaped data
<jcsackett> sinzui: dig.
<jcsackett> thanks.
<lifeless> nigelb: flask looks interesting
<LPCIBot> Project windmill-devel build #110: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/110/
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:210 - 0:[######=_]:256
<jcsackett> lifless: you referring to the framework?
<jcsackett> lifeless, rather. :-P ^
<lifeless> yes
<jcsackett> it does seem interesting. i keep wanting to clear up some time to throw something together with it.
<jcsackett> werkzeug, the wsgi library underneath it, is very nice.
<lifeless> a gpg signature checking & secure key creation service would be nice
<lifeless> small isolated, no DB to worry about (but gpg stuff to glue together)
<jcsackett> that would be pretty cool.
<james_w> http://blog.chromium.org/2011/05/ssl-falsestart-performance-results.html
<nigelb> lifeless: Indeed.  Its pretty simple and easy :)
<nigelb> jcsackett: test failed :(
<nigelb> jcsackett: I can't figure out why though :/
<nigelb> hm, I guess he's out of the day
<jcsackett> nigelb: sort of. it's the end of my work day, but i have a call at in 40 min so i'm sort of around. :-)
<jcsackett> just slower to respond, as i'm cooking.
<nigelb> jcsackett: ahh, did you see the failure email?
<jcsackett> i see the failure--it's an easy fix. just update the sort order in the test; since you changed how sorting is happening, the change in the order is expected.
<jcsackett> in a perverse way, this proves your code does what you want it to, nigelb. :-)
<nigelb> ah,the doctests failed?
<jcsackett> yup.
<jcsackett> blueprints/stories/sprints/20-sprint-registration.txt
<jcsackett> at line 148, it prints out the attendees.
<nigelb> haha
<nigelb> of all the things to happen ^-^
<jcsackett> it's actually pretty common that changes to sorts or what text is presented causes this sort of trivial error. it can be a good idea to do a quick search through docs and stories in the module your working in to see if there's anything related that might brewak.
<LPCIBot> Project windmill-db-devel build #297: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-db-devel/297/
<jcsackett> s/brewak/break/
<jcsackett> on the plus side, this is an easy fix for you; just change the ordering in the story to reflect your changes. :-)
<nigelb> I should have run all the blueprint tests once
<jcsackett> nigelb: that can be a good thing to do. i frequently just kick off the unittests i know about and the doc/stories modules.
<nigelb> jcsackett: at this point though, do I need to run the tests locally again? Or can you just re-land it?
<jcsackett> have you pushed up the change?
<nigelb> yep
<jcsackett> cool, i'll land it.
<nigelb> \o/
<jcsackett> nigelb: it'll have to wait till after i finish making dinner though. cooking + landing is a bit difficult. :-P
<nigelb> heh
<nigelb> Well, this time, hopefully, I'll be asleep by the time the mail comes in.
<nigelb> 4 am is a good time to sleep :p
<cjohnston> nigelb, wake up!
<nigelb> cjohnston: bah, wwhy?
<cjohnston> lol
#launchpad-dev 2011-05-20
<sinzui> wgrant: mumble?
<LPCIBot> Project windmill-devel build #111: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/111/
* wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld* (jtv) | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:210 - 0:[######=_]:256
 * wallyworld shakes fist at unity. check email shortcut has stopped working :-(
<thumper> :(
<wgrant> Ah! thumper!
<wgrant> Why does my launcher not auto-hide now?
<wgrant> And then when I start mumble the launcher goes into the background :(
<wgrant> It's all your fault.
 * thumper shrugs
<LPCIBot> Project windmill-devel build #112: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/112/
<wgrant> wallyworld: Are you going to be able to do the ML QA?
<wallyworld> wgrant: sinzui said he was but it's probably past his EOD now. is the rev on staging yet? that's what the holdup was
<wgrant> Ah, a good point.
<wgrant> staging is mid-update.
<lifeless> so how do you delete a blueprint ?
<wgrant> Lalala
<lifeless> ah
<lifeless> definition obsolete
<lifeless> man,
<lifeless> some go back a -long- way https://blueprints.launchpad.net/launchpad/+spec/record-bzr-branch
<wgrant> Should we garden or just disable the feature for LP?
<lifeless> ok I'm officially blind
<lifeless> https://blueprints.launchpad.net/launchpad/+spec/ui-roadmap
<lifeless> I don't have a particular opinion
<lifeless> we're not using it for planning
<wgrant> Ahaha
<lifeless> LEP + bugs seem to serve us well
<wgrant> And that spec is only for Code...
<cjohnston> create a blueprint to remove blueprints?
<lifeless> noooo
<wallyworld_> anyone know if it's possible to dynamically enable/disable the lp rss feed embedded as "<link rel="alternate" type="application/atom+xml" ..."? it seems that once the page loads and the browser has hooked up the rss button, only a page refresh will force an update?
<wgrant> I'm not sure it's possible.
<wgrant> And it's not going to be relevant for very long.
<wallyworld_> ?
<wgrant> No modern browser has the button any more.
<wallyworld_> ff4 does
<wallyworld_> and so does chrome
<wgrant> Which Chrome?
<wgrant> My Chromium doesn't.
<wallyworld_> i'm running the latest google chrome beta
<wallyworld_> why you running chromium and not chrome?
<wgrant> I also don't see it in Firefox 3.
<wgrant> Why would one run Chrome?
<wgrant> s/Firefox 3/Firefox 4/
<wallyworld_> it may not be visible by default but you can drag the button to your toolbar
<wgrant> What benefits does Chrome provide, besides proprietariness and spying?
<wgrant> And a PDF reader.
<wgrant> Which I have a perfect good implementation of already.
<wallyworld_> h.264 i think
<persia> That's in chromium
<wgrant> My Chromium does H.264.
<wallyworld_> i read a while ago what the differences were but have forgotten
<wallyworld_> i thought chrome offered something significant but am not sure now
<persia> Chrome offers Android support, and chromium doesn't, but that's reaching a bit.
<wallyworld_> i think chrome's pdf viewer in inline?
<wallyworld_> is
<wgrant> I don't understand why you'd want to run the proprietary variant from a company known to be information-hungry, without knowing about significant benefits :(
<wgrant> It is, yes. Chrome has a proprietary inline PDF plugin.
<wgrant> But I consider that a misfeature.
<wallyworld_> that is important to me
<persia> Oh, heh.  In January Chrome decided to drop H.264
<wallyworld_> if i'm browsing, i hate external apps popping up
<wgrant> I like my window manager to manage my windows.
<wgrant> Rather than this stupid tabs thing.
<persia> Chrome also has it's own built-in implementation of flash.
<wallyworld_> you don't like tabbed browsing? i can't live without it
<wgrant> wallyworld_: Tabbed applications are a workaround for inadequate window managers.
<StevenK> It reminds me of IE embedding in Acrobat Reader, which just makes me twitch.
<wgrant> (but I do use browser tabs)
<wgrant> (because most contemporary window managers are inadequate)
<wallyworld_> we'll have to have a pub discussion about that wgrant. i can't use a browser without tabs :-)
<persia> most?
<StevenK> Tomorrow, wgrant switches to twm
<wgrant> wallyworld_: http://code.google.com/p/chromium/wiki/ChromiumBrowserVsGoogleChrome
 * wallyworld_ looks
<persia> wallyworld_, This is mostly because you don't have a window manager that makes it easy enough to track things that you don't need to have in-application implementations of window management to be able to cope.
<wgrant> Right. If my applications have to manage their own windows, my window manager is not doing it sjob.
<wallyworld_> persia: perhaps :-) but i sorta like all my web sessions together in the one window frame
<persia> wgrant, On a completely different note, I was pointed to you last week to ask what was required to happen to sbuild in oneiric to not need a separate Soyuz implementation come Querelous Quahog (or whatever)
<wgrant> persia: For multiarch?
<wgrant> Or just in general?
<persia> wallyworld_, Yes, one of the issues with current window managers is that they fail to track whether multiple windows come from the same application and sort it sensibly.
<persia> wgrant, In general.
<wallyworld_> yes. that applies to more than web browsing too of course
<persia> Indeed, which is why there are N implementations of "tabbing" for N applications (which is "doing it wrong")
<wallyworld_> sooo, with the rss stuff, i sadly fear i will have to force a page refresh whenever the user using inline ajax widget to change bug or branch privacy values :-(
<wgrant> persia: Two hacks are still required: the one to copy DDEBs to ~/public_html (which we can possibly externalise if primary archive ddeb support doesn't get finished by a maintenance squad in the next few months), and the one to return extended status info (depwait/chrootwait/etc.)
<wgrant> wallyworld_: That sounds like a major inconvenience for users for such a minor issue.
<persia> So the first is easy with a post-build script.
<wgrant> Right.
<wgrant> The second required something like a 10 line patch.
<wgrant> That I've just somewhere along the line.
<wgrant> just lost.
<wallyworld_> wgrant: yes, agreed :-( but without doing that, the bug is not considered fixed
<wgrant> wallyworld_: Why not?
<wgrant> wallyworld_: It's little worse than someone having a page open, someone else privatising the bug, and then the first person adding the RSS feed without refreshing.
<persia> wgrant, And those should be sufficient?  What was your concern about multiarch?
<wallyworld_> because curtis said so :-) plus it's possible to get an rss feed of a private bug if the page was loaded when the bug was public and the privacy changed inline
<wgrant> persia: Well, once we have non-closed architectures through multiarch, I suspect we'll need to use an sbuild that has a multiarch-capable resolver.
<wgrant> persia: Around a year ago I ported launchpad-buildd to then-current Ubuntu sbuild, and that was all that was required.
<persia> distro sbuild (at least in oneiric) no longer uses the internal resolver by default: it defaults to apt.  Would we expect this to be sufficient?
<wgrant> But then exams happened, and it bitrotted.
<wgrant> I suspect so.
<persia> Cool.  How large was the launchpad-buildd porting patch?
 * persia found the bitrotten branch and investigates
<persia> Thanks a lot for the pointers, and the prior work :)
<wallyworld_> wgrant: i've figured out another solution - if they hit the rss button (because it is enabled when it shouldn't be) i'll just redirect back to the bug/branch page and display a notification. that will suffice
<wgrant> wallyworld_: How can you know that?
<wgrant> Does it request the feed?
<wallyworld_> wgrant: yes, it makes a request to feeds.lp.net
<wgrant> Hopefully it handles an error/redirect sanely.
<wallyworld_> well i'm about to find out
<wallyworld_> i don't know if it will work but it seems like the best thing to try and do
<wgrant> persia: Apart from deleting sbuild, the diff isn't that bad... let's see.
<persia> wgrant, I'm looking at http://bazaar.launchpad.net/~wgrant/launchpad/use-system-sbuild/revision/11151 now : looks smallish.  Needs forward-porting, of course, but it shouldn't be too bad.
<wgrant> launchpad-buildd doesn't change much.
<wgrant> I wonder if I still have that sbuild diff around somewhere.
<wgrant> Otherwise I might try to write it again. It's pretty small.
<wgrant> Just returning a different exit code depending on the failure stage.
<persia> You left it on LP: http://bazaar.launchpad.net/~wgrant/ubuntu/lucid/sbuild/extended-result/revision/26
<wgrant> Hm, the LP diff is only like 140 lines.
<wgrant> Oh!
<wgrant> I had completely forgotten about that.
<wgrant> Thankyou for finding it.
<wgrant> That makes things a bit easier.
<persia> Yes.  We use distributed version control so that we don't need to use our brains.
<wgrant> I was sure I must have had a diff somewhere.
<persia> The goal is to acheive productive senescence.
<wgrant> Since I had clearly deleted it at some point.
<wgrant> I didn't consider I would have pushed a branch.
<lifeless> wgrant: some users will use chrome though
<persia> (or, to misquote someone, real men don't make backups: they just upload to the internet and other people mirror their code)
<lifeless> wallyworld_: there is something I don't understand
<lifeless> wallyworld_: why are you worried about the rss feed link; surely the problem is on the feeds page?
<lifeless> wallyworld_: or perhaps I misunderstand whats going on here
<wgrant> persia: So, I think it all works now except for ddebs.
<wgrant> Which should be easy enough.
<wgrant> Huh.
<wgrant> test_handleStatus_OK_successful_upload just failed on lucid_db_lp too ;(
<wgrant> :(
<wgrant> Curse you, Twisted.
<wgrant> wallyworld_: Looks like staging shoudl have your rev now.
<wallyworld_> wgrant: ok. will quickly finish the mp i'm on first
<wgrant> wallyworld_: Thanks.
<persia> wgrant, You mean "all works now, with the identified patches" or "everything was merged while I wasn't looking except this bit"?
<wgrant> persia: Neither of those branches are merged.
<wgrant> They both must be.
<persia> OK.  I am now unconfused :)
<lifeless> mwhudson: what was the confusing bit about team participation / directory service ?
<jtv> hi wallyworld_âI'm a bit late today
<wallyworld_> jtv: hi, no reviews yet anyway
<wallyworld_> but i'm about to finish a mp myself
<jtv> then I'll take that
<wallyworld_> :-)
<jtv> And you can mentor me.  :)
<jtv> Whoo, looks like I landed 3 branches overnight.
<jtv> We do have a long-running buildbot failure though.
<jtv> https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/966/steps/shell_6/logs/summary
<nigelb> good morning
<jtv> hello nigelb
<nigelb> jcsacket was supposed to re-land this last night, can someone check if its done running through the tests? https://code.launchpad.net/~nigelbabu/launchpad/203478-meeting-sort/+merge/61623
<StevenK> If it isn't marked as Merged, it either failed ec2 or failed PQM
<nigelb> StevenK: It failed once. I fixed and he said he'd reland
<lifeless> mwhudson: I've tweaked, see if its helpful ?
<StevenK> nigelb: Did you get a mail from an ec2 instance?
<nigelb> StevenK: Not yet. But I'm not sure its 4 hours yet.
<nigelb> (Darn, I've had too less sleep :\)
<StevenK> Right. Sadly, we can't check
<nigelb> StevenK: Ah.
<lifeless> sigh
<lifeless> for attendance in self.context.attendances:
<lifeless>     if attendance.attendee == self.user:
<lifeless> whats wrong with this code
<wgrant> Heh
<lifeless> yes, you can break a sprint by having too many attendees
<lifeless> but it will self limit: once we can't late evaluate in the signup form, it won't get worse
<lifeless> ah, I lie. that is eager loaded, but still - should be a direct probe.
<nigelb> that looks like somewhere around code I touched.
<lifeless> Sprint.checkAuthenticated also makes me want to cry.
<lifeless> I wonder if thats where the python time really is going
 * lifeless hopes not
<wgrant> Also I'm not quite sure how that makes sense.
<lifeless> qastaging is down ?
<wgrant> Working for me...
<StevenK> Bwaha
<StevenK> Perl 5.14 is out, and Debian/Ubuntu have yet to finish the 5.12 transition.
<wgrant> Yup.
<wgrant> armel caught up!
<wgrant> The build queues are empty for the first time in two months :)
<StevenK> Gasp!
<persia> Already!  That's fairly early in the cycle.
<lifeless> wgrant: check SprintMeetingExportView . initialize
<lifeless> wgrant: and the cunning combination of passing domain filters in and in-python filtering.
<lifeless> wgrant: I think we have lots of opportunities to make things better here
<wgrant> lifeless: Oh, that is looooovely.
<lifeless> (note that priority is not-null)
<lifeless>     priority = EnumCol(schema=SpecificationPriority, notNull=True
<nigelb> Blueprints are slated to go away in the distant future right? Would sprints go away with them?
<lifeless> no
<lifeless> the functionality is to be kept
<lifeless> but the hard to justify split between blueprints and bugs is to go
<nigelb> ah, okay.
<StevenK> Blueprints and bugs turn into 'issues'
<StevenK> Launchpad has issues
 * StevenK smirks
<wgrant> Yes.
<nigelb> Launchpad has *lots* of issues :p
<lifeless> hmm, I think we have two 'reload' helpers ><
<wgrant> Probably.
<lifeless> bulk has one
<lifeless> and I think someone added one to testing
<lifeless> (a broken one)
<lifeless> can has revue ?
<jtv> lifeless: wallyworld_'s on call.
<lifeless> wallyworld_: oh hai - https://code.launchpad.net/~lifeless/launchpad/bug-784988/+merge/61697
* lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld* (jtv) | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:222 - 0:[######=_]:256
<wgrant> lifeless: Lies.
<wgrant> lifeless: Lots of those are escalated.
<wgrant> Freshly.
<wgrant> SO they do not count for the goal that matters :)
<StevenK> What was it before?
<lifeless> the previous figure was 210
<lifeless> wgrant is about to close a bunch
<lifeless> and I'll update it then
<wgrant> Indeed.
<wgrant> Was just opening the page.
<wgrant> Fail.
<wgrant> Whole lot criticals landed on qastaging half an hour ago :(
<lifeless> well, thats my critical for the day up for review
<lifeless> see you all monday
<wgrant> Night lifeless.
<jtv> by lifeless!
<jtv> *bye
<jtv> StevenK, wgrant: is "<" a total ordering on debversions?
<jtv> In other words, if not (x < y) and not (y < x), does that mean they're equal?
<wgrant> No.
<wgrant> There are some equivalent versions :(
<wgrant> well.
<jtv> Equivalent ain't so bad I guess; it's unordered version pairs that I'm worried about.
<wgrant> Those equivalent debversions will compare identically, but the string representations differ.
<jtv> wgrant: I don't think what you just said has any bearing on the question, come to think of it.
<wgrant> jtv: Two different versions compare identically.
<jtv> Yes, but I'm asking about the case where two versions do not compare as x < y or y < x.
<wgrant> It depends what you mean by equal.
<jtv> True.
<wgrant> They will be equal, but not the same.
<jtv> So does this imply that it _is_ possible to have an unresolved DSD where the versions are "equal"?
* wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld* (jtv) | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs: 217 - 0:[######=_]:256 (-5 non-pie-critical)
<jtv> Or are the equivalent versions considered equal for all intents and purposes?
<wgrant> It depends how the versions are compared.
<wgrant> Some parts of Soyuz treat them the same.
<wgrant> Some don't.
<StevenK> Awww, only 217
<jtv> This worries me somewhat.
<wgrant> Fortunately such versions are rare.
<wgrant> Yes.
<wgrant> It causes non-deterministic domination.
<wgrant> Which is rather unfortunate, quite unobvious, and entirely unhelpful.
* wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld* (jtv) | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs: 212 - 0:[######=_]:256 (+5 non-pie-critical)
<StevenK> wgrant: You know how the versions are compared for DSDs, since we wrote The Plan
<wgrant> StevenK: I don't.
<wgrant> I know how the base version is calculated.
<wgrant> I don't know how you compare the versions.
<StevenK> if self.source_version == self.parent_source_version:
<wgrant> What are they?
<wgrant> debversions or strs?
<wgrant> s/strs/unicodes/
<StevenK> They are both debversions
<wgrant> In Python?
<jtv> Do we have a clear definition of the comparison operators for those?
<StevenK> wgrant: No, the postgres type
<wgrant> Bug #654878, for reference.
<_mup_> Bug #654878: Should reject uploads with equivalent versions <boobytrap> <lp-soyuz> <soyuz-upload> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/654878 >
<jtv> And is it possible for two versions to have no conclusive ordering at all?  In other words, where not x < y and not y < x but we're also not sure that they're equivalent?
<wgrant> NAFAIK
<wgrant> I think equivalence is defined here as !(x < y || y < x)
<wgrant> Pretty much.
<jtv> And people complain about SQL's 3-way logic... it's perfect for this sort of thing!
<wgrant> Die, foul demon.
<jtv> Come on, would you rather have a false certainty than an honest null?  Face the chasm, discard your illusions!
<jtv> Meanwhile, I forget... did +localpackagediffs also show packages that are missing from, or specific to, the derived series?
<StevenK> No
<StevenK> There are seperate smaller pages for those
<jtv> Then my check for "don't offer to sync packages that are newer in the child" doesn't need testing for the one-sided DSDTypes.
<LPCIBot> Project windmill-devel build #113: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/113/
* lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld* (jtv) | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:217 - 0:[######=_]:256
<LPCIBot> Project db-devel build #565: FAILURE in 5 hr 13 min: https://lpci.wedontsleep.org/job/db-devel/565/
<henninge> wgrant: Hi! What's not-pie-critical?
 * StevenK smacks lifeless 
<StevenK> Stop that!
<jtv> wallyworld_: how's your MP coming?  Meanwhile I've got a small one of my own up that you could review (but someone else would have to mentor it, of course): https://code.launchpad.net/~jtv/launchpad/db-bug-783435/+merge/61703
<wgrant> lifeless: Such a graph is not of significant value if it can be arbitrarily massively inflated by stakeholders. Newly escalated bugs shouldn't count as part of the tech-debt critical pile, or we will never get anywhere!
<wallyworld_> jtv: stupid doc test giving me the shits. i'll look at yours first
<jtv> wallyworld_: when in doubt, kill it off.  :)
<jtv> The doctest that is, not my MP!
 * jtv has seen wallyworld_ with a big scary rifle...
<wgrant> (seeing the counter go backwards through no fault of ours is rather demotivating)
<wallyworld_> jtv: i'm thinking about it
<jtv> uh-oh
<wallyworld_> jtv: do distro series packages always have numeric version numbers? like 1.0 1.1 etc?
<jtv> wallyworld_: no, they're full Debian version strings such as 0.999c-ubuntu9
<jtv> and they have their own comparison operators.
<jtv> They may have multiple dots, too.
<wgrant> eg. 1:1.2-3~beta2+really1.2-2~rc1+git20110223-2.3ubuntu4.5~hardy1+ppa1
<wgrant> Which is depressingly not *that* contrived. :/
<wallyworld_> jtv: perhaps the tests could use some version strings other than '1.0' to make that explicitly clear for noobs like me?
<jtv> wallyworld_: this seems a bit of an arbitrary place to make that explicit, to be honestâI'd rather that the "oh this one's newer than that one" be instantly clear here.
<wallyworld_> jtv: and will a simple < be the correct comparison operator?
<jtv> Yes, because it's the most conservative comparison.
<jtv> (C++ background helps here :)
<wgrant>     parent_source_version = StringCol(dbName='parent_source_version',
<wgrant>                                       notNull=False)
<wgrant> That's not going to work.
<wallyworld_> i know how < works in C++ but wasn't sure if the version strings would always start with a perfix that made sense to compare
<wgrant> They may be debversions with a correct < in the DB, but in Python they are just strings.
<jtv> I'm thinking not so much about how < works in C++, but how it is used: the less<> template, and its consistent use as the only comparison operator in ordered containers etc.
<wgrant> You may want to use apt_pkg.VersionCompare.
<wgrant> Or cast them to debversions in Python too.
<jtv> wgrant: oh, they're not debversions in memory?
<jtv> That's worrisome because I cribbed this from other code.
<wgrant> jtv: No, they're normal stringcols.
<wgrant> debversion in the DB is very new.
<jtv> Or at least, I verified that other code also did straightforward comparisons.
<wgrant> jtv: Yes, and lots of code is wrong :)
 * jtv trembles with joy
<wallyworld_> joy or something else :-)
<jtv> wallyworld_: I think I'll try to contrive a test then where a string comparison would give the wrong answer.
<nigelb> okay, the merge I was talking about earlier did land successfully :)
<wgrant> nigelb: Great!
<nigelb> That's 2 bug fixes in a week \o/
<wallyworld_> jtv: that would make me happier since i get the impression there's a lot that could go wrong in this area
 * wallyworld_ knows way too little about debian packaging :-(
<jtv> wallyworld_: it seems there is.  This is where a C++ background is a bad thing because it instills far too much trust in the type system.  :)
<wallyworld_> i hear you :-)
 * wallyworld_ reboots. stupid unity :-(
 * jtv ones worked at a project where a compiler upgrade from 4.x to 5.x revealed that the central object cache lookup had been comparing numeric ids to pointers all along
<jtv> *once
<jtv> Damn, I've gone dyslexic.
<StevenK> Gone?
<nigelb> hrm has the topic become stale? I see only 190 critical bugs
<wgrant> nigelb: This is over all of launchpad-project.
<wgrant> And there are a few private bugs.
<wgrant> I see 196 critical bugs in the launchpad project itself.
<wgrant> 214 bugs, 217 bugtasks in launchpad-project overall.
<nigelb> ah
<nigelb> I see 208 critical bugs now
<nigelb> I'm curious, why is bug 500015 critcal?
<_mup_> Bug #500015: IE js error in filebug <dhrb> <ie> <javascript> <lp-bugs> <oem-services> <story-ajaxify-dupe-finder> <Launchpad itself:Triaged> < https://launchpad.net/bugs/500015 >
<wgrant> nigelb: It's a JS exception that would be an OOPS if we had a JS OOPS system.
<nigelb> Ah.
<wgrant> So it is an honorary beneficiary of ZOP.
<nigelb> any more easy critical bugs left? ;)
<wgrant> You could look for critical bugs tagged easy or trivial.
<lifeless> wgrant: we don't accept all escalations, so its not arbitrarily inflated
<wgrant> sinzui tagged a few earlier in the week, but most have since been squashed.
<wgrant> lifeless: It is uncontrollable reversal of the countdown.
<wgrant> That is silly.
<lifeless> anyhow, my issue is much more pragmatic
<wgrant> We're just about always going to have *something* in the critical queue. I think the burndown should track the backlog.
<lifeless> I don't have a query to get the 'right' count (whatever that may be defined as - and I don't want to debate it right now - family time) with any reasonable ease
<wgrant> Or what's the point?
<wgrant> Perhaps.
<lifeless> theres a few factors and we should talk about it more on Monday
<lifeless> gotta run
<wgrant> Night!
<jtv> bye again lifeless
<nigelb> is it just me or is the wording in bug 659184 complicated?
<_mup_> Bug #659184: IntegrityError: duplicate key value violates unique constraint "ticketmessage_message_ticket_uniq <email> <lp-answers> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/659184 >
<nigelb> I can't make head or tail of what's said there.
<wgrant> It's also a duplicate.
<wgrant> I understand what's going on there, but is it easier if you read the dupe?
<wgrant> s/dupe/master/
<nigelb> okay
<nigelb> heh, the master has copy paste of what's said in the dup :p
<wgrant> Bah.
<wgrant> Well.
<wgrant> MessageSet.fromEmail looks up the message ID and content, and checks if there's an existing identical Message in the DB.
<wgrant> If there is, it just links it in as a comment (with a BugMessage or QuestionMessage) rather than creating a new Message object and linking that.
<wgrant> But there is a UNIQUE constriant on BugMessage(bug, message) and QuestionMessage(question, message).
<wgrant> If it receives an identical email twice to the same bug or question, it will try to link the same Message twice, and run afoul of that constraint.
<nigelb> and the solution is?
<wgrant> Possibly just ignoring a second attempt to link a message to a bug.
<nigelb> this needs more read of code that I'm capable right now.
<nigelb> will read at home.
<adeuring> good morning
<StevenK> wgrant: What's fiera used for?
<StevenK> I can't recall
<jtv> wallyworld_: having some lock problems with that branch.  Hope to have an updated diff in a few minutes.
<wgrant> StevenK: It's buildd-manager.
<wallyworld_> jtv: ok. i just got my tests passing so will finish the mp. but i may have to cook dinner first
<jtv> OK
<StevenK> Ah
<StevenK> wgrant: Perhaps it needs to go the way of the lucille DB user :-)
<wgrant> StevenK: Indeed, but I broke production for a few minutes with that one, so I am a bit more wary now.
<StevenK> Whee
<StevenK> wgrant: Wait, with lucille or fiera?
<wgrant> StevenK: lucille
<jtv> wallyworld_: diff has updated.
<StevenK> wgrant: Clearly she didn't want to die
<LPCIBot> Project windmill-devel build #114: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/114/
<wallyworld_> jtv: ack. will look after cooking. just typing up mp and will light the bbq after hitting submit :-)
<jtv> wallyworld_: by all means don't multitask while lighting stuff on fire.  :)
<StevenK> Unless it's Soyuz code
<jtv> No, even then.
<nigelb> heh
<mrevell> Hello
* adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:217 - 0:[######=_]:256
<bigjools> stub: can I have a db patch number please?
<stub> 2208-72-0. Can you give me a two word description for my notes?
<bigjools> stub: ta. converting textual version columns in DistroSeriesDifference into debversion types
<stub> ta
<bigjools> stub: sorry, scratch that.  jtv told me porkies, they are already debversions...
<wgrant> It's in Python that they're just strings.
<bigjools> yes
<jtv> I managed to get different results from DSD.source_version < DSD.parent_source_version than from Version(DSD.source_version) < Version(DSD.parent_source_version).
<wgrant> Sure.
<wgrant> In the DB they are debversions.
<wgrant> But they come back Python as normal strings.
<bigjools> apt_pkg.VersionCompare is what we need
<jtv> Anybody willing to mentor wallyworld_'s review?  I've got a conflict of interest on this one: https://code.launchpad.net/~jtv/launchpad/db-bug-783435/+merge/61703
<jtv> (Thanks Ian)
<jtv> bigjools: if it gets this subtle, I'd definitely like to have a DSD.child_is_newer or something along those lines.
<bigjools> jtv: +1
 * jtv has to be off now
<bigjools> thanks jtv
<jtv> wallyworld_: won't be able to finish that review now... mind if I put it off?
<stub> Consider adding a psycopg2 type conversion hook to give you some sort of version object instead of a string. I think documentation may even exist now!
<jtv> bigjools: I think you've got enough new work to keep you happy for a bit.  :)  I can pick it up Monday, but also won't be offended if you grab another reviewer.
<bigjools> jtv: well approve with changes recommended? :)
<jtv> OKOKOK
<jtv> Good weekend everyone!
<bigjools> StormBase classes have @cachedproperty invalidation working, right?
<bigjools> ah yes
<gmb> danilos: Does the test failure for the latest build make any sense to you? It looks like a translations thing but it could just be noise as far as I know: https://lpbuildbot.canonical.com/builders/lucid_lp/builds/965/steps/shell_6/logs/summary
<danilos> gmb, looking
<gmb> Ta
<danilos> gmb, that's not a translation test (test_handleStatus_OK_successful_upload in test_sourcepackagerecipebuild)
<danilos> gmb, translation tests do spit out some nonsense there which seems not to be parsed out by the test handler
<gmb> danilos: Ah, right. I was seeing all the references to lp.translations and reaching the wrong conclusion. Okay, thanks.
<wgrant> gmb, danilos: That's failed twice on lucid_lp and once on lucid_db_lp today. poolie touched it a few days ago; you may want to disable it for now.
<wgrant> Or work out why it's not working.
<gmb> wgrant: I'll try (2) but I suspect (1) is what I'll end up doing.
<gmb> Looking now.
<rvba> stub: Hi! Could you please review this db-patch when you get a chance: https://code.launchpad.net/~rvb/launchpad/dsp-order/+merge/61727
<rvba> stub: I'm very sorry to submit these db patches bits by bits like this ... but I confess I am figuring this whole thing bits by bits as well ;).
<wgrant> gmb: It's not reproducible locally.
<wgrant> gmb: At least not when run in isolation.
<wgrant> gmb: It may be using a constant path that has been polluted on the slaves.
<gmb> wgrant: Ah, okay. Disabling seems sane then.
<gmb> For now at least.
 * gmb goes to work
<wgrant> :( more Criticals :(
<wgrant> Thanks.
<gmb> wgrant: Less pie for Jono.
<bigjools> Jono is not allowed to file Critical bugs :)
<gmb> :)
<stub> rvba: looking
<poolie> nigelb: congratulations on your landing!
<rvba> stub: Julian suggested to change the index to "btree(derived_series, ordering)"
<stub> rvba: Yes, that will be better. If you list the columns in that order, the index still allows fast lookups just by id.
 * gmb -> early lunch
<stub> rvba: The existing index can also be used to lookup rows just by derived_series (no ordering), but it is slower.
<rvba> stub: Just pushed the correction. Not sure I understand how this index affects lookups by id. Would you care to explain it to me?
<stub> This index does not affect lookups by id. Lookups by id will use the implicit index created for the primary key (distroseriesparent_pkey)
<stub> I'm talking about a query like 'SELECT * FROM DistroSeriesParent WHERE derived_series=42 ORDER BY ordering'.
<rvba> Ah ok, I get it now.
<stub> (I suspect we won't use the index at all because I doubt there will be more than half a dozen parent series)
<nigelb> poolie: Thanks!
<rvba> stub: I suppose you are right ... but God knows what OEM will do with this (I'm paraphrasing Julian here).
<poolie> nigelb, there was another one recently touched which is vaguely similar
<poolie> which is just to have a "delete this project" button that takes you to a help page explaining you should open a support request
<poolie> or i guess that's also a bit like what mrevell did recently
<stub> rvba: We keep the new index though, because it *might* be useful and it makes another one redundant, so we don't lose much space or write performance.
<nigelb> poolie: I saw that bug last night when looking for next candidate
<rvba> statik: Understood. Thanks a lot for your explanation.
<rvba> oops ... s/statik/stub/
<stub> approved
<cjohnston> henninge: https://code.launchpad.net/~chrisjohnston/launchpad/197793/+merge/61053
<henninge> cjohnston: would you like me to land that? (Although I thought somebody was already doing that)
<cjohnston> I don't think anyone has gotten to that one.... If you would that'd be great.
<henninge> cjohnston: what about this one? https://code.launchpad.net/~chrisjohnston/launchpad/483373/+merge/61042
<henninge> cjohnston: it just needs one line.
<henninge> icon='edit'
<bigjools> wgrant: can you think of anything clever we can do to make >, < and = DTRT on versions, without having to remember apt_pkg?
<stub> bigjools: Storm column type. Even register the type with psycopg2 to get a custom object for non storm code.
<cjohnston> henninge: done.. sorry.. been a busy week
<bigjools> yeah we'd at least need a new type so we can define operators
<henninge> cjohnston: ok, cool. I'll do that after lunch.
<cjohnston> :-
<cjohnston> )
<stub> bigjools: Looks like you define a variable, per storm/variables.py and a SimpleProperty per storm/properties.py - both look pretty trivial actually. And your custom class defining __str__ and __cmp__ and friends of course.
<bigjools> stub: coolio
<stub> rvba: Just added a fresh column to that MP. I believe the new index should be UNIQUE
<stub> rvba: Except that will make reordering a pain in the bum I guess.
<rvba> stub: makes sense ... I must say I hesitated to make the index unique. Reordering is exactly the reason why I decided not to do it :).
<bigjools> make the default 10
<bigjools> should then be obvious how to re-order :)
<stub> rvba: Yer. Maybe we should keep it the way it is for practicality.
<rvba> stub: agreed.
<rvba> stub: Besides, the reordering will be done in a fancy js UI. It will be tricky (but possible) to manage transaction from there.
<rvba> s/transaction/transactions/
<stub> You still need to swap two rows using a temporary value since you can't defer the UNIQUE check until the transaction end.
<rvba> stub: Good point. I'll be careful when doing the js part..
<lifeless> rvba: you are -so- not going to manage transactions from js.
<rvba> lifeless: sure, I'll do the reordering thing inside a view.
<lifeless> rvba: perhaps you mean something very different to what it reads as.
<lifeless> rvba: much saner :)
<rvba> lifeless: ;)
<lifeless> *yawn* night all
<rvba> lifeless: good night.
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring, bac | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:217 - 0:[######=_]:256
<bac> morning adeuring
<adeuring> morning bac!
<LPCIBot> Project windmill-db-devel build #298: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-db-devel/298/
<LPCIBot> Project windmill-devel build #115: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/115/
<bigjools> I get so excited when I see lots of red in a merge proposal diff
 * jml too
<nigelb> hehe
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build #566: FIXED in 5 hr 15 min: https://lpci.wedontsleep.org/job/db-devel/566/
<adeuring> bac: could you please review this mp: https://code.launchpad.net/~adeuring/launchpad/bug-739065-2/+merge/61768 ?
<bac> adeuring: yes, i'll get right on it
<adeuring> bac: great, thanks!
<bac> adeuring: do you really need to specify the main store or should you use the store of the object?
<adeuring> bac: right, I can use Store.of(self.distroseries)
<adeuring> (self itself is not a Storm object)
<adeuring> erm, DistroSeriesSourcePackageRelease is not a storm object
<bac> flacoste: you're probably unaware but you're sending out html email again with a tiny font
<flacoste> bac: shit, thanks for telling me
 * flacoste curses kmali
 * bac puts his glasses away
<adeuring> bac: thanks for the review!
<bac> np
<deryck> flacoste, Aren't security bugs always marked critical?
<flacoste> deryck: i think they should yeah
<deryck> flacoste, should I update the BugTriage wiki page then?
<flacoste> deryck: yes, please
<deryck> ok, will do.
<danilos> adeuring, bac: anyone got time to take on https://code.launchpad.net/~danilo/launchpad/bug-772763-remove-unmute-dialog-part1/+merge/61775?
<adeuring> danilos: sure, I'll look
<danilos> adeuring, thanks
<danilos> adeuring, let me know if you've got any questions
<adeuring> danilos: the last line in test_bug_mute_self_view_unmutes_bug() looks odd: self.assertTrue(self.bug.isMuted(self.person)) Since the bug is unmuted, shouldn't this be assertFalse()? Or am I simply confused?
<danilos> bac, I know you're jealous that adeuring picked that one up first, so I've prepared one for you as well: https://code.launchpad.net/~danilo/launchpad/bug-772763-remove-unmute-dialog/+merge/61780 :P
<bac> danilos: :)
<bac> be glad to look at it
<danilos> adeuring, checking
<danilos> adeuring, the create_initialized_view actually submits the form
<danilos> bac, thanks
<adeuring> danilos: yes, but that's an unmute operation, right? So, afterwards, the bug shoulld be unmuted, I think
<danilos> adeuring, good point, let me check
<danilos> adeuring, indeed, you've found a buggy test, thanks; the form action should be "field.actions.unmute", not "field.actions.mute"
<adeuring> danilos: ahh, I missed this detail ;)
<danilos> adeuring, incremental diff: https://pastebin.canonical.com/47682/
<danilos> adeuring, not at all, you've seen an inconsistency :)
<adeuring> danilos: in line 250 of the diff, you mention a bug. Isn't this worth an XXX?
<danilos> adeuring, I believe that's not "my" code, that bug is in progress (landed then reverted)
<danilos> adeuring, the reversion caused the issues, I'll remove that from my branch
<adeuring> danilos: ah, ok.
<adeuring> danilos: r=me. thanks for the additional change!
<danilos> adeuring, thanks, very much appreciated!
<jcsackett> henninge: i'm looking at bug 504062, about the "used in" link for deactivated templates. the oops for it is no longer there, so i was wondering if you could point me to where this error actually occurs?
<_mup_> Bug #504062: External suggestion "used in" links to disabled template <404> <lp-translations> <oops> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/504062 >
<danilos> bac, I'll be running out in a few, since it's basically gary_poster's branch, I am sure you can defer to him for the questions as well; I hope you don't mind me not really being around for the OCR, and if you do, I apologize!
<bac> np, danilos
<LPCIBot> Project windmill-db-devel build #299: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-db-devel/299/
<bac> just used my newly minted powers to hide bug comment spam.  felt good.  thanks green squad!
<jcsackett> bac: You're welcome!
<poolie> mrevell: still here?
<mrevell> Hello poolie
<poolie> i was just contemplating a blog post to celebrate the landings from nigelb, and um charles
<nigelb> poolie: chris?
<poolie> sorry, chris
<nigelb> heh
<poolie> chris is the other non-core contributor who got patches in this week
<poolie> oh i see
<mrevell> poolie, If you have something in mind already I think that would make a great blog post. If you're not offering to write it then I can do so next week.
<poolie> :) i might
<poolie> it is somehow easier to write praise of projcets other than your own
<mrevell> :)
<bigjools> night folks, have a good weekend
<poolie> nigelb: was that in fact your first landing?
<nigelb> poolie: which one?
<nigelb> poolie: I've had 2 landings so far, one I believe is already in production, one I just qa'd on qastaging
<bac> nigelb: nice blog post about your initial lp work!
<nigelb> bac: :)
<nigelb> bac: Not sure if you remember, but I think I sat next to you for the opening keynote :p
<nigelb> (it just clicked how your nick was familiar)
<bac> nigelb: ah yes.  you, me, jane i believe
<nigelb> yup :)
<bac> was nice to meet you
<nigelb> you too :)
<nigelb> Bah, this isn't right.
<nigelb> Meeting attendees should be sorted by display name https://bugs.edge.launchpad.net/bugs/203478 You received this bug notification because you are a bug assignee.
<_mup_> Bug #203478: Meeting attendees should be sorted by display name <easy> <lp-blueprints> <qa-ok> <sprints> <ui> <Launchpad itself:Fix Committed by nigelbabu> < https://launchpad.net/bugs/203478 >
<nigelb> Got this in my mail.  shouldn't the edge link be deprecated?
<sinzui> Edge is deprecated.Users are accessing it via bookmarks and offsite links. We will shut it off in a few weeks
<nigelb> sinzui: I got a link to edge in my mail
<sinzui> Because someone used edge. Mail came from that server
<nigelb> PQM!
<sinzui> No, more likely the tagging api script
<sinzui> PQM does not know about any website
<nigelb> sinzui: "Launchpad QA Bot (lpqabot)" is what assigned the bug to me
<sinzui> yep, Ursinha-afk  lpqabot will break when we turn edge off
<nigelb> sinzui: heh, I thought it was a bug I could fix
<sinzui> nigelb: there is not a formal definition of trivial verses easy, but many of use mean trivial is fixable in an hour and may not need a test. easy means fixable in a day
<nigelb> sinzui: aha, I've been fixing the easy ones, I didn't know trivial were easier than that ;)
<sinzui> When I start a bug that is labeled trivial, but realise it is not, I stop work and update the bug about why the work is more complicated
<LPCIBot> Project windmill-db-devel build #300: STILL FAILING in 47 min: https://lpci.wedontsleep.org/job/windmill-db-devel/300/
<LPCIBot> Project devel build #739: FAILURE in 20 min: https://lpci.wedontsleep.org/job/devel/739/
<jcsackett> sinzui: i'm looking at bug 252172, but i'm not sure it's entirely accurate anymore. i don't see any control as described in the bug.
<_mup_> Bug #252172: Changing a branch's status/privacy isn't obvious <confusing-ui> <disclosure> <easy-ui> <privacy> <Launchpad itself:Triaged> < https://launchpad.net/bugs/252172 >
<UrsulaJ> sinzui, why is that? (lpqabot break when we turn edge off)
<jcsackett> UrsulaJ: i believe sinzui determined that qatagger was using edge based links.
<jcsackett> see nigelb's comments above.
<sinzui> UrsulaJ: As reported in the scrollback, nigelb got email from edge. A person or a bot used edge to update the bug. It looks like the bot
<UrsulaJ> hm, qatagger doesn't send email
<UrsulaJ> it might be using edge api instance
<sinzui> No, it updates a bug, then the server sees the update and sends an email
<UrsulaJ> sinzui, edge api is the problem then
<sinzui> If it is not used edge api, then all is goof
 * UrsulaJ goes fix
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:217 - 0:[######=_]:256
<nigelb> ahoy
<nigelb> can someone help me figure out where is the painpoint to fix bug 90628?
<_mup_> Bug #90628: Subscribers to a spec are randomly arranged <easy> <lp-blueprints> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/90628 >
<nigelb> I've been looking at the source for an hour or so and I'm still lostt
<nigelb> *lost
 * sinzui looks
<sinzui> nigelb: is that still true?
<nigelb> sinzui: being lost? yes
<sinzui> we do not sort the subscribers by displayname?
<nigelb> nope, not on BPs
<nigelb> https://blueprints.launchpad.net/loco-directory/+spec/community-o-loco-directory
<nigelb> its sorted by order subscribed.
<sinzui> excellent.
<nigelb> and I just noticed another bug, where if you subscribe a team, LP thinks the person is invalid.
 * sinzui looks for SpecificationSubscription, or something like that
<sinzui> nigelb: um, I have a nasty suspicion that there is no code to manage this, so that is why we see order by db id. We might be able to define an order in the Specification Model, or we want to create a property to get them ordered.
 * sinzui looks further
<nigelb> sinzui: that's what I felt too.  take a look at subscriptionnavigation
<nigelb> erm
<nigelb> SpecificationNavigation rather
<sinzui> nigelb: Things are not that bad. I am looking at line 184 in model/specification.py
<nigelb> *whee*
<sinzui> There is subscriptions and subscribers. The former is by id, the later is right
<sinzui> The portlet must be using the first one
<sinzui> well I hope it is
<nigelb> yeah, it is
<nigelb> I saw that bit in the template and I couldn't figure where it was getting that
<sinzui> I wonder if it does that because it wants to know something about the subscription and not the person
<sinzui> That markup is nasty
<sinzui> It dates from the Lp beta I think.
<sinzui> lets see if we can make subscriptions ordered
<nigelb> okay!
<sinzui> This is ancient code. This is a pretty easy query to construct in storm, but I have not worked with this SQLObject code in a long time. I think we need to change the subscriptions attribute from a MultiJoin to a property that returns the subscription (and precaches the person)
 * sinzui looks up SQLMultipleJoin
<lifeless> sinzui: hi
<sinzui> hi lifeless
<lifeless> sinzui: precaching the persons on subscription?
<lifeless> sinzui: will interact with https://code.launchpad.net/~lifeless/launchpad/bug-784988/+merge/61697 which is playing in ec2 now
<sinzui> the person because we need the subscriptions
<lifeless> if you're going to show all the people anyway, sorting in python is ok
<lifeless> if you're not, then sorting in the db is definitely preferred
<nigelb> sinzui: do you want me to look at how sprint attendees in sprint and try and reuse that code here?
<nigelb> *sprint functions
<lifeless> sinzui: the interaction I'm thinking of is that we don't want to eager-load the people twice - once per spec, and once for the entire group
<sinzui> nigelb: I think you need to delay working on this since the code is different. I do not see how Specification gets a .subscriptions attr now
<lifeless> sinzui: shouldn't be hard to avoid
<nigelb> sinzui: wait for Monday? :)
<lifeless> sinzui: you mean that _subscriptions is a multi join, but there is no 'subscriptions' property-or-join?
<sinzui> lifeless: how did you *not* break specification-portlet-subscribers. It is referencing that attr on Specification
<lifeless> sinzui: I may have, ec2 will tell me.
<lifeless> hah, that was not meant to be committed
<lifeless> I was going to add a cachedproperty there
 * lifeless backs that out promptly :)
<nigelb> heh
<nigelb> sinzui: I'll head to bed now then, and be back Monday/Tuesday to tackle this again :)
<sinzui> goodnight nigelb
<lifeless> sinzui: thanks for noticing that
<nigelb> night sinzui, thanks for looking into this :)
<sinzui> np, It is nice that we talk about these things before the code is commited
<LPCIBot> Project windmill-devel build #116: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/116/
#launchpad-dev 2011-05-21
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build #740: FIXED in 5 hr 37 min: https://lpci.wedontsleep.org/job/devel/740/
<LPCIBot> Project windmill-devel build #117: STILL FAILING in 47 min: https://lpci.wedontsleep.org/job/windmill-devel/117/
<maxb> Anyone around who knows: Is the LP API *supposed* to accept anonymous read requests without any OAuth authorization header at all?
<lifeless> I hope so
<maxb> This is rather weird. I get a HTTP 400 Bad Request saying 'distro_series: No such object "/ubuntu/natty".' - but if I add an incredibly bare-bones Authorization: OAuth header, it works
<maxb> Requests that don't involve any parameters that are links to other API objects complete fine without the OAuth header
#launchpad-dev 2011-05-22
<wgrant> maxb: poolie saw something strange like that a while ago.
<wgrant> maxb: We didn't make the Authorization header connection, though.
<wgrant> It was noticed only as a difference between launchpad.net/api and api.launchpad.net... the reason now becomes obvious.
<wgrant> Ah, I see you found that bug.
<wgrant> I guess squid must be being crap.
<lifeless> wgrant: !cite
<wgrant> Aha, it worked.
<wgrant> I knew that would wake you up.
<wgrant> But it seems that requests going through squid are broken, requests not going through squid are not broken.
<wgrant> A bit suspicious.
<lifeless> or
<lifeless> it could be faulty interaction setup in anonymous api requests
<wgrant> Doesn't affect staging/dogfood/qastaging/dev.
<lifeless> interesting
<wgrant> Precisely.
<lifeless> so, lets get the squid config
<wgrant> That was the plan.
<wgrant> NFI what it could be.
<lifeless> also we should get squid (tiny cache) in front of qastaging with the analogous config
<wgrant> Was going to check appserver logs.
<wgrant> But they are big :(
<lifeless> gnar
<lifeless> 3% packet loss
<wgrant> Where?
<lifeless> hth am I meant to raid like this
<lifeless> my adsl
<wgrant> Bah, there's like a hunred appserver logs now.
<lifeless> (actually, it may be higher, its 3% on first hop pings; 5% second, 4% on the target server
<lifeless> oh -yay-
<lifeless> just observed a 20s rtt
<wgrant> Hm?
<wgrant> Yay
<lifeless> not ms
<lifeless> s
<wgrant> Yeah.
<lifeless> 2400ms stddev on ones internet is Not Good
<wgrant> :(
<lifeless> win
<lifeless> 3K
<wgrant> Grar devpad is still BST.
<wgrant> Ahhh
<wgrant> I think I may see.
<wgrant> Yeah.
<wgrant> Squid puts a port in the hostname.
<wgrant> 3128
<wgrant> That breaks lazr.restful.
<wgrant> Somehow.
<wgrant>         url_host_and_http_host_are_identical = (
<wgrant>             host == request_host and port == request_port)
<wgrant>         if (not url_host_and_http_host_are_identical
<wgrant>             or protocol != site_protocol or query is not None
<wgrant>             or fragment is not None):
<wgrant>             raise NotFound(self, url, self.request)
<lifeless> sigh
<wgrant> lazr.restful turns the path into a URL by appending it to the service root. Then it checks that the URL matches the request.
<wgrant> We should stop squid from inserting the :3128, I guess.
<lifeless> I'm just looking for the bug
<wgrant> As am I.
<wgrant> There we are.
<lifeless> u found it?
<wgrant> Bug #714038
<_mup_> Bug #714038: strange "no such object" error on unauthenticated api calls with parameters referring to other objects <api> <Launchpad itself:Triaged> < https://launchpad.net/bugs/714038 >
<lifeless> the squid bug
<wgrant> It's a squid bug, not an apache/squid config bug?
<lifeless> its a feature IIRC
<wgrant> Pardon?
<lifeless> exactly
<lifeless> https://bugs.launchpad.net/collective.buildout/+bug/438694
<_mup_> Bug #438694: squid.conf and Squid 2.6 vs. Squid 2.7 <collective.buildout:New> < https://launchpad.net/bugs/438694 >
<wgrant> Hm, so we need to set vport?
<lifeless> thats my current wager
<lifeless> 2.7s7
<lifeless> so yes
<lifeless> rt it?
<wgrant> Will do.
<wgrant> I've been seeing this :3128 crap showing up in OOPSes for a while, had been vaguely wondering what was going on.
<lifeless> iz apache bug I suspect
<lifeless> information is being lost along the way
<lifeless> still, vport=443 is appropriate
<lifeless> and should fix
<maxb> well, yay :-)
<maxb> Always nice to wake up to find a bug has been prepared for squishing :-)
<maxb> haha
<maxb> Right, so sending Cookie: bananas avoids the bug just as well as sending OAuth :-)
<wgrant> Yes.
<lifeless> jcsackett: sadly flask is not packaged on Lucid
<lifeless> however werkzeug is
#launchpad-dev 2012-05-14
 * wallyworld needs to go buy coffee
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/die-spr-spn/+merge/105597 may be of interest, if you want a break from auditing. Or it can wait for OCR.
<StevenK> wgrant: I'm not auditing, I'm glaring at PackageUpload, hoping it will spontaneously combust.
<wgrant> Heh
<StevenK> wgrant: Looks excellent, r=me
<wgrant> StevenK: Thanks.
<lifeless> StevenK: how is auditor coming along ?
<StevenK> lifeless: I have an auditorfixture project up on LP, and I was trying to get that working last Monday. I'm about to start poking again.
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/populate-spph-pu/+merge/105601 if you can
<wgrant> StevenK: Is that a 2.7 vs 2.6 email spacing change I see there?
<StevenK> wgrant: Ah, is that why that test was failing?
<StevenK> Let me revert that bit.
<wgrant> StevenK: Also, what about PCJs?
<StevenK> wgrant: I was going to ignore them for now.
<wgrant> I wouldn't.
<wgrant> That's just asking for trouble.
<StevenK> wgrant: Why not? It's a copy, not a new source upload.
<wgrant> StevenK: It's still something that gets approved by an archive admin and creates an SPPH
<wgrant> And it has a PU
<StevenK> May have an PU, based on the code.
<wgrant> If it's been approved it has a PU
<wgrant> StevenK: Did you know that some tests change SPR.spn? :)
<StevenK> Oh, twitch.
<StevenK> Soyuz, where immutable means only on production.
 * StevenK stabs PCJ.
<StevenK> wgrant: http://pastebin.ubuntu.com/986687/ :-(
<wgrant> StevenK: Hm?
<StevenK> wgrant: Trying to write a test using PCJ to check the PU is actually set.
<wgrant> I suspect that your test is buggy.
<StevenK> At the moment, it creates a PCJ and then calls .run()
<wgrant> StevenK: Perhaps the PCJ is not meant to be proxied.
<adeuring> good morning
<jamestunnicliffe> Hi, I am trying to QA https://bugs.launchpad.net/launchpad/+bug/998052 and I have a demo page at https://qastaging.launchpad.net/~linaro-infrastructure/+upcomingwork running
<_mup_> Bug #998052: Upcoming Work View now showing all desired work items <qa-needstesting> <Launchpad itself:Fix Committed by dooferlad> < https://launchpad.net/bugs/998052 >
<jamestunnicliffe> I would like to have https://blueprints.qastaging.launchpad.net/linaro-infrastructure-misc/+spec/setup-freescale-click-through retargetted + approved. I can change who owns the blueprint, but as soon as I do, I lose the ability to approve it.
<jamestunnicliffe> Anyone have super-powers who could do that?
<jamestunnicliffe> Sorry, wrong language, re-target the blueprint. It is supposed to be a duplicate of https://blueprints.launchpad.net/linaro-android/+spec/setup-freescale-click-through
<wgrant> jamestunnicliffe: Why does that need superpowers?
<jamestunnicliffe> Once I re-target to another project I don't have a button to set the "Direction" field.
<jamestunnicliffe> wgrant: I think that Direction needs to be set to approved for it to show up on the page I am testing.
<wgrant> I don't see how the target is relevant here.
<wgrant> What behaviour are you trying to verify?
<jamestunnicliffe> https://qastaging.launchpad.net/~linaro-infrastructure/+upcomingwork should show approved blueprints that involve people from linaro-infrastructure
<rick_h_> morning party people
<wgrant> https://qastaging.launchpad.net/~linaro-infrastructure/+upcomingwork already shows the one you linked.
<wgrant> I don't see how the target is relevant to this.
<jamestunnicliffe> wgrant: yes, but if I retarget...
<jamestunnicliffe> wgrant: hang on
<wgrant> Oh, the milestone?
<jamestunnicliffe> yep
<wgrant> The target could refer to the product, the series, or the milestone :)
<jamestunnicliffe> wgrant: :-) Sorry, getting used to the language!
<jamestunnicliffe> So, now https://blueprints.qastaging.launchpad.net/linaro-android/+spec/setup-freescale-click-through is a Linaro Android blueprint, but not showing up on  https://qastaging.launchpad.net/~linaro-infrastructure/+upcomingwork
<jamestunnicliffe> I think the blueprint just needs approving (I could be wrong)
<wgrant> So, you can probably convince a WebOps  to poke these things for you.
<wgrant> Although the premise of both of those blueprints is quite nauseating.
<jamestunnicliffe> don't shoot the messenger - I just present the data.
<wgrant> webops: Can you help jamestunnicliffe with poking a few blueprint fields on qas?
<wgrant> Ah, lunch has taken gnuoy.
<wgrant> jamestunnicliffe: It could be a while.
<jamestunnicliffe> wgrant: No worries. Thanks for helping.
<jamestunnicliffe> webops: Change to ^^ request. https://qastaging.launchpad.net/linaro-android/+milestone/12.05 just needs a due date at the end of the month.
<danilos> jamestunnicliffe, fwiw, BPs don't need to be approved, but they need to be assigned to someone in the team and targetted to a milestone with a date set in the future
<jamestunnicliffe> danilos: Yea, I looked at the source and found that out, hence the change to the above request :-)
<wgrant> jamestunnicliffe: Anyone in ~linaro-maintainers should be able to change that.
<wgrant> Or ~linaro-drivers
<danilos> jamestunnicliffe, I've changed the milestone for a BP there
<danilos> jamestunnicliffe, fwiw, for qaing this, you could have simply assigned a workitem or two to someone outside the team
<danilos> jamestunnicliffe, it also looks qa-ok to me, I used wgrant as the outside-the-team assignee, and it looks fine
<jamestunnicliffe> danilos: Yea, I did, and that worked, but I wanted to be paranoid and examine a BP that was for another team to show that we see the remote blueprint as expected.
<danilos> jamestunnicliffe, right, but that's a different functionality and should already be working: if it's not, it's nothing this fix broke :)
<jamestunnicliffe> danilos: Clearly I like doing more work than I need to :-)
<danilos> jamestunnicliffe, that's ok, there's always more work to do
<danilos> jamestunnicliffe, just in case, I tested that too, and now the outside contributor doesn't show up, which is fine :)
<danilos> jamestunnicliffe, I think you can mark the bug as 'qa-ok' now
<jamestunnicliffe> danilos: Will do.
<wgrant> Thanks guys.
<danilos> yw
<rick_h_> anyone have a hint why my tests that assert an exception is raised come out of the test runner as errors?
<rick_h_> https://pastebin.canonical.com/65934/ for instance
<rick_h_> I get the error with either the assertRaises or the with ExpectedException usage
<wgrant> rick_h_: That's a security proxy blocking your attribute access. You'll want a 'with person_logged_in(someone):' around it.
<wgrant> rick_h_: Oh, bah, I see you're actually checking for that.
<rick_h_> wgrant: right, I've got 5 tests that are checking access expecting the exception but showing Error in the test runs
<wgrant> rick_h_: But the security proxy raises the exception when you try to getattr transitionToStatus.
<wgrant> Not when you call transitionToStatus
<wgrant> rick_h_: What are you trying to do?
<rick_h_> that's right, let me look closer. I know I fixed one of these with the context manager, but that one is failing the same way
<wgrant> transitionToStatus should be callable by any logged in user.
<rick_h_> wgrant: this is me trying to finish getting the bugtask tests moved over. Some were doctests, some were existing.
<wgrant> So it shouldn't raise Unauthorized.
<rick_h_> wgrant: so they're existing tests, I know a couple are around setting something private.
<wgrant> You want to use the context manager here.
<wgrant> Ah
<rick_h_> I'll poke at them closer, thanks for the reminder on the "exception in getattr vs the actual access" kind of thing from once before
<wgrant> rick_h_: Any logged-in user can edit tasks filed on distros as long as the bug
<wgrant> is not marked private. So, as an anonymous user, we cannot edit
<wgrant> Is that the test you've ported?
<wgrant> anything:
<rick_h_> wgrant: so one of them is this one: https://pastebin.canonical.com/65939/
<wgrant> That exception there is triggered by not being logged in and accessing transitionToStatus. So I'd either drop the test or say "self.assertRaises(Unauthorized, getattr, distro_task, 'transitionToStatus')"
<wgrant> Also, why are you destroying the doctest?
<rick_h_> and gets this: https://pastebin.canonical.com/65940/
<rick_h_> wgrant: LoC credit I needed for that work around the bug nomination timeout work
<wgrant> As much as I hate doctests, splitting them up into unit tests without refactoring the rest of the existing unit tests generally just results in longer code and 10x or worse slower tests.
<rick_h_> moving doctest to unit test and cleaning up dupe tests between existing model/test_bugtask
<wgrant> If you're doing that too, excellent :)
<rick_h_> wgrant: yea, there's definitely some disjoint since the doctests all work around the fixture db data while the unit tests tend to factory
<wgrant> Right, and per-test DB setup is not trivial, either.
<wgrant> It would be fine if our unit tests were unit tests.
<wgrant> But they're not.
<rick_h_> so not sure it'll be as pretty as it should be, but need to move on past this atm and these last few errors around the exceptions are killing me
<rick_h_> need more coffee for my monday morning I guess
<rick_h_> wgrant: oh definitely agree on that point :)
<wgrant> rick_h_: https://pastebin.canonical.com/65939/ doesn't work?
<rick_h_> wgrant: right, it's throwing: https://pastebin.canonical.com/65940/
<wgrant> rick_h_: What if you drop the '' in the ExpectedException?
<rick_h_> wgrant: let me run that again, I think I tried it, but maybe not on this test, without success
<rick_h_> wgrant: yea, same error
<rick_h_> I'm tempted to throw it at an ec2 test and see if it's just something strange locally since it really doesn't make a ton of sense
<wgrant> rick_h_: What if you use the assertRaises/getattr example I gave above?
<rick_h_> wgrant: will try that
<rick_h_> wgrant: so https://pastebin.canonical.com/65942/
<wgrant> rick_h_: Are you sure you have the right Unauthorized?
<wgrant> It's not an HTTP Unauthorized or something?
<wgrant> You want zope.security.interfaces.Unauthorized
<rick_h_> wgrant: oooooh, crap you're right.
<rick_h_> from lazr.restfulclient.errors import Unauthorized
<wgrant> Heh
<wgrant> That would do it.
<rick_h_> see, more coffee...I knew it
<rick_h_> dude, thanks, been staring at this for a chunk of time this morning
<wgrant> np, i think everyone's fallen into that trap a few times...
<jcsackett> rick_h_: so, you asked me to check out the watch_jsbuild thing last week. i can tell you that it appears to not do anything on my machine. it notes changes, but doesn't rebuild anything.
<jcsackett> am i misunderstanding its use?
<rick_h_> jcsackett: no, it should auto copy your file to the build dir, minify it, etc
<rick_h_> on save
<rick_h_> jcsackett: I'll try to check it out and test, I know I was using it at one point
<jcsackett> rick_h_: hm, actually, may be caching issues.
<jcsackett> in which i case, i apologize for besmirching your work. :-P
<rick_h_> jcsackett: heh, well the thing to do is ls the build dir and you shuold see the filetimes update
<rick_h_> at bare min
<jcsackett> rick_h_: hrm, yeah, i don't think i'm seeing that. i *do* get a message of "new path /builddir/path/to/file/i/edited/"
<jcsackett> anyway--no big, just letting you know since you were curious last week. i may have time to poke at it myself, cause it would help a lot of the work i'm doing. :-)
<rick_h_> jcsackett: k, I'll give it a quick go and dbl check nothing broke it recently
<rick_h_> jcsackett: hmm, working here. http://paste.mitechie.com/show/665/
<rick_h_> jcsackett: wonder if it's some subdir issue? You working in a different file location?
<jcsackett> rick_h_: i suppose it could be. my working path is lib/lp/app/javascript/banners.
<rick_h_> jcsackett: so the 'new file' path was build/js/lp/app/banners/somefile.js ?
 * jcsackett nods
<jcsackett> make jsbuild grabs it properly--they work off different path definitions?
<rick_h_> just that it maps from source tree to build tree
<rick_h_> notice that it's lp/app/banners (sans /javascript)
<jcsackett> right, i meant do the two make commands work off different definitions.
<jcsackett> like, could watch not be finding things exaclty the same way as jsbuild
<rick_h_> no, but if the JS files were in a strange place (used to have things not in $Module/javascript) it could go into a strange place
<rick_h_> so just making sure your new files are in the "normal" JS paths now
<jcsackett> rick_h_: by normal, do you mean everything should be module/javascript/jsfile? or is module/javascript/subdir/jsfile valid?
<rick_h_> jcsackett: subdir is fine
<rick_h_> I just mean it's not module/geodata/javascript/something.js
<jcsackett> rick_h_: ok. then the code i'm working on should be fine.
<jcsackett> rick_h_: anyway, like i said, not hugely important now. i've made a note for myself that these files aren't auto building right, and i'll look into it later. thanks!
<rick_h_> jcsackett: right, sounds like it should be ok
<rick_h_> jcsackett: yea, just wanted to let you know my quick test did work
<sinzui> danhg. Do you want to talk about text changes?
<danhg> hey sinzui - sure, are you free in 45 mins?
<sinzui> yes
<deryck> rick_h_, I moved the last convoy card to done-done. nothing left there for opening for ~launchpad, right?
<rick_h_> deryck: correct
<rick_h_> welcome to combo loader everyone bwuhahaha
<rick_h_> abentley: ok, I think I've got this ready to go: https://code.launchpad.net/~rharding/launchpad/diedoctests_bugtask/+merge/105502https://code.launchpad.net/~rharding/launchpad/diedoctests_bugtask/+merge/105502
<rick_h_> abentley: let me know where to send the 'oversized diff' beverage payment
<abentley> rick_h_: ACK.  I'll have a look in a couple of minutes.
<abentley> adeuring: Could you please review https://code.launchpad.net/~abentley/lazr.jobrunner/add-missing-jobs/+merge/105680 ?
<adeuring> abentley: sure
<abentley> adeuring: Thanks.
<adeuring> abentley: connection.drain_events(timeout=.1 ** 100) scared me at first glance: seemed to be a huge number ... until i spotted the tiny '.' ;) what about '0.1 ** 100' ?
<abentley> adeuring: sure.
<adeuring> abentley: r=me. nice & useful stuff!
<abentley> adeuring: Thanks!
<stub> gary_poster: Have you been using amd64 or i386 when that textsearching.txt failure has occurred?
<gary_poster> stub, I saw your bug comment.  the test machines all run amd64.  I don't know what benji is running (back tomorrow). I have no idea why you can't dupe.  I'll ask Benji to try and dupe what you've done and then gradually add the other workarounds lxc needs to work for other tests to see if one of them triggers anything.
<gary_poster> I think he sees it once every 5 or 10 runs
<stub> gary_poster: It could be load, which will be a right bugger to replicate :-/
<stub> I suspect I am running on cheaper and slower toys
<gary_poster> stub, load: yeah, that would kinda suck.  I think benji's laptop is not a scream machine.
<gary_poster> It was fast three years ago I think
<gary_poster> 2.5
<stub> so my desktop may be better
<gary_poster> yes
<stub> my spinning metal platter is my bottleneck I think
<gary_poster> hm.  stub, benji might have been using mxc-start-ephemeral
<gary_poster> lxc
<gary_poster> that would get rid of the spinning platter
<stub> Ok. If you have any thoughts, I can try things again tomorrow.
<gary_poster> ack, stub.  I'll hold off bothering you about it further till benji and I consult.  thanks again.
<stub> I know not this ephemeral wizardry but can work it out tomorrow if that looks like a trigger.
<stub> k
<gary_poster> cool
<lifeless> gary_poster: you could give stub access to the dc test machine, perhaps
<gary_poster> lifeless, good idea, thanks.
<sinzui> abentley, what is the ETA for celery running in production?
<abentley> sinzui: abel is working on getting the necessary changes deployed.  It may already be done, or may be done tomorrow.
<sinzui> abentley, rock
<sinzui> thank you
<abentley> sinzui: np.
<abentley> sinzui: It's actually deployed on production, but the fast-lane/slow-lane wasn't configured properly, so jobs that took too long would go into the ether.
<abentley> sinzui: That's what abel's fixing.
<sinzui> excellent/ Thank you for the explanation.
<abentley> rick_h_: I think we should file a bug that these unit tests are still doctestty, tag it tech-debt and add FIXMEs to the relevant TestCase classes.  That would make me feel better about approving this.
<rick_h_> abentley: ok
<abentley> rick_h_: Do you know our https://dev.launchpad.net/PolicyandProcess/XXXPolicy ?
<rick_h_> abentley: I've seen it, not had a big cause to use it. So I will review
<abentley> rick_h_: target_uses_malone was already sufficiently unit-tested?
<rick_h_> abentley: looking
<rick_h_> abentley: there's a negative test case in assertBugTaskIsPendingBugWatchElsewhere
<rick_h_> abentley: it's not completely the same, but the initial test seemed rather superficial so yes, considered it a match
<abentley> rick_h_: cool.
<abentley> rick_h_: similar_bugs already unit-tested?
<rick_h_> abentley: looking
<gary_poster> lifeless, testr is behaving a bit strangely in the DC, but they are not using the versions of testr and its dependencies that we are, so I'm not sure if it is simply that problem.  In any case, it would be great to have the releases of subunit, testrepository, and testtools done for now and for the future.  I saw that the last subunit build failed in the testing cabal's PPA.  Do you know anything about that?  Should
<gary_poster>  I trying pinging jelmer, or should I try assigning someone from my squad to help?  And finally, were you planning on trying to get a precise SRU for these changes because it fixes tag handling in many ways?  That would be the easiest sell for IS, I think.
<lifeless> OTP sorry
<abentley> rick_h_: login_foobar is only used once.  Is it needed?
<rick_h_> abentley: hmm, looks like I lost similar bugs somehow. Wonder if it didn't make the split between bugtask and bugtaskset. Will find a home
<rick_h_> abentley: I thought that was removed...me looks for login_foobar again
<gary_poster> np, will step away myself.  biab.  FWIW, the strange behavior: I get a seemingly full test run, with a nice big list of subunit output and a failure correctly rendered, but testr failing gives me simply "id=3, tests=0" even though I know we had lots of tests and at least one failure.
<abentley> rick_h_: near TestCountsForProducts
<gary_poster> lifeless, when you are off the phone, that was directed at you too ^^  :-)
<rick_h_> abentley: ah in the bugtaskset, no, it's not. I removed it from the bugtask because of infrequent use and missed the other file
<allenap> deryck[lunch]: When you're back, perhaps you or another Orange could take a look at https://code.launchpad.net/~allenap/postgresfixture/it-begins/+merge/105708? I won't be around to field questions, but I'll address them in my morning.
<deryck> allenap, sure, I'll take a look
<bac> lifeless: when you're available i'd like to get some advice on bug 998040.
<_mup_> Bug #998040: lp.codehosting.tests.test_bzrutils.TestGetBranchStackedOnURL.testGetBranchStackedOnUrlNotStacked(RemoteBranchFormat-v2) fails rarely/intermittently in parallel tests <paralleltest> <Launchpad itself:Triaged> < https://launchpad.net/bugs/998040 >
<rick_h_> abentley: I've pushed changes with the various items we chatted about + the simillar bugs add in. Diff is updating. https://code.launchpad.net/~rharding/launchpad/diedoctests_bugtask/+merge/105502
<rick_h_> abentley: I'm hitting EOD and need to get the boy, let me know of anything else and I'll update and try to get out in the morning.
<abentley> rick_h_: I don't think there was anything else.  similar_bugs was the blocker.
<rick_h_> abentley: ok, cool
<rick_h_> abentley: thanks for catching that one btw.
<abentley> rick_h_: Note that with these changes, your LoC only decreases by 61.
<rick_h_> abentley: right, they start at line 1943
<rick_h_> abentley: but according to the https://dev.launchpad.net/PolicyAndProcess/MaintenanceCosts/HitList just converting doctest to unit tests is considered some form of LoC credit and just should just offset things with https://code.launchpad.net/~rharding/launchpad/bugnom_874250/+merge/105317
<abentley> rick_h_: Oh, that's not what I thought was meant by that.  I thought that converting doctests to unit tests was expected to decrease LoC.
<rick_h_> abentley: ah, see I read that as reducing doctests was good form of reducing maint. w/o necessarily reducing lines of code
<rick_h_> since resetting up data/etc that doctests do throughout might actually lean towards an increase in LoC
<abentley> rick_h_: In any case, it squeeks by.
<rick_h_> :)
<rick_h_> ty much for suffering the long review, appreciate it a ton
<abentley> rick_h_: Nope, bad math on my part.  67 > 61.
<lifeless> gary_poster: hi, off the phone
<lifeless> bac: you're in the queue
<lifeless> gary_poster: I'd be delighted to see an SRU, I wasn't planning on doing one myself.
<rick_h_> abentley: ok, I'm out. If you get a sec to check and flip the needs fixing bit appreciate it
<lifeless> gary_poster: I do think you should get the latest testr etc, in the DC you can run them unpackaged to eliminate them as issues.
<lifeless> gary_poster: (install to ~/local/python etc, then add that to PYTHONPATH & away you go)
<lifeless> bac: hi hi
<bac> hi lifeless
<bac> so i've been looking at bug 998040 but cannot reproduce it.  i was wondering if you had any thoughts on the cause
<_mup_> Bug #998040: lp.codehosting.tests.test_bzrutils.TestGetBranchStackedOnURL.testGetBranchStackedOnUrlNotStacked(RemoteBranchFormat-v2) fails rarely/intermittently in parallel tests <paralleltest> <Launchpad itself:Triaged> < https://launchpad.net/bugs/998040 >
<lifeless> gary_poster: on subunit w/python3 - I'm not sure whats up there, Jelmer was hoping to look at it this week. If you want to ask someone to do so that would be grand; make distcheck was broken in trunk, so there was an issue with the 0.0.8 tarball, but trunk should be better, though it hasn't fixed the ppa builds so probably unrelated.
<lifeless> bac: ah, its a concurrent import issue
<lifeless> bac: I WAG that there is a test that triggers the import, *and* uses an in-process thread helper
<gary_poster> ack thanks lifeless
<lifeless> bac: (which the bzr test framework will do)
<lifeless> bac: there is a bug, let me grab it
<lifeless> bac: bug 593536
<_mup_> Bug #593536: Test failure: IllegalUseOfScopeReplacer: ScopeReplacer object 'ui' was used incorrectly <babune> <Bazaar:Confirmed> < https://launchpad.net/bugs/593536 >
<lifeless> brb
<bac> lifeless: any ideas on what to look for?
<lifeless> bac: the root cause is that bzr doesn't support concurrent dereferences to the scope replacer
<lifeless> it should
<lifeless> there is an MP up and all
<lifeless> it may even be fixed in bzr trunk.
<lifeless> or it may be stuck in review hell.
<gary_poster> lifeless, for subunit question, the other half of my question was whether you plan to make a Precise SRU for all those packages once you release. Have you decided?
<lifeless> I have to put cynthia down for a nap, will dig more details later if you have no joy.
<lifeless> gary_poster: 08:37 < lifeless> gary_poster: I'd be delighted to see an SRU, I wasn't planning on doing one myself.
<lifeless> gary_poster: (no, I'm not going to do the SRU myself)
<gary_poster> lifeless, bah, saw only one reply thanks
<bac> thanks lifeless, the link to that bug is great
<lifeless> gary_poster: oh,there are like 5 lines to you :)
<lifeless> gotta go, back in a bit
<gary_poster> cool thanks
<lifeless> back
<lifeless> I've commented in that bug
<bac> lifeless: you mentioned a MP for bug 593536 -- i can't find anything
<_mup_> Bug #593536: Test failure: IllegalUseOfScopeReplacer: ScopeReplacer object 'ui' was used incorrectly <babune> <Bazaar:Confirmed> < https://launchpad.net/bugs/593536 >
<lifeless> let me look at trunk's changelog
<lifeless> bac: revno: 6426 [merge]
<lifeless> committer: Patch Queue Manager <pqm@pqm.ubuntu.com>
<lifeless> branch nick: +trunk
<lifeless> timestamp: Thu 2012-01-05 11:06:47 +0000
<lifeless> message:
<lifeless>   (gz) Make lazy imports proxy by default so that concurrent resolution is
<lifeless>    robust (Martin Packman)
<lifeless> bac: so it looks like its fixed as of rev 6426
<lifeless> bac: so 2.6 has the fix
<lifeless> bac: we could upgrade to 2.6bwhatever, or backport the fix.
<bac> lifeless: ah, great.
<lifeless> allenap: ping
<lifeless> nvm, I've replied in the MP
<wgrant> Blah
<wgrant> I wish we would do away with the subdomains :(
<huwshimi> wgrant: If I remember correctly, removing subdomains will remove a maintenance/codebase burden. However, subdomains were added to make the workflow better (switching between apps/projects). If we can show that this is no longer the case and that the workflow is better without them then I think we would probably be in a good position to make it happen.
<wgrant> Remove a maintenance burden and increase performance :)
<lifeless> huwshimi: We could probably generate data showing that folk don't manually change the domain
<lifeless> huwshimi: (by looking for referrer rather than direct entry after a same-url different-domain page from the same user
<wgrant> In my branches 6 months ago to remove subdomains, the behaviour of the tabs is not changed at all.
<lifeless> huwshimi: that would show (if it does), that the links are what matter, and as wgrant says, we can preserve those easily.
<wgrant> So it only affects people who change the URL manually.
<wgrant> Plus it gets rid of stuff like https://code.launchpad.net/launchpad/+bug/1234
<_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
<wgrant> Bugs tab, Code breadcrumb, code domain.
<wgrant> Yay
<wgrant>          ->  BitmapOr  (cost=104.26..104.26 rows=11717 width=0) (actual time=218.365..218.365 rows=0 loops=1)
<wgrant>                ->  Bitmap Index Scan on temp_bugtaskflat  (cost=0.00..26.47 rows=5859 width=0) (actual time=217.475..217.475 rows=55302 loops=1)
<wgrant>                      Index Cond: (access_grants && $0)
<wgrant>                ->  Bitmap Index Scan on temp_bugtaskflat2  (cost=0.00..71.94 rows=5859 width=0) (actual time=0.884..0.884 rows=1203 loops=1)
<wgrant>                      Index Cond: (access_policies && $1)
<wgrant> GIN makes for pretty plans.
<james_w>   
#launchpad-dev 2012-05-15
<lifeless> wgrant: flat and flat2 ?
<wgrant> lifeless: 2 is just a second temporary index on that table
<wgrant> gin (access_grants) and gin (access_policies) respectively.
<wgrant> lifeless: So, BugSummary v2 needs to avoid the journal write slowness that we see today, which probably means not having an exploded journal, instead just journalling the new and old states. This leaves a couple of options for displaying up to date numbers: rely on garbo-frequently to keep the table up to date, and hope that users don't notice the numbers are a couple of minutes out of date; or use array indices to quickly count the ...
<wgrant> ... relevant non-exploded rows in the journal.
<wgrant> Thoughts?
<lifeless> wgrant: do we know why its slow?
<lifeless> wgrant: when we originally did it it was under some time pressure
<lifeless> so it probably hasn't had even a single pass optimisation run over it
<wgrant> lifeless: Say I have an 80-task Linux task, because the kernel team are evil.
<wgrant> It has 6 tags.
<wgrant> Each change to the bug is likely to generate 960 journal rows
<wgrant> If it's a security bug, it might be private.
<wgrant> 5 subscribers
<wgrant> 5000 journal rows
<wgrant> This goes into the list of "things that probably don't scale very well"
<StevenK> wallyworld, wgrant: No complaints about my mail? I'm shocked.
<wgrant> lifeless: eg. each change to bug #732628 that requires a BugSummary update (eg. adding a tag) takes 650ms to journal 770 rows.
<_mup_> Bug #732628: TOCTOU in mount.ecryptfs_private <kernel-cve-tracking-bug> <patch> <eCryptfs:Fix Released by kirkland> <ecryptfs-utils (Ubuntu):Fix Released by kirkland> <linux (Ubuntu):Fix Released> <linux-ec2 (Ubuntu):Invalid> <linux-fsl-imx51 (Ubuntu):Invalid> <linux-linaro (Ubuntu):Won't Fix> <linux-lts-backport-maverick (Ubuntu):Invalid> <linux-lts-backport-natty (Ubuntu):Invalid> <linux-lts-backport-oneiric (Ubuntu):Invalid> <linux-mvl-dove
<wgrant> Add 3 tags, 2970 rows total.
<wallyworld> StevenK: haven't read it yet
<StevenK> Typical. :-P
<wallyworld> StevenK: seems a reasonable summary. devil will be in the detail
<lifeless> wgrant: how many are -1+1 pairs ?
<wgrant> lifeless:  count | count
<wgrant> -------+-------
<wgrant>      1 |  1650
<wgrant>     -1 |  1320
<lifeless> so, lots
<lifeless> is there some way we could filter those out ?
<wgrant> Sure.
<lifeless> IIRC we call two helpers, one to un-count thebug and one to recount it
<wgrant> We can use our sensible data access layer to not do this in the DB :)
<wgrant> *cough*
<lifeless> simple but apparently high overhead
<wgrant> lifeless: The difficulty is that we don't know when the update is done.
<wgrant> So we can't avoid the writes.
<lifeless> we can reduce them
<wgrant> If our data access layer existed we could implement it there.
<lifeless> indeed
<lifeless> so, at the moment
<lifeless> UPDATE FOO
<lifeless> -> trigger which gets old, new
<wgrant> Yes
<lifeless> old gets dereferneced, new gets referenced
<lifeless> that trigger could optimise
<wgrant> How?
<wgrant> It can't potentially delete the old ones.
<wgrant> Oh, I guess it could.
<wgrant> Since they're not committed yet.
<wgrant> That would almost halve the writes.
<lifeless> we could have the helpers return the tuples, not add them, calculate in-memory, then write out the remainder
<wgrant> We could.
<lifeless> would that be sufficient?
<wgrant> There's no persistent cross-statement storage for that purpose, apart from temp tables.
<lifeless> its all one statement
<lifeless> the UPDATE (or add/delete in the case of tags)
<wgrant> True. No cross-trigger storage, then.
<lifeless> will it truely optimimal it pathological cases? (email command sequences) - no, but does that matter?
<wgrant> lifeless: INSERTing two tags will fire each trigger twice.
<wgrant> How do you propose to optimise that?
<lifeless> do we need to? do we know we need to?
<wgrant> I don't understand how your optimisation thing can work at all.
<lifeless> INSERT INTO BugTag knws it only needs the +1s
<wgrant> Oh, for that case, sure.
<wgrant> But now I change an attribute of the bug.
<lifeless> thats an UPDATE
<wgrant> And it has to journal both sides.
<lifeless> why ?
<wgrant> Because it's removing from some counts, and adding to others?
<lifeless> it has to journal -1s for the no longer relevant summary rows
<lifeless> but it doesn't have to journal -1s for every summary row
<wgrant> Anyway, do we know that this journalling approach has benefits over my proposal?
<wgrant> Mine is a lot easier on writes and probably easier on reads too.
<lifeless> so your proposal is 'journal the old,new inputs' ?
<wgrant> Yes.
<lifeless> that will be pretty big too
<wgrant> The number of writes scales linearly with number of tasks.
<lifeless> + subscribers + tags
<wgrant> And each will only be slightly larger than a single existing journal row
<wgrant> Yes.
<wgrant> Well, not subscribers, grants/polciies.
<lifeless> which is a lot larger than a single journal row
<wgrant> For things with a lot of grants or tags, the row will be a fair bit larger, yes.
<lifeless> 2*bugtask + 2*tags + 2*policies
<lifeless> so this case, will be 160 bugtasks, + the other bits
<wgrant> Currently it's bugtask*tags*(policies+subscribers)
<lifeless> * summary width
<lifeless> *2
<lifeless> (for non-delete/add cases)
<lifeless> journaling the state will be 2*(bugtasks*bigtask width+area(tags) + policies*grant width)
<lifeless> wgrant: anyhow, I've no objection if you want to journal an array of bugtasks + array of tags + array of policies and adjust accordingly.
<lifeless> wgrant: I'm not convinced its better (or worse)
<lifeless> wgrant: but thats because I haven't modelled it sufficiently
<wgrant> lifeless: The journalled thing would be a subset of bugsummary + array of tags.
<wgrant> So roughly (subset of bug, subset of bugtask, [tags], [grants], [policies])
<lifeless> so when a tag changes, you'll journal multiple rows?
<wgrant> lifeless: Yes, since I can't efficiently index into inhomogenous arrays like an array of task attributes.
<wgrant> (or even filter, if we have few enough rows to not care about indices)
<lifeless> so, how much space does 160 of these rows take
<lifeless> for someone adding a tag and deleting a tag
<wgrant> I can never remember the precise disk format of arrays.
<wgrant> But IIRC it's just a 4 byte size followed by the fields.
<wgrant> So the row size increase for the bug I mentioned above will be (#tasks * (task width + 4 bytes + all the tags)).
<wgrant> Currently we have approx (#tasks * #tags * (task width + avg tag size))
<wgrant> Also the base postgres per-row overhead is not insignificant :)
<wgrant> The postgres overhead makes up >30% of the average bugsummary tuple size now.
<wgrant> Likely around 50%, in fact.
<wgrant> Average bugsummary tuple is 62 bytes (including header), header is 27 bytes + a couple of bytes + 8 byte alignment.
<lifeless> could we do away with bugsummary ?
<wgrant> No.
<StevenK> lifeless: After you spent all that time writing it, and then rewriting it six times?
<lifeless> I suspect, due to writing just a few bugsummaries, that coalescing around statements would be a bigger win overall, but it may be more work
<lifeless> StevenK: Its a tool, not an end goal.
<lifeless> StevenK: dropping it if its no longer a win would be entirely appropriate
<wgrant> lifeless: Coalescing around statements?
<StevenK> lifeless: I'm teasing
<lifeless> wgrant: what I described before
<lifeless> wgrant: anyhow, the constraints I see are:
<wgrant> lifeless: I don't see how thta does away with bugsummary...
<lifeless>  - alterations do not timeout
<lifeless>  - things work.
<lifeless> done
<lifeless> beyond that I've no particular view on it
<wgrant> 13:23:39 < lifeless> could we do away with bugsummary ?
<wgrant> 13:27:21 < lifeless> I suspect, due to writing just a few bugsummaries, that coalescing around statements would be a bigger win overall, but it may be more work
<wgrant> Are those two statements unrelated?
<lifeless> no
<lifeless> you said no
<lifeless> so I went back to discussing how to evolve it
<wgrant> Hm
<wgrant> Does https://launchpad.net/ubuntu/+patches do anything that a bug search for latest_patch_uploaded IS NOT NULL ordered by latest_patch_uploaded and showing a new "Patch age" field wouldn't do?
<wgrant> I think I might add the 4 lines of code needed to support that on +bugs, and delete the view.
<StevenK> Is it linked from anywhere, and do people use it?
<wgrant> It is linked from the portlet, and people do use it.
<wgrant> I would change the link to point to a search, like the rest of them already do.
<StevenK> Oh, right.
<StevenK> Sounds good, then.
<wgrant> Ah, hm.
<wgrant> The Patch age column is a link with a tooltip.
<wgrant> And dynamic bug listings pull all the data every time, so it would be a little inefficient to pull all the LFAs.
<StevenK> steven@undermined:~% indicator-weather
<StevenK> Another instance of this program is already running
<StevenK> zsh: exit 1     indicator-weather
<StevenK> RARGH
 * StevenK stabs it.
<bigjools> I gave up  with that
<StevenK> It keeps crashing and bringing up apport too
<lifeless> sent an error report ?
<lifeless> wgrant: can annotate the LFAs in a post-load hook, but yea, not trivial
<wgrant> lifeless: We can, but it's still a fair bit more data to get from the DB and send to the browser.
<wgrant> For something that's used on probably 0.1% of requests.
<StevenK> lifeless: I've sent two or three
<lifeless> wgrant: right, thats why I'm saying load it only when used
<wgrant> lifeless: The infrastructure doesn't support that :(
<wgrant> Would need significant changes.
<lifeless> wgrant: I don't think so: we do a very similar thing for linkification
<lifeless> wgrant: get page -> after render -> send request -> markup results
<wgrant> lifeless: Oh, true, could do it like that.
<lifeless> is it pretty and integrated and all that - no
<lifeless> would it be nice to do that? yes.
<lifeless> but ...
<lifeless> it would be doable and fairly small to code
<lifeless> and likely more efficient overall
<wgrant> Yeah.
<lifeless> wgrant: voice call - bugsummary2 ?
<wgrant> Sure
<wgrant> I'm online
<lifeless> does db-link-sppu bypass auditord?
<stub> Oh my god, its full of jargon...
<StevenK> lifeless: No?
<StevenK> It is complementary, it just doesn't depend on it
<lifeless> StevenK: ah, it just being on the bug that the service was discussed on confused me.
<lifeless> StevenK: I thought it was one of the things we'd be storing in auditord
<StevenK> lifeless: It is certainly related to the bug.
<StevenK> lifeless: No, we will be storing details relating to the PU in auditor, so we need a way to get at the PU from SPPH.
<lifeless> cool cool
<stub> The PG 9.2 feature list in the beta2 announcement does look nice. Even the short version.
<wgrant> Oh, that's actually been released?
<wgrant> I was looking through commit logs to see what had changed.
<wgrant> Because the only reference to a changelog was "oh, I'm here's a draft announcement, but I'm still writing the changelog"
<wgrant> Heh: "I have completed the Postgres 9.2 release notes I started seven days ago."
<danilos> hi all, anyone able to review https://code.launchpad.net/~danilo/launchpad/bug-999040/+merge/105637 for me?
<wgrant> stub: Array stats, yay!
<wgrant> and sensible prepared statement plans.
<wgrant> And of course index-only scans, but they go without saying.
<stub> "Allow analyze statistics to be collected for foreign tables" could be interesting
<wgrant> I hope we never use foreign tables :)
<wgrant> Also, DROP INDEX CONCURRENTLY.
<StevenK> Oooh
<StevenK> WANT
<wgrant> And quick CHECK adding
<wgrant> The ALTER TABLE lock reduction stuff didn't make it in, though.
<adeuring> good morning
<wgrant> stub: "Have pg_upgrade create a script to incrementally generate more accurate optimizer statistics"
<wgrant> So no need for waiting for ANALYZE
<danilos> wgrant, gmb: you guys are still listed as on-call reviewers for Tuesday on https://dev.launchpad.net/ReviewerSchedule, so I hope you don't mind if I pester you to get https://code.launchpad.net/~danilo/launchpad/bug-999040/+merge/105637 reviewed :)
<wgrant> danilos: Done
<danilos> wgrant, thanks, will you land it for me as well please? (as for LOC addition, before we started this work we [salgado] removed a bunch of LOC, and I am pretty sure we are still a net negative; I'd have to check though)
<wallyworld> wgrant: question. in a test case, i can makeAccessArtifactGrant for a bug but for a branch i also have to call makeAccessPolicyArtifact in order for findArtifactsByGrantee to work. why is that?
<wgrant> wallyworld: Branches don't have triggers to set up the APAs.
<wgrant> wallyworld: Bugs do (for now)
<wallyworld> ok. will put a note in the test. thanks
<wgrant> danilos: Sure.
<danilos> wgrant, thanks
<wgrant> danilos: You need to set a commit message.
<danilos> wgrant, sorry, done
<wgrant> danilos: It's on its way.
<danilos> cool, ta
<danilos> wgrant, btw, I believe bug 998052 is still at 'fix committed' instead of released
<_mup_> Bug #998052: Upcoming Work View now showing all desired work items <qa-ok> <Launchpad itself:Fix Released by dooferlad> < https://launchpad.net/bugs/998052 >
<wgrant> danilos: Ah, it was deployed but rolled back shortly afterwards due to an unrelated regression. It should be redeployed in a few hours if all goes well.
<danilos> wgrant, ok, that explains it, thanks
* Topic unset by gmb on #launchpad-dev
<gmb> Oh arse
* gmb changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: gmb | Firefighting: - | Critical bugs: 3.47*10^2
<gmb> I fail at IRC. Again.
<wgrant> Blame jetlag.
<wgrant> Always jetlag.
* rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: gmb, rharding | Firefighting: - | Critical bugs: 3.47*10^2
<wgrant> danilos: ec2 seems to hate you. Let me retry it.
<danilos> wgrant, :(
<danilos> wgrant, I'll pretend to like it if that's going to help
<allenap> rick_h_: Thanks for the review! I'll get to work :)
<rick_h_> allenap: thanks for all the fresh code
<rick_h_> talk about a wake up in the morning
<rick_h_> and I feel I lacked as a reviewer to not have anything to complain about on something new/large like that :P
<rick_h_> jcsackett: ping
<jcsackett> hola rick_h_
<rick_h_> jcsackett: so couple of things
<jcsackett> never good, that. :-P
<rick_h_> 1) I bet the jsbuild_watch doesn't work for you because you don't have the combo loader FF enalbed in dev?
<rick_h_> that auto build only builds into the combo load directory and doesn't rebuild launchpad.js
<rick_h_> too slow to do that
<jcsackett> aah.
<jcsackett> didn't realize that.
<jcsackett> and no, i didn't set any feature flags.
<rick_h_> 2) Just a heads up, in checking the YUI widget source, the default for the visible property is true, wonder if that was giving you grief after seeing the comments on not listening to the html/etc
<jcsackett> rick_h_: that's one thing, but i set it to false in ATTRS.
<rick_h_> jcsackett: ok, that makes me feel better (in a way) and sorry I didn't think of it until last night
<jcsackett> rick_h_: dig, so i'll set that up, b/c i'm doing more js hacking. :-P
<rick_h_> jcsackett: yea, I feel like this is a combo issue, at some point I hope to poke at it. I was going to note in my reivew that you didn't need to have the ATTR, but I saw you were setting it false vs true
<rick_h_> jcsackett: awesome, hopefully it goes smoother then
<jcsackett> rick_h_: as to the visible, the *other* thing is that listening "on" means the visible change event has happened, but it's not guaranteed visible *has* changed yet.
<jcsackett> thus, listening to "after" means you're trigger based on the change, but the change is definitely done.
<rick_h_> jcsackett: yea, there's also afterChange
<rick_h_> jcsackett: right
<jcsackett> rick_h_: yeah, it seems stable with this.after('visibleChange'). i owe reading longpoll code for figuring that one out. :-P
<rick_h_> heh
<rick_h_> cool, well glad it's fitting together better. Hate it when things *should* work but don't
<jcsackett> rick_h_: it's not they don't work--it's that i insufficiently understand the parameters in which they *should*. :-P
<jcsackett> rick_h_: incidentally, apologies for the blitzkrieg of js branches in the queue today. :-P
<rick_h_> jcsackett: hah, all good, these look pretty now that there's nice module/code reuse
<jcsackett> yeah, i'm way happier with them.
<jcsackett> rick_h_: reply to your comments on privacy-banner branch. in particular as regards the build/ in tests. happy to talk here after you've read the comments, or we can converse via MP. :-)
<rick_h_> jcsackett: k, loading it up
<rick_h_> jcsackett: so the build thing was something we chatted about in our squad when doing combo loader/test updates.
<deryck> rick_h_, abentley, adeuring -- sorry, missed it was stand-up.  coming now....
<rick_h_> the idea is that those are actually 'deps' and should come from a static/standard location like the download-cache kind of idea
<rick_h_> deryck: ooh, me too
<jcsackett> rick_h_: except that totally breaks code/reload. i don't know if bin/test rebuilds js everytime, but if you're checking things in the browser (which is way easier than trying to read the error messages from bin/test) you now have to rebuild every time.
<rick_h_> jcsackett: and that we want to make sure that files don't break during 'build' so that they fail in tests as they would in production
<rick_h_> if something causes a file to not get put into the build directory right, tests will pass, but production usage will fail
<rick_h_> jcsackett: right, but the _watch should fix that up tbh
<rick_h_> and combo loader is coming
<rick_h_> so it's kind of a convention to help make sure that building will work correctly along with tests passing I guess
<rick_h_> you're probably right that a -dev discussion is a good idea
<jcsackett> rick_h_: right, but _watch has undocumented provisos to it working (as we demoed :-P) and combo loader isn't going to fix coding/reloading a test_html file, is it?
<rick_h_> jcsackett: right, that's what I mean. I'm telling you the idea behind the enforcement, but admitting it's not something that's been vetted/put into stone
<jcsackett> rick_h_: i think if you want this to be a policy to keep people from doing it the way i have, we *def* need to talk about it and get group buy in. :-)
<rick_h_> jcsackett: no, but you're not linking to a test file, but a dependency which is copied to the build directory
<jcsackett> rick_h_: dig. to be clear, i got the idea behind your request--i'm just pointing out there are some non-trivial disadvantages.
<rick_h_> jcsackett: I'm not totally clear on the issue though
<rick_h_> so you change code, reload, your test is linking to deps in a build dir
<rick_h_> you're not editing the deps, just the current module under test which is ok to be relative since it's right there
<rick_h_> the only time it requires a rebuild is if you edit a dependency which should have its own test file
<jcsackett> rick_h_: hm. i suppose in this instance, i was dealing with test files that were/are poorly separated. so yeah, my experience may be nonstandard.
<rick_h_> jcsackett: yea, I guess the idea is that deps come from build and only the code 'under test' is linked directly as a build step sanity check
<jcsackett> rick_h_: fair. okay, i'll make those changes since outside of something like what i was doing where i had to modify and test a bunch of files it isn't actually such an issue.
<rick_h_> jcsackett: ok, sorry, stand up. The rest of that thanks for the notes/feedback to the questions there.
<jcsackett> rick_h_: all good. i'm in the process of changing over to build paths.
<rick_h_> jcsackett: thanks, does the idea click after the discussion? I'll look to add some notes somewhere on the jsbuild_watch stuff and can bring up the build link discussion to -dev
<rick_h_> you're getting to be the first user that didn't write the stuff so lucky you with the growing pains :)
<jcsackett> rick_h_: yeah, i think the problem is it is still a gotcha if you're doing work over several modules and their tests.
<jcsackett> but that's a less common workflow, so i'm making the update.
<jamestunnicliffe> gmb: Before I ask for a review of the changes I have made for Bug #999717, I need to get a test written. It will require a JS test I think, but I would appreciate some pointers.
<_mup_> Bug #999717: upcomingwork view blueprints should be initially expanded if incomplete <Launchpad itself:In Progress by dooferlad> < https://launchpad.net/bugs/999717 >
<gmb> jamestunnicliffe, Okay. Let me take a look at the branch.
<gmb> jamestunnicliffe, So, I think that rather than doing the detection of not-100%-completeness in the JS we can do it in the view code and make the testing a bit easier. Submit it for review and I'll suggest a patch for it (easier than me explaining it line-by-line in IRC).
<jamestunnicliffe> gmb: Will do, thanks.
<gmb> np
* Topic unset by gmb on #launchpad-dev
<gmb> AAAAAAAA
* gmb changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2
* rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: rharding | Firefighting: - | Critical bugs: 3.47*10^2
<sinzui> rick_h_, do you have time to review https://code.launchpad.net/~sinzui/launchpad/halt-when-done-2/+merge/105859
<rick_h_> sinzui: loading now
 * deryck steps away to eat
<rick_h_> sinzui: r=me
<sinzui> thank you
<maxb> Is there a polite way of attracting the attention of any webops who may be around?
<maxb> (re #launchpad current conversation; psusi wants to know why he can't access bug 999790 despite receiving email about it)
<sinzui> rick_h_, do you have time to review https://code.launchpad.net/~sinzui/launchpad/daily-build-form/+merge/105884
<adeuring> abentley: this is the stuff i have so far for the test if a job with a retry error is queued again: http://paste.ubuntu.com/989542/ . Note the "poor man's debug attempt" in BaseRunnableJob.xxxRunExtraCommit() (the exception): Allows me to check if the fleature flag is correctly set. WHat I get in a test run: Exception: waaaaa2 TestJobWithRetryError False None . In other words: the feature flag "vanished"... Any idea?
<abentley> adeuring: looking.
<abentley> adeuring: Feature flags are memoized, so it's possible that it could start with None, then the flag could get updated, but the worker would still have the stale value.  Are you running this test by itself or with other tests?
<adeuring> abentley: just the two tests in the module. The flag is set in both tests...
<adeuring> abentley: and the flag is also missing if i run just the one test...
<abentley> adeuring: My new task_init code just landed in devel, and that explicitly clears the feature flag cache, so could you try merging devel?
<adeuring> abentley: ok, I'll try it.
<james_w> has anyone succeeded in getting the python-oops-tools tests passing locally?
<rick_h_> sinzui: loading
<james_w> I can't get them to pass before I've changed any code
<adeuring> abentley: yay, that did it!
<rick_h_> james_w: sinzui r=me
<abentley> adeuring: great!
<james_w> possibly because of the db being emptied after each test
<sinzui> thank you rick_h_
<james_w> lifeless, https://code.launchpad.net/~james-w/python-oops-tools/remove-lp-branding/+merge/105892
* rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2
<wgrant> sinzui: Bah, I thought I tracked down all the ES5 array ops :(
<gary_poster> lifeless, I have to run to dinner but fwiw, I'm still seeing the odd -tags.  They don't hurt anything except themselves, but... http://pastebin.ubuntu.com/989769/  gotta run
#launchpad-dev 2012-05-16
<wgrant> wallyworld: BugTaskSearchParams.setTarget maybe of interest.
<wallyworld> wgrant: context?
<wgrant> +            all_branches = getUtility(IAllBranches).visibleByUser(user)
<wgrant> +            wanted_branches = all_branches.visibleByUser(user).withIds(
<wgrant> +                *branch_ids)
<wgrant> Also, that's got a duplicate visibleByUser
<wgrant> wallyworld: The preloading branch
<wallyworld> i copied that code from elsewhere
<wgrant> You currently branch based on pillar interface and call setProduct/setDistribution
<wgrant> Rather than setTarget
<wallyworld> ok. i just cut and pasted it. will fix along with the other typo. thanks
<wgrant> Cargo-culting Launchpad code is a little less likely to be optimal than in other projects, sadly.
<wgrant> Our codebase is in a bit of a sorry state.
<wallyworld> it's getting better though
<wgrant> Wow
<wgrant> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-b0f528b0f920a20462267635b6697b7a
<wgrant> SQL time: 4032 ms
<wgrant> Non-sql time: 32597 ms
<wgrant> Ah, it's the old "Product.has_release_files actually retrieves every detail about everything relating to every release file" trick.
<wgrant> wallyworld: Thanks :)
<wallyworld> np. i hate typos
<wgrant> Oh.
<wgrant> lifeless: I still fundamentally reject the way bugsummary journalling is done, but you weren't wrong about there being a lot of fat...
<wgrant> There we go, 20 times faster already
 * StevenK stabs stacking
<wgrant> Yes.
<wgrant> That is the correct response to stacking in Launchpad :(
<wgrant> Tag addition to an 80 task bug in 20ms instead of 650ms.
<wgrant> And there's probably another 5-10ms or so still to trim.
<StevenK> I can't figure out where a branch is created with the stacked_on set
<wgrant> I guess there really was no thought put to optimisation during the mad scramble to unbreak prod
<wgrant> StevenK: That would never happen on production.
<wgrant> Only in a test.
<StevenK> wgrant: I need a DB trigger then?
<wgrant> StevenK: No. The things that update the stacked_on field will be easily findable in the application code.
<wgrant> You can put guards there.
<wgrant> Code's code isn't insane.
<wgrant> Bugs' code is, which is why I used triggers for the early stuff.
<wgrant> Branches are also far far simpler. The only vague complications they have are retargeting and restacking.
<StevenK> Let me paste a diff and I can explain the problem.
<wgrant> The existing privacy model is sufficiently crap that we don't have to migrate it or work around it.
<StevenK> http://pastebin.ubuntu.com/990144/ is my diff
<StevenK> lp.code.model.tests.test_branch.TestBranchPrivacy.test_public_stacked_on_private_is_private fails since it's not private
<wgrant> You need to define rules around what happens when stacked_on is changed, and implement them.
<wgrant> Nasty lifeless writing n+1 query code in DB triggers :)
<wgrant> Although I'm not quite sure why it's so slow.
<wgrant> Since it's all static so it should be preplanned.
<wgrant> Perhaps bulk inserts optimise heap insertion somehow.
<StevenK> wgrant: So <branch namespace>.createBranch() is called, and then branch.branchChanged() is called?
<wgrant> StevenK: That's how it normally happens, yes.
<wgrant> branchChanged should hopefully be the only place stacked_on is changed on production.
<StevenK> Looks like it
<StevenK> Also looks like I'll need to change makeBranch() to do the same.
<lifeless> wgrant: thats great news
<lifeless> wgrant: what did you change to make it faster ?
<wgrant> lifeless: First I removed the fixed_upstream thing, which I turned off display of by feature flag a couple of months back. That saved about 50% of the time. Then I fixed summarise/unsummarise/flush to do bulk inserts instead of a FOR loop.
<wgrant> That saved the rest of the time.
<lifeless> interesting
<wgrant> Yes.
<lifeless> thanks for suspending your disbelief long enough to investigate
<wgrant> Heh
<lifeless> well, a little tease is in order ;)
<wgrant> Thanks for poking me in this direction; it will indeed be a bit quicker to implement than the redesign.
<wgrant> naturally :)
<lifeless> anytime
<wgrant> It's not entirely implausible that eg. FK constraints are optimised in a batch INSERT, I guess.
<wgrant> Since most of the FKs will be duplicates.
<adeuring> good mornin
* frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban* (rvba) | Firefighting: - | Critical bugs: 3.47*10^2
<StevenK_> frankban: Oooh, is this your first shift?
<frankban> yes StevenK_
<StevenK_> Hm, where did that _ come from?
<StevenK_> frankban: However, congrats for standing up as a reviewer.
<frankban> StevenK: thanks
<cjwatson> Ooh, a victim! :-)
<cjwatson> frankban: I've got https://code.launchpad.net/~cjwatson/launchpad/packageset-score/+merge/105915 for you, if you fancy it
<cjwatson> (But not if you have more urgent stuff)
<frankban> cjwatson: on it in a minute
<nigelb> heh, a victim.
<jamestunnicliffe> gmb: Any news on that review? https://code.launchpad.net/~dooferlad/launchpad/upcomingwork_show_incomplete_bp/+merge/105846
<gmb> jamestunnicliffe, I haven't had a chance to look at it yet; it's on my list for this morning.
<jamestunnicliffe> gmb: Cool, thanks.
<danilos> mrevell, just to confirm, we have our call today?
<mrevell> danilos, If you and James can make it, that would be very helpful for us.
<danilos> mrevell, I can for sure, let's invite James as well
<danilos> mrevell, oh, and hi btw :)
<mrevell> Hello! :)
<cjwatson> Good grief the whole Archive/ArchivePermission edifice isn't half wordy.
<deryck> rick_h_, hey, man.
<rick_h_> deryck: howdy
<rick_h_> deryck: nvm email I sent last night, problems solved I think
<rick_h_> will bring it up in call
<deryck> rick_h_, ah, ok.  was about to say I couldn't find email to respond and then respond here. :)  But we can chat on call then.
<wgrant> cjwatson: Hm, why do you have a setScore method?
<cjwatson> wgrant: score should be visible read-only on the API and have a restricted setter; happy to take suggestions on a better way to do it, I was probably cargo-culting from nearby code
 * czajkowski peers at wgrant 
<czajkowski> wgrant: it's not a competition who can stay up the latest you know :)
<wgrant> cjwatson: Attributes have separate read and write permissions.
<wgrant> cjwatson: eg. look at Builder
<wgrant>         <allow
<wgrant>             interface="lp.buildmaster.interfaces.builder.IBuilder"/>
<wgrant>         <allow
<wgrant>             interface="lp.soyuz.interfaces.buildrecords.IHasBuildRecords"/>
<wgrant>         <require
<wgrant>             permission="launchpad.Edit"
<wgrant>             set_schema="lp.buildmaster.interfaces.builder.IBuilder"/>
<cjwatson> So maybe I can avoid the grotty IPackagesetRestricted altogether?
<wgrant> interface= is for getting attributes on the interface (including methods), set_schema= for setting attributes, attributes= for reading specific non-interface attributes, set_attributes= for writing them.
<wgrant> cjwatson: You probably need a separate permission.
<cjwatson> Right, but I'm using launchpad.Moderate for that.
<wgrant> Unless anyone who can edit a packageset should be able to edit its score.;
<cjwatson> No.  Build scores control access to a site-wide resource.
<cjwatson> There's a test for that :)
<wgrant> Right, so it needs a separate permission. But you could indeed do away with the interface, and just use set_attributes
<cjwatson> But perhaps I can just do set_attributes="score".  Right.
<wgrant> On large interfaces we usually use sub-interfaces for read permissions.
<wgrant> But write permissions often end up as set_attributes because they need to be split differently.
<wgrant> Like this.
<cjwatson> Does the strictest <require/> apply, or is there a problem with <require permission="launchpad.Edit" interface="lp.soyuz.interfaces.packageset.IPackagesetEdit"/> <require permission="launchpad.Moderate" set_attributes="score"/>?
<wgrant> That ZCML will fail to execute.
<wgrant> Conflicts like that are fatal.
<cjwatson> Ugh, so I have to enumerate all the non-Moderate attributes?  A separate interface suddenly looks nicer after all.
<wgrant> Indeed. And a separate interface works here, since everything is world-readable.
<wgrant> Things get messy when you have some stuff read-restricted, and subsets of that write-restricted, so you'd end up needing like 10 interfaces.
<cjwatson> But I can still make it be set_schema= rather than having a setScore method, I guess.
<wgrant> Yep.
<wgrant> czajkowski: It's not yet midnight :)
<wgrant> czajkowski: Some of us weren't up at 4am...
<czajkowski> yeah wont be doing that again
<wgrant> I am glad :)
<cjwatson> wgrant: Not entirely sure how to write the setter, though.  I can't use @score.setter here, can I?  Doesn't look like storm implements that.
<wgrant> cjwatson: No need for a setter.
<wgrant> It's not a property, is it?
<cjwatson> Duh.  Good point.
<wgrant> Right.
<wgrant> You should have just to change the permission and set readonly=False on the interface.
<wgrant> And it will all magically work.
<wgrant> But also tests.
<cjwatson> But then the restricted interface has nothing in it.
<wgrant> You move score to that interface.
<wgrant> The <allow interface="BlahRestricted" />
<wgrant> *Then
<cjwatson> s/move/copy/ maybe?  I need it in the read-only one too.
<wgrant> No
<wgrant> You have to have it in only one.
<cjwatson> Oh I se
<cjwatson> e
<wgrant> So you <allow> read and <require> write
<wgrant> For that interface.
<cjwatson> I think the existing tests I have should cover this
<cjwatson> test_score_packageset_forbids_non_buildd_admin and test_score_packageset_allows_buildd_admin
<stub> deryck: Has all the translations opening been completes as far as you know?
<deryck> stub, hi.  As far as I know, it has *not* be complete.  I filed an RT and never heard back.  And I need to hand that off to jam and the blue squad now actually.
<wgrant> Um
<cjwatson> wgrant: Something like http://bazaar.launchpad.net/~cjwatson/launchpad/packageset-score/revision/15260 then?
<wgrant> Handing an extremely fragile process that almost always breaks off to a squad that's new to Launchpad doesn't sound like the wisest of plans.
<wgrant> cjwatson: Much nicer, thanks.
<stub> deryck: Ta. There are some droppings in the DB I was wondering about from one of the scripts.
<deryck> stub, yeah, I gave webops a script to clean that up.
<stub> deryck: ok. Is that in your RT?
<deryck> stub, yes
<stub> Have the number handy?
<cjwatson> wgrant: The only downside is that it shows up as writeable in the apidoc.
<cjwatson> But I guess it is, sort of.
<deryck> wgrant, maybe not the wisest of plans.  but there is literally no one that understands the process, except jtv.  so if he isn't doing it, anyone of us is a good as another.
<wgrant> cjwatson: Yeah, permissions have always been an issue there.
<wgrant> deryck: Perhaps.
<wgrant> I'm not sure Blue is likely to agree :P
<czajkowski> poor smurfs
<jcsackett> "The smurfs"; that sound much friendlier than some of the other squad nicknames. :-P
<czajkowski> jcsackett: lol
<deryck> rick_h_, hey. give me 5 minutes to settle in again and we can chat
<rick_h_> deryck: sounds good
<mrevell> danilos, Are we Mumbling?
<mrevell> danilos, Does James have access to Mumble?
<mrevell> well, our Mumble server
<danilos> mrevell, flacoste, jamestunnicliffe: let's meet up in https://plus.google.com/hangouts/_/extras/linaro.org/lp-meetup (James doesn't have access to our mumble server)
<flacoste> danilos: welcome to the 21st century :-)
<danilos> flacoste, heh, thanks :)
<danilos> though, 21st century has suddenly left me with no sound output
<jamestunnicliffe> danilos: pulseaudio -k solves everything :-)
<danilos> jamestunnicliffe, I was just restarting it system wide
<sinzui> rick_h_, I suspect the combo-loader is broke the translation import queue. Can you take a few minutes to give your thoughts: https://bugs.launchpad.net/launchpad/+bug/1000282
<_mup_> Bug #1000282: Uncaught TypeError on translations series +imports <combo-loader> <javascript> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1000282 >
<rick_h_> sinzui: looking, have a call in a moment, but will check it out
<rick_h_> sinzui: off the bat I'd say it was a requires: issue. A module isn't requiring something it needs to, or a lint issue, if a module fails to parse due to invalid JS? I'll look deeper in a second
<rick_h_> but those are my initial thoughts
<danilos> mrevell, flacoste, jamestunnicliffe: hangout hanged for me again, I'll reboot to get to a clean state
<flacoste> danilos: hang out
<flacoste> we are switching to the conf system
<danilos> ok
<flacoste> danilos: conf code: 116 862 4336
<danilos> flacoste, ack, in and waiting for the leader
<flacoste> danilos: are you in?
<danilos> mrevell, I am
<danilos> mrevell, that's right
<danilos> 12.04 has started popping up a bunch of crash reports
<danilos> mrevell, there is a lot, I'll reboot
<danilos> jamestunnicliffe, flacoste, mrevell: https://launchpad.net/~linaro-infrastructure/+upcomingwork
<danilos> flacoste, mrevell: https://docs.google.com/spreadsheet/ccc?key=0AvOsYPy8e7yUdGkyRmx2WGFwT3NnSjdHVW04Q1pvSmc
<flacoste> mrevell: danilos' email is "Per-milestone metadata in blueprints" dated from 12-03-21
<noodles775> Hi people, we're just trying to use staging.lp for some QA, and wanted to check whether it's just a quick outage, or is it likely to be a while before it's up again?
<czajkowski> noodles775: let me find out
<noodles775> Thanks czajkowski
<czajkowski> noodles775: just checking
<danilos> flacoste, mrevell: https://blueprints.launchpad.net/linaro-infrastructure-misc/+spec/lp-workitems-qa-tracking
<danilos> jamestunnicliffe, ^
<czajkowski> noodles775: back up there now
<noodles775> czajkowski: thanks!
<timrc> how do I view an oops from the web again? forgot the subdomain
<czajkowski> timrc: https://lp-oops.canonical.com/
<timrc> czajkowski, thanks
<timrc> anyone else getting timeouts? I tried, https://launchpad.net/ubuntu/+search?text=live-build, and it resulted in this oops: https://lp-oops.canonical.com/?oopsid=OOPS-e439dc4c04ec939b5798cebb1d5c4177
<adeuring> abentley: https://code.launchpad.net/~adeuring/launchpad/put-retry-jobs-into-celery-queue/+merge/106012
<rick_h_> sinzui: do you have a sample url for that JS error? have a branch to fix it, but want to make sure I qa the right place
<rick_h_> sinzui: nvm, got it
<sinzui> rick_h_, sorry, I was picking my son up from school: qastaging doesn't have the combo loader on at the moment so this works https://translations.qastaging.launchpad.net/+imports where as production does not
<rick_h_> sinzui: yea, got it, MP is up now
<rick_h_> waiting for the diff to update
<sinzui> fab
<rick_h_> https://code.launchpad.net/~rharding/launchpad/meta_1000282/+merge/106013 if you're feeling like moving along quiclly
<sinzui> my pleasure
<rick_h_> sinzui: I tried to note in the bug and the MP why it failed and how to debug that in the future hopefully
<rick_h_> let me know if it doesn't make sense
<sinzui> ah
<rick_h_> but thanks for catching this, exactly the type of things hard to find automatically
<sinzui> rick_h_, what are the odds that the comment is irrelevant now
<rick_h_> sinzui: not sure, I didn't look at how they were using things tbh
<sinzui> rick_h_, understood. We have a problem when we do not document the version that is broken. I fixed a few bugs recently by removing our hacks because YUI does work
<rick_h_> sinzui: heh, yea. In a quick glance through the code I don't see what's 'strange' but like you say, no reference to when this was added. I guess I could annotate/match YUI versions/etc
<rick_h_> would be great if they had a link to a bug/etc
<sinzui> rick_h_, you have my approval to land the fix. I will see if I can track down the version in annotate and report a bug if needed
<rick_h_> sinzui: yea, I'll remove the comment
<rick_h_> it doesn't say anything other than why oop/event are added to req
<rick_h_> and honestly, those are on every page anyway
<rick_h_> and if someone comes along, they're not going to remove those/get passing tests if it really is required
<sinzui> excellent point
<rick_h_> ok, so removing comment, will get to land shortly, try to get fix out asap. Sorry to break the page
<rick_h_> guess I should apologize to czajkowski on that one
<cjwatson> I seem to recall hearing before that using launchpadlib_for in tests is awfully slow, and it does seem to be true here.  Is there an example somewhere of a reasonably fast and current preferred style for webservice unit tests?
<czajkowski> rick_h_: eh ?
<rick_h_> czajkowski: the combo loader stuff broke the translations import queue page which is in the maint. watch stuff
<rick_h_> assuming you're doing that these days as I know we used to before you started
<czajkowski> rick_h_: ahhhh
<cjwatson> (I don't actually need to test launchpadlib as such, only what's exposed on the webservice.)
<james_w> cjwatson, there's webservice_for I think
<james_w> direct requests, rather than via lplib
<cjwatson> webservice_for_person?
<james_w> cjwatson, that's the one
<cjwatson> Thanks, I'll give that a try
<james_w> from lp.testing.pages import webservice_for_person
* frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2
<daker> hello
<czajkowski> daker: aloha there
<czajkowski> daker: coming to submit patches :-)
<daker> hhhh ã
<abentley> adeuring: I believe the recommended way of creating a naive datetime from a UTC datetime is datetime.reaplace(tzinfo=None)
<czajkowski> daker: folks will help if you get stuck
<daker> i hope ã
<czajkowski> daker: feel free to ask here or on the mailing list, and they're very friendly
<adeuring> abentley: maybe. but then we simply assume that the time delta is correct...
<abentley> adeuring: How do you mean?
<adeuring> abentley: lets me try your suggestion first...
<abentley> s/reaplace/replace/
<abentley> adeuring: Catching AttributeError is too broad, because db_class.makeInstance might raise an AttributeError.
<adeuring> abentley: http://paste.ubuntu.com/991017/
<abentley> adeuring: I recommend getattr(db_class, 'makeInstance', None)
<adeuring> abentley: right,  that is better. but check the paste above: replace(tzinfo=None) is not usable.
<abentley> adeuring: I thought if Celery was using naive datetimes, they would represent UTC.  They represent local time?
<adeuring> abentley: yes
<adeuring> abentley: perhaps that can be configured
<abentley> adeuring: How about datetime.astimezone then?
<adeuring> now_utc.astimezone(tz=None)
<adeuring> -> astimezone() argument 1 must be datetime.tzinfo, not None
<adeuring> ... a TypeError
<abentley> adeuring: astimezone can be used to convert from UTC to the local timezone, and then you can strip off the tzinfo with replace.
<adeuring> abentley: well, ok. But is that really much better than to use the delta?
<abentley> adeuring: I think it is much better than using datetime.now() twice, since the current date is not relevant to the conversion you're performing.
<adeuring> well, ok...
<adeuring> abentley: do you know how figure out the local timezone? I find the example in the Python docs a bit cumbersome...
<adeuring> (class LocalTimezone)
<abentley> adeuring: No, I don't know how to do that.
<adeuring> abentley: so.... with the delta, we don't have to deal with this ;)
<abentley> adeuring: Yes, but we'd be doing a lossy conversion.
<abentley> adeuring: And unnecessary system calls.
<adeuring> abentley: well, maybe. But anyway, there is a different details that concerns me a bit there: It might make sense to add another 10 seconds or so to the delat, to allow for time skew between the DB time and the time seen by celeryd
<adeuring> s/delat/delta/
<abentley> adeuring: I agree that's a reason for concern.
<abentley> adeuring: I wonder if it makes sense to use the delta from the current DB time?
<adeuring> abentley: maybe. But I would prefer a system call to another DB request...
<abentley> adeuring: Using a system call doesn't address the concern of skew between the db and the celeryd system time.
<adeuring> abentley: right, I'll try that.
<abentley> adeuring: So AFAICT, the DB time isn't relevant.
<abentley> adeuring: acquireLease doesn't use DB time.
<adeuring> abentley: ah, right.
<abentley> adeuring: I believe there's no possibility of skew.
<adeuring> abentley: unless we have workers on more than one machine
<abentley> adeuring: Right.  We don't have that, and we're not expecting to have that in the near future, at least for a single queue.
<abentley> adeuring: Still, I guess a fudge factor doesn't hurt here.
<adeuring> abentley: right, one second should be enough
<abentley> adeuring: sure.
<adeuring> abentley: the example from the Python docs (class Localtime in the description of the datetime module) make _four_ calls to time.mktime() if the class is used in astimezone.astimezone(Localtime()) ;)
<adeuring> abentley: any progress with the review?
<abentley> adeuring: No, I was waiting on your changes.
<adeuring> abentley: so... what should we do woth the time delta? That's my main question. I think it does not make sense to use the example from the python docs to get local timezone.
<adeuring> but UI leave this decision to you...
<abentley> adeuring: I agree that the example from the python docs doesn't make sense, but I find it hard to accept the proposition that calling datetime.now multiple times is the cleanest way to get a naive datetime.
<adeuring> abentley: agreed, this not elegant but straightforward and easy to understand...
<adeuring> and I don't think that this is an all-important aspect of what we want to achieve.
<adeuring> abentley: but I am open to better suggestions
<abentley> adeuring: No, respecting the lease eta was something we weren't trying to achieve at all.
<adeuring> abentley: well, the other option would be to drop the lease completely. but I am not sure if it is reasonable to retry jobs vers fast
<adeuring> ...very fast
<abentley> adeuring: It's not reasonable, but the lease isn't the correct value to use here.  If we're actually implementing retry delays, we should be doing exponential backoff so that outages of up to a day don't prevent the job from completing.
<adeuring> abentley: ok, makes sense. But this is nothing I am going to implement before friday
<adeuring> abentley: anyway, hereis the current diff: http://paste.ubuntu.com/991164/
<abentley> adeuring: So I suggest making it a hardcoded 10-minute delay.  That will easily allow leases to expire, and give a bit of time for problems to clear.
<adeuring> abentley: ok
<adeuring> abentley: current diff: http://paste.ubuntu.com/991191/
<abentley> adeuring: Since 'generator' has a specific meaning in Python, how about 'factory'?
<adeuring> abentley: sure
<abentley> adeuring: It looks like you're using a retry delay of 1 second, rather than 10 minutes.
<adeuring> abentley: gahh, fixed: retry_delay = timedelta(minutes=10)
<abentley> adeuring: Are the Celery docs wrong?  They say "eta must be a datetime object, specifying an exact date and time (including millisecond precision, and timezone information)"
<adeuring> abentley: yes. try it for yourself
<adeuring> i tried datetime objects with timezone myself...
<abentley> We should file a bug on the documentation, then.
<adeuring> yes
<abentley> adeuring: Okay, r=me with your latest changes.
<adeuring> abentley: thanks
<abentley> adeuring: we should always supply an ETA, not just when there is a lease.
<adeuring> abentley: why?
<abentley> adeuring: If we're retrying, then we must have acquired a lease, because we always acquire a lease before running, and we can't retry until we run.
<abentley> adeuring: But if there was some scenario where we could retry without having acquired a lease, we would still want to wait because it doesn't make sense to retry immediately, as you've pointed out.
<adeuring> abentley: yes, that's the logic there: If a lease exists, this is an attemt to retry a job, so we need an ETA: but we don't need that when the job is run fpot the first time
<adeuring> abentley: ok, i see your point, but for now i give. simply too late here...
<abentley> adeuring: I'm not retracting the r=me, but I think we should fix that.
<adeuring> abentley: ok, that's right
<daker-cloud> czajkowski: the CPU is getting hot :)
<czajkowski> daker-cloud: do ask questions if you get stuck ok
<czajkowski> lotta lp dev folks around
<daker-cloud> ok now i am running make schema
<daker-cloud> czajkowski: https://plus.google.com/u/0/101694416703170881163/posts/Ad3hvn385Po :)
<sinzui> jcsackett, mumble?
<czajkowski> daker-cloud: cool, what are you looking to fix
<daker-cloud> not sure czajkowski, do i need a mentor ?
<daker-cloud> this thing is huge
<czajkowski> so lp doesnt have mentors, they do have code reviewers, and you could post to the launchpad-dev mailing list with abug you are working on or want to work on to get some feedback
<czajkowski> daker-cloud: or ask people in here like sinzui wgrant jcsackett and others who are around in your timezone
<daker-cloud> ok
<wgrant> czajkowski: I'm American now!?
<czajkowski> wgrant: no, you just dont sleep
<wgrant> True.
<StevenK> wallyworld_: I've got a deployment edit all ready, let me know when your QA is done.
<wallyworld_> StevenK: done
#launchpad-dev 2012-05-17
<cjwatson> Would anyone else find http://paste.ubuntu.com/991587/ useful?  Should I send that to launchpad-dev?
<cjwatson> My bzrlib is rusty; it probably shows.
<jelmer> cjwatson: perhaps a useful thing to stick in lp-dev-utils ?
<cjwatson> Yeah, perhaps I should just send an MP there ...
<wallyworld_> wgrant: the sharingdetails page for ~launchpad-security timeout cold at around 6s on qas since it is displaying ~750 bugs and that page doesn't have batching. the slowest query is the bugtask privacy filter with all those ORs, plus there's some slowish python to assemble the results. given this level of sharing will be going away and it runs ok on qas after a refresh or two, i think we can leave it go for now. the page bulk
<wallyworld_> loads all data and query count is minimal
<wgrant> wallyworld_: OOPS ID?
<wallyworld_> don't have one anymore since i refresh the page with ++profile++ and it went away
<cjwatson> https://code.launchpad.net/~cjwatson/lp-dev-utils/loc-delta/+merge/106080
<wgrant> wallyworld_: Can you use ++oops++ to grab one?
<wgrant> Want to see the query and just how slow it is.
<wallyworld_> wgrant: OOPS-3ce9cad8e944ce915a7b4b967eeed405
<wallyworld_> query is the standard bug task id search
<wallyworld_> about 1300ms
<wallyworld_> that's the slowest one
<wallyworld_> StevenK: does your current work add an info_type parameter to makeBranch() in factory?
<wgrant> wallyworld_: That query is 40ms hot on DF. I wonder if qastaging is just cold.
<wallyworld_> wgrant: could be. there's a lot of OR's in there. the page on qas now takes around 5s to load which is pushing the friendship a bit. but it's rendering 750 entries
<wallyworld_> and since we do not expect to see that many shared artifacts moving forward, i think it's ok
<wallyworld_> or we need to add batching
<wgrant> We probably will need to add batching, but we'll see.
<wallyworld_> the core issue with regard to the number and type of queries has been addressed
<wallyworld_> let's see what happens on prod
<StevenK> wallyworld_: It does, yes.
<wallyworld_> StevenK: what's the eta? i may have to put a branch up for review a bit later and then merge yours in before i land
<StevenK> wallyworld_: I have a bunch of test failures to sort out.
<wallyworld_> ok
<wgrant> wallyworld_: Ahhh
<wgrant> wallyworld_: There's so many disjunctions that the planner gets confused.
<wallyworld_> would IN be better?
<wgrant> wallyworld_: With <100 it's OK, but with 700 it spends a second planning and gives up.
<wgrant> wallyworld_: So an IN is much better for huge stuff like this :(
<wallyworld_> wgrant: i f*cking told you!
<wgrant> You didn't say there were 770 of them :P
<wallyworld_> i said there were "lots"
<wallyworld_> :-P
<wgrant> I thought we were dealing with sensible batches!
<wallyworld_> to quote you, "but this is launchpad"
<wgrant> Anyway, should be easy enough to convince that function to use is_in instead.
<wallyworld_> i'll spin up a followup branch a bit later
<wallyworld_> wgrant: i could just replace the OR with IN in all cases
<wgrant> You'll need to special-case for when the PK is a single column.
<wgrant> But it's like 2 lines.
<wgrant> Since technically it can be used for composite keys now too
<wgrant> Although you could just assert in that case :)
<wgrant> Since it's unlikely we'll ever want it to.
<wgrant>                 comp._relation.get_where_for_local(value)
<wgrant>                 for value in search_value.query_values])
<wgrant> get_where_for_local can technically return more than a simple equality.
<wgrant> You should probably assert that it returns a simple equality.
<wallyworld_> ok, will look into doing that
<wallyworld_> will finish what i'm on first
<wgrant> Sure
<lifeless> loc - http://www.ohloh.net/p/launchpad
<wgrant> _dbify_value and _dbify_column in lp.services.database.bulk show some of the Storm molestation you might desire.
 * wgrant needs a reviewer for https://code.launchpad.net/~wgrant/launchpad/what-the-distromirror/+merge/106086 at some point (non-urgent now)
<wgrant> wallyworld_: +        <div id='information-type-description' style='padding-top: 5px'>Everyone can see this information.</div>
<wgrant> Isn't that too hardcoded?
<wallyworld_> huh? that's template which is replaced
<wgrant> By JavaScript.
<wallyworld_> like we do for the rest of our TAL
<wallyworld_> yes
<wgrant> +      This report contains <strong id="information-type" tal:content="view/information_type"></strong> information&nbsp;
<wgrant> +        <a class="sprite edit" id="privacy-link" tal:attributes="href link/path" tal:condition="link/enabled"></a>
<wgrant> +        <div id='information-type-description' style='padding-top: 5px'>Everyone can see this information.</div>
<wgrant> The information_type title will be replaced if it's non-public, but the description will not.
<wgrant> (before the JS loads)
<wallyworld_> hmmm. i think you are right
<wallyworld_> i should fix that
<wallyworld_> grumble. too many branches open
<cjwatson> Sounds like an error message from Perforce.
 * cjwatson eyes his branch to allow granting per-pocket upload permissions.  It's passing tests.  I'm not sure I quite believe it can be this easy.
<wgrant> cjwatson: It's very easy.
<wgrant> Queue perms are a bit harder.
<wgrant> But not by much.
<cjwatson> I wonder if this would allow nuking ubuntu-security as a celebrity.  (Probably not quite since (a) they have to move over to copyPackage and (b) I have to figure out how to save them from having to manually approve all their copies.)
<wgrant> That was the plan.
<wgrant> It's only a celebrity so they can have launchpad.Append on the primary archive, to use syncSource.
<cjwatson> Oh and copyPackage probably needs to learn how to do the librarian republishing dance.
<wgrant> It should already do that.
<wgrant> But that needs testing.
<cjwatson> OK, that helps.
<wgrant> It's in the core copy infrastructure these days.
<cjwatson> Modulo lies about the db revision, does http://paste.ubuntu.com/991705/ look plausible?  I'm concerned that the constraint modification there is wrong, but there's no MODIFY CONSTRAINT in pg.
<wgrant> cjwatson: Seems sort of reasonable, unless you want universe queue admins.
<wgrant> In which case you want component+pocket.
<wgrant> s/queue admins/SRU admins/
<cjwatson> I don't.
<StevenK> cjwatson: COMMENTs are usually added to database/schema/comments.sql
<cjwatson> I was more concerned whether DROP/ADD CONSTRAINT was remotely sane.
<wgrant> cjwatson: That's fine, the table is small.
<cjwatson> $ grep COMMENT database/schema/patch-2209-* | wc -l
<cjwatson> 12
<wgrant> cjwatson: It's a problem on large tables until PG 9.2
<wgrant> StevenK: It can be either now
<StevenK> Bleh
<StevenK> cjwatson: grep -c ? :-)
<cjwatson> picky picky
<StevenK> Haha
<cjwatson> Anyway, no, that's a per-file count
<cjwatson> Well, in that case does anyone fancy allocating me a DB patch number for this?  I need sleep shortly but I could get at least the DB side of this going.
<cjwatson> wgrant: the librarian privacy bits only seem to be driven from UnembargoPackage, looking at packagecopier.py
<wgrant> cjwatson: I'll grab a patch number.
<cjwatson> UnembargoSecurityPackage that is
<wgrant> cjwatson: You're missing a crucial piece of information.
<wgrant> cjwatson: Launchpad is not sensible.
<wgrant> scripts.packagecopier is also called by model.queue
<wgrant> When realising copies.
<StevenK> cjwatson: You can also look at lp:~launchpad/+junk/dbpatches and ask someone to allocate you a patch number you pick.
<wgrant> Ah, but PCJs skip that :(
<wgrant> bigjools: !!!
<bigjools> what
<wgrant> DDs left us with four inconsistent copiers and it makes me sad.
<cjwatson> Ah, I missed the call in realiseUpload
<wgrant> cjwatson: That's how syncSource works.
<wgrant> When it sees there are private files it produces a delayed copy.
<wgrant> Which is actually a PackageUpload.
<cjwatson> The direct/delayed copy nomenclature refuses to fit into my head for some reason.
<wgrant> cjwatson: 2209-18-1
<cjwatson> Though I can see how it makes sense.
<StevenK> Can we destroy delayed copies yet?
<wgrant> It doesn't make sense.
<wgrant> StevenK: No, mostly because of this particular thing.
<cjwatson> wgrant: I'm adding a column, is that allowed to be -1?
<StevenK> wgrant: Yes. :-(
<wgrant> cjwatson: Yeah, the notes on -0 have been a lie since October.
<wgrant> cjwatson: All patches are equal.
<wgrant> And none are more equal than others.
<cjwatson> I've been rather confused, since the last time I asked for a patch number for ADD COLUMN lifeless allocated me a -0, and I figured he knew what he was doing.
<wgrant> When was that?
<wgrant> He probably just opted to start a new series.
<cjwatson> 2012-05-08
<wgrant> Not specifically for a -0
<StevenK> 2209-18-0 cjwatson      Add packageset.score.
<wgrant> 'cause I deploy -1 patches that add and drop tables and columns all the time.
<StevenK> Heh, 19-0 is already wgrant's.
<lifeless> we're at +4K over 5 months now, thats much better
<lifeless> +45K for the same period a year earliy
<wgrant> A fair bit of that will go away with the next DB refresh, too.
<lifeless> \o/
<lifeless> the encouraging thing is that its a whole OOM
<lifeless> vs say 75%
<lifeless> which would have a different and sadder explanation
<lifeless> cjwatson: are you also in perth this weke ?
<cjwatson> lifeless: No, just insomniac
<cjwatson> Is there some kind of event in Perth then?
<bigjools> that is particularly insomniac at 4am
<wallyworld_> wgrant: the storm NEWS file seems out of date. the one in our lpwithnodatetime fork i mean. do we not need to update that if we package a release?
<wgrant> We don't ever actually release, we just package snapshots.
<wgrant> I think it's up to date...
<wgrant> wallyworld_: Why are you patching Storm?
<wallyworld_> to make get_where_for_local work more efficiently and to handle single values and lists
<wallyworld_> so we don't have to construct an Or expr manually in the calling code
<wallyworld_> or worry about single or composite keys
<wallyworld_> so it reduces down to one line in the calling code
<wallyworld_> the work is done, i just need to package
<wgrant> Mmm, I'd just do it in our tree. There's already a couple of functions that poke the necessary bits. None of this is exposed in Storm's public API
<wgrant> Ah
<wgrant> What's the diff?
<wallyworld_> wgrant: a bit easier to read a straight cut and paste https://pastebin.canonical.com/66227/
<wgrant> wallyworld_: Won't that break if I have a composite primary key and say "Foo.bar == (Bar.pk1, Bar.pk2)"?
<wgrant> Which IIRC works now
<wallyworld_> hmm. might do. i'm not 100% familiar with how == is parsed
<wallyworld_> i could add logic to handle that
<wallyworld_> i was going to run the storm tests to see what broke
<wgrant> I would just add a separate function
<wgrant> Well, method if you want it in Storm itself.
<wgrant> Rather than overloading the existing one
<wgrant> When it can probably already take an iterable.
<wallyworld_> the implementation uses things like self.local_keys which are internal so i think i'd prefer it to be in storm. but we could do it in our tree if we wanted
<wgrant> Sometimes there's little choice but to poke in the internals, because there's no way to access this internally.
<wgrant> I mean, look at the caller already :)
<wgrant> comp._relation
<wgrant> It already touches Storm inappropriately.
<wgrant> No way to access this *externally*, that is
<lifeless> we should push as much of this into storm as we can
<lifeless> the in-tree storm stuff shouldn't be, mostly.
<wgrant> Sure, but that involves talking to Storm and working out how to expose these private things sensibly.
<wgrant> ... or switching to SQLAlchemy, but I digress.
<wallyworld_> i wish we weren't on a fork of storm
<wgrant> The fork is very small.
<wallyworld_> so if i do this change, do i just push it to our fork, or do i also get it merged into trunk?
<wgrant> It's just got a couple of lines of Datetime stuff removed, and the With stuff added.
<wgrant> wallyworld_: Also merge it into trunk.
<wgrant> We don't want to diverge any further than we have to.
<wgrant> Which means that if Storm doesn't accept it quickly, I'd keep it in our tree instead.
<wgrant> Although Storm development has stalled enough that conflict resolution isn't too bad.
<wallyworld_> the issue here is that i would be adding a method which is not exposed publically which we are calling
<wallyworld_> and so asking for it to be added to trunk would be unusual
<wgrant> Right.
<wgrant> Exactly.
<wgrant> Which is why it shouldn't be in Storm, unless it's part of a larger strategy to expose this stuff.
<wallyworld_> i really don't want to go down that path right now
<wgrant> Which is why I did bulk.create()'s stuff in LP, not Storm.
<wallyworld_> i might stick it with the rest of our storm stuff
<wgrant> There's no reason to do that.
<wallyworld_> hide it under the carpet
<wgrant> All it does is make things more awkward.
<wgrant> The stuff in there is only there because it has to be in core, or monkeypatching everywhere.
<wgrant> _get_where_for_local_many can easily be implemented as an isolated function in our codebase.
<wallyworld_> well the alternative is to continue divirging our fork
<wgrant> 13:37:06 < wallyworld_> i might stick it with the rest of our storm stuff
<wgrant> Isn't that what you meant?
<wgrant> Or you mean in like lp.services.database? That's where I'd put it.
<wgrant> I thought you meant in the fork :)
<wallyworld_> yes, that's what i meant
<wallyworld_> lp.services..
<wgrant> Right.
<wgrant> There's already very similar stuff in lp.services.database.bulk
<wgrant> I use _relation there
<wallyworld_> at least then also the reference to _relation is shoved off to a helper
<wgrant> Precisely.
<wgrant> (bulk.create() uses it to take objects and Reference columns and work out the relevant underlying columns and values -- exactly what you're doing here)
<wallyworld_> ok, will do that. might not get it done before i have to duck out to take the kid to his occupational therapy session. but will get it done today
<wgrant> :)
<wallyworld_> then the performance issue should be fully squashed i hope
<wgrant> Yup
<wgrant> Sorry for misleading you, I forgot it was an unbatched page.
<wallyworld_> it seems to work on prod now but is sliggish
<wallyworld_> sluggish
<wgrant> Thought we were talking like 75 :)
<wgrant> Yeah
<wallyworld_> 75 what?
<wgrant> 75 bugs
<wgrant> Not 770
<wgrant> It plans 75 ORs with no trouble at all
<wallyworld_> ah, right. no need to apologise.
<wallyworld_> and 700+ is way too many anyway. once we get stuff cleaned up, that will surely go away
<wallyworld_> once we move to policy grants
<wgrant> Weeell
<wgrant> There'll still be some big stuff, probably.
<wallyworld_> once we find it, we can add batching :-)
<wgrant> Heh
<StevenK> lifeless: It's *so* handy that testr --version or -V don't work.
<StevenK> And I think testr run --failing is running every test
<lifeless> StevenK: dpkg -l testrepository
<StevenK> wgrant, wallyworld_: https://code.launchpad.net/~stevenk/launchpad/branch-use-information_type/+merge/106109
<wgrant> Aha, the LoC offenders are revealed!
<StevenK> Hm?
<wgrant> Linaro looks to be +3400 in total :(
<StevenK> Is there a breakdown by squad/person?
<StevenK> wgrant: information_type is fully populated on production, which means we can depend on it.
<wgrant> StevenK: Oh, bah, indeed.
<wgrant> Forgot that.
<wgrant> StevenK: Does it respect transitively_private?
<wgrant> I suspect not.
<StevenK> wgrant: In terms of your other comments, http://pastebin.ubuntu.com/991832/
<wgrant> StevenK: You untaught the factory about information_type entirely?
<StevenK> Hm, so I did.
<StevenK> Bah, .transistionToInformationType respects the rules in terms of branch policy. :-/
<bigjools> packageset.score is a terrible name :(
<StevenK> wgrant: http://pastebin.ubuntu.com/991845/
<wgrant> StevenK: Now the factory won't set information_type if you pass private but not information_type.
<wgrant> And information_type silently clobbers private.
<StevenK> And if you pass in information_type=InformationType.EMBARGOEDSECURITY, private=False ? :-)
<wgrant> StevenK: assert
<wgrant> Don't just silently clobber.
<StevenK> wgrant: http://pastebin.ubuntu.com/991859/
<wgrant> StevenK: You can't spell specify, and that check doesn't handle the case above.
<StevenK> Yes it does?
<StevenK> In [2]: b = factory.makeBranch(information_type=InformationType.EMBARGOEDSECURITY, private=False)
<StevenK> ---------------------------------------------------------------------------
<StevenK> AssertionError
<StevenK> But it doesn't complain with private=True. Strange
<wgrant> Er, yeah, that's the case it doesn't complain in.
<wgrant> You want both to default to none.
<wgrant> And at most one of them to not be none.
<StevenK> Right, fixed.
<StevenK> wgrant: Now that we've spent 30 minutes talking about the factory, what was your concern with respecting transitively_private?
<wgrant> StevenK: eg. transitively_private or private gets set on a stacked-on branch, it won't propagate up.
<StevenK> wgrant: Yes, I'm not sure what happens in that case.
<StevenK> I do wonder how many layers of stacked_on we have in prod
<StevenK> wgrant: Shall I land it, or we can talk it over on the call tomorrow?
<wgrant> StevenK: You need to investigate and probably test how it interacts with stacking.
<wgrant> There's not much to discuss yet.
<lifeless> StevenK: I think 7 is the highest
<lifeless> anyone looked at http://optimizely.appspot.com/features - specifically whether its js will work if we self host ?
<stub> Does a public branch stacked on a private branch leak any information? Is it possible to retrieve revisions only in the private branch via the public branch?
<lifeless> no and no
<lifeless> however, the public branch will be unusable
<stub> ah, thought it was a security issue rather than an its broken issue :)
<lifeless> stacking: an ancient african word meaning 'we made a mistake here'
<lifeless> stub: catchup?
<stub> lifeless: sure. let me scare up my mic
<lifeless> stub: I should be logged into skype; if not tell me here and I'll kill-9it
<stub> lifeless: I don't see you
<lifeless> stub: grah, yeah its hung
<lifeless> stub:
<lifeless> http://reorg.projects.postgresql.org/
<lifeless> stub: http://pgfoundry.org/projects/reorg/
<wgrant> Omg
<wgrant> CLUSTER, but usable?
<wgrant> Give me it now
<stub> CLUSTER, but scary
<stub> actually, not that scary. Looks like it creates a holding table, adds triggers to the source table, pours data into the holding table, merges in the delta, swaps holding table into place.
<stub> 'swapping into place' is the scary bit as it modifies the system catalog directly so all the dependencies don't notice the move (foreign key references, views etc.).
<stub> Leading to lovely things like: Bugfix: VIEWs and FUNCTIONs could be corrupted that used a reorganized table which has a dropped column.
<lifeless> stub: I'm back
<lifeless> stub: http://www.pretotyping.org/
<lifeless> ok, night all
<StevenK> rick_h_: Oh sigh. I see what was broken in bug 1000282.
<_mup_> Bug #1000282: Uncaught TypeError on translations series +imports <combo-loader> <javascript> <qa-needstesting> <Launchpad itself:Fix Committed by rharding> < https://launchpad.net/bugs/1000282 >
<jamestunnicliffe> gmb: Any estimate on https://code.launchpad.net/~dooferlad/launchpad/upcomingwork_show_incomplete_bp/+merge/105846 being reviewed? If you can't get around to it today I would like to open it up to another reviewer since it is getting urgent.
<gmb> jamestunnicliffe: I'll have an updated patch for you by 1pm.
<jamestunnicliffe> gmb: Supurb!
<gmb> Apologies for the delay; post-UDS stuff has been eating into my time.
<jamestunnicliffe> gmb: superb even :-)
<jamestunnicliffe> Oh, I can't see this morning
<jamestunnicliffe> Good start to the day!
<rick_h_> StevenK: yea, nothing big. I'm surprised there aren't more of those
<rick_h_> StevenK: at some point I'll get back to that AST branch of the combo.meta that will hopefully not be as fragile with the parsing, which isn't all *that* fragile so far
<jelmer> cjwatson: Did you have any plans to put your loc script for review? If not, I can have a stab at doing that now.
<wallyworld_> anyone else having issues with branches not being scanned?
<cjwatson> jelmer: https://code.launchpad.net/~cjwatson/lp-dev-utils/loc-delta/+merge/106080 (which is awaiting scanning for the latest change that renames it to the slightly more explanatory loc-contributions, c.f. wallyworld_'s comment ...)
 * wallyworld_ has 3 branches which have not been scanned
<wallyworld_> all within the last 45 minutes or so
<wallyworld_> i tried forcing a rescan and also pushing to a new test branch
<cjwatson> sounds like something to ask ops about, since that roughly coincides with the 9.1 upgrade
<cjwatson> Anyone have thoughts on plausible things I can do with bug 1000570?
<jelmer> bug 1000570 ?
<cjwatson> bah, botless.  it's a column rename, which I think is reasonable; the code change that uses it has just landed but not yet been QAed or deployed
<cjwatson> wondering if there's any more elegant approach than backing out the code change, FDTing a rename, reapplying code with rename
<gmb> jamestunnicliffe, Can you tell me how to get something to appear in the work items for a Person in Launchpad.dev so that I can test my  solution?
<gmb> I just want to verify it before pinging it back to you.
<jelmer> cjwatson: I guess you could just rename it in python and leave it as is in the db.
<cjwatson> I could, not sure that would please bigjools though :)
<cjwatson> seems like this is probably about the best opportunity to get the naming right, and there isn't a desperate rush to get this deployed
<jelmer> cjwatson: On the other hand, it's marked low so it might be sensible to just leave the bug open until somebody touches this bit of the code again.
<jelmer> cjwatson: and renaming the zope bit of it at least means we don't break API users in the future.
<cjwatson> I guess I can ask bigjools what he thinks when he's next online.  That was easier before he inconsiderately moved. :-)
<jelmer> :-)
<cjwatson> I mostly don't want to do renaming work in one direction to find that it's insufficient and it would've been easier to back out
<cjwatson> IYSWIM
<jelmer> cjwatson: fair enough; indeed best to ask bigjools what he means though, the rest of us can only speculate :)
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/packageset-score/+merge/105915 has the other half of his comments
<cjwatson> jelmer: did you see my loc merge request above that you were asking about?
<jelmer> cjwatson: yep, playing with the code atm
<wallyworld_> cjwatson: branch scanning seems ok again
<cjwatson> wallyworld_: oh good, thanks
<wallyworld_> np
<cjwatson> Can somebody set https://code.launchpad.net/~cjwatson/launchpad/db-pocket-permissions/+merge/106091
<cjwatson> to Approved so I can land it?  Looks like it has sufficient review.
<rick_h_> cjwatson: looking
<rick_h_> cjwatson: can you set a commmit msg please?
<cjwatson> Oh yes, done.  Thanks, I'll go ahead and land that now then
<rick_h_> ok
<danilos> gmb, did you manage to get workitems to show up on upcoming work page?
<jamestunnicliffe> gmb: Apologies, had a few things to get done over lunch and just missed you. There is a script that didn't make it into trunk to create some users with outstanding work items that I can pastebin you if you want.
<danilos> gmb, easiest is to create a blueprint, target it to a milestone (with target date set to a date in nearby future), and then add a few workitems in the workitem box on the BP page (eg. "[gmb] Sing the song of love: TODO")
<jamestunnicliffe> gmb: Just tested your version - it works :-)
<salgado> jamestunnicliffe, oh, I have a script like that... it does create loads of stuff, and using WI titles from production even
<salgado> http://paste.ubuntu.com/992291/
<jamestunnicliffe> salgado: Cool - that is more extensive than the one I have. Thanks!
<salgado> np :)
<wallyworld_> sinzui: hi, i'm about to go to bed but it appears there's a timeout issue submitting mps (i have one i was hoping for you to review). seems coincident with the postgres upgrade. could you ping someone for me to see what's up?
<wgrant> wallyworld_: OOPS ID?
<gmb> jamestunnicliffe: Okay, so, we need to find something to offset the change with. I'll be looking this afternoon and will try to get this into EC2 for you before my EoD.
<wallyworld_> wgrant: no oops is shown, just a simple dialog
 * gmb -> grabbing a late lunch; bbiab.
<jamestunnicliffe> gmb: Don't worry about LOC. danilos is going to do a big delete soon.
<gmb> jamestunnicliffe, danilos: How soon is "soon"? I'd like to be able to point lifeless at it when he asks me...
<danilos> gmb, https://code.launchpad.net/~danilo/launchpad/kill-feedback-requests/+merge/106119
<danilos> gmb, I'd be happy to get a review if that works for you :)
<danilos> gmb, (i.e. to make it "sooner" :)
<gmb> danilos: Then I'll take a look this afternoon :)
<danilos> gmb, thanks
<salgado> jamestunnicliffe, I just saw that https://launchpad.net/~linaro/+upcomingwork is broken.  maybe you guys know about it already...
<jamestunnicliffe> salgado: no, that is new to me.
<jamestunnicliffe> salgado: is there backtrace or other info available in a log somewhere that could help me recreate it? I see that the linaro team has no blueprints, but I would hope that condition is already covered by a test.
<salgado> jamestunnicliffe, you'll have to ask somebody from the LP team for the backtrace. I don't have the rights to see it anymore
<jamestunnicliffe> gmb: Can you get those logs ^^ or pass the request on?
<gmb> jamestunnicliffe: There will be something soon; I'm waiting for the OOPS data to sync so I can look at it.
<jamestunnicliffe> gmb: Thanks.
<wgrant>     Module lp.registry.browser.person, line 4469, in initialize
<wgrant>     100.0 * total_done / float(total_items))
<wgrant> ZeroDivisionError: float division<br />
<wgrant> jamestunnicliffe, salgado: ^^
<jamestunnicliffe> wgrant: Thanks. Should be an easy fix!
<wgrant> jelmer: Thanks.
<jelmer> wgrant: anytime
<jelmer> wgrant: how are reviews generally done these days, are there still on-call reviewers?
<mgz> ...why is wgrant still awake?
<wgrant> jelmer: Yeah, there's an OCR schedule. But it's a bit empty sometimes, since some squads are doing other things.
<wgrant> mgz: It's not quite midnight :)
<wgrant> jelmer: https://dev.launchpad.net/ReviewerSchedule
<jelmer> wgrant: thanks; I'd seen it but was curious if it was still accurate
<wgrant> It's meant to be.
<jelmer> I guess I should find myself a new slot.
<czajkowski> mgz: https://dev.launchpad.net/ReviewerSchedule
<wgrant> And is vaguely.
<wgrant> jelmer: You may wish to strike out Orange for now
 * czajkowski and wgrant are in competition as to who can stay up the latest 
<jelmer> I'll take Thurs/Europe
* jelmer changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jelmer | Firefighting: - | Critical bugs: 3.47*10^2
<wgrant> Thanks :)
 * jelmer heads out for belated lunch and to get a new headset
<mgz> if you want to test it when you get back I brought mine into town :)
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jelmer, jcsackett | Firefighting: - | Critical bugs: 3.47*10^2
<czajkowski> jcsackett: any idea how you add content to the download section of a project page ?
<jcsackett> czajkowski: i *think* your project needs to have a release, and on the release page there should be an "add download" button. but that information may be outdated.
<jcsackett> sinzui: can you confirm/correct that? ^
<jelmer> mgz: feel like doing some headset testing?
<mgz> mumblin' it up now
<czajkowski> jcsackett: thanks
<jcsackett> czajkowski: you're welcome. hope i'm right. :-P
<popey> czajkowski / jcsackett ok, so how does one do the release bit?
<czajkowski> jcsackett: I was trying to find out for popey for his project
<jcsackett> czajkowski: dig. popey, what project?
<popey> https://launchpad.net/ubuntu-online-tour
<jcsackett> popey: what are you trying to put up for downloads? b/c at a guess you're not trying to put up a tarball package of your code.
<popey> i am
<popey> ubuntu-online-tour_0.11.tar.gz <- that :D
<jcsackett> ah, fantastic.
<jcsackett> then let's see if i can remember all of this right from the days of the registry team. :-)
<gmb> jamestunnicliffe, salgado: https://pastebin.canonical.com/66273/
<gmb> (that OOPs from earlier)
<jamestunnicliffe> gmb: I don't have access to the pastebin, but I am working on it (bug #1000787)
<_mup_> Bug #1000787: upcomingwork page fails when there are no work items <Launchpad itself:Confirmed for dooferlad> < https://launchpad.net/bugs/1000787 >
<gmb> jamestunnicliffe: Ok, cool.
<jamestunnicliffe> gmb: If the backtrace doesn't contain anything sensitive, perhaps post it as a comment on the bug?
<popey> jcsackett: thanks! help is appreciated
<gmb> jamestunnicliffe: Way ahead of you...
<jamestunnicliffe> gmb :-)
 * jelmer waves to allenap 
<allenap> \o jelmer
<jcsackett> popey: ok, so you can add a release on the series for your project, in your case https://launchpad.net/ubuntu-online-tour/trunk.
<jcsackett> in the "Milestones and releases" section you'll see a "+ Create release" link. that will require you to make a milestone--since you're releasing a tarball for 0.11, that's a likely name for your milestone. the option to do that will appear in the form for creating a release.
<jcsackett> popey, once you've created the release (and i think most of the information is optional for both it and the milestone) you will find the add download button on the release's page under the Download files for this release heading.
<popey> yay!
<popey> awesome, thanks!
<jcsackett> popey: you're welcome. :-)
<cjwatson> I can't see to do what Julian's asking for in bug 1000570.  I can see how to export a property on the webservice with a different name, but I think Julian's asking for LP-internal code also to refer to this variable as relative_build_score, and only the column to be called score.  Is that possible?  I can't seem to find an example.
<_mup_> Bug #1000570: "Packageset.score" is badly named <tech-debt> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1000570 >
<james_w> cjwatson, you can rename the attribute on the model and specify the column to use IIRC
<james_w> just trying to remember an example in the codebase already
<james_w> ah, set name="score" in the constructor
<james_w> relative_build_score = Int(name="score")
<cjwatson> james_w: oh, cool, thanks.  name= was hard to grep for, I actually tried and thought I didn't see anything
<cjwatson> grepping for ' [A-Z][a-z]*(name=' finds examples though
<cjwatson> OCR: could I have a review of https://code.launchpad.net/~cjwatson/launchpad/packageset-score/+merge/106220?
<cjwatson> hmm, jelmer and jcsackett may not have "OCR" on highlight, I guess :-)
 * cjwatson upgrades dogfood for some QA
<barry> gary_poster: ping
<gary_poster> barry, pong.
<barry> gary_poster: hi.  you probably heard about our py3 plans for 12.10, right?  i'm starting down the long arduous road of porting launchpadlib to python 3.  first stop is lazr.restfulclient.  i just wanted to coordinate to make sure i'm not duplicating effort, and so that we can eventually get releases of py3 compatible libraries.
<barry> gary_poster: i have a few questions for you, but want to first see if you have any questions for me :)
<gary_poster> cool, barry, yeah.  Well, I'm not sure whom you need to coordinate with, but it is probably not me.  flacoste or lifeless are the obvious candidates.  I'm happy to try and help coordinate the coordination though ;-)
<gary_poster> (since the squad rotation, my connection with lazr.* is not much more than anyone else's, and my visibility to things related to it and plans for it are much less)
<barry> gary_poster: cool.  i'll work with flacoste and lifeless (already working with him on testtools and testresources, via jseutter).  quick question: just how married are y'all to buildout for libraries like lazr.restfulclient?
<gary_poster> barry, um, no idea really.  another question for lifeless.  From my perspective as long as the approach specifies the version numbers for dependencies in a python friendly way (i.e., setup declares minimal dependencies and some other file specifies dependencies for shared testing, equivalent to buildbot versions, I'm happy enough.  I think pip has had something like that for years now.
<gary_poster> mm, the parenthetical phrase was supposed to end after "equivalent to buildbot versions" :-P
<barry> gary_poster: cool, thanks.  i'll try to chat with lifeless when he gets online
<gary_poster> cool, thanks for the py3 work barry
<barry> gary_poster: np!  i'm not volunteering to port launchpad just yet :)
<gary_poster> heh, darn :-)
<jamestunnicliffe> salgado: Having a problem with https://pastebin.canonical.com/66273/ is I can't recreate it in a test, or on a dev instance. In fact, I have looked through the code it calls and have no idea how total_items (and, I assume, total_done) are 0.
<jamestunnicliffe> salgado: Any inspiration appreciated :-)
<cjwatson> barry: it had occurred to me whether it might be worthwhile to do the obvious basic porting of Launchpad (print functions and the like) and get some good practices instilled early, even if a full port is a ways off
<barry> cjwatson: certainly making it `python2.7 -3` compatible would be a great first step
<cjwatson> IIRC maas has tooling to use the usual __future__ imports all over the shop
<salgado> jamestunnicliffe, not really, can't think of anything.  but you could craft a script that just calls getWorkItemsDueBefore('~linaro', ...) and get somebody to run it against the staging DB
<salgado> jamestunnicliffe, that would only work if you get the same OOPS on staging, though
<jamestunnicliffe> salgado: Thanks - it is something to try at least!
<jamestunnicliffe> salgado: https://staging.launchpad.net/~linaro/+upcomingwork - works on staging :-(
<jcsackett> cjwatson: r=me your MP. if you could you add a commit message to it, i will try to get it out to land today.
<cjwatson> jcsackett: I have landing access these days, so I can do that, although I generally need somebody in ~launchpad to set Status to Approved first
<jcsackett> cjwatson: i can do that, didn't realize you had landing rights or i would have already done it. :-)
<cjwatson> I've set a commit message, thanks
<cjwatson> I'm the weirdo who's in set(PQM - ~launchpad)
<jcsackett> cjwatson: that is peculiar. you're all set on the MP now.
<cjwatson> Great, thanks
<daker-cloud> hi i am looking for easy to fix bugs(html/css) anyone can pointe me?
<daker-cloud> czajkowski: launchpad superwomen help :)
<rick_h_> sinzui: did you fix history? /me looks up address for the "thank you beverage"
<sinzui> I did fix it
<rick_h_> that will be awesome
<sinzui> msie has a deep bug: link.pathname is relative
<sinzui> I wish Lp believed my branch has revisions in it to generate the diff
<rick_h_> bah, I hate it when adding a simple thing requires adding complex tests
<sinzui> The tests were easy actually. Most of my time as in a debugger in chromium and msie to locate the point they diverge
<rick_h_> sorry, talking about this small add to lazr.restfulclient. My issue isn't in a current set of tests so hav to add a bunch of crap
<rick_h_> waiting for your diff to load on this one so I can peek at the changes, curious how it ended up working out
<sinzui> rick_h_, I think I am going to repush the branch to a new location...overwrite said nothing needed to be pushed
<sinzui> rick_h_, http://pastebin.ubuntu.com/993138/
<rick_h_> sinzui: doh, sucky
<rick_h_> thanks for the link, I'll peek at it tonight.
<sinzui> jcsackett, do you have a few minutes to review https://code.launchpad.net/~sinzui/launchpad/bug-listings-urls/+merge/106266
<barry> lifeless: ping
<lifeless> barry: otp
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2
<barry> lifeless: cool.  just ping me when you're free (if in the next hour)
<lifeless> kk
<sinzui> ian is this a start? https://code.launchpad.net/~wallyworld/launchpad/subscribe-grants-access/+merge/106277
<jelmer> are code import failures generally considered critical?
<jelmer> generally that doesn't seem to be the case, but bug 932463 is
<_mup_> Bug #932463: CVS code import failing <canonical-losa-lp> <code-import> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/932463 >
<lifeless> barry: hi
<lifeless> barry: I'm Off the phone
<barry> lifeless: haha!  i just sent you an email :)
<lifeless> jelmer: import failures per se - no; a regression in imports yes.
<barry> literally 5 seconds before you pinged me
<lifeless> so short answer
<lifeless> no resources
<lifeless> the team can and will review
<lifeless> we need to keep python 2 compat for the next 5 years.
<jelmer> lifeless: thanks
<barry> lifeless: python 2.6 minimal at least?
<lifeless> 2.6.5 (lucid) through to 2015
<lifeless> 2017 for python 2.7
<barry> that's fine.  nothing < 2.6 makes life much easier
<lifeless> (basically we need to be able to do SRU's or fixes for support Ubuntu releases)
<lifeless> if we fork into a 2 and a 3 branch that becomes harder
<lifeless> but it may be cheaper overall; its hard to tell
<barry> yep.  i'm not planning on dropping python 2 support.  i think we can support both with a single code base
<jelmer> lifeless: where regression is an actual regression in the code I assume, not a code import that used to succeed but now happens to trigger a particular bug?
<lifeless> much of our stack isn't packaged and has little reason to be
<barry> lifeless: i only care about the parts of that stack that end up on the desktop cd images.  launchpadlib is the tip of the iceberg for that.
<lifeless> jelmer: right, so if import A suddenly has submodules added and fails, its not a regression. If extended file modes stops working its a regression.
<jelmer> lifeless: fair 'nough
<barry> lifeless: of course, what makes things trickier is trying to run the test suite under python 3 also.  that usually triggers a port of all the test dependencies.  i'm personally not comfortable testing only on py2, but it does increase the porting effort.
<lifeless> barry: yah. It would be nice if python packaging were more robust and safer to use on live systems ;)
<barry> lifeless: and buildout/pypi is better? :)
<lifeless> barry: hugely so
<lifeless> barry: and its an upstream root cause :)
 * barry sighs
<barry> lifeless: testtools and testresources, any eta on py3 compatible releases?
<jelmer> barry: testtools has a py3 compatible release that is packaged
<lifeless> barry: I got busy this week, haven't gotten to the reviews.
<lifeless> barry: other than noting the various issues and bugs :)
<jelmer> barry: it looks like python-testtools mostly just needs a sync from Debian (it's got a custom version in Ubuntu without py3 support)
<lifeless> barry: a note for LP things as well - please don't drop huge boilerplate in the projects; what we have is terrible enough :)
<barry> jelmer: hmm, i guess jseutter's branch isn't strictly necessary then
<barry> jelmer: oh, that's easy then
 * barry can do that
<barry> lifeless: right.  some of the packages use ez_setup.  in those cases we need to switch to distribute (or drop ez_setup).  if it doesn't use it, i won't add it
<lifeless> cool
<lifeless> I loath the use of ez_setup too, FWIW.
<barry> me too
<lifeless> LP's actual needed thing is for buildout to work.
 * barry nods
<lifeless> beyond that, we don't care, if you can nuke ez_setup at the same time (while retaining compat with lucid for deploys) \o/
<lifeless> For now though, we need buildout to work on lucid precise and quantal
<barry> fun
<lifeless> with python 2.6.5 on lucid and 2.7.x on precise and up
<lifeless> once we have pg9.1 behind LP, the next step is python 2.7 everywhere using the PPA for lucid
<lifeless> we'll still need 2.6.5 compat for client libraries
<barry> lifeless: oh, i sure hope that'll work :)
<lifeless> barry: so do we :)
<barry> lifeless: okay, thanks.  if there's anything else you can tell me in response to my email, that would be great.  otherwise, i'll just keep pinging you as mps stack up :)
<lifeless> barry: hah
<lifeless> :)
<barry> lifeless: if you get blocked, ping me.  either i can help, or i can find other folks to chip in too.  foundations team is probably going to sprint on py3 mid-june-ish
<lifeless> will do
<czajkowski> daker-cloud: whats up
<barry> thanks!
<daker-cloud> czajkowski: i am looking for easy to fix bugs(html/css) can you pointe me to someone who can help ?
<czajkowski> daker-cloud: um lemmie see
<czajkowski> lifeless: any thoughts?
<czajkowski> daker-cloud: https://bugs.launchpad.net/launchpad/+bugs?search=Search&field.tag=trivial  all those bugs are tagged trivial
<czajkowski> perhaps there is one in there
<daker-cloud> means those shouldn't be fixed, right ?
<barry> jelmer: i'm going to do a sync from sid->quantal of python-testtools 0.9.14-2 which will give us py3 support.  i don't think there's anything to keep from the 0.9.14-0ubuntu1 version
<czajkowski> daker-cloud: no they should
<jelmer> barry: me neither - and thanks!
<barry> jelmer: np!
<daker-cloud> czajkowski: ah ok ok
<StevenK> jelmer: Did you want to land cjwatson's lp-dev-utils MP?
<jelmer> barry: can you perhaps sync subunit too while you're at it?
<jelmer> StevenK: sorry, yes.. hadn't gotten round to that yet
<barry> jelmer: sure, let me look
<daker-cloud> czajkowski: thanks :)
<czajkowski> daker-cloud: https://bugs.launchpad.net/launchpad/+bugs?field.tag=easy also that one as well
<wallyworld_> StevenK: does any of your current work update BranchCollection to use information_type rather than private?
<StevenK> wallyworld_: BranchCollection? Nope.
<wallyworld_> StevenK: ok. i'll raise a separate bug for that
<wallyworld_> i have some XXX in some tests which i'll link to that new bug
<czajkowski> daker-cloud: if I'm not around do prod people in here they don't bite and will help you if they can ok
<wallyworld_> czajkowski: wgrant bites sometimes if he is hungry
<czajkowski> wallyworld_: I now owe him about 4 buckets worth of bickies!
<wallyworld_> if we keep him well fed we are all better off
<barry> jelmer: hahahah!  subunit's already been sync'd but it's in depwait on python3-testtools :)  that should all get unjammed when the testtools sync is processed
<barry> jelmer: i'll keep an eye on it tho
<czajkowski> wallyworld_: I do wonder if we fed him red bull and sugary sweets what would happen
<wallyworld_> czajkowski: i can tell you're not american or else it would have been cookies. actually he can legally drink now so maybe a 6 pack of beer instead
<jelmer> barry: ah, neat :) I didn't realize the automatic sync mechanism knew what 0build1 was for
<jelmer> barry: and thanks
<lifeless> jelmer: speaking of subunit
<lifeless> jelmer: daily build breakage :)
<wallyworld_> czajkowski: nooo. he would never sleep at all if he had red bull
<barry> jelmer: yep, *build*'s are ignored as deltas by the autosync
<daker-cloud> czajkowski: ok ok :)
<lifeless> czajkowski: trivial is indeed a good place to start
<czajkowski> wallyworld_: nope I'm Irish :)
<wallyworld_> awesome. i love ireland
<czajkowski> it rains. it's green. it rains :)
<jelmer> lifeless: whoops, thanks for the reminder
<jelmer> lifeless: I'll have a look this week
<StevenK> wgrant: http://pastebin.ubuntu.com/993320/ Was that what you envisioned?
<wgrant> StevenK: That sort of configuration, but I'm not sure what to do about branch D
<bigjools> czajkowski: you forgot the Guinness bit
<czajkowski> heh
<StevenK> wgrant: Currently the test fails because D remains EMBARGOEDSECURITY.
<StevenK> wgrant: But we all agree that EMBARGOEDSECURITY stacked on top of USERDATA makes no sense.
<wgrant> StevenK: Right, the question is what does make sense?
<StevenK> wgrant: Forcing all of them to USERDATA?
<wgrant> That could disclose them inappropriately.
<StevenK> wgrant: Note that B does exactly that as it stands.
<wgrant> This is true.
<rick_h_> wallyworld_: thanks for the quick review
<wallyworld_> rick_h_: np. btw, the combo stuff on lp.net rocks. seems so much faster
<rick_h_> wallyworld_: awesome! glad to hear it.
<rick_h_> lots that could be done to be made better, but hopefully good start.
<wallyworld_> rick_h_: so what's the timeframe for the additional optimisations?
<rick_h_> don't forget to run the combo loader in dev and check out the jsbuild_watch script as well
<rick_h_> wallyworld_: atm no idea since I'm off on something else for the next little bit
<wallyworld_> rick_h_: yeah, on my todo list.
<rick_h_> just working on bug fixes for the combo loader as they come up
<wallyworld_> rick_h_: perhaps a reminder post to dev list about how to run combo loader etc locally is warranted. just to prod everyone to do it
<rick_h_> yea, I tried to get jcsackett using it and even I forgot how to use it right.
<rick_h_> so probably a good idea to email again
<wallyworld_> rick_h_: it would be nice if you were allowed a bit of slack time to finish it all off 100% since otherwise it will not get done despiet best intentions
<rick_h_> I should look to see if there's a good way to get the combo loader defaulted to on in dev mode actually, in the dev db data I guess it'd be
<rick_h_> wallyworld_: yea, I know it. Had hoped to have some of that during maint, but got some higher priority proddings on other things
<wallyworld_> rick_h_: yes, you need to add the flag and regenerate sample data and commit
<wallyworld_> rick_h_: i do think we need to dogfood this so if you send the email, i can do the flag if you like
<StevenK> wgrant: Do you think D -> USERDATA is okay and then I can land this thing?
<rick_h_> wallyworld_: ok, will do. Working on closing up some work here at the moment and I'll do the email before I hit bed tonight
<wallyworld_> rick_h_: ok, no hurry. next SOD is fine :-)
<wgrant> StevenK: I don't think so.
<rick_h_> wallyworld_: appreciate the assist with the flag bit, I think that'd help a ton.
<wgrant> StevenK: But it may be,.
<rick_h_> wallyworld_: heh don't worry about it, working late to get stuff done so I can go away this weekend. rush rush
<wallyworld_> rick_h_: np, pleased to help. i'm just happy to have this all being used now. bring on yuii 3.5 i say
<rick_h_> hah! now that would be freaking awesome
<rick_h_> <3 3.5
<StevenK> And then the death of YUI 2
<rick_h_> yep, the calendar widget in 3.5 is shaping up nicely I believe
<wallyworld_> rick_h_: otp, talk later
<rick_h_> rgr
<rick_h_> anyone have permissions to pypi for lazr.restfulclient ?
<StevenK> I think wallyworld_ may.
<rick_h_> k, I'll bug him on it later, thanks
<wallyworld_> rick_h_: what's your pypi user name?
<rick_h_> wallyworld_: mitechie
<wallyworld_> rick_h_: you now owner, have fun
<rick_h_> wallyworld_: ty much sir
#launchpad-dev 2012-05-18
<bigjools> wallyworld_: are you review bitch today?
<wallyworld_> bigjools: depends
* wallyworld_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: wallyworld | Firefighting: - | Critical bugs: 3.47*10^2
<bigjools> heh
<bigjools> shame, I was just thinking about lunch at the P&W
<wallyworld_> bigjools: i can do that a bit later
<bigjools> allrighty then
<rick_h_> hey, team bonding is only to occur over approve video conference devices :P
<bigjools> rick_h_: we can stare at each other through beer glasses, does that count?
<rick_h_> hah, as long as the beer glasses aren't too thick where you get *confused*
 * StevenK stabs stacking more.
<wallyworld_> wgrant: when specifying a maintainer for a distro, how often would someone choose a new team that is not in existence yet?
<wgrant> wallyworld_: Somewhere between never and twice ever, I suspect.
<wgrant> wallyworld_: For projects it's slightly more relevant, but only barely.
<wgrant> I would not mourn its loss.
<wallyworld_> wgrant: good. because the +reassign page for distros has "this is a new team" choice but the js picker will not have that
<mwhudson> is that the generic "object reassignment" view?
<mwhudson> because that one is pretty good evidence that generic views work well approximately never
<wallyworld_> mwhudson: indeed it is
 * wallyworld_ goes to lunch with bigjools
<bigjools> I can't eat any more of wallyworld_
<StevenK> Well, he is full of cholesterol and coffee.
<StevenK> wgrant: You object to http://pastebin.ubuntu.com/993569/ ?
<wgrant> StevenK: Probably.
<wgrant> StevenK: For one thing it's racy.
<wgrant> The existing stuff was already racy.
<wgrant> But this is probably worse.
<wgrant> And it's also not clearly the correct behaviour.
<StevenK> wgrant: But we can't agree on the correct behaviour. :-(
<wgrant> Right.
<wgrant> Probably-buggy implementations of behaviour that hasn't yet been defined are fairly high on my schedule of things to object to.
<StevenK> But you also object without that change, and you say that there is nothing to discuss.
<wgrant> The two of us probably can't define what the correct behaviour should be, so just us discussing isn't going to be very helpful :()
<StevenK> wgrant: There, that should make you slightly happier.
<wallyworld_> StevenK: does your current work replace usages of transitively_private eg "if self.source_branch.transitively_private: do something"
<StevenK> wallyworld_: I don't think so.
<StevenK> Perhaps it should
<StevenK> However, that branch is blocked
<wallyworld_> StevenK: i am making branchcollection work with information_type. but tests are failing because stuff gets and sets private (and there's no hooks to sync info_type)
<wallyworld_> StevenK: so i might add that in my branch then
<StevenK> wallyworld_: So, I've discovered that an awful lot of code tests just set branch.explicitly_private directly. It's very annoying.
<wallyworld_> StevenK: yes, indeed. i'm running into the same thing
<wallyworld_> StevenK: i might introduce a mutator
<StevenK> wallyworld_: That might work.
<wallyworld_> StevenK: so if i do this stuff, it won't stomp on your work i hope
<StevenK> wallyworld_: I'm going to have to redo part of the work anyway, due to the f&%&$*$^$$ stacking discussion
<wgrant> wallyworld_: I think you basically have to wait for StevenK.
<wgrant> Due to the stacking thing.
<wallyworld_> what stacking thing?
<wgrant> Neither branch can be deployed until that issue is resolved.
<StevenK> wallyworld_: Read -dev
<StevenK> wgrant: You saw it?
<wgrant> Because information_type doesn't behave like transitively_private yet.
<wgrant> Yes.
<wallyworld_> wgrant: i can deploy my branch because info_type will just be mirroring transitively private
<StevenK> wallyworld_: The "Branch information_type and stacking" novel on the -dev list, that is.
<wgrant> wallyworld_: Only if you use a trigger.
<wallyworld_> ah right. but behind on my email
<StevenK> wallyworld_: You can not assume that, since transitively_private is done by trigger and information_type is not.
<wgrant> Precisely.
<wgrant> A mutator won't work
<wgrant> Since it's done behind Python's back.
<wallyworld_> sure. i haven't implemented anything yet
<StevenK> Then don't, and wait for me.
<wallyworld_> just finding failures in tests
<wallyworld_> well, i've started the branchcollection work. but i'll park that
 * wallyworld_ reads email
<wgrant> Once we've solved that it should be pretty easy.
<StevenK> I'll be auditing on Monday, anyway
<wallyworld_> wgrant: StevenK: the branchcollectin stuff works, but tests fail due to info_type and private getting out of sync. so i'll come back to that after StevenK does his stuff
<wgrant> Yup.
<wgrant> Sounds like a plan.
* wallyworld_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2
<wgrant> Night wallyworld_.
<wallyworld_> wgrant: i'm still here. just not ocr :-)
<wgrant> Ah
<adeuring> good morning
<czajkowski> morning
* adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugs: 3.47*10^2
<danilos> jelmer, hi, I see you claimed https://code.launchpad.net/~danilo/launchpad/kill-feedback-requests/+merge/106119: are there any questions you might have about it?
<jelmer> danilos: hi
<jelmer> danilos: yes, I started reviewing it yesterday. It seemed pretty straightforward
<jelmer> danilos: I'll try and finish it today, will ping you if I have any questions.
<danilos> jelmer, ok, thanks, just making sure you are not blocked waiting on me or anything :)
<danilos> jelmer, sure things, thanks again
<wgrant> danilos: That'll fail the person merge tests.
<danilos> wgrant, it will? because of the DB fields still in?
<wgrant> danilos: Person merge is required to have explicit handling for any person FK involved in a UNIQUE constraint.
<wgrant> danilos: You've removed that, so it will complain.
<wgrant> Normally you land a separate DB patch first which drops the FKs.
<wgrant> Then you can drop the person merge bits and the rest of the code.
<wgrant> And once that's deployed you can drop the table.
<danilos> wgrant, right, I was hoping to be able to pass with only one DB patch :)
<wgrant> Sadly not.
<danilos> btw, what was the policy, a separate bug for each db-devel landing or can I just reuse the existing bug number?
<wgrant> Reuse
<danilos> ack, thanks
<jamestunnicliffe> gmb: Mornin'. Now that your code is in https://code.launchpad.net/~dooferlad/launchpad/upcomingwork_show_incomplete_bp/+merge/105846, should I ask the on-call reviewer to take a look?
<gmb> jamestunnicliffe: Yes, that sounds sane. Don't forget to mention danilos's branch w.r.t LoC. I'll have that reviewed this morning.
<danilos> gmb, jelmer is on it already :)
<gmb> danilos: Ah, cool beans.
 * cjwatson looks very confused at dogfood.  I'm sure I've screwed something up, but I don't know what
<cjwatson> dogfood is at r15273; https://dogfood.launchpad.net/+apidoc/devel.html#packageset includes the new relative_build_score property; but:
<cjwatson> $ lp-shell dogfood devel
<cjwatson> ...
<cjwatson> >>> core = lp.packagesets.getByName(name='core')
<cjwatson> >>> core.relative_build_score
<cjwatson> AttributeError: https://api.dogfood.launchpad.net/devel/package-sets/quantal/core object has no attribute 'relative_build_score'
<wgrant> cjwatson: The WADL's probably old.
<cjwatson> Anyone have any clue what I did wrong?
<wgrant> Either your cached WADL, or the one on mawson
<cjwatson> mawson seems to have it; how do I clear the local cache?
<cjwatson> ah, let's try nuking this file ...
<wgrant> Somewhere in ~/.launchpadlib
<wgrant> It changes :/
<cjwatson> got it, thanks
<cjwatson> >>> core.relative_build_score
<cjwatson> 0
<danilos> wgrant, fwiw, the following makes person-merge tests pass for me: https://code.launchpad.net/~danilo/launchpad/bug-1000642-db/+merge/106343
<wgrant> danilos: Great.
<danilos> hum, branch is stuck at "updating branch"; I wonder if that's because I first pushed a branch with no changes compared to db-stable (forgot to commit the patch)
<danilos> or if the branch scanner is just being slow (though, it has been pretty quick lately)
<danilos> it updated, I guess it was just slow
<danilos> jamestunnicliffe, I believe you'll need to request another review on https://code.launchpad.net/~dooferlad/launchpad/upcomingwork_show_incomplete_bp/+merge/105846
<jamestunnicliffe> danilos: I know. I am just attempting to do some more testing, but having a bit of DB trouble.
<danilos> jamestunnicliffe, ah, ok :)
<danilos> jelmer, thanks for the review, we'll have to wait for the DB patch to land (stub has approved it) before we can land this
<wallyworld_> sinzui: is there any reason why the distribution members field is not exported to the webservice  like mirror_admin (for example) is?
<sinzui> wallyworld_, there was never a request to export it. The team does not have power
<wallyworld_> sinzui: if it is not exported, the ajax picker can't work
<sinzui> ha
<sinzui> it can be exported
<wallyworld_> so i would like to wrap the field definition inside exported()
<wgrant> Well
<wgrant> We could just drop the field instead.
<wgrant> That would be my preference.
<sinzui> wgrant, I want to keep it. I would like to add it projects. I would only consider removing it if someone ever implements project team hierarchies AKA project affiliations
<wgrant> Perhaps.
<wgrant> But the inconsistency with projects is confusing and silly.
<sinzui> wgrant, then we give project a members field so that Lp knows that the project has members who are not in an Lp role with power
<wgrant> sinzui: Can you look at bug #1001181?
<_mup_> Bug #1001181: Bug, branch and merge proposal views have large amounts of horizontal overflow in Firefox <javascript> <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1001181 >
<mrevell> jelmer, Is there a way to view code imports by VCS type? I can't find one, so I'm guessing not.
<wgrant> https://code.launchpad.net/+code-imports
<sinzui> wgrant, It is a regression. Something is  creating a very wide invisible something. I suspect help or a overlay which is visibility: hidden
<sinzui> they still take up space
<wgrant> sinzui: Yeah, that seems to be the issue.
<wgrant> I don't know quite which element it is, though.
<jelmer> mrevell: the code imports page has a way to list them by type
<wgrant> Perhaps one of the new intermediate divs you added.
<jelmer> mrevell: e.g. https://code.launchpad.net/+code-imports?field.review_status=&field.review_status-empty-marker=1&field.rcs_type=HG&field.rcs_type-empty-marker=1&submit=Submit
<mrevell> jelmer, Erk, yes, sorry
<sinzui> wgrant, I doubt that since the div would be following the existing rules. I think this might relate to the noscript branches I landed. I was going to remove the last Y.ua.ie hack fro our code today. I will solve this regression first
<wgrant> sinzui: Unless there was a > rule or something. But yeah, could be noscript.
<wallyworld> sinzui: i may have missed you reply - am i ok to export the distro members filed so the ajax picker can work?
<sinzui> yes
<wallyworld>  /msg NickServ identify cuteb89
<jamestunnicliffe> Hi, hopefully someone with good Zope Template foo can help. I need to conditionally add a class to a <tbody> element. I am not finding anything useful in the docs.
<jcsackett> jamestunnicliffe: i'm not TAL expert, but this *might* work. http://pastebin.ubuntu.com/994317/
<jcsackett> someone with better TAL foo could probably come up with something better, but it's a start.
<benji> jcsackett and jamestunnicliffe: unfortunately that won't work because it's not well formed.  One second, let me see if I can remember the way to do that.
<jcsackett> benji: doh, you're right.
<benji> the best way is probably to just tal:define the class list conditionally and have a single <tbody> element that uses that definition
<jamestunnicliffe> Sounds reasonable.
<jamestunnicliffe> Hi, I see that the on call reviewer is offline. What is the protocal at this point? Assign the review to launchpad and let someone claim it/
<jamestunnicliffe> ?
<cjwatson> yeah
<cjwatson> just leave the merge proposal at the defaults
<jamestunnicliffe> thx
<abentley> deryck: if around, could you please review https://code.launchpad.net/~abentley/maza-lib/basic-auth/+merge/106465 ?
<deryck> abentley, sure
<deryck> abentley, looks good to me.  r=me
<abentley> deryck: Thanks.
<deryck> abentley, np.  and have a nice weekend!  I am about to step away now.
<abentley> deryck: You too!
<deryck> Thanks!
<kendfinger> I have a Code import of the Chromium Git repo. it failed last time, and I am trying again as I see nothing wrong. I tried the SVN repo, but It imported , but I could not branch or browse the code! Anybody else have a problem like this?
#launchpad-dev 2012-05-20
<lifeless> StevenK: auditording?
<StevenK> lifeless: Yup, after e-mail and such like
<lifeless> cool
<lifeless> ping me if you need a sounding board or whatever
<StevenK> lifeless: You could have a peek at lp:auditorfixture and tell me if my _start() is full of crack
#launchpad-dev 2013-05-13
<StevenK> wgrant: I'm free to land db-previewdiff-to-bmp and start this pipe up?
<wgrant> StevenK: Might as well
 * StevenK files a high bug to track it all
<wgrant> DF's nearly done, btw
<wgrant> Probably 2-3 hours left
<StevenK> wgrant: Putting together an FDT for 1000Z
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/index-previewdiff-merge_proposal/+merge/162915 is the only branch of the pipe missing an Approve, can you look again?
<wgrant> StevenK: Hm, might that want to be unique actually?
<wgrant> So we can use the timestamp as a key
<StevenK> wgrant: The best we could do is a composite key of BMP and the timestamp, but it's a little table
<wgrant> StevenK: I mean in the context of an MP
<wgrant> With the schema in the pipe today, we'd have to use PD.id
<wgrant> But the timestamp is a natural key
<wgrant> So I'd make the index in that patch unique
<wgrant> (and rename to _key)
<StevenK> wgrant: Hm, I don't see the lxc veth* device after rebooting
<wgrant> StevenK: It won't be there until the container starts
<wgrant> It's the host side of the guest's eth0
<StevenK> wgrant: http://pastebin.ubuntu.com/5660394/
<wgrant> StevenK: Indeed
<StevenK> wgrant: The diff has updated
<Ursinha> wgrant, StevenK, hello :) how bad things would break if removed the requirement of people being sprint attendees for them to show listed as blueprint subscribers here: https://launchpad.net/sprints/uds-1305/+temp-meeting-export ?
<Ursinha> (and good morning, whenever you show up :))
<wgrant> Ursinha: We should check how much bigger and slower it would get.
<Ursinha> wgrant, right. How can we do that?
<Ursinha> wgrant, reasoning behind this is that it seems this is the first UDS registering attendance isn't required, but they still need to know the people that are subscribed to the blueprints
<Ursinha> cjohnston said they'll have problems with that, starting tomorrow
<Ursinha> I checked the code and it seems that being an attendee is a requirement to be displayed on that page, but I couldn't find the reason why
<Ursinha> do you know?
<Ursinha> I meant, subscribers displayed there need to be also attendees
<wgrant> Ursinha: Summit only cared about attendees, and there was no way in the export format to say whether someone was an attendee or not.
<wgrant> And IIRC Summit used to try to schedule even non-essential participants without conflicts if possible.
<wgrant> So it was fairly important that it not get random extra people.
<Ursinha> right, got it
<Ursinha> actually, as that page has a list of attendees, it would be fairly trivial to know if a subscriber is an attendee or not whenever parsing that
<Ursinha> so adding all subscribers at this moment is more a matter of performance than anything else?
<wgrant> Ursinha: It seems so.
<wgrant> Removing them is probably reasonable, though it might be worth someone running some quick queries to determine how many times more people that would have been for historical UDSen.
<Ursinha> right
<cjohnston> howdy
<cjohnston> wgrant and Ursinha thanks for looking into this... when summit runs in auto mode it does still try to make as many peoples schedules work as possible
<wgrant> cjohnston: So this sounds like it might be a regression.
<cjohnston> wgrant: I'm not sure that it is. I think while we were using LP for attendees, we never noticed the problem. but since we are trying to make things easier by not requiring registration on one service and everything else on another, I think we are now figuring this out
<Ursinha> cjohnston, wouldn't be too much to summit trying to work with the schedules of all subscribed people?
<cjohnston> Ursinha: I doubt there are that many people who aren't 'attending' but are subscribed to a BP
<cjohnston> But, atleast for this event, summit isn't doing the schdeuling, its being done manually
#launchpad-dev 2013-05-14
<cjohnston> Ursinha: if there is anything we can do to help please let us know
<Ursinha> wgrant, cjohnston , that page is only used by summit?
<cjohnston> AFAIK
<wgrant> Ursinha: Yes
<Ursinha> and who maintains summit?
 * cjohnston points to mhall119
 * cjohnston hopes wgrant doesn't point at cjohnston
<Ursinha> lol
<Ursinha> I ask because if we change launchpad and that causes summit to go crazy, that wouldnt be a launchpad problem :)
<cjohnston> Ursinha: its me
<cjohnston> and yes
<cjohnston> :-)
<Ursinha> given that summit people are aware and so
<Ursinha> ah, good then
<StevenK> wgrant: I might have to fix the garbo job to use memcache. Or we deploy it and then cowboy disable it until the next NDT
<wgrant> StevenK: Why?
<wgrant> Oh, you mean to stop it running more than once?
<StevenK> wgrant: Yeah.
<wgrant> StevenK: Depending on timing we'll want to run it at least twice anyway
<StevenK> wgrant: Really?
<wgrant> I'd personally have used a feature flag to just run it once when we wanted to
<wgrant> But it doesn't really matter
<wgrant> StevenK: Because it's possible that garbo will start before everything that creates previewdiffs has the new code.
<StevenK> Ah, true
<wgrant> eg. code deploys to ackee, garbo runs and updates MP 1234, taotie updates MP 1234's diff with the old code, then taotie gets the new code
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/deny-ddeb-deletion/+merge/163633 or shall I refactor out and have the same thing for changeOverride() ?
<wgrant> StevenK: I'd consider explaining that you should delete the deb instead, but otherwise fine
<StevenK> wgrant: "Cannot delete debug publications directly, please delete the publication" doesn't sound right either
<wgrant> "Cannot delete ddeb publications directly; delete the corresponding deb instead."?
<StevenK> wgrant: http://pastebin.ubuntu.com/5663470/
<wgrant> StevenK: right
<StevenK> wgrant: I'll land it with --incremental, since the bug also mentions changeOverride()
<wgrant> StevenK: Yep
<wgrant> StevenK: Or do changeOverride in the same branch
<wgrant> Because it's like two lines
<wgrant> + a test
<StevenK> So 12
<wgrant> Won't quite be over the limit :)
<StevenK> And I have like 35k LOC credit
<StevenK> Hmmm, how do you pass kwargs through assertRaisesWithContent
<StevenK> TypeError: assertRaisesWithContent() got an unexpected keyword argument 'new_phased_update_percentage'
<StevenK> wgrant: changeOverride() now complains too
<wgrant> StevenK: 50	+ AssertionError, "Cannot override debug publications directly; "
<wgrant> 51	+ "please override the publication."
<StevenK> wgrant: Hmmmm?
<wgrant> StevenK: That's the old message
<wgrant> You used the old message in changeOverride
<StevenK> wgrant: PopulatePreviewDiffMergeProposal is done on prod, landing the branch to drop it
<wgrant> StevenK: Do run a query to confirm that it worked first, pls.
<StevenK> wgrant: The ddeb MP has updated
<StevenK> wgrant: Can haz +1?
<wgrant> StevenK: Should that be OverrideError rather than AssertionError? Otherwise +1
<StevenK> Oh, I didn't realize there was an OverrideError
<StevenK> Bah, MPJs can't really run on qas either
<StevenK> But they're run under cron
#launchpad-dev 2013-05-15
<xnox> mgz: wgrant: i think package-import is a bit wrong atm, w.r.t. stacking.
<mgz> hmmm
<xnox> for example https://code.launchpad.net/~ubuntu-branches/ubuntu/quantal/mdadm/quantal is stacked on top of raring. Is that at all sane?
<mgz> the release script does a dance
<xnox> (imho it's backwards, or is this due to way the "development focus" is moved)
<mgz> to restack things on the new series
<mgz> I don't actually remember *why* though
<xnox> because to me it seems that it should another way around. Anyhow the _real_ problem is:
<xnox> $ bzr tags -d lp:ubuntu/oneiric/openssl
<xnox> Most recent Ubuntu Oneiric version: 1.0.0e-2ubuntu4
<xnox> Packaging branch status: CURRENT
<xnox> Most recent Ubuntu Precise version: 1.0.1-4ubuntu3
<xnox> Packaging branch status: CURRENT
<xnox> bzr: ERROR: Revision {cjwatson@canonical.com-20120424130658-womnlxhz6duwrz5y} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".
<xnox> and well, it would not be present, since =) i'm expecting 2012 was after 2011, not before =)
<xnox> but it does look weird. Maybe i just need to try to fetch that revision of cjwatson's backups? and push it into launchpad branches somehow....
<cjwatson> or nuke and reimport :-/
<jelmer> xnox: it's not the usual thing where disabling the freshness check fixes it?
<wgrant> xnox: That's not actually a corrupt branch; it's as jelmer says.
<wgrant> https://bugs.launchpad.net/bzr/+bug/888615
<_mup_> Bug #888615: UDD branch freshness checker breaks on incomplete history <Bazaar:Confirmed> <https://launchpad.net/bugs/888615>
#launchpad-dev 2013-05-16
 * mpt closes one Launchpad bug report before reporting another, thereby keeping czajkowski happy
<czajkowski> mpt: the only thing going to make me happy today is a very large JD and maybe I'll have some coke
<czajkowski> either that mpt or you owe me cake :)
<mpt> czajkowski, I can't give you cake if you aren't here
<czajkowski> mpt: I was there and there was still no cake
<czajkowski> cake is a lie :(
<mpt> was?
 * mpt wonders if JD and Coke mix
<czajkowski> mpt: do you lke the new G+ themee
<mpt> czajkowski, I haven't seen it
<czajkowski> :o
<mpt> Don't look at me like that, czajkowski, I don't use Google Plus
<jelmer> hmm, has the inline replying to bugzilla bugs been there for a while or is that new?
<jelmer> it looks pretty nifty
<cjwatson> jelmer: a while
<cjwatson> if you mean the way it's imported
<jelmer> also the fact that it lets you reply to the upstream bug directly from launchpad
<cjwatson> ah, that I'm not sure about, though doesn't sound like the sort of thing that'd have been done recently
<wgrant> jelmer, cjwatson: That's been there for a few years
<jelmer> oh, hmm. I guess I just never came across it :)
<wgrant> Early 2010 :)
#launchpad-dev 2014-05-12
<wgrant> cjwatson: """+ This is of limited usefulness as LiveFSes can be navigated to via
<wgrant> + Person:+livefs, but we need something minimal here to allow the
<wgrant> + "livefses" API root collection to work.
<wgrant> Why?
<wgrant> + """
<wgrant> A top-level collection can be empty, and even if it's not empty the objects don't have to be subordinate.
<wgrant> lp.livefses is a thing mostly to avoid having more Soyuz code in Registry.
<wgrant> Not to actually be a useful collection.
<wgrant> Hm
<wgrant> I might just declare inline comments to be in beta for ~launchpad, because 4000 line diffs are unfun to review otherwise.
<wgrant> Plus it'll give us a week or so to test it out before we open it up more widely once the fixes are done this week.
<cjwatson> wgrant: I don't recall exactly what breakage I was trying to work around there; I'll go back and try removing it again
<wgrant> I guess it was all a bit messy while you sorted out that versioning crash.
<wgrant> I know for a fact that it's not required, though. So you should be able to do away with it trivially.
<cjwatson> Quite possible I was dealing with fallout from that and not realising it, indeed.
<wgrant> I got nearly halfway through with inline comments, so I'll hopefully have another round for you tomorrow morning.
<cjwatson> I'll look forward to it.
<cjwatson> wgrant: OK, this may have been the problem: http://paste.ubuntu.com/7451806/
<cjwatson> After applying http://paste.ubuntu.com/7451808/
<cjwatson> Maybe I need some trivial navigation, just without the traversal?
<wgrant>      <browser:url
<wgrant> -        for="lp.soyuz.interfaces.livefs.ILiveFSSet"
<wgrant> -        path_expression="string:livefses"
<wgrant> -        parent_utility="lp.services.webapp.interfaces.ILaunchpadRoot"
<wgrant> -        />
<wgrant> There's your problem
<cjwatson> Oh duh right
<cjwatson> OK, much better, thanks
<wgrant> :)
#launchpad-dev 2014-05-14
<cprov> wgrant: here I am
<wgrant> cprov: Hi
<wgrant> cprov: What's the status of https://code.launchpad.net/~cjohnston/launchpad/fix-word-break/+merge/219285? I think that can land, can't it?
<cprov> wgrant: I've landed the working bits from it yesterday
<wgrant> cprov: What about the pending publish_inline_comments default change?
<cprov> wgrant: it will be better fixed by my WIP branch
<wgrant> Great. Should that be Rejected?
<cprov> yes
<wgrant> cjohnston, cprov: I know it's getting late, but do you guys have time for a quick status call? If not, your tomorrow is fine.
<cprov> wgrant: sure
<cjohnston> sure.. give me 5 min
<cjohnston> ok.. maybe only 2.. ready whenever
<wgrant> cjohnston, cprov: https://plus.google.com/hangouts/_/7acpjfd54idrcghi0or1q0ia4o
<wgrant> (finally worked out how to create one)
<cjohnston> https://code.launchpad.net/~cjohnston/launchpad/publish-ic-link
<cjohnston> cprov: ^
<cprov> https://oops.canonical.com/oops/?oopsid=OOPS-2585482ac97b2e5a570df8e24888e181
<cjohnston> wgrant: are you good with marking bug #918284 as wontfix now?
<_mup_> Bug #918284: Use Ubuntu Mono webfont so all users see it <css> <Launchpad itself:Triaged> <https://launchpad.net/bugs/918284>
<wgrant> cjohnston: Good point, done.
 * cjwatson writes a somewhat hair-raising caching wrapper for various launchpadlib objects for cdimage
<cjohnston> wgrant: https://code.launchpad.net/~cjohnston/launchpad/883258/+merge/215332 can also be rejected
<cjohnston> since I don't have the ability
<wgrant> cjohnston: Huh, you should be able to reject your own.
<wgrant> But done.
<cjohnston> All I see is WIP, Needs review, Merged..
<cjohnston> I guess because I'm not a part of ~somelpteam
<danilos> heya all, how do I get to see/use inline comments? I know I used to be a part of launchpad-beta-testers team, is that still what it takes?
<cjohnston> danilos: it isn't available yet
<wgrant> Hopefully some time next week for some internal teams that nag a lot :)
<danilos> cjohnston, interesting, somebody seems to have used it yesterday and now I can't see their comments on the MP
<danilos> wgrant, heh, can I nag a lot too? :)
<wgrant> danilos: Bah, they weren't meant to use it outside the CI/LP projects, to avoid this :)
<danilos> wgrant, well, I can read emails about it, so there is a work-around to get to the comments :)
<cjohnston> wgrant: with the changes that are happening at a decent pace and the fact that we are doing the testing of IC, do you think we should release LP more frequently right now to allow more testing of the newer changes before next week?
<wgrant> cjohnston: When we have relevant changes to deploy, sure.
<cjohnston> wgrant: I was thinking that both the empty lines around IC and the FF issue were both something that would be nice to get out sooner rather than later
<cjohnston> the first is a nice usability thing, the second could potentially just cause issues
<wgrant> Oh, I'd forgotten about the linebreaking fix.
<cjohnston> I just marked the monospace bug as qa-ok, were you wanting to QA it as well, or are you good with it
<wgrant> I've seen it in action already :)
<cjohnston> cool
<wgrant> cprov: Hangout when you're around?
#launchpad-dev 2014-05-15
<wgrant> cprov: https://code.launchpad.net/~wgrant/launchpad/unicode-diff-comments/+merge/219622
<cprov> okay, let's do it
<wgrant> cprov: https://plus.google.com/hangouts/_/76cpjr00m1nqltssq00re4q8sg when you're ready
<cprov> wgrant: ping
<wgrant> cprov: Hi
<wgrant> I'm half-way through the review
<cprov> wgrant: cool, thx
<cjwatson> wgrant: Any luck with the livefs review?  (Should I arrange to be in the Soyuz call tonight?  I've lost track of what timezone it's in)
<cjwatson> I've just got the cdimage bits working end-to-end, albeit hackily
<wgrant> cjwatson: Sorry, been busy with other stuff... possibly tomorrow, though more likely next week.
<wgrant> I think the call is 22:00 atm, but I'm not sure we have much to discuss.
<jtv> Hi cjwatson, hi wgrant.
<wgrant> Evening jtv.
<jtv> Spent some time with Adam last week reminiscing about how much slower the publishing cycle used to be...  The optimisation work is really appreciated.
<jtv> (Yes I know, that's a long time ago.  But it's also nice to hear that the benefits of what we do lasts, isn't it?)
<wgrant> Yeah, it's a little bit better now.
<jtv> Didn't it go from struggle-to-keep-it-under-an-hour to let's-do-another-one-in-the-time-left?
<cjwatson> I must say this font change is a noticeable improvement.
<cjwatson> jtv: I think we average about four an hour.
<cjwatson> It's not necessarily predictable, but usually that doesn't matter :)
<cjwatson> wgrant: How might I QA https://code.launchpad.net/~cjwatson/launchpad/copy-errors-to-sponsored/+merge/219666 ?  The obvious ways I can think of don't send mail
<wgrant> cjwatson: Which don't send mail?
<wgrant> The stagings (inc. dogfood) send mail, but it all goes to one mailbox.
<cjwatson> I don't see anything in /srv/launchpad.net/launchpad_mailqueue, which is what labbu:/srv/launchpad.net/codelines/current/production-configs/dogfood/mail-configure-normal.zcml declares
<wgrant> cjwatson: That's a temporary mailbox which is flushed at the end of the request.
<wgrant> If it's even still used at all.
<wgrant> You don't know about staging@mail.canonical.com?
<cjwatson> I think I've seen mention of it but have no idea how I'd access it
<wgrant> cjwatson: Normal IMAP server, username staging, password somewhere.
 * wgrant finds password
<cjwatson> Ah.  Maybe I'd better move back inside then in order to be on a proper-ish network
<wgrant> Oh yeah
<wgrant> I should probably do this for you
<wgrant> Though your connection is probably about as good as mine to the UK.
<cjwatson> Oh?
<wgrant> The inbox will probably have literally a million messages in it atm.
<cjwatson> Oh, right.  I can probably fire up a client on chiark if that's OK.
<cjwatson> If I can remember the rune to stop mutt sorting the mailbox on entry
<wgrant> I'd really prefer that random unowned machines didn't have this sort of password, but perhaps :)
<wgrant> If the IMAP server wants to respond to my request to open the mailbox...
<cjwatson> Well, my own network might cope
<cjwatson> I can certainly try
<wgrant> It might need IS intervention to clear out some of the contents.
<wgrant> I'm not sure if grenadilla is going to reply.
<StevenK> wgrant: Even with running purge-mail first?
 * cjwatson finds the relevant wiki.c.c page
<cjwatson> Heh, "mailbox is locked", I guess it's at least trying to respond to wgrant
<cjwatson> Oh, there we go, fetching headers when I try in read-only mode
<wgrant> StevenK: It's purge-mail's login attempt...
<wgrant> It's logged in now; took about 10 minutes
<StevenK> Niiiice
<wgrant> imaplib.abort: command: STORE => socket error: EOF
<wgrant> Still, one batch of deletions got through.
<wgrant> And it seems faster now.
<wgrant> Only a few seconds to log in.
<StevenK> I suspect the mailbox has been re-indexed and the inodes are in RAM
<wgrant> Yeah, it's deleting reasonably quickly now.
<wgrant> cprov: http://people.canonical.com/~wgrant/launchpad/mp-edit-icon.png has some CSS changes I'm playing with.
<cprov> nice!
<wgrant> It looks a bit less crazy when you don't have a couple of comments for each line.
<wgrant> But the comments are more obvious now, and the edit icon appears on <tr> hover
<cprov> eheh, but that's how it will look like in real life scenario
<wgrant> The editor is invoked by double-clicking on the line, or single clicking on the line number.
<wgrant> cprov: Can you look at https://code.launchpad.net/~wgrant/launchpad/unicode-diff-comments/+merge/219622?
<cprov> sure, in a bit
<cjwatson> wgrant: I guess your script only expunges in one go at the end?  mutt still wants to load 925000-odd messages.
<cjwatson> (or headers for them, anyway)
<wgrant> cjwatson: It's still going.
<wgrant> There may be that many left
<cjwatson> It hasn't changed in some time.
<wgrant> Ah, maybe then.
<cprov> wgrant: you can land the rc unicode mail fixing branch, then we can rollout ... is there anything else worth waiting ?
<wgrant> cprov: I think that's a good plan. I've just send it off to PQM; can you deploy when it's done?
<cprov> wgrant: sure thing
<wgrant> Thanks.
<wgrant> cjwatson: Inbox looks slightly cleaner now.
 * wgrant wanders off
<cjwatson> wgrant: Great, thanks.  You sure dogfood sends stuff there?  I'm not seeing it if so
<cjwatson> wgrant: Never mind, I managed to QA it on staging.
<wgrant> cjwatson: Dogfood's meant to :/
<cjwatson> Yup.  Fairly clearly didn't.
<cjwatson> Firewall maybe?
<cjwatson> files/firewall/lutin/lan_to_net.sh seems to accept only asuka, loganberry, gandwana.
<wgrant> labbu and arsenic are on the same LAN
<cjwatson> labbu and grenadilla aren't though?
<cjwatson> Or is it meant to relay through arsenic?
<wgrant>   driver = manualroute
<wgrant>   domains = ! +local_domains
<wgrant>   transport = rewrite_smtp
<wgrant>   route_list = * arsenic.canonical.com
<wgrant> It forwards everything arsenic, which rewrites it to staging@mail.canonical.com
<cjohnston> wgrant: is http://bazaar.launchpad.net/~canonical-ci-engineering/uci-engine/trunk/revision/483 503ing for you as well?
<cjwatson> it did but works for me now
<wgrant> Weird.
<cjohnston> hrm
<cjwatson> (I loaded a different URL on bazaar.launchpad.net in between; shouldn't matter, but ...)
#launchpad-dev 2014-05-16
<bigjools> wgrant: more font changes in LP lately?
<wgrant> bigjools: Yes, we reverted from Ubuntu Mono to monospace, because Ubuntu Mono is difficult to size correctly.
<bigjools> ok
<bigjools> wondered if it was my browser screwing me over
<wgrant> Not this time, at least :)
<bigjools> on MPs the font size for commit message and description is now larger than the rest of the page
<wgrant> It's meant to be exactly the same size.
<bigjools> no big deal but a bit jarring
<wgrant> But it probably looks larger because the characters are wider, because monospace.
<bigjools> well it ain't :)
#launchpad-dev 2015-05-11
<blr> wgrant: cjwatson: if we can add tags to make it clear which part of the UI a given task refers to in the Launchpad:UI asana project, suspect that will be helpful (e.g. User Profile)
<cjwatson> blr: ack
<blr> cjwatson: context/getCodebrowseUrl is rendering with '?h=master', is there any way to just get the root?
<cjwatson> blr: context/repository/getCodebrowseUrl
<cjwatson> blr: I expect context in this case is a ref ...
<cjwatson> so getCodebrowseUrl on a repository gives you the root, on a ref takes you straight to that ref, otherwise it ends up a bit strange
<blr> cjwatson: awesome, that works nicely thanks
<cjwatson> cool
<wgrant> cjwatson: What do you think of the {Product,Distribution}.vcs design?
<cjwatson> so I'd been sort of hoping that it could be avoided or made implicit somehow
<cjwatson> we shouldn't be able to end up in states where the flag says git and there are only bzr branches, or vice versa
<cjwatson> and I also think it should be possible to run both bzr dev focus and git default repo in parallel, for migration, which means that we need to be able to show both
<cjwatson> at that point it is not clear to me what the vcs enum actually governs
<wgrant> What value does showing both provide?
<wgrant> eg. look at https://code.launchpad.net/launchpad
<wgrant> It's confusing and I can't see a case where it would ever be desirable.
<wgrant> The column probably just selects whether the code page shows bzr or git stuff by default.
<cjwatson> I think if we aren't going to show both, we need some way to get at the default git repository for a project in the web UI that isn't /target
<cjwatson> or, perhaps better, it should be impossible to set a default git repository for a target that doesn't have its vcs set to git
<cjwatson> or something like that
<cjwatson> we need to think through the migration path for a project
<wgrant> Or someone has to click the git link if they run into a git default URL on a bzr-defaulting project.
<cjwatson> the git link that doesn't exist yet, but yes
<wgrant> Well yeah, once the page is split there will presumably be a link between the two halves :)
<cjwatson> this ties into my hope to be able to make the canonical url for a default repo be (target, rootsite="code")
<cjwatson> this only works if it's reliably shown there.  although I suppose we could do that only if vcs==git, but that starts being messy ...
<wgrant> Is it as messy as showing both?
<cjwatson> perhaps not
<wgrant> The URLs already vary based on whether the repo is the default or not.
<wgrant> Varying slightly further based on whether the *VCS* is the default doesn't seem out of the question.
<cjwatson> this is true
<cjwatson> so what's the URL for the default git repository on a bzr-defaulting project?
<cjwatson> I suppose we could just send you to the unique name
<wgrant> Right, I think the web URL is just the full URL in that case.
<wgrant> But switching the +branches to the git view using the link at the top will also show it.
<cjwatson> can you explain that last bit?
<cjwatson> link at the top of where?
<wgrant> There's some widget on the project code index which switches between the git and bzr views, defaulting to target.vcs.
<wgrant> If target.vcs is bzr and you click on the git link, you'll presumably get the view you would get if the default was git.
<cjwatson> I'd been working on Person:+repositories; perhaps that makes sense as a view name elsewhere as well
<cjwatson> (or it could just be +git, but I wasn't sure if that would cause ambiguity problems)
<wgrant> +repositories is a) realllly long and b) poor apt :(
<wgrant> I'm not sure if +git can currently be implemented.
<wgrant> I *think* it works, and there is one example somewhere, but I can't think what.
<wgrant> +bug vs +bugs is just stupidity, not a technical limitation.
<cjwatson> The only case where there's potential ambiguity is on Person itself, and the traversal there is sufficiently manual that we could probably manage to say zero remaining path elements => PersonGitView
<wgrant> Yeah.
<cjwatson> The reason I'd been going a little more general is that I was thinking of it as a good way to simplify things for bzr too
<wgrant> Howso?
<cjwatson> You could reasonably look as PersonProduct etc. as metaphorically a repository
<wgrant> aaaaa
<cjwatson> In the bzr sense too
<cjwatson> And then code pages could suck a bit less
<cjwatson> But I don't know if it's worthwhile
<wgrant> I'm not quite sure.
<cjwatson> Because you could see people who'd worked on a project recently, and then drill down from there to look at individual branches, rather than just getting a sea of branches
<wgrant> So, convince me about your plan for eg. the project code index.
<wgrant> Hm, true.
<wgrant> But that's less interesting in the git future.
<cjwatson> I think that should be approximately the git view, though.
<wgrant> Yep.
<cjwatson> So, I think I'm fine with the project code index being switchable; the dual view was admittedly (in the MP description) a stopgap
<wgrant> Oh yeah, and it's a fine stopgap, because it still isn't quite clear how to do it properly.
<cjwatson> It needs to be switchable on "Configure code hosting" or whatever replaces it (since +setbranch is series-specific)
<wgrant> Do you have an idea on how to obviate Product.vcs, though?
<wgrant> Ah yeah
<wgrant> We discussed this on the call last week, sorry.
<wgrant> Kit's working on a Product-wide +setbranch equivalent.
<cjwatson> Right
<cjwatson> So it's not so much that I have a clear plan as that I'm trying to understand how we avoid inconsistencies in yours :)
<cjwatson> If the view switches then at least people have a clear incentive to set it to the right thing
<wgrant> The default git repo URL is the only serious issue I see.
<wgrant> And that's only an issue during migration.
<cjwatson> If you're happy with a conditional canonical URL that depends on the vcs enum, I think that satisfies my concerns.
<cjwatson> I just don't want to be stuck with the canonical URL being ugly forever.
<wgrant> So, the canonical URL itself can't be that.
<wgrant> We'll have to do something a bit magical.
<wgrant> because eg. the API
<wgrant> But maybe the web canonical_url can be different.
<cjwatson> So, what's the preferred migration path for a project?  We have docs somewhere (say, a help popup) giving some advice on migrating to git (maybe an auto-importer in the magical future, but I remain to be convinced about the tractability of that for an entire set of branches without manual gardening).  You do that and push to the default repository path.  Product:+branches notices and gives you a view for git stuff, and maybe an AJAX ...
<cjwatson> ... switcher to change over.  What do the view names become here?
<wgrant> The easiest way is a query string on the end of +branches.
<cjwatson> Or perhaps Product:+branches and Product:+git, and the default view depends on vcs?
<wgrant> It's awkward, but currently we have no way to configure default view name very eaisly.
<cjwatson> Hm.
<wgrant> We could do it, though.
<wgrant> It would require a small amount of infrastructure work.
<wgrant> Auto-importer is difficult due to various gardening that can be required.
<wgrant> eg. for LP I have to replace two whoamis to get something that git fsck is happy with (and thus GitHub will accept, for example).
<cjwatson> I think my latest prototype reimplemented BranchListingView etc., but it would probably be possible to crowbar it all into the same view in order to support both.
<cjwatson> Right, my experiences with converting stuff to git have all employed various bits of manual gardening.
<cjwatson> Mostly using http://www.catb.org/~esr/reposurgeon/ once I discovered that it existed.
<cjwatson> (Because this is the sort of job where having a DSL can really improve your life)
<cjwatson> So I think I'm OK with the vcs plan; now that we've talked through it it makes a bit more sense to me.
<wgrant> I think you click the code settings link, where you can get instructions on pushing to the other VCS.
<wgrant> Once a repo exists for the other VCS, the default code listing grows a switcher.
<cjwatson> Yeah, probably shouldn't clutter the default view with that sort of instructions.
<wgrant> (what this doesn't handle is hiding the switcher once both types exist, but meh)
<cjwatson> You could do that by deleting all the bzr branches.
<cjwatson> Or something.
<cjwatson> Except you probably wanted to keep MP history.
<cjwatson> (I occasionally refer to years-old MP history in Launchpad ...)
<wgrant> That's why we did git MPs a bit more sensibly, indeed.
<cjwatson> "meh" seems like a reasonable disposal.
<wgrant> Quite.
<wgrant> I'm just thinking about where to put the default widget.
<wgrant> I think ti would make sense to have it behind a link at the bottom of +edit, below the submit button, in what looks like an ignorable footer.
<wgrant> Similar to the team ownership change view.
<cjwatson> Shouldn't it be on Product:+setbranch?
<wgrant> Yes, I was just thinking of the most obtuse and Launchpaddy place to put it.
<wgrant> Product:+setbranch or equivalent is indeed where it should go in the real world.
<bigjools> wgrant: what's the default size limit for P3As nowadays?
<cjwatson> bigjools: 2 GiB for both public and private
<bigjools> cjwatson: can that be upped for P3As?
<bigjools> and hi :)
<cjwatson> bigjools: wgrant generally processes tickets to raise limits on request pretty quickly
<bigjools> cjwatson: the guys I work with say that it's annoying to have to do that and want to up the default
<cjwatson> I'm sure it's possible, I think we should look at some stats for archive usage plotted against whether they're public or private, though
<cjwatson> there might be a few possible fixes to that annoyance
<bigjools> that would be nice :)
#launchpad-dev 2015-05-12
<cjwatson> wgrant: So here's a problem with the approach taken in https://code.launchpad.net/~cjwatson/launchpad/bpph-source/+merge/255070
<cjwatson> wgrant: chaenomeles/launchpad-access60.log:91.189.89.30 - "91.189.90.217" "api.launchpad.net" [11/May/2015:16:55:19 +0000] "GET /devel/~ubuntu-security/+archive/ubuntu/ppa/+build/7403388?ws.op=getLatestSourcePublication HTTP/1.1" 401 480 14 0.106685876846 626 191 "Anonymous" "BinaryPackageBuild:EntryResource:getLatestSourcePublication" "" "lazr.restfulclient 0.12.0; oauth_consumer="ddeb-retriever""
<cjwatson> that's a build from a private archive copied into the primary Ubuntu archive; we can't do BPPH.build.getLatestSourcePublication() because that's constrained to return an SPPH in the same archive as the build, and that archive is private
<cjwatson> I wonder, though, if we should have a similar exception for SPPH visibility as there is for BPB visibility
<cjwatson> That is, if you can see the SPR you might as well be able to see the other thing
<cjwatson> Though it might be a problem that SPPH URLs are under their archive
<cjwatson> We should find some solution for this soon, as it's blocking ddeb-retriever right now
<cjwatson> (Though fortunately ddeb-retriever can now catch up in a way that was awkward before)
<wgrant> bigjools: We could change the default if you know you're going to be exceeding it.
<wgrant> cjwatson: ugh, indeed, we really should just fix this to not be completely and utterly broken model-wise at some point :/
<cjwatson> So we could just implement your suggestion from that MP of exporting the source name as a stopgap
<cjwatson> In the specific case of ddeb-retriever that's all it actually needs today
<cjwatson> There are probably other users that will have issues, but ...
<cjwatson> It's independently irritating that the source on https://launchpad.net/~ubuntu-security/+archive/ubuntu/ppa/+build/7403388 isn't linked, but that has nothing to do with privacy, it's because we never make that a link if the context archive is a PPA.  Though in this case you don't get to see the archive either.
<wgrant> Yeah, I have a partially implemented fix for all that, but it's a reasonable amount of work.
<wgrant> (see my ArchiveBinaryPackageBuild series)
<cjwatson> Ah yes, I think I've seen that before
<wgrant> Fixes a lot of performance issues as well.
<cjwatson> In the short term I think exporting BPB.source_package_name is likely to be most practical, though.
<wgrant> Yep.
<wgrant> Most awkward bit is ensuring the correct preloading.
<cjwatson> wgrant: self.source_package_release.name is already used by BPB.title, which is exported, so I don't think it needs anything new.
<blr> wgrant: cjwatson: what are your thoughts on changing the "Configure project branch" label under Config Progress to "Configure project code" or something that suits both git and bzr.
<cjwatson> blr: Sounds sensible
<cjwatson> "Code" is a reasonable term in existing use that covers both.
<blr> sounds good, thanks.
<wgrant> cjwatson: Ah, of course.
<wgrant> settings
<wgrant> settings dammit.
<wgrant> None of this "Change details"
<wgrant> Or "Configure"
<wgrant> god. damn. settings.
<cjwatson> I was just thinking that "Configure ... code" does sound a bit like ./configure
<wgrant> It's also awkward and long :)
<wgrant> I think "settings" is the usual word nowadays just about everywhere else.
<blr> we certainly like saying configure a fair bit -> "Configuration progress ... Configuration options... Configure bug tracker"
<wgrant> Indeed.
<blr> we could drop configuration from everything save Configuration progress and it would all still make sense
<wgrant> In that portlet it probably makes sense, indeed. I'm not sure where else those links are used, though.
<wgrant> Other places (eg. https://blueprints.launchpad.net/launchpad) need something like the current text.
<wgrant> (or "settings"!)
<wgrant> The config portlet probably does want to override it.
<blr> it "options" even the right word in that portlet, they seems more like 'steps'
<blr> granted they are optional.
<cjwatson> Except you don't have to carry them out in order.
<wgrant> And they never go away :/
<cjwatson> Or at all.
<blr> heh
<wgrant> The whole thing needs to be redesigned, but I'd be tempted to just have links named after the tabs without saying configure configure configure.
<blr> yep, let's do that for now.
 * blr wanders off to de-yodawg.
<blr> will also add something to the UI asana board about the entire process being clunky generally
<wgrant> A good idea.
<wgrant> It's the first impression you get of LP (other than the adventure of finding out how to create a project, and then fill in the eleven thousand fields on ProjectSet:+new, which keeps going across multiple steps each with variants of the same fields), and it's a little dodgy.
<blr> right, I think if we could address this config process _and_ add more visibility to +new that would help new users a great dela.
<blr> or deal even.
<cjwatson> Although careful with pushing ProjectSet:+new because people often hit that when they really meant to create a PPA.
<cjwatson> Despite the warnings.
<cjwatson> It's not clear whether it's really easier to find ProjectSet:+new than Person:+create-ppa, or if we just don't hear about the latter because you can do self-service PPA deletion.
<blr> sounds like another task for the UI board :)
<cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/bpb-source-package-name/+merge/258820
<wgrant> cjwatson: You'll probably also need to fix xx-builds.txt
<cjwatson> sassenfrassendoctests
<cjwatson> yeah
 * cjwatson lands that and sleeps
<bigjools> cjwatson: I had completely forgotten about the hidden copy-packages link!
<wgrant> cjwatson: buildd branches fixed.
<blr> have changed the order of the configuration options to reflect the top menu as well, code coming first.
<blr> wgrant: what's the best way to render the links on Bugs/Blueprints/Translations etc? They should still read 'Configure foo' on those views.
<wgrant> blr: I'd rather customise the links rendered by pillar-involvement-portlet.pt
<wgrant> blr: ProductInvolvementView.configuration_links already changes things up a bit.
<blr> ah I see, I'll leave the configure_foo methods as they are in that case.
<blr> wgrant: why is blueprints commented?
<wgrant> blr: I'm not quite sure. The revision that disabled it added the progress bar.
<wgrant> 3220eba or r11189.1.5
<wgrant> But no rationale provided.
<blr> weird, seems a little odd not to have it enabled, given we're still supporting blueprints.
<wgrant> Indeed.
<wgrant> blr: Are you landing that DB branch?
<blr> wgrant: no, I'm still not entirely sure about windows. There's no hurry, I need the corresponding setup/setbranch branch working for it be of any use, unless it is useful for you or colin.
<wgrant> blr: What do you mean about windows?
<wgrant> blr: The column is useful even without the setbranch rework.
<blr> wgrant: windows for landing a db patch.
<blr> colin landed the last patch I wrote - can I lp-land it now?
<wgrant> blr: Yep, you can land as soon as there are no deployment blockers (eg. code on prod that depends on a column that you're removing).
<wgrant> There are traditionally *deployment* windows, but we tend to ignore them nowadays if that would be convenient.
<blr> ok, will do that after dinner. thanks :)
<blr> wgrant: ok to land the patch with no-qa?
<wgrant> blr: Yep
<blr> wgrant: assuming for the API export, vcs should be a Choice, but presumably that requires the creation of a new vocabulary?
<wgrant> blr: No, you can give Choice an enum directly.
<wgrant> For simple cases like this.
<wgrant> No filtering or restrictions required.
<blr> ah good
<blr> wgrant: fixed up the api export - regenerated the api docs which seem correct.
<wgrant> blr: Thanks, will look in a bit.
<cjwatson> wgrant: buildd> r=me, thanks
<wgrant> cjwatson: Thanks.
<cjwatson> Hm, are we OK with CSS3 selectors in LP?
<cjwatson> I guess that not() is in use in several other places.
<beuno> cjwatson, I think it's been a few years to be ok with them!
<cjwatson> spot the person with a distro developer background, not web dev. :-)
<wgrant> cjwatson: http://caniuse.com/
<wgrant> cjwatson: IE8 doesn't support it, but everything else of significance does.
<beuno> cjwatson, beowulf is my go-to guy for these questions, FWIW
<wgrant> And we don't particularly care about IE8 any more, particularly for something so trivial.
<beuno> he's usually happy to help
<beuno> and in the UK
<beuno> we'll soon get another FE-focused person on board in the CI team as well
<beuno> disclaimer, he's on a mission to move away from YUI wherever possible/cheap/sensible
<cjwatson> In this case it was just for https://code.launchpad.net/~rbanffy/launchpad/highlight_listing_tr/+merge/258766 rather than anything deeply involved
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/git-activereviews/+merge/258910 - phew.  EOD time.
<cjwatson> (modulo team meeting)
#launchpad-dev 2015-05-13
<bigjools> wgrant: do recipes work with the new git repos?
<wgrant> bigjools: Not yet. Recipes are implemented by a bzr plugin, so we have to pretty much rewrite them.
<bigjools> darn, shame
<bigjools> recipes are possibly the coolest thing in LP
<wgrant> But it's fairly high on the priority list, as they're sort of useful.
<bigjools> ok cheers, good luck :)
<bigjools> wgrant: is it possible to mirror a remote private git repo into a private bzr one?
<wgrant> bigjools: No, but we will probably support that for git.
<wgrant> (and remember that bzr recipes don't work for private bzr branches today)
<bigjools> bugger
<bigjools> thanks
 * mwhudson twitches
<wgrant> mwhudson: Hm?
<mwhudson> i remember worrying about all these things, private code imports, recipes that consume private branches
<mwhudson> is there anything at all like bzr builddeb already?
<mwhudson> maybe that's not the thing i mean
<mwhudson> the thing that interprets recipes
<wgrant> bzr builder? Nothing quite the same.
<mwhudson> so what i want to do is this: i want to build go tip from git into a ppa
<mwhudson> the part that i can't remember at all about how this works from bzr recipes is the orig handling
<wgrant> bzr-builddeb requires there to be pristine-tar metadata in one of the branches.
<mwhudson> the diff from the most recent 1.4 release is (a) enormous and (b) can't be represented as a textual patch anyway
<mwhudson> so the solutions seem to be build a native package or make orig tarballs myself
<mwhudson> i can make a new orig every time there is an unrepresentable change, or for every build
<mwhudson> the latter sounds more automatable
<mwhudson> (the package version numbers will be hilarious i expect)
<mwhudson> wgrant: so this situation wouldn't work very well even if go upstream was bzr hosted on lp?
<wgrant> mwhudson: You'd just use a native package in that case, I expect.
<mwhudson> ok
<mwhudson> native packages are indicated by not having a - in the version, right?
<wgrant> Ish.
<wgrant> A non-native package must have a -
<wgrant> Natives shouldn't, but it works.
<mwhudson> ok
<mwhudson> not having revnos sure makes for lovely lovely package versions
<wgrant> +git20150512+deadbeef ftw
<mwhudson> yeah
<mwhudson> 2:1.5~pre-snap2~upstream201505131327git350fd548b331ubuntu1 <= 2:1.5~pre-snap1-0ubuntu1~7.gbpfbb499
 * mwhudson blinks
<mwhudson> apparently i don't know the rules quite by heart yet
<mwhudson> oh wait
<blr> wgrant: would appreciate some clarification around the series_menu - I see that it takes a series/development_focus, but it isn't clear to me how the link target is set.
<blr> productseries just uses ILink, in a well.. more obvious manner.
<wgrant> blr: There is some magic in the menus that even I will have to read the code to understand, but let me see.
<blr> the MenuAPI implementation has some concepts I'm not familiar with - facets?
<wgrant> bugs/code/translations/etc.
<blr> ah okay.
<wgrant> Each facet can have a different menu, which used to define what appeared in various slots on the page automatically.
<wgrant> That's used a lot less nowadays, as the templates position the links more explicitly.
<wgrant> MenuAPI is a TALES traverser thingy, so it does some weird stuff to interpret paths.
<wgrant> THe main weirdness being the colon-separated facet name.
<wgrant> But MenuAPI basically just finds the relevant IMenu by looking for an IApplicationMenu or INavigationMenu adapter for the context object and the given facet.
<wgrant> It's the IMenu that has the Links.
<wgrant> You can see the context handling in lp.services.webapp.menu.MenuBase.
<wgrant> The initLink method, specifically.
<wgrant> So the MenuAPI TALES adapter is instantiated from your context/menu:blahblah. It uses a Zope adapter to get the relevant ApplicationMenu or NavigationMenu subclass, which constructs the Links.
<blr> ok, trying to digest all that :)
<wgrant> Basically: ignore MenuAPI, find the relevant I*Menu adapter and look at that instead.
<blr> thanks, that's very helpful.
<wgrant> blr: Will you have time to fix up product-vcs-default-attrib today?
<wgrant> It's very close and would be handy to have.
<blr> yep, will need to have a look at examples of permissions for other exports - haven't quite got to it yet.
<wgrant> blr: It's actually just normal Zope permissions, so a one-liner in configure.zcml for each.
<blr> ah the configure.zcml in registry, not browser.
<wgrant> Yup
<wgrant> The only part of browser that the API uses is the URL traversal bits.
<blr> wgrant: done
<wgrant> blr: The permission tests don't need fixing?
<wgrant> Those are fortunately quick to run.
<blr> ah right.
<blr> I did add vcs earlier for View, but not Edit. thanks
<wgrant> blr: One last thing: your interface attributes end with triple quotes, but start with singles.
<blr> err so they do.
<blr> consistently wrong, the best kind of wrong.
<blr> wgrant: hmm where are the permissions tests for distribution?
<wgrant> blr: There probably aren't any. They were only added for Product as part of the private projects project.
<blr> ah right
<blr> wgrant: ok, tests happy.
<wgrant> blr: Yay
<wgrant> blr: r=me
<wgrant> Thanks.
<blr> cheers
<wgrant> blr: buildbot had failed, but you should be able to successfully land it now.
<blr> wgrant: building now I think
<blr> has that timeout cropped up before?
<wgrant> On very rare occasion.
<wgrant> blr: It's building because I forced it.
<wgrant> blr: Your change hasn't landed.
<blr> huh odd, no feedback from lp-land that it failed.
<wgrant> lp-land just sends an email, so it can't tell whether it succeeded.
<wgrant> PQM is meant to email you when it fails, but that's sort of broken.
<wgrant> After an upgrade recently.
<StevenK> I do not miss those horrid PQM failure e-mails.
<wgrant> You miss them when they mean it silently fails instead :P
<blr> ah I see
<wgrant> But soon PQM will die.
<lifeless> thats what deadmanswitch is for :)
<StevenK> wgrant: Because switching to git?
<wgrant> StevenK: Git and Tarmac, indeed.
<wgrant> https://git.launchpad.net/launchpad/
<blr> wgrant: hmm still not seeing anything in the pqm queue
<blr> nvm there now
<blr> wgrant: hmm I didn't run the doctests :/
<wgrant> blr: That's what buildbot's for.
<wgrant> They were easy fixes.
<blr> thanks for that
<blr> cjwatson: wgrant: any thoughts on the distinction between project and project code settings? Ideally should they be accessible from the same view?
<blr> s/code/facet/
<blr> maybe I should do a mockup
<cjwatson> blr: On the one hand, I dislike the pattern of lots of little tiny views where you have to guess which one the setting you care about is in.  On the other, a gigantic view with everything isn't great either.  I think ideally I'd like a tabbed settings page, but we should probably try to implement what we need for git without refactoring the *whole* world
<cjwatson> (Or at least something that *feels* like a tabbed settings page, e.g. github's repository settings)
<blr> cjwatson: oh certainly not suggesting one massive view, just a container with a sensible menu encapsulating all those small views
<blr> cjwatson: if we could start in that _direction_ wrt to git, I think that would be positibve.
<blr> just not certain how we can do that without changing eveything and the kitchen sink.
<blr> will think about it a bit more.
<cjwatson> I thought I remembered there being something like this once, maybe on Person, but I can't find it now - maybe it went away at some point
<cjwatson> blr: I wonder if the VCS should (also) be an AJAX drop-down under "project information", which already has a little bit of code stuff in it
<cjwatson> blr: Did you decide what to do about new projects?  I mean, ideally if somebody creates a project and pushes a git repository to it, they shouldn't also have to go and select that their project uses git when it has no bzr stuff; ditto vice versa
<cjwatson> blr: perhaps we can just default it on the first push of a repository/branch to a project that had neither
<cjwatson> ?
<cjwatson> that also suggests that the "your project has no code" case in the +branches view should have instructions for both
<cjwatson> (which is probably easier if it's the same view for both cases with a big conditional in the template, as we discussed)
<blr> cjwatson: sorry just trying to understand the context, Project Information on the main project view?
<cjwatson> yeah
<blr> cjwatson: that could work, yep.
<cjwatson> of course it still has to live in a view somewhere, we try not to be totally reliant on ajax
<cjwatson> so may not solve your dilemma per se
<blr> would certainly be nice to set the default on first push
<cjwatson> I suspect the place to do that would be BranchNamespace.createBranch / GitNamespace.createRepository
<cjwatson> you might want to think about this before pushing the model code though
<cjwatson> oh, possibly too late
<blr> oh, did william implement that?
<cjwatson> well, no I meant the enum
<cjwatson> hmm
<cjwatson> I guess this is a nullable column
<blr> it is
<blr> not following, is the enum problematic?
<cjwatson> so null can be not-specified-yet, you don't need a separate enum value for that
<blr> right
<cjwatson> which was where my train of thought was going
<cjwatson> ok, all good
<blr> I wonder how we can provide feedback to the user that we've set the project default vcs for them
<cjwatson> I don't know that we need to
<blr> perhaps just having it visible under project information is sufficient
<blr> yeah
<cjwatson> it can just show up
<cjwatson> alternatively to default-on-first-push, we have to think of all the existing rows *anyway*
<blr> Should we however provide feedback if they push the converse repo type?
<blr> after a default has been set
<cjwatson> so perhaps {Product,Distribution}.vcs is reserved for explicitly specified, and otherwise the view has corresponding properties which will calculate a value on the fly based on whether any bzr or git things exist
<cjwatson> that way we don't have to go through filling in values in existing rows, which is usually a good thing to avoid if we can
<cjwatson> and in this case it's convenient because we don't have to actually write our magic default to the db
<cjwatson> does that make sense to you?
<cjwatson> we can't provide feedback to the actual VCS client, at least not with git.  The best we can do, I think, would be for the choice widget (of whatever kind) to appear in the relevant views once there is more than one option
<blr> I think so - project and distribution would need a new property to return the vcs type for the first pushed repo?
<cjwatson> doesn't even need that
<cjwatson> not IBranchCollection(project).getBranches().is_empty()
<cjwatson> similarly for IGitCollection
<blr> ah right
<blr> that exists already?
<cjwatson> we don't need to distinguish the first one
<cjwatson> it does
<blr> great
<cjwatson> (it's getRepositories in the git case)
<cjwatson> blr: in fact, just not I{Branch,Git}Collection(target).is_empty() - they have helper methods for that
<blr> ah handy
<cjwatson> that will compile down to something like SELECT 1 FROM GitRepository WHERE GitRepository.project = project_id
<cjwatson> but with the adapters you don't have to worry about cases like Branch having distroseries rather than distribution
<cjwatson> blr: if it's in a view, you should possibly do .visibleByUser(self.user).is_empty() to avoid leaking information about a private branch/repository on the target if there's nothing else, although that's certainly a corner case
<blr> ok, will bear that in mind.
<cjwatson> I got the pending diff indicator fixed today (well, in the review queue) - William was right that it was one of those things that was much more complicated in Branch, though some of that complexity is due to imports so may sneak back in later
<blr> oh nice
#launchpad-dev 2015-05-14
<cjwatson> haven't quite decided what to do tomorrow, I might do the two-haproxy-units thing, maybe fix tech debt of GitNamespace tests, maybe do the LP side of repository deletion
<cjwatson> let me know if there's anything particular that would be helpful for me to attack
<cjwatson> but for now, sleep
<cjwatson> night
<blr> ok, thanks for the suggestions, night :)
<wgrant> cjwatson: The old tabbed person +edit was abolished with 3.0.
<wgrant> cjwatson: I definitely want a single Settings button per object which takes you to a tabbed (or GitHub-like) view with everything under it. We still have something similar on Person:+edit, except the tabs are at the very bottom of the page and not tabs.
<wgrant> The Settings button the Code page then takes you directly to the code tab, but in the same tab hierarchy.
<blr> wgrant: any way we could carve off a bit of that for git ui - concerned that moving all the settings will be non-trivial.
<wgrant> blr: Oh, certainly, we're not doing that rework now.
<wgrant> blr: I don't understand what you mean by "any thoughts on the distinction between project and project code settings"
<blr> wgrant: yeah, I didn't express that very well. I was suggesting that we should have settings for the project and facets under the same view.
<blr> as you say, like github.
<wgrant> The same *page* is impractical (Product:+edit is several times too long today), but it should be possible to navigate sensibly between the settings pages.
<wgrant> But we don't have that capability today, so I'd just have the link in the involvement portlet and somewhere on the code page.
<blr> pains me to be adding yet another yellow pencil icon.
<wgrant> Heh, indeed, but such is life.
<blr> hah yes. Did you like colin's suggestion on infering a default in views?
<blr> inferring the default from is_empty()
<blr> still setting product/distribution.vcs from project setbranch
<wgrant> Mmm.
<wgrant> I think that'll do for now.
<wgrant> It's possibly not ideal long-term, but it's easy to work out which projects are affected, as they all have vcs = NULL, so we can easily fix it.
<blr> yep
<blr> wgrant: any reason why we don't render attached images inline on bugs?
<wgrant> blr: No particular reason.
<blr> might be nice?
<wgrant> It needs appropriate resizing stuff etc., and there may be spam concerns, but there's no good reason not to do it eventually.
<blr> will assign to myself to work on at some point.
<blr> wgrant: how can I get the default series for a product?
<blr> is that product.series
<blr> forbidden attr on product.series.branch which seems odd.
<wgrant> blr: Product.series is the list of all series.
<wgrant> You probably want Product.development_focus
<wgrant> (the Distribution equivalent is Distribution.currentseries, which is a bit easier to find)
<blr> ah I see series is a storm result collection
<wgrant> Yep
<wgrant> bin/iharness is invaluable here.
<StevenK> s/ here//
<blr> wgrant: is there a good reason why branch name and owner are at the bottom of setbranch?
<blr> seems they should be at the top, but I may be missing something.
<wgrant> blr: That's the weirdness I mentioned, yeah. They should be somewhere in the "Import a branch hosted somewhere else" section, as they only apply when a new branch is created.
<blr> right
<wgrant> It probably makes sense to have them at the top of that section; it certainly makes more sense than where they are now.
<blr> unrelated, but do you like the 0 padding on input elements?
<wgrant> It's not too bad when they're surrounded by a name at the top and a description underneath.
<blr> oh I mean padding within the elements
<wgrant> Ah, not particularly.
<wgrant> It makes the overlarge forms slightly more compact, though :)
<blr> true, but even 1.5px there helps the forms ..err 'breath'?
<blr> should have a look at a large form
<blr> wgrant: unless you have any objections, would like to suggest we use fieldsets in preference to tables for forms.
<blr> widget_row is used all over the place however
<wgrant> blr: if it's not too much work to get the styling right, by all means
<cjwatson> wgrant: I still don't properly understand the BPPH.binaryFileUrls failure bdmurray reported.  Using BPFP seems weird, but BPFP rows aren't actually deleted when a package is e.g. deathrowed, are they?
<wgrant> cjwatson: hahah
<wgrant> cjwatson: BPFP is a view
<cjwatson> wgrant: oh!  light dawns
<wgrant> https://code.launchpad.net/~wgrant/launchpad/i-really-do-hate-views creates a non-DB-backed version of it.
<wgrant> But it's, uh, sorta out of date.
<cjwatson> little bit.
<wgrant> I haven't looked at the method recently, but it probably uses it to get an archive-wrapped LFA or something.
<wgrant> If not, then I have no idea.
<cjwatson> ok, now I at least know how to write a test for this.
<cjwatson> yes, it does.
<cjwatson> so my initial instinct was probably correct, it can just be self.binarypackagerelease.files instead.
<wgrant> Yeah, as long as you wrap them.
<cjwatson> right, same as before
<wgrant> Oh.
<wgrant> It wraps them manually.
<wgrant> So no reason to use BPFP at all.
<cjwatson> Exactly
<cjwatson> Sorry, misread you above.
<wgrant> And SPPH.binaryFileUrls is fine too.
<cjwatson> I think it just uses .files because it was there and looked seductively correct.
<wgrant> Yep
<wgrant> I'd forgotten that .files used it.
<wgrant> Rather than just forwarding.
<blr> wgrant: excellent branch name
<blr> wgrant: any docs you could point me towards that clarify how the form processing works (e.g. @action(_('Update'), name='update')) - not clear to me how the data dict is composed.
<blr> nvm, found the zope.formlib docs
<lifeless> wgrant: I'm curious, whats the current 99th% request time on LP (prod), and requests/day.
#launchpad-dev 2015-05-15
<blr> wgrant: have project +setbranch working (sans tests currently), but would also like the branch to include the vcs default on the project info page - working on that now.
<blr> wgrant: cjwatson: does "Preferred VCS" work better than "Default VCS", only for user facing UI.
<wgrant> blr: "Version control system", I think.
<wgrant> Possibly with text near it that says the other repos will still be usable, but only if they exist.
<wgrant> lifeless: 99% is almost exactly 1s.
<wgrant> Don't know requests per day offhand.
<wgrant> blr: It is technically only the preferred VCS, but "technically" arguments don't usually make for good UI :)
<lifeless> wgrant: thanks; 1s seems slow :(
<lifeless> wgrant: I don't suppose you remember what it was a couple years back
<wgrant> lifeless: Much better than it was, but indeed. It's dragged down by bugs at the moment due to the way subscriptions are implemented.
<wgrant> lifeless: It was ~1.4 between 2012 and 2013.
<wgrant> Only with the new DB servers did it drop substantially below that.
<wgrant> s/dragged down/dragged up/
<lifeless> I knew what you meant :P
<lifeless> made worse
<blr> wgrant: yes have a note that you can still have bzr/git repos as well using the formHelp class
<blr> lifeless: we're running on SSDs now which presumably have made a difference
<blr> not loving this markup, but it will have to do for now.
<blr> wgrant: shall I merge the tabbed pull instructions into this branch?
<blr> err push
<wgrant> blr: That possibly makes sense less on a form that has to show both sets of options anyway.
<blr> wgrant: hmm, I've pushed a bzr branch to lp.dev/foo, which appears to have succeeded, however IBranchCollection(self.context).is_empty() is true (where self.context is foo)
<blr> do I need to run a branch scan job?
<blr> ./cronscripts/process-job-source.py -v IBranchScanJobSource reports "No jobs to run"
<blr> added ipdb to source-deps, hope that's okay.
<wgrant> blr: Hmm, that's mysterious.
<wgrant> Did you get to the bottom of it?
<blr> wgrant: no, I think the push must have failed actually, not certain if I have codehosting running correctly, getting "Parent directory of lp://dev/turnip/ does not exist."
<wgrant> blr: Oh
<blr> when running `bzr push -d devel lp://dev/turnip/` - using make-lp-user with my real lp id
<wgrant> blr: Did you follow https://dev.launchpad.net/Code/HowToUseCodehostingLocally?
<wgrant> I suspect you're connecting to OpenSSH :)
<wgrant> You need a snippet in ~/.ssh/config to force it to port 5022, and possibly to a different hostname depending on exactly how things are set up.
<blr> ah 5502, connection refused
<blr> wgrant: hmm nmap'ing lpdev 5502 is not open, running with make run_codehosting however
<wgrant> blr: 5022
<blr> sorry, meant 5022, which is also not open
<wgrant> blr: Ah, what's the mtime on /var/tmp/launchpad_forking_service.sock?
<blr> wgrant: about 10m ago
<wgrant> blr: Odd. From inside the container does 127.0.0.88:5022 appear to be open?
<wgrant> Ah yeah, it only listens to that by default, I think.
<wgrant> configs/development/launchpad-lazr.conf:port: tcp:5022:interface=127.0.0.88
<blr> no, open: 22, 80, 443, 2121
<wgrant> Any processes mentioning 'sftp' in ps?
<blr> codehosting port/interface are correct in the config
<blr> no sftp
<blr> ah it is there in fact
<blr> clearly I've done something terrible :)
<wgrant> Is it listening on anything?
<wgrant> What does netstat -lnp -A inet say?
<blr> tcp        0      0 127.0.0.88:5022         0.0.0.0:*               LISTEN      32189/python2.7
<blr> I can connect from inside the container
<wgrant> Right, it's not visible from the outside by default, I suppose.
<wgrant> You can tweak the config I mentioned above to 0.0.0.0, or just push from inside.
<blr> excellent thanks wgrant - I'll make a note on the wiki.
<wgrant> Sounds good.
<cjwatson> wgrant: I have most of the LP side of repository deletion done now, but one remaining bit is dealing with deleting referencing GitRef rows.  I notice that for Branch/BranchRevision we do this by having BranchRevision.branch REFERENCES branch(id) ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED.  Do you think that makes sense for GitRef.repository too?  I'm assuming the deferrable bits are mainly for performance
<cjwatson> The alternative of course would be to clean them up manually in Python
<wgrant> cjwatson: I generally prefer it to be explicit, since it's a one-liner.
<wgrant> It's arguably sensible to have it cascade at the DB level in this case, though.
<cjwatson> I'm happy to implement it either way, just noticed that I couldn't find anything to clean up BR and went looking in the schema.
<cjwatson> Doing it in Python saves me another DB patch ;-)
<wgrant> Heh
<cjwatson> OK, repository deletion basically done, I just shoved in self.refs.remove().  It'll need an FDT first so I won't rush to push it.
<cjwatson> Oh, browser code I guess
#launchpad-dev 2016-05-16
<lifeless> wgrant: https://pypi.python.org/pypi/turnip/0.1.1 <- note the rendering
<blr_> lifeless: hmm not ideal
<blr_> lifeless: rst2html does produce warnings, no errors that I can see
<lifeless> blr_: yup, you need it to be clean - validate it in strict mode
<lifeless> blr_: or, use the readmethingy packae
<lifeless> readme_renderer
<blr_> lifeless: cool, wasn't aware of readme_renderer. This should do the trick hopefully https://code.launchpad.net/~blr/turnip/+git/turnip/+merge/294747
<lifeless> blr_: its worth putting that in as a unit test
<blr_> lifeless: true
<lifeless> https://bugs.launchpad.net/launchpad/+bug/110195 - lukasz has just touched a chunk of bugs
<mup> Bug #110195: Nominating a bug for a distro series affects all package tasks for that distro <bug-nomination> <bug-relationships> <lp-bugs> <motu> <oops> <Launchpad itself:Fix Released> <https://launchpad.net/bugs/110195>
<lifeless> I don't have time to check they are all bogus updates, but I smell a rate
<lifeless> rat
<cjwatson> lifeless: Yep, noticed and will go do some cleanup as soon as I've woken up properly and done a bit of planned rewiring.
<cjwatson> lifeless: all reverted, warned (new) user
<lifeless> cjwatson: cool; its a shame this happens
<blr_> lifeless: looking better now, thanks for noticing that https://pypi.python.org/pypi/turnip
#launchpad-dev 2016-05-17
<lifeless> blr: de nada
<wgrant> cjwatson: Do we actually need the depopulation job, or will update-pkgcache do that automatically if we explicitly set it to None there?
<cjwatson> wgrant: I initially thought we needed to set fti to None as well in order to get ftiupdate to do anything, but looking at it again I think I was wrong.
<wgrant> cjwatson: The triggers? They should fire on any column change.
<wgrant> Any change to a relevant column, that is.
<cjwatson> Yeah, I just misread the guard at the top of ftiupdate
<cjwatson> Apparently yesterday wasn't one of my cleverer days
<wgrant> Heh, I outright rejected one of your branches for the first time, so indeed.
<wgrant> Ah, which I see you've fixed. Excellent, thanks.
<cjwatson> Yep, although I think it needs further work as per my comment.
<wgrant> What's your concern?
<wgrant> Unless someone has requested a great many builds recently, or snuck in thousands for an architecture that will never build, there should not be many living BuildQueues.
<wgrant> BuildQueues existing only for pending or building builds.
<cjwatson> Ah, good.  That was my initial assumption when I wrote that code and then I realised I didn't remember if BQ was left around afterward.
<cjwatson> fixing the excessive join
<wgrant> Great.
<wgrant> BFJ is forever, but BQ lives up to its name.
<cjwatson> What's the difference between the two feature flags you propose in git-ref-commits?
<wgrant> One prevents memcached from being DoSed or causing problems, while the other prevents turnip from being DoSed.
<wgrant> Useful for working out which is screwed, if nothing else.
<wgrant> Our memcached cluster has not been tested with significant load in some time.
<wgrant> But we at least need the latter one.
<cjwatson> Oh I see, right.
<cjwatson> Probably need to at least synthesise the most recent commit out of the information we have in the latter case.
<wgrant> If it's not going to be on by default, maybe, yeah.
<wgrant> Avoid regressing behaviour from current, plus it's a handful of lines of TAL, right?
<cjwatson> Doesn't even need to be in TAL, I was thinking of having getCommits do it
<cjwatson> That's entirely dynamic, the results of that never wind up in the DB
<cjwatson> So getCommits could reasonably say "shrug, this is all I've got"
<wgrant> Ah, of course.
<wgrant> I would also consider potential for mischief through very large commit messages. But with the feature flags in place that is easy to manually mitigate once discovered.
<cjwatson> Disabling the "use memcache" flag would of course significantly increase the load on turnip.
<wgrant> It would.
<cjwatson> Probably ought to see if we can do something about turnip scaling soon, at least splitting some of the layers.  There's the cgit bodge, but it occurred to me that perhaps we could proxy it to the pack backend.
<wgrant> Yeahhh, I'd been considering that.
<wgrant> That makes it a slightly more complicated marginally less bodgy bodge that doesn't inhibit scaling.
<cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/package-cache-drop-changelog/+merge/294894 updated
<wgrant> cjwatson: Much simpler, thanks.
<cjwatson> Hm, re getLog, I think I also need to ensure a fallback for the frozen GitRef case.
<cjwatson> Oh, no, the commits will still be in the repository, so that bit is fine.
<wgrant> Exactly.
<cjwatson> wgrant: Also, I was thinking last night of adding a ~registry-viewable memcache stats page to the web UI.
<cjwatson> Unless scripts/memcache-stats output is already available somewhere we can see.
<wgrant> I've never seen it.
<cjwatson> Though graphs would be more useful.
<cjwatson> https://lpstats.canonical.com/graphs/ allegedly has various memcached things but they're all empty.
<cjwatson> I have no idea where to look for what's supposed to generate that; no matches in tuolumne
<wgrant> They'd be in tuolumne-lp-configs, but nothing there either.
<cjwatson> Yeah that's what I meant
<cjwatson> Presumably they'd have to come off the appservers
<cjwatson> There's a bit of Nagios monitoring but it's very basic
 * cjwatson tries to understand why update-pkgcache even exists at all
<cjwatson> I don't quite see why we couldn't just fill in cache rows when we touch xPPHs
<cjwatson> We can't fill in all the columns of DSPC until we have binaries, but we could fill that in when we get BPPHs
<cjwatson> Er, that's DistributionSourcePackageCache not DistroSeriesPackageCache
<wgrant> Calculating the entire everything on every BPPH creation would be a bit odd. But it could probably be optimised to be reasonable.
<wgrant> Just need to watch out for bloat etc.
<cjwatson> We still need to do counters and such in update-pkgcache
<cjwatson> It's a bit odd because you have to look at all BPRs for a source, yes; it would probably do a hell of a lot less work total
<wgrant> Less work than current update-pkgcache, indeed.
<cjwatson> Seems to make more sense to only update caches when things change
<wgrant> Less work than an update-pkgcache that was written with a mind, probably not.
<cjwatson> Could be when we process a build rather than on each individual BPPH, though still watching out for copies and removals
<wgrant> Right, the only sensible place for it is in publishBinaries
<wgrant> If we were going to do it inline.
<cjwatson> How else had you been thinking of improving update-pkgcache (aside from obvious query optimisations and such)?  Its current overall design is all about getting all the published sources and binaries and materialising them, so that would be similar order of work to the queries for NMAF publication of all archives, which doesn't sound like the ten minutes you suggested in Asana
#launchpad-dev 2016-05-18
<gQuigs> I have a new version of https://bugs.launchpad.net/launchpad/+bug/1579158 that works better.  Can I have wiki access to I can edit it for all to see?
<mup> Bug #1579158: [doc] Make an LXD version of Running/LXC <Launchpad itself:Incomplete> <https://launchpad.net/bugs/1579158>
<cjwatson> gQuigs: done (by adding you to ~launchpad-doc); if you're logged into the wiki, you will need to log out and back in
<gQuigs> cjwatson: awesome, thanks!
<gQuigs> btw... when I go to https://testopenid.dev/+auth and it asks for my email what should I put in?  (and where is that documented?)
<cjwatson> gQuigs: https://dev.launchpad.net/Running#Running-1
<cjwatson> gQuigs: or utilities/make-lp-user
<gQuigs> I need to get my eyes checked apparently
<gQuigs> thanks
#launchpad-dev 2016-05-19
<cjwatson> wgrant: I just rearranged https://code.launchpad.net/~cjwatson/launchpad/snap-authorize-view/+merge/294358 rather extensively to use POST requests rather than mutating GETs.  I think it's less weird now, but it may be worth another look.
<cjwatson> wgrant: Oh, and any objection to me going ahead with getting https://code.launchpad.net/~cjwatson/meta-lp-deps/libsodium/+merge/294316 deployed to world tomorrow morning?
<cjwatson> Forgot I hadn't done that yet.
<wgrant> cjwatson: libsodium everywhere indeed makes sense. I'll look at snap-authorize-view after lunch, unless it's urgent.
<cjwatson> Not urgent since I can't land it until doing libsodium.
#launchpad-dev 2016-05-21
<olmari> hello... more of an suggestion rather than real development stuff.. but here comes: launchpad to support Curve25519 gpg keys
<olmari> rel: codeofconduct signing and pgp key "import"
<olmari> well.. same for ssh-keys too :)
#launchpad-dev 2016-05-22
<cjwatson> olmari: https://bugs.launchpad.net/launchpad/+bug/907675
<mup> Bug #907675: Add support for ECDSA and Ed25519 SSH keys <Launchpad itself:Triaged> <https://launchpad.net/bugs/907675>
<olmari> oh well.. would have been obvious to look there (too)
<cjwatson> olmari: Please don't post me-too comments in bugs
#launchpad-dev 2017-05-18
<Laney> print(Gst.Caps.can_intersectillllli"can_intersect: %s, is_subset: %s" % ( (caps1, caps2))jhla,
<Laney> yk
<Laney> khhhhhhhhhhx:w
<Laney> y
<Laney> :q
<Laney> haha
<Laney> sorry about that
#launchpad-dev 2020-05-11
<cjwatson> Crossing fingers and landing my buildmaster-fetch-in-thread branch
 * SpecialK|Canon eats^Wsacrifices a biscuit to the concurrency deities
 * tomwardill -> lunch
<cjwatson> ilasc: I'm starting to look at your question in https://code.launchpad.net/~ilasc/launchpad/+git/launchpad/+merge/383333 now (sorry for the delay).  Is there a failing test that exhibits the problem, or do I need to set something up in a browser?
<ilasc> cjwatson: thanks! there is a Unit Test that you can use to avoid all the browser action, putting together a pastebin now
<ilasc> cjwatson: this is how I test without browser: https://pastebin.canonical.com/p/dytcVy7vmS/
<cjwatson> ilasc: OK, thanks
<teward> cjwatson: thanks for looking @ my merge request, changes made to the branch accordingly.
<teward> question though: if we're replacing Person.displayname -> Person.display_name does that apply for all cases of a 'person' including bug owner, etc.?
<teward> 'cause if so there's a *lot* of deprecated usages in the bug notification builder
<cjwatson> teward: We should eventually fix it tree-wide, but it'll be a massive change so for now it's fine to just chase the deprecation on lines we're changing anyway
<teward> ok
<teward> 'cause if we WANT I can start a change for the bug notification part
<teward> since i'm already stabbing that xD
<cjwatson> teward: It's not urgent
<teward> ok
<cjwatson> I'll land your change once I've fixed the buildbot chaos I just caused
<teward> heh no problem.  let me guess it exploded hard :)
<teward> cjwatson: does Canonical and the LP team need to make an announcement about the DMARC compliance change?
<teward> (for bug notifications only at the moment)
<cjwatson> I don't think it's vital, since it's already the status quo for users with hidden email addresses
<cjwatson> But we'll probably put something about it on blog.launchpad.net
<cjwatson> tomwardill: if you're still around?  https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/383734 (Fix proxy token handling for buildd-manager changes)
<cjwatson> or maybe pappacena
<tomwardill> looking
<tomwardill> +1
<cjwatson> Thanks
<cjwatson> pappacena: http://lpbuildbot.canonical.com/builders/lp-devel-xenial/builds/1247/steps/shell_9/logs/summary looks like your bug so far FYI
<pappacena> let me check
<cjwatson> (assuming no more of mine show up ...)
<pappacena> ah, it's probably something I've changed in the previous lp-signing MP, and didn't fix the tests here. Should be easy. Give me a minute
<cjwatson> Yeah, it looked like something along those lines
<pappacena> I'll run all the tests here and open a MP in some minutes
<cjwatson> Ta
<cjwatson> I've mostly EODed but can manage a testfix review if you need it
<pappacena> I'm opening the MP right now
<pappacena> Here: https://code.launchpad.net/~pappacena/launchpad/+git/launchpad/+merge/383739
<pappacena> bin/test -vvct lp.services.signing -t lp.archivepublisher.tests.test_signing
<pappacena> Total: 100 tests, 0 failures, 0 errors, 0 skipped in 48.322 seconds.
<pappacena> cjwatson, it's a quite easy test fix. Not a big deal if you EODed and I self-approve it...
<cjwatson> pappacena: r=me
 * pappacena Thanks!
#launchpad-dev 2020-05-12
<teward> cjwatson: got an email from the build bot that it failed, looks like the timeout was RabbitMQ related, is this a failure in buildbot?
<wgrant> teward: Yeah, known flakiness. I've retried it.
<teward> wgrant: ah, thanks.  So not my fault :)
<teward> looks like it passed.
<teward> (and yes I can't sleep >.<  Time to try again with melatonin now)
<tomwardill> Fix an OOPS if you search for OCI projects with no term: https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/383773
<cjwatson> r=me, one comment
<tomwardill> oh, it's not different, I just did a silly
<cjwatson> Hmm, looking at the perennial problem where you need to manually clear launchpadlib's wadl cache
<cjwatson> I don't think it's a client-side problem
<cjwatson> At the server end we seem to be somehow changing the content without changing the Etag
<cjwatson> So no wonder the poor client is confused
<tomwardill> that would do it
<cjwatson> Hm, this only seems to be the case on dogfood though.  I wonder if Apache is doing something in front of all the other instances?
<cjwatson> Though I'm sure I remember seeing this problem across production upgrades too
<cjwatson> Right now the etag on dogfood is literally the sha1 of '\0application/vnd.sun.wadl+xml' though
<wgrant> The etag config is customised to ensure consistency across the FEs
<wgrant> I forget what it is, maybe mtime and size
<cjwatson> I'll see if I have to do anything manual after the next deployment
<cjwatson> https://code.launchpad.net/~cjwatson/lazr.restful/fix-wadl-etag/+merge/383777
<wgrant> That MP explains a lot.
<tomwardill> Looks like the librarian file upload deduplication either doesn't work or wasn't actually implemented
<tomwardill> (or I've lost a bunch of code somewhere)
<tomwardill> fixing
<tomwardill> oh no, I think I'm just being silly
<tomwardill> cjwatson: remind me where the code that pulls files from the builder lives?
<tomwardill> aha, buildbehaviour, of course
<tomwardill> ah, right,that code does exist, I was just looking in the wrong place
<tomwardill> (for future travellers, it's in the buildbehaviour, which ensures that all the files exist from the librarian on disk, ready for the uploadjob)
<tomwardill> although the scope it's checking for existing files might be too limited there
 * tomwardill stares at it a bit harder
<cjwatson> lp.buildmaster.interactor too IIRC
<cjwatson> Well, in fact that's more about causing the builder to pull files from LP
<cjwatson> There's also lp.archiveuploader.ocirecipeupload
<tomwardill> yeah, that's where I was originally
<tomwardill> by the code in ocirecipebuildbehaviour, we're only looking for existing layer files within the same build (L13(
<tomwardill> *L139
<tomwardill> which isn't correct, or useful
<tomwardill> cjwatson: so, the buildbehaviour grabs the (existing) file from the librarian and puts it on disk, so the uploadjob can reupload it. This seems a bit weird
<cjwatson> I think this was partly in case of racing with GC, but I'm sure it's possible to do better, yes
<tomwardill> yeah
#launchpad-dev 2020-05-13
<SpecialK|Canon> Suggested MP URLs on push is <3 <3 <3
<tomwardill> "# IF YOU ARE READING THIS, TWOM FORGOT TO ADD TESTS"
<tomwardill> ah, thanks past twom
<SpecialK|Canon> :D
<StevenK> On one of the open source projects I work on, I tore my hair out for a few hours about why a test I added that did self.assertTrue(False) didn't fail. Turns out the entire test class of 94 unit tests wasn't being run at all
<tomwardill> reuse layers across image uploads, a first punt. https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/383859
<cjwatson> pappacena: https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/383860   small fix to sync-signingkeys
 * pappacena reviewing
<SpecialK|Canon> Do we still use lp:txlongpoll?
<SpecialK|Canon> Tom was unsure when we spoke earlier
<cjwatson> Is dead
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/remove-txlongpoll/+merge/366122
 * cjwatson removes it from launchpad-project
<SpecialK|Canon> Fab, thanks!
<cjwatson> I think we may not have actually decommissioned the deployment of it, but it's doing nothing
<SpecialK|Canon> Is it appropriate for me to remove it from the OSA rollout docs or should I ask "a LOSA"?
<cjwatson> Feel free to nuke it
<SpecialK|Canon> I can safely drop Staging Auditor from that too, ja?
<cjwatson> ja
<cjwatson> wgrant: Could you review https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/383880 please?  Some new xPPH indexes in preparation for publisher rework
<tomwardill> cjwatson: any idea what would give "ImportError: No module named loom.branch" on `make apidoc`?
<tomwardill> it's entirely possible I have a broken build env
<cjwatson> tomwardill: utilities/update-sourcecode
#launchpad-dev 2020-05-14
 * tomwardill -> lunch
<tomwardill> this .. is not going well
<tomwardill> digests are mysteriously vanishing and I don't know why
<ilasc> :(
<tomwardill> aha, finally
<tomwardill> (running wrong version of buildd)
<tomwardill> that'd do it
<ilasc> :D
 * ilasc is having a nerdy moment of joy here after discovering widget_class='field subordinate'
<ilasc> I believe I have something close enough to what we need for the "nested" widgets on the Push Rules page:
<ilasc> https://pastebin.canonical.com/p/hVXVCK5TdX/
<pappacena> Folks, I have 3 open MP for UI pieces of OCI needing review. If someone could help me...
<pappacena> - OCI project search on distribution: https://code.launchpad.net/~pappacena/launchpad/+git/launchpad/+merge/383657
<pappacena> - Official OCI recipe of an OCI project (first round of review already done): https://code.launchpad.net/~pappacena/launchpad/+git/launchpad/+merge/383542
<pappacena> - OCI Recipe list (First round of reviews already done): https://code.launchpad.net/~pappacena/launchpad/+git/launchpad/+merge/383094
<ilasc> pappacena : on it right after Standup
<pappacena> Thank you! :-D
<cjwatson> Yeah, subordinate is a handy bit of CSS
<ilasc> :) indeed!
 * tomwardill needs more coffee
<tomwardill> cjwatson: you are right about the buildbehaviour changes
 * tomwardill fixes the comment
#launchpad-dev 2020-05-15
<cjwatson>   File "/home/cjwatson/src/canonical/launchpad/git/launchpad/lib/lp/buildmaster/manager.py", line 641, in update
<cjwatson>     transaction.sbort()
 * cjwatson is clever
<cjwatson> AttributeError: 'module' object has no attribute 'sbort'
<cjwatson> it sure doesn't
<wgrant> Sounds like a serious Zope bug, really.
<tomwardill> sounds like it could be easier to use
<tomwardill> someone must have done a levenshtein implementation for __call__, right?
<wgrant> Should be built into the MRO, really.
<tomwardill> cjwatson: slightly silly question, but how do I test/operate a running codebrowse instance?
<cjwatson> tomwardill: should be able to go to https://bazaar.launchpad.test/~some/branch/path or so
<cjwatson> assuming you've pushed something to a local codehosting
<tomwardill> ah, right
<cjwatson> I can't remember whether codebrowse requires local filesystem access to the branch storage
<cjwatson> Which is obviously somewhat relevant for what you're experimenting with
<wgrant> It uses dumb HTTP
<SpecialK|Canon> I'd assumed it didn't because babaco didn't look SAN-y
<SpecialK|Canon> but equally maybe there's a sharedfs there!
