[12:07] <ntsjk> zein
[01:04] <CarlFK> "Patch                (Required)"
[01:04] <CarlFK> required? ! ;)
[01:19] <jamesh> CarlFK: it is required that you either leave the checkbox checked or unchecked :)
[01:29] <mpt_> Goooooooooooooooood afternoon Launchpadders!
[01:29] <mpt_> jamesh, oh boy, that's a bug
[01:39] <CarlFK> heh
[01:49] <mpt> I can never change the people of a spec
[01:49] <mpt> it always times out
[01:50] <mpt> whoa, I take that back
[01:50] <mpt> it took about 25 seconds, but it worked
[03:46] <jamesh> so, MultipleJoin is really bad for pretty much any case where we'd get lots of results
[04:00] <spiv> jamesh: Yep.
[04:01] <spiv> jamesh: newer versions of SQLObject have SQLMultipleJoin or some-such that are better.
[04:01] <jamesh> spiv: I noticed that.  I wonder why you'd ever want to use MultipleJoin instead of SQLMultipleJoin though?
[04:02] <spiv> jamesh: The only reason I can think of is backwards compatibility.
[04:02] <jamesh> if the aim is backward compatibility (i.e. don't make something start returning a SelectResults when it used to return a list), then it would probably be better to make MultipleJoin just convert the SelectResults to a list
[04:03] <jamesh> so you still get one query
[04:08] <spiv> jamesh: So for MulipleJoins that are hurting us, we can either manually replace them with properties that generate the appropirate SelectResults, or perhaps look at borrowing the newer joins from upstream.
[04:08] <spiv> I think there's already one or two places where we've taken the ad hoc property road.
[04:11] <jamesh> I converted a few MultipleJoins to SelectResults properties, but that wasn't performance related
[04:12] <jamesh> that was where we had two classes implementing the same interface but one returning a list and the other returning a SelectResults
[04:19] <jamesh> maybe we should look at upgrading our sqlobject
[04:19] <spiv> Definitely.
[04:19] <spiv> There's a bit of pain, because we've diverged a little bit.
[04:20] <spiv> And upstream has rearranged a lot of internals for "class sqlmeta:", so most of our patches need work to keep them applying.
[04:21] <stub> Are our patches suitable for applying upstream? I can't remember much of what local changes we rely on.
[04:21] <spiv> Some are, some aren't.
[04:22] <jamesh> the Table.selectFirst() and SelectResults.__nonzero__() stuff might be appropriate
[04:22] <spiv> E.g. our postgres-specific unicode stuff isn't.
[04:22] <spiv> selectOne got a mixed reception on the list, but I think if we synced it up to current upstream, they would probably take it.
[04:23] <spiv> They didn't like SelectResults.__len__ when I proposed that :)
[04:23] <jamesh> do you think they'd like selectFirst()?
[04:23] <jamesh> I can understand them not liking __len__()
[04:23] <spiv> I'm not sure, it's a relatively uncommon use-case, so it might be hard justify.
[04:24] <spiv> I think there's a reasonable argument to be made that there's something inelegant about having lots and lots of select* variants, although I can't think of any obviously better alternatives.
[04:29] <mpt> meh
[04:30] <mpt> Anyone here an expert on wpasupplicant? My Internet connection was working on Friday...
[04:31] <ajmitch_> mpt: and what broke since then? why is it wpasupplicant?
[04:31] <mpt> ok, maybe I'm misattributing blame
[04:32] <mpt> What broke is that I have no Internet connection, no DNS, nothing
[04:32] <ajmitch_> brave/silly enough to be running dapper?
[04:32] <mpt> no, 5.10
[04:33] <ajmitch_> hm
[04:33] <mpt> and I know it's not the AP, because if it was, you wouldn't be able to see what I'm typing on my Mac
[04:34] <jamesh> try turning off WPA :)
[04:34] <mpt> If I did that, I'd break everyone else's Internet connection
[04:34] <mpt> or setup, anyway
[04:34] <ajmitch_> ah yes, shared flat connection :)
[04:39] <jamesh> spiv: looks like upstream sqlobject has SelectResults.getOne()
[04:39] <jamesh> spiv: so you'd do Table.select(...).getOne()
[04:40] <spiv> jamesh: Hmm, instead of selectOne, it seems.
[04:40] <jamesh> yeah
[04:41] <jamesh> actually, you'd do Table.select(...).getOne(None)
[04:41] <jamesh> getOne() will raise SQLObjectNotFound if you don't give a default
[04:42] <spiv> It would be good to get closer to upstream.
[04:43] <jamesh> I suppose the other big change we've got is the set operations stuff for SelectResults
[04:43] <spiv> Yeah.
[04:43] <spiv> That's suitable for upstream, I think.
[04:44] <spiv> Although not necessarily portable to all backends, which may be a problem.
[04:44] <mpt> well, that's progress
[04:44] <mpt> dhclient works now, but still no Internet
[05:09] <spiv> lifeless: what's up with pqm.ubuntu.com?
[05:14] <stub> lifeless: star-merge sftp://chinstrap.ubuntu.com/home/warthogs/archives/stub/psycopgda/devel/ sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/psycopgda/3.0/test
[05:21] <spiv> stub: pqm appears to be down... do you have access to it?
[05:21] <stub> yes. pqm isn't down, but the web interface maybe
[05:22] <spiv> The web interface certainly is :)
[05:22] <spiv> And because it's not on chinstrap anymore, I can't check if it's alive with ps anymore :)
[05:22] <stub> would have been the weekend sheduled outage
[05:22] <spiv> Yeah, I expect so.
[05:23] <spiv> Well, I'll just be patient then.
[05:29] <lifeless> spiv: up
[05:29] <spiv> lifeless: Thanks
[05:29] <spiv> Hmm, where did my branch merge request go...
[05:31] <spiv> lifeless: I sent a request to pqm@, Message-ID: <20060213040821.GB10611@home.puzzling.org>, but have got no reply, and the web interface says the queue is empty.
[05:31] <lifeless> spiv: bzrlib.errors.UnrelatedBranches: Branches have no common ancestor, and no base revision specified.
[05:31] <lifeless> I got a traceback
[05:32] <spiv> lifeless: Oh, heh.
[05:32] <spiv> lifeless: Why didn't I get that traceback?
[05:32] <lifeless> stub: cd pqm; twistd -oy pqm/ui/twisted.py
[05:32] <lifeless> stub: I need to make an init script at some point
[05:33] <lifeless> spiv: unhandled exception
[05:33] <lifeless> spiv: to debug this, try doing the merge on chinstrap - make a branch from the rf psycopgda and merge into that
[05:33] <spiv> lifeless: Oh, I know what my snafu was.
[05:34] <spiv> I just want pqm fixed so I don't have to ask to find out what my embarrassing snafu was :)
[05:34] <lifeless> spiv: oh, it will be.
[05:34] <lifeless> I have a note now
[05:38] <stub> lifeless: psycopgda was my request. I just wanted you to toss that at pqm since it tells me I don't have permissions :)
[05:38] <stub> (or I could just do it manually on balleny)
[05:39] <spiv> lifeless: So, buildbot merge still doesn't work :)
[05:41] <lifeless> stub: if you could do it manually right now that would be great.
[05:41] <lifeless> spiv: details details details
[05:42] <spiv> lifeless: are in the mail :P
[05:43] <spiv> lifeless: (I'm keeping launchpad@ in the loop this time)
[05:43] <spiv> (or would, if I could spell "canonical"... ahem)
[05:49] <jamesh> spiv: in the upstream sqlobject, SelectResults.__iter__() seems to evaluate every row in the result set before iterating :(
[05:49] <spiv> jamesh: Yuck :(
[05:49] <jamesh> return iter(list(self.lazyIter()))
[05:50] <jamesh> has a comment saying that it could be optimised
[05:50] <spiv> Ahem.
[05:52] <jamesh> the SelectResults.lazyIter() looks like the __iter__() in our version
[05:52] <spiv> I wonder what tests will break (if any) if I make the obvious change...
[06:15] <spiv> jamesh: So, replacing "return iter(list(self.lazyIter()))" with "return self.lazyIter()" doesn't break any SQLObject tests in SVN (although two tests are already broken...)
[06:15] <spiv> But then SQLObject only has 167 tests all up.
[06:16] <jamesh> spiv: I wonder why they changed things?
[06:19] <spiv> jamesh: r946, log message of "Made select results aggressively fetch objects, instead of lazily"
[06:19] <jamesh> that doesn't help much :)
[06:20] <spiv> No, not really :)
[06:20] <spiv> I'm trying to see if any other files changed in that revision, but my svn-fu is too wek.
[06:20] <spiv> weak, rather.
[06:20] <jamesh> svn diff -r 945:946
[06:20] <spiv> (and "svn log -r 946" doesn't work for some reason I don't understand, and the cryptic error message doesn't help)
[06:21] <spiv> It's things like this that make me feel a little less worried about the little warts that bzr still has :)
[06:21] <jamesh> only other change appears to be in docs/News.txt explaining that it now does something different :)
[06:22] <spiv> I wonder why.
[06:22] <jamesh> "When iterating over select results, a list is now immediately created with the full list of instances being selected."
[06:22] <spiv> I suppose it's meant as an optimisation for the expected "average" use of SQLobject.
[06:23] <spiv> If the result set is small enough, and is going to be entirely consumed, fetching it all at once probably is a small win.
[06:23] <spiv> But I don't think I like the tradeoff.
[06:23] <spiv> And I definitely don't like the lack of tests :)
[06:23] <jamesh> I wonder if it is a transaction isolation type issue
[06:24] <spiv> The history of that function has flip-flopped on this, I think.
[06:24] <jamesh> or to cover some issue of iterating over a result set while modifying those rows
[06:25] <spiv> I vaguely recall there used to be a comment that actually justified the call to list(...)
[06:25] <spiv> Or rather, iter(list(...)))
[06:27] <spiv> jamesh: See dbconnection.py:635 in our sqlobject snapshot
[06:27] <spiv> Which sort of does the same thing, and says:
[06:27] <spiv>         # We can't keep the cursor open with results in a transaction,
[06:27] <spiv>         # because we might want to use the connection while we're
[06:27] <spiv>         # still iterating through the results.
[06:27] <spiv>         # @@: But would it be okay for psycopg, with threadsafety
[06:27] <spiv>         # level 2?
[06:28] <spiv> So maybe it is to allow "for result in Foo.select(...): do_another_query(result)"?
[06:28] <spiv> (In which case there should be a test for it, dammit!)
[06:52] <mpt__> whoo, I now have DNS
[06:53] <mpt__> TCP here we come
[07:00] <stub> Average use? Toy use more like.
[07:02] <stub> Although for us, if we ever actually want to call __iter__ on a SelectResults containing more than 100 items or so then our code is broken.
[07:04] <stub> Cause that would indicate  performance issues on the webapp. Batch jobs might have use cases, but I suspect that it would just be asking for memory bloat problems.
[07:04] <jamesh> stub: we'd want to for /distros/ubuntu/+allpackages
[07:05] <jamesh> or other pages primarily aimed at spiders
[07:05] <stub> jamesh: We can't list all packages on one page - it is broken
[07:05] <stub> jamesh: ZPT just isn't fast enough. spiders are happy following links.
[07:06] <jamesh> I suppose so
[07:06] <stub> We might have a large batch size, but no batch size is just a scalability problem waiting to be triggered.
[07:06] <jamesh> and if we're just interested in spiders, something like google site maps might be more appropriate
[07:07] <SteveA> spiv, jamesh: the stuff you point out about sqlobject upstream worries me
[07:07] <stub> Google would be more likely to pay attention to properly batched pages anyway. A huge page full of 10,000 odd links looks like someone attempting to futz with their googlerankings.
[07:07] <SteveA> it looks like the project is actively moving in the direction of being just for noddy applications.
[07:08] <spiv> stub: To be fair, that's pure speculation on my part
[07:09] <spiv> stub: That it was an optimisation
[07:09] <spiv> Or should I say, "optimisation" ;)
[07:10] <spiv> stub: It's possible it's meant as a way to avoid holding a cursor open when something else may want to use it in the middle of an iteration, maybe.
[07:10] <jamesh> SteveA: on the subject of join columns, they seem to be moving to more scalable versions (SQLRelatedJoin, OneToMany, etc)
[07:10] <stub> cursor sharing and iterating over results across multiple transactions seem more likely to me.
[07:11] <dilys> Merge to devel/launchpad/: [trivial]  Updates required for serialization and deadlock handling in upstream psycopgda, and tests (r3128: Stuart Bishop)
[07:11] <stub> (the answer to the first being don't be so stingy with cursors. The second is trickier if you really want to support it. We don't do it in Launchpad because it is scary)
[07:15] <SteveA> jamesh: that's good to hear.  things i'm concerned about are test coverage, leaving broken tests checked in, lack of rationale in commit logs for changes
[07:16] <SteveA> as well as not considering large datasets
[07:18] <stub> Upstream is really just the work of one developer at the moment (Oleg). Nothing to stop us contributing, although not all of our work has been wanted (we didn't convince upstream that selectOne was a good idea, them prefering to leave the burden of getting it right up to the developer)
[07:18] <spiv> SteveA: I suspect the tests pass with their default backend, sqlite.
[07:19] <spiv> stub: Oleg was ambivalent on selectOne after lots of people on this list piped up and said they wanted it
[07:19] <jamesh> stub: there is something equivalent to selectOne() in there now
[07:19] <spiv> stub: And since then SelectResults has sprouted a getOne with a similar meaning
[07:20] <jamesh> stub: rather than Table.selectOne(...), you do Table.select(...).getOne(None)
[07:20] <jamesh> slightly more verbose, but it covers both the select() and selectBy() variants
[07:20] <jamesh> and anything else that returns a SelectResults
[07:21] <stub> SteveA: I'm being rained out. Ok if I take my public holiday next Monday?
[07:25] <SteveA> stub: oleg?  broyntmann?
[07:25] <SteveA> not ian bicking anymore?
[07:26] <spiv> Oleg is much more active on the lists, at least.
[07:26] <spiv> I get the feeling Ian is a bit more of a ceremonial leader, and Oleg does more of the dirty work.  Ian still does stuff, though.
[07:27] <SteveA> i wonder if oleg lives anywhere near me
[07:28] <SteveA> spiv, jamesh, mpt: i'd like to have a series of phone calls or skype calls with you (one at a time) to catch up with what's on your todo lists, what you're blocked on and that kind of thing
[07:34] <SteveA> oleg is in moscow, so not *so* far away
[07:35] <SteveA> kaip gaila, kad a nekalbu rusikai
[07:38] <mpt> SteveA, currently I'm blocked hacking-wise on https://launchpad.net/distros/ubuntu/+ticket/363
[07:39] <mpt> well, push-/pull-wise, anyway
[07:53] <SteveA> mpt: let's spend a couple of minutes trying to get your network back up
[07:53] <SteveA> but on a different channel
[07:53] <SteveA>  /join ##wpa-supplication
[08:25] <CarlFK> do launchpad submissions get announced in any #channels ?
[08:28] <SteveA> submissions?
[08:28] <SteveA> some stuff gets announced here by dilys 
[08:34] <CarlFK> what's that?
[08:36] <SteveA> dilys is an irc bot that recieves notifications when certain things happen in launchpad
[08:36] <CarlFK> like when I post a bug - is there a bot somewhre that blerts out "Bug #31285 in synaptic (upstream): "Add repository dialog doesn't close"
[08:43] <SteveA> i just checked the logs.  dilys is reporting here merges into the launchpad codebase.
[08:43] <SteveA> i'm sure i've seen some ircbot report new bugs filed here before...
[08:47] <BjornT> dilys used to report when new bugs were filed
[09:01] <mpt_> anyone know?
[09:23] <carlos> morning
[09:23] <mpt> hi carlos
[09:25] <mpt> How can I reliably find an URL that uses a particular template?
[09:26] <mpt> Some templates have lp:urls associated with them in the ZCML, but many don't
[09:26] <mpt> in this case, binarypackagerelease-index.pt
[09:28] <SteveA> mpt: in general...
[09:28] <SteveA> mpt: find what the template is for
[09:28] <SteveA> to do this, you need to grep / look inside the zcml or the browser code for that template's name
[09:28] <mpt> I got that far :-)
[09:28] <SteveA> like: grep 'foo-bar.pt' zcml/*.zcml browser/*.py
[09:29] <SteveA> if it is in zcml, then look at what kind of object the template is used for
[09:29] <SteveA> like
[09:29] <mpt> it's for BinaryPackageRelease
[09:29] <SteveA>   <browser:pages for="....ISourcePackage" 
[09:29] <SteveA> right
[09:29] <SteveA> so next, you need to find what URL a binary package release has
[09:30] <SteveA> and then put the name of the page for that template on the end of that URL
[09:30] <mpt> well, /distros/ubuntu/hoary/i386/pmount/0.1-1 looks promising
[09:30] <SteveA> the easiest way to do that is to look in
[09:30] <SteveA>  doc/canonical-url-examples.txt
[09:30] <mpt> but it turns out that's handled by distroarchreleasebinarypackagerelease-index.pt
[09:30] <SteveA> and look for an example of an IBinaryPackageRelease
[09:31] <mpt> The text "BinaryPackageRelease" was not found.
[09:32] <mpt> Maybe this template isn't used at all...
[09:32] <SteveA> then such things don't have canonical urls
[09:32] <SteveA> another thing to do
[09:33] <spiv> mpt: you could always delete it, and see if any tests fail ;)
[09:33] <SteveA> unregister the page the template is used in in zcml
[09:33] <SteveA> and then see if tests fail
[09:33] <SteveA> spiv: it is registered in zcml, so deleting it will stop functional tests from starting
[09:33] <SteveA> spiv: voice call?
[09:33] <mpt> <!--browser:page ...
[09:33] <spiv> SteveA: I'm just about to head out for dinner, unfortunately.
[09:34] <SteveA> maybe when you get back?
[09:34] <spiv> I think so; I need to be around in a few hours for the review team meeting anyway.
[09:34] <lifeless> jamesh: how are you going on the branch status page ?
[09:35] <ddaa> hello guys
[09:35] <mpt> ddaa, what did https://launchpad.net/projects/+syncreview used to be for?
[09:35] <mpt> hi, btw
[09:36] <ddaa> good question
[09:36] <spiv> Ouch, I can't assign a bug due to timeouts... https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-13/C187
[09:37] <mpt> ddaa, bazaar-sync-review.pt
[09:37] <ddaa> looking at it already
[09:38] <ddaa> baffling
[09:39] <ddaa> it looks like it would be an earlier version of https://launchpad.net/bazaar/series?text=&state=4&search=search
[09:39] <ddaa> but seriously, I do not remember ever using something called +syncreview
[09:40] <ddaa> the whole rcs-imports stuff in launchpad starts to feel like 3 generations of programmers have gone over it...
[09:40] <spiv> ddaa: bzr annotate suggests it was added by sabdfl, with the log message of "work on revision control import workflow"
[09:41] <mpt> yeah :-(
[09:41] <ddaa> mpt: date?
[09:41] <spiv> Way back in Nov 2004.
[09:41] <spiv> (revno 891)
[09:41] <ddaa> wait a min...
[09:41] <mpt> ddaa, perhaps you could offer your professional opinion in https://launchpad.net/products/launchpad/+bug/750
[09:41] <Ubugtu> malone bug 750 in launchpad "Oops at /projects/+syncreview" [Normal,Confirmed]  
[09:42] <ddaa> I have no idea what we were up to in Nov. 2004...
[09:42] <mpt> SteveA, when I unregister the page, no tests fail
[09:43] <ddaa> Should be like the time of the Oxford conference...
[09:43] <mpt> In which situation would you have a binary package that doesn't belong to a distro arch release, anyway?
[09:44] <ddaa> mpt: do you need me to write a comment in the bug tracker saying "I have no freakin' memory what this page was meant to do, and from the look of it it appears superceded by /bazaar/series"?
[09:44] <ddaa> or do you feel comfortable enough about rm it without that?
[09:44] <mpt> ddaa, if that will be enough for matsubara to delete it confidently, sure
[09:45] <SteveA> ddaa: do we have a meeting in 14 mins?
[09:45] <ddaa> SteveA: we usually do
[09:47] <ddaa> I think this one is going to be quick
[09:50] <dilys> Merge to devel/launchpad/: [r=salgado]  First part of SupportTrackerTweaks, reduce the number of status in the support tracker to three. (r3129: Bjorn Tillenius)
[09:50] <ddaa> jamesh: you around?
[09:53] <daf> SteveA, BjornT: yes, dilys used to report new bugs
[09:53] <daf> I can work out why she stopped and fix her if there's demand
[09:54] <SteveA> daf: CarlFK was asking about it.
[09:54] <SteveA> we should have a dilys product in the launchpad project
[09:54] <daf> yes. we should
[09:55] <daf> perhaps we should keep dilys in RF
[09:55] <jamesh> ddaa: yeah
[09:55] <ddaa> nice, I see you are already in #canonical-meetingh
[09:55] <SteveA> daf: so, add a product, and file a bug
[09:55] <SteveA> daf: and then invite CarlFK to subscribe to the bug
[09:56] <Seveas> OOPS-44C196 - subscribing someone else (I tried to subscribe pitti) takes too long
[09:56] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/44C196
[09:56] <Seveas> Should I file it or is it known>
[09:56] <daf> I think this is known
[09:57] <daf> I'll check
[09:57] <daf> hmm, where's mpt today?
[09:57] <sivang> morning all!
[09:57] <SteveA> mpt is having network problems
[09:57] <daf> hi Sivan
[09:57] <daf> SteveA: thanks
[09:57] <sivang> morning daf :)
[09:58] <Seveas> another thing: what is the usefulness of the "Link to CVE" feature? No link appears on the bug page...
[09:58] <SteveA> Seveas: daf and matsubara are regularly filing bugs for OOPSes, particularly timeouts
[09:58] <jamesh> Seveas: check the portlets
[09:58] <SteveA> Seveas: see https://wiki.launchpad.canonical.com/LaunchpadBugTriage
[09:58] <SteveA> Seveas: as a workaround, you can subscribe pitti by gpg mail
[09:58] <Seveas> ah narf, didn't look good enough :)
[09:58] <jamesh> Seveas: also, you can check the bugs associated with a CVE under /malone/cve
[09:59] <jamesh> and there is a distribution cve report where you can see the open bugs with CVEs associated with them
[10:00] <jamesh> (although it is currently busted for ubuntu due to lack of handling of private bugs)
[10:00] <daf> CarlFK: bug #31290
[10:00] <Ubugtu> malone bug 31290 in dilys "Dilys doesn't announce new Malone bugs any more" [Normal,Unconfirmed]  http://launchpad.net/bugs/31290
[10:02] <mvo> is there a reason that I can't "Edit Source" in launchpads display of a product series ? I try that for gnome-app-install (to point to the current bzr tree) and get a no permission error 
[10:02] <mvo> (https://launchpad.net/products/gnome-app-install/+series/main)
[10:09] <ogra> mvo, are you the owner of the product ? 
[10:09] <mvo> ogra: I'm registrant at least
[10:09] <ogra> hmm, i see 
[10:10] <ogra> i had a similar prob with ltsp ... but it was sufficient for me just to add my branch as bazaar branch ...
[10:10] <SteveA> daf: hello
[10:11] <ogra> (even if we are upstream for the new implementation)
[10:13] <daf> SteveA: hi
[10:14] <daf> mpt: I think the checkbox required thing is a Zope bug rather than a Launchpad one
[10:15] <SteveA> daf: please would you talk with mvo and ogra about the permissions issues they are encountering
[10:16] <SteveA> daf, mpt: in fact, it is both
[10:16] <ogra> SteveA, mine seems valid, i didnt register the product 
[10:16] <ogra> upstream changed to us (in fact we're our own upstream and there is still the old one) after the product was registered ...
[10:18] <daf> mvo: hmm
[10:20] <mvo> daf: it would be enough if I can remove one series and add a new one with the changed vcs information
[10:23] <daf> perhaps, as a temporary measure, one of the Launchpad admins can make the change for you
[10:23] <daf> what was the change you wanted to make?
[10:26] <mvo> daf: gnome-app-install no longer uses cvs but bzr at http://people.ubuntu.com/~mvo/bzr/gai--main/
[10:26] <dilys> Merge to devel/launchpad/: [trivial]  more suggested changes to analyse-error-reports.py script (r3130: James Henstridge)
[10:26] <mvo> daf: the same for update-manager. no cvs anymore but http://people.ubuntu.com/~mvo/bzr/gai--main/
[10:27] <daf> both are from the same bzr branch?
[10:28] <mvo> daf: ups, no
[10:28] <daf> http://people.ubuntu.com/~mvo/bzr/update-manager--mvo/
[10:28] <daf> ?
[10:28] <mvo> daf: yes, sorry. 
[10:28] <daf> :)
[10:28] <mvo> copy'n'paste error
[10:29] <daf> SteveA: can you arrange that?
[10:29] <daf> SteveA: I can't work out how to work out who has launchpad.Edit on ProductSeries
[10:32] <daf> Seveas: I've looked at your OOPS
[10:32] <SteveA> daf: basically, it is the buttsource group
[10:33] <daf> Seveas: I think we should have a bug on that, but I can't find it right now
[10:33] <daf> Seveas: how do I work that out?
[10:33] <daf> hola Carlos
[10:33] <daf> er
[10:33] <daf> SteveA: how do I work that out?
[10:33] <carlos> hi ;-)
[10:33] <SteveA> daf: it is tricky :-(
[10:34] <daf> SteveA: hmm, that's bad
[10:34] <SteveA> daf: this will get easier when i've landed the CrowdControl optimisations
[10:34] <SteveA> which have some architectural improvements too
[10:34] <daf> so they will optimise for clarity as well as performance?
[10:35] <SteveA> yes
[10:35] <daf> I don't see why the owner of a product shouldn't be able to modify product series
[10:36] <daf> there's also IProductSeriesSource
[10:36] <daf> it's not clear what it does
[10:36] <daf> class IProductSeriesSource(Interface):
[10:36] <daf>     # revision control items
[10:36] <SteveA> it's various permissions hacks
[10:37] <SteveA> to work around a shortcoming in the authorization system
[10:37] <daf> that's what I suspected
[10:37] <SteveA> the work i'll be doing this week is the first step in fixing that
[10:37] <daf> I'm not sure that the UI makes it clear that certain bits of productseries have different permissions to the rest
[10:37] <daf> so, it is a UI problem as well as an infrastructure problem
[10:38] <mpt> ddaa, you wanted to talk with me about RCS imports?
[10:39] <daf> mpt: https://launchpad.net/products/+new has completely mad tab ordering in the form
[10:40] <mpt> daf, that's because it's a standard form
[10:40] <mpt> see the FormLayout spec
[10:40] <daf> mpt: right -- we have a bug on this, don't we?
[10:40] <mpt> yes, bug is cited in that spec
[10:40] <daf> ta
[10:40] <mpt> along with BjornT's description of how to fix it
[10:40] <SteveA> mpt: ddaa, me, lifeless and jamesh are in a meeting
[10:40] <mpt> ok
[10:41] <daf> this spec seem to imply that it will be necessary to specify tab indexes in the code
[10:42] <daf> whereas I'd like the form machinery to be able to generate tab inidces itself
[10:42] <daf> BjornT: am I correct?
[10:43] <daf> mpt: the only bug I can see cited in that spec is #3736, which appears to have nothing to do with tab indices
[10:43] <daf> mpt: ah, never mind, I see it
[10:43] <BjornT> daf: hmm, i have to take a look at that again. but do we have to use tabindex at all?
[10:44] <daf> good question
[10:44] <daf> it seems that some forms use it partially
[10:44] <BjornT> yeah, and that causes problems
[10:45] <daf> yes, I think you have to use it all or not at all
[10:45] <BjornT> exactly
[10:45] <BjornT> i think the current implementation plan is based on that we won't use tabindex at all, since it's hard to generate them automatically
[10:46] <daf> well, FormLayout includes:
[10:46] <daf>     submit_button = SubmitButton('Add', 'UPDATE_SUBMIT', tabindex=1000)
[10:48] <BjornT> ah yes, i think i added that since the current implementation adds tabindex=1000, and i wanted to show that it'd be possible to still specify a tabindex if you want that. i'll take a quick look at it again, to make sure it isn't needed, and update the spec.
[10:48] <daf> thank you
[10:50] <daf> is there any reason to add the view/focused_element_id stuff to *form.pt rather than just the main template?
[10:50] <daf> (i.e. do we need the duplication?)
[10:53] <BjornT> just that the only use case for it so far is for forms. if we make it into a macro it should be ok to include it only in *form.pt i think.
[10:53] <daf> ok
[10:54] <daf> hmm, that reminds me -- I think some pages with custom forms are using an existing JavaScript hack to focus the first form element
[10:54] <daf> setFocus() in launchpad.js
[10:56] <mvo> daf: should I file a but about my g-a-i and update-manager request? or is that not needed (now that I have spoken to you)?
[10:57] <daf> it is needed, I think
[10:57] <daf> something like "product registrant should be able to modify product series details"
[10:57] <daf> please include the URL of the +edit page
[11:00] <BjornT> daf: true, i forgot about that. they should be modified to use the same macro, and the macro should include the functionality of that function, that is focus on either the first error or the control with the explicit id.
[11:00] <daf> BjornT: agreed -- can you put that in the spec? :)
[11:00] <BjornT> daf: yes, i will update the spec later today.
[11:00] <daf> great, thanks
[11:01] <BjornT> well, thanks for commenting on the spec and giving good suggestions :)
[11:01] <daf> you're welcome!
[11:01] <daf> stub: I wonder if the fix for #30979 is cherrypickable
[11:01] <daf> stub: and awful lot of people are running into it
[11:01] <daf> *an
[11:05] <daf> stub: also, does your mail to the list mean that you've been working on #2088?
[11:05] <stub> Bug 2088
[11:05] <daf> https://launchpad.net/products/launchpad/+bug/2088
[11:05] <Ubugtu> malone bug 2088 in launchpad "psycopgda reconnection and conflict handling" [Normal,Confirmed]  
[11:05] <daf> bug 2088
[11:05] <Ubugtu> malone bug 2088 in launchpad "psycopgda reconnection and conflict handling" [Normal,Confirmed]  http://launchpad.net/bugs/2088
[11:06] <daf> Seveas: maybe Ubugtu should be case-insensitive
[11:06] <mpt> why?
[11:06] <stub> daf: Yes. Fix committed.
[11:06] <mpt> oh, insensitive
[11:07] <daf> stub: that's really excellent news
[11:07] <Seveas> daf, it is
[11:07] <Seveas> well, it should be
[11:07] <daf> I'm wondering why "<stub> Bug 2088" didn't trigger earlier
[11:07] <daf> Bug 2088
[11:08] <stub> daf: What revision did the fix for Bug 30979 land in?
[11:08] <Ubugtu> malone bug 30979 in malone "Oops in popup to select a Ubuntu package" [Normal,Fix committed]  http://launchpad.net/bugs/30979
[11:08] <mpt> haha
[11:08] <daf> stub: not sure -- I'll look
[11:08] <Seveas> daf, malone may just be too slow today - Ubugtu will silently fail on timeouts
[11:09] <daf> ah, I see
[11:09] <daf> stub: looks like it was #3119
[11:10] <daf> stub: which includes an unrelated change to shipit, seemingly
[11:10] <daf> stub: but it's [trivial]  so hopefully shouldn't be risky
[11:10] <daf> stub: I guess we can run the test suite on the current prod code + that cherrypick
[11:10] <stub> yup
[11:12] <daf> together with the #2088 fix, that accounts for the biggest causes of not-from-search-bots crashes
[11:12] <daf> lifeless: :)
[11:12] <mvo> daf: bug #31294, does that look ok? or do you need more information?
[11:12] <Ubugtu> malone bug 31294 in launchpad "product registrant should be able to modify product series details" [Normal,Unconfirmed]  http://launchpad.net/bugs/31294
[11:13] <daf> mvo: looks great to me
[11:14] <daf> mvo: I'm sure we can pester you later if we need more from you :)
[11:17] <mvo> daf: yep :)
[11:19] <daf> stub: any idea why http://localhost:9030 would be turning up as a URL in the OOPS reports?
[11:20] <stub> daf: We havn't been able to repeat cases where that URL pops up. No idea why it happens.
[11:20] <stub> What is the oops?
[11:21] <daf> OOPS-43A111, OOPS-43A112, OOPS-43A114, OOPS-43A116, OOPS-43B140...
[11:21] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/43A111
[11:21] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/43A112
[11:21] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/43A114
[11:21] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/43A116
[11:21] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/43B140
[11:22] <stub> Ahh... oops happening before auth and traversal stuff has happened, confusing Zope as the virtual hosting gumph hasn't happened yet.
[11:22] <daf> urg
[11:23] <daf> ah, presumably the SELECT on Person is during the auth process
[11:23] <stub> Yup
[11:23] <daf> and it's timing out due to contention
[11:23] <stub> yup
[11:24] <daf> do we know what's causing the contention?
[11:24] <stub> Nup
[11:24] <daf> it must be something writing to Person, right?
[11:24] <stub> Yup
[11:24] <daf> hmm
[11:25] <daf> it can't be the karma cron, because that now uses a separate table, IIRC
[11:26] <SteveA> stub: so, i guess we should change publication so that it does vhosting before the first person lookup
[11:26] <daf> can we selectively log INSERTs and UPDATEs to Person, and would that help?
[11:26] <SteveA> stub: maybe i'll do this as part of some shipit work i want to do, so that we don't do URL mangling in apache any more
[11:27] <daf> SteveA: please file a bug
[11:27] <SteveA> stub: and instead use httpds on separate ports, with a conf file entry for where they're supposed to be
[11:27] <SteveA> daf: why?
[11:28] <daf> SteveA: so that the problem is not forgotten, can be discussed, and can be tracked
[11:28] <SteveA> daf: we're discussing it now.  i think it is premature to file a bug.
[11:28] <daf> well, the solution may not be settled on
[11:28] <stub> SteveA: Sure. I'm not sure what sort of priority it would be though.
[11:29] <SteveA> stub: do you think the approach is sound?
[11:29] <SteveA> i probably need to do the shipit stuff fairly soon, for shipit business reasons
[11:30] <daf> I suppose the problem is very minor, the symptom being that OOPS reports are missing some information that isn't critical given that we know what the problem is (contention on Person)
[11:30] <stub> We can't selectively log INSERTs and UPDATES. We can log everything and grep, but there would be too much info to wade through. Most likely the trigger is another launchpad request that also timedout, so the easiest source would be other  OOPS reports that occurred in the previous 30 seconds.
[11:30] <daf> I thought INSERTs and UPDATEs to Person were relatively rare
[11:31] <SteveA> stub: i talked a little on irc the other day about having a section in oops reports presented via cgi saying "other oopses that occurred concurrently with this one".
[11:31] <SteveA> i'm curious though, why the previous 30s ?
[11:32] <daf> SteveA: or perhaps a separate page which lists OOPSes chronologically
[11:32] <SteveA> daf: now that the karma cache is in its own table, i expect they would be rare.  but maybe there is some other cache... ?
[11:32] <SteveA> daf: that would be interesting to see.  it could use an html table
[11:32] <SteveA> to lay them out with concurrency
[11:32] <daf> yes
[11:33] <SteveA> or svg
[11:33] <BjornT> daf: it's not missing the information entirely,  you do have the url in the PATH_INFO variable
[11:33] <SteveA> for those using dapper, or possibly a backported firefox
[11:33] <SteveA> my main concern about the vhosting being messed up is that the error page contains broken links
[11:33] <daf> I think it would be very informative to know the relative frequencies of the queries that modify Person
[11:33] <stub> The oops you are looking at took 25 seconds to occur. If another request was interfering with it, that request may have started up to 50 seconds before the one you are looking at. The closer the time between them, the more the contention will have contributed to the timeout.
[11:34] <ddaa> mpt: yes
[11:34] <ddaa> mpt: I have issues with the RCS import details being recorded in productseries.
[11:35] <SteveA> daf: from oops reports, we just get long queries, not modifying queries
[11:35] <ddaa> mpt: BTW, that's probably related to mvo's being confused a bit earlier today.
[11:35] <SteveA> daf: we could extend the launchpad application logging to record timing information for POSTs
[11:35] <stub> The karma cache should not be an issue now. It only gets updates to it for a few minutes each day by a single process. It might cause issues in very rare circumstances (a page needs to query the karma cache twice, but the updater happened to update the cached value between the selects).
make Postgres on emperor log to a socket which has a Python program listening on the other end which greps for INSERT/UPDATE to Person and logs them cumulatively with constants stripped out</scifi>
[11:35] <stub> (And if that happened, you would get a serialization exception anyway)
[11:36] <SteveA> daf: we need to consider transactions, really
[11:36] <stub> Actually, we could log inserts and updates using a trigger bug again it is too much information to wade through.
[11:36] <SteveA> i think we will want to log the time taken for POST requests at some point anyway
[11:36] <SteveA> as those are the ones that will be hardest to optimise in the long run
[11:36] <daf> then let's do that
[11:36] <ddaa> mvo, daf: the limits on editing rcs details for syncing imports is a half assed implementation or requirements which will soon be obsolete.
[11:37] <daf> ddaa: what's being done about it?
[11:37] <daf> SteveA: is it much work to log POSTs in addition to GETs?
[11:37] <ddaa> not much, last time I checked there was clearly a bug that even I was not able to use the web UI to update such details...
[11:37] <SteveA> we just discussed two different issues.  the first is that some error pages display incorrect URL links.
[11:37] <ddaa> daf: so I had to do raw SQL...
[11:37] <daf> ddaa: do we have an updated set of requirements?
[11:38] <SteveA> this is almost certainly caused by a timeout before zope does traversal, so that the virtual hosting stuff isn't processed
[11:38] <daf> yes
[11:38] <SteveA> the mid-term solution to this is steve's refactoring of how we tell launchpad about virtual hosting
[11:38] <SteveA> so that we get a decent error page
[11:39] <SteveA> the second issue is that it is hard to see when database updates occur concurrently with other problems
[11:39] <daf> I wouldn't prioritise that very highly -- it occurs relatively infrequently
[11:39] <stub> Another approach would be to flag oops timeouts that contain UPDATE, INSERT or DELETEs as high priority, as these may be vicimizing other requests.
[11:39] <ddaa> daf: in short, not really. The rational for all that was preventing fucking up the Arch namespace. And the complete (old) requiremest are quite complex.
[11:39] <SteveA> some database updates are caused by launchpad POSTs
[11:39] <SteveA> stub: jamesh will be adding the HTTP method to the urls in the oops summary
[11:39] <SteveA> stub: so, when we get fascist about readonly GETs, this will serve
[11:40] <ddaa> daf: since the priority for rcs imports is leaving arch stuff behind, the only reasonable thing to do would be leaving the stuff broken, and maybe just unbreak it just enough to allow buttsource to edit syncing productseries.
[11:40] <SteveA> and for other reasons to do with monitoring scalability, we should record the start and end times of POST requests
[11:40] <SteveA> this does not account for scripts and other daemons that use the database directly, though
[11:40] <daf> stub: OOPS-43C97 -- timeout on INSERT to Person
[11:40] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/43C97
[11:41] <SteveA> i'll file a bug for the virtual hosting/timeout issue
[11:41] <stub> daf: Daisy chain :-)
[11:41] <SteveA> as i'll probably fix that while i do some shipit work in a few weeks
[11:41] <daf> stub: :)
[11:41] <ddaa> daf: but maybe filing a but would help documenting the issue. People seem to have enough trouble with the current situation that we hear about that quite often.
[11:41] <daf> ddaa: mvo just filed a bug
[11:41] <SteveA> hmm... daf: maybe in the text representation of bugs, grep out any OOPS code in it...
[11:42] <SteveA> then, when you say a bug number, ubugtu could give the bug URL and OOPS URLs
[11:42] <ddaa> daf: in the meantime, I can use sql superpowers to fix his stuff.
[11:42] <SteveA> daf: not a high priority, of course :-)
[11:42] <daf> SteveA: indeed
[11:43] <SteveA> on the recording of POST timestamps and durations, i don't think this will help so much now
[11:43] <SteveA> and stu's suggestion of seeing in the OOPS report when we have database writes is a good idea
[11:43] <daf> stub: hmm, INSERT into LoginToken that timed out: OOPS-43C110
[11:43] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/43C110
[11:43] <SteveA> daf: is "bad urls in error pages" already filed as a bug?
[11:44] <daf> don't think so
[11:44] <stub> logintoken has a foreign key relationship to the person table, so if the person table is locked the insert is blocked (I think this is improved in PG8.1)
[11:49] <SteveA> bug 31299
[11:49] <Ubugtu> malone bug 31299 in launchpad "bad URLs some error pages" [Normal,Confirmed]  http://launchpad.net/bugs/31299
[11:55] <SteveA> stub: can we turn down the serialization of login tokens or something like that?
[11:56] <SteveA> does the FK relationship help us in a tangible way here?
[11:57] <stub> FK relationship just gives us integrity guarantees. We can drop them. It might help - not 100% sure.
[11:59] <lifeless> review meeting time
[11:59] <lifeless> whos here?
[11:59] <BjornT> i'm here
[11:59] <spiv> I am
[12:00] <lifeless> agenda:
[12:00] <lifeless>  next meeting
[12:00] <lifeless>  queue status
[12:00] <lifeless> 20ths at the same time ok ?
[12:00] <spiv> Fine with me.
[12:00] <SteveA> yes
[12:00] <BjornT> sure
[12:00] <lifeless> ok.
[12:01] <lifeless> queue wise there are still a significant number of 2005 merge-conditional or other such pending merges
[12:01] <lifeless> i.,e.
[12:01] <lifeless> sftp://chinstrap/home/warthogs/archives/salgado/guilherme.salgado@canonical.com/sqlobject/2/smallfixes
[12:01] <lifeless> and
[12:02] <lifeless>  sftp://chinstrap/home/warthogs/archives/jamesh/sqlos/select-results-len-fix
[12:02] <lifeless>     *
[12:02] <lifeless> what is the best way to handle this ?
[12:02] <lifeless> I'm concerned that noise will make it hard to tell how busy reviewers are, and also whether we are dropping things.
[12:02] <jamesh> the sqlos/select-results-len-fix one can be removed
[12:02] <lifeless> jamesh: it would be nice if already merged branches could be automatically trimmed or something
[12:03] <lifeless> by the merge-calculator
[12:03] <SteveA> i suggest an email to salgado about the other branch
[12:03] <lifeless> well it was an example 
[12:03] <lifeless> there are more
[12:03] <SteveA> would be nice this meeting and salgado could meet
[12:04] <stub> pqm is down for 30 mins while I run the test suite on balleny
[12:05] <lifeless> anyhow, lets keep a low priority eye on ones own queue
[12:06] <lifeless> feel free to drop people a mail - its not your problem as reviewers to drive branches through, but neither should we let the page rot.
[12:06] <lifeless> i.e. what is debonzi's branch still on there for ?
[12:07] <lifeless> (I've mailed salgado)
[12:07] <SteveA> lifeless: maybe have a "compost" section to the page
[12:07] <SteveA> for branches that have been around for a while, and can probably be decomposed
[12:07] <lifeless> SteveA: then we need a gardener...
[12:08] <lifeless> I'd rather an email to lp cced the person direct
[12:08] <lifeless> if they don't reply, and noone takes it on, we can delete it after a couple of days
[12:09] <cprov> morning guys
[12:09] <lifeless> spiv: ? jamesh? BjornT ? ok with you ?
[12:09] <BjornT> lifeless: sure, fine with me
[12:10] <spiv> I'm ok with that.
[12:10] <jamesh> lifeless: sounds okay
[12:10] <lifeless> ok, lets do that
[12:11] <lifeless> any other business ?
[12:11] <lifeless> 5
[12:11] <BjornT> lifeless: i have a branch in your queue which is more than two weeks old, it'd be good if it was reviewed soon
[12:12] <lifeless> BjornT: I will either do it or ask another to do it tomorrow.
[12:12] <BjornT> thanks
[12:12] <SteveA> jamesh: i'll look at the reviews i have in my queue shortly
[12:12] <lifeless> 4
[12:12] <lifeless> 3
[12:12] <lifeless> 2
[12:12] <lifeless> 1
[12:12] <lifeless> 0
[12:12] <lifeless> tick tock tick tock tick
[12:13] <SteveA> ddaa: i'm expecting an email from you about open issues
[12:13] <lifeless> s/issues/wounds/
[12:13] <spiv> lifeless: Your story branch... I've made the trivial changes specified in my review.  I'm a bit reluctant to merge it myself r=spiv though :)
[12:13] <SteveA> ddaa: i'd like to get that, and reply to it this morning, before i get lunch.  after lunch, i'll be away from irc.
[12:13] <lifeless> spiv: rs=lifeless
[12:14] <lifeless> spiv: I agreed with your review comments
[12:14] <lifeless> and it has been reviewed.
[12:14] <spiv> lifeless: Good idea.
[12:14] <spiv> Ah, the the rsync just finished, excellent.
[12:14] <spiv> lifeless: Also, when will bzr on remote branches stop taking an eternity? ;)
[12:15] <lifeless> spiv: 0.8
[12:15] <lifeless> http://mail.opensolaris.org/pipermail/tools-discuss/2006-February/000165.html covers this a little
[12:16] <stub> daf: Test failures cherry picking 3119. I'll try and roll in out tomorrow with the production update
[12:17] <lifeless> stub: reminder to reenablepqm
[12:17] <lifeless> sweet
[12:18] <daf> stub: ah, shame; thanks for trying
[12:19] <BjornT> cprov: hi. it seems that you forgot to push your soyuz-ui branch
[12:20] <SteveA> jblack: ping?
[12:20] <cprov> BjornT: really, let'me check 
[12:21] <jblack> stevea: pong
[12:21] <SteveA> hi jblack 
[12:21] <jblack> Hiya
[12:22] <SteveA> can you help me with some questions about RocketfuelSetup?
[12:22] <jblack> What can your local friendly neighborhood bzrguy do today?
[12:22] <jblack> Sure thing. What's on your mind? 
[12:22] <SteveA> i have some code review to do
[12:22] <jblack> Ok.
[12:22] <SteveA> if you take a look here https://chinstrap.warthogs.hbd.com/~jamesh/pending-reviews/
[12:22] <SteveA> there are two branches from jamesh
[12:23] <SteveA> one of them, i can get a nice diff for on that page
[12:23] <ddaa> SteveA: okay, I'll do that right now.
[12:23] <SteveA> the other is a new tree that isn't in RF yet
[12:23] <SteveA> so, i need to get this to review it
[12:23] <SteveA> it is quite small, so a "bzr get" worked
[12:23] <jblack> All the way new.
[12:23] <jblack> Ok.
[12:23] <SteveA> in only a few minutes
[12:23] <jamesh> SteveA: there is no previous revision in rocketfuel for pygpgme
[12:23] <SteveA> is there a better way to get it, thoough?
[12:23] <jamesh> it is all new code
[12:23] <jblack> Thats the way.
[12:24] <SteveA> if it was bigger, should i use rsync somehow?
[12:24] <jblack> Oh, I see what you're asking. You mean time.
[12:24] <SteveA> right
[12:24] <jblack> Yeah, you can definitely use rsync if you have bzrtools, which you should
[12:24] <SteveA> would you add this "get an entire branch from someone, from chinstrap" use-case to the docs?
[12:25] <SteveA> then i can direct people to it when it comes up again
[12:25] <jblack> "bzr branch chinstrap:/full/working/dir newdir" I believe
[12:25] <jblack> sure.
[12:25] <SteveA> i see
[12:25] <SteveA> i didn't think about using "bzr branch"
[12:25] <cprov> BjornT: the chinstrap branch is up to date, let me check the permission issues 
[12:25] <SteveA> because i just wanted to see it, not edit it
[12:25] <SteveA> but i see the point now
[12:25] <lifeless> SteveA: you can also use 'bzr get'
[12:25] <jblack> Yeah. thats a misnomer. branch does the same thing as pull when you dont' have it.
[12:26] <jblack> bzr pull chinstrap:... may very well work as well.
[12:26] <lifeless> it wont
[12:26] <lifeless> pull only uses existing branches
[12:26] <SteveA> i tried "bzr pull" first, and it said I wasn't in a branch
[12:26] <lifeless> SteveA: there are three rules of thumb here:
[12:26] <SteveA> so i tried "bzr get" and it was got, in a few minutes
[12:26] <jblack> Yeah, then you neeed branch.
[12:26] <lifeless>  To make a new line of development use branch
[12:26] <lifeless>  To retrieve an existing branch use 'get'
[12:27] <SteveA> jblack: on another issue, jbailey agreed to maintain the launchpad-deps packages.  would you talk with him about getting your package of scripts combined into that?
[12:27] <lifeless>  To make a branch you have look like another branch use 'pull'
[12:27] <BjornT> cprov: ok, the pending-reviews page was updated a few hours ago, and it shows no diff.
[12:27] <jblack> stevea: Ok.
[12:27] <SteveA> lifeless: okay.  so, could i have used "bzr get" with the rsync syntax?
[12:27] <jblack> Any particular reason?
[12:27] <SteveA> any particular reason for what?
[12:27] <lifeless> SteveA: no, get, like branch, does not understand rsync.
[12:27] <jblack> for jbailey taking it over?
[12:28] <SteveA> jbailey is taking over the launchpad-deps packages
[12:28] <SteveA> and it would make sense to combine the scripts into the package that developers should install
[12:28] <jblack> stevea: sure.
[12:28] <SteveA> i'd still like you to work on it, from the point of view of improving the scripts etc.
[12:29] <SteveA> but for jbailey to do the dependency and packaging parts
[12:30] <jblack> what the? I could have sworn I've used rsync.
[12:31] <lifeless> jam has an rsync transport
[12:31] <lifeless> but I think its bitrotten
[12:31] <jblack> stevea: no problem. we can rsync directly.
[12:32] <SteveA> what is 'jam' ?
[12:32] <SteveA> i had a databases lecturer once called 'jam'
[12:32] <lifeless> John A meinel
[12:33] <jblack> stevea: that should be something like "rsync chinstrap:/home/warthogs/archives/jamesh/branchname/ nameyouwant
[12:33] <jblack> The slash after branchname/ is significant
[12:33] <jblack> And be in the directory that you want nameyouwant to show
[12:33] <SteveA> lifeless: aha, john.  i hadn't connected the initials with the name/person
[12:34] <SteveA> for a second i thought 'jam' was an add-on for bzr ;-)
[12:34] <jblack> It is, but its probably old
[12:39] <jblack> SteveA: Ok. I added a rsync section. Read it over and tell me if it reads clearly to you?
[12:41] <niemeyer> jblack!
[12:42] <niemeyer> What's up doc? :)
[12:42] <jblack> niemeyer!!
[12:42] <jblack> The sun is coming up. 
[12:42] <dilys> Merge to devel/launchpad/: [r=spiv,rs=lifeless]  Prevent test filtering breaking stories up - allows running of stories easily. (r3131: Robert Collins, Andrew Bennetts)
[12:42] <ddaa> SteveA: jam is an add-on, it's the code name for our experimental patch generator based on genetic algorithms ;)
[12:42] <ddaa> it works pretty well overall, but we have stability issues with its IRC UI.
[12:42] <jblack> how are you my man?
[12:42] <niemeyer> jblack: That's good news. ;)
[12:43] <niemeyer> ddaa: Enjoy it
[12:43] <jblack> anything bothering you today, buddy?
[12:43] <SteveA> jblack: it's good.  i would change the title to something other than "Adding a new branch for review".  Perhaps "Getting a whole branch for review" ?
[12:43] <niemeyer> ddaa: I was wondering where you were
[12:43] <ddaa> niemeyer: so do I
[12:43] <niemeyer> :-)
[12:43] <SteveA> jblack: also, i'd add a note about the importance of the trailing slash
[12:44] <SteveA> other than those comments, it reads very clearly.
[12:44] <ddaa> SteveA: btw, email sent
[12:44] <niemeyer> jblack: Not at all.. lot's of flying birds around my head with different ideas. :)
[12:44] <jblack> SteveA: A whole branch?
[12:44] <SteveA> ddaa: i will read now
[12:44] <niemeyer> SteveA: Morning
[12:44] <jblack> niemeyer: Oh, you need a bb gun.
[12:44] <SteveA> jblack: or maybe "getting a new branch for review"
[12:45] <SteveA> jblack: or maybe "getting a branch that is not in rocketfuel for review"
[12:45] <niemeyer> SteveA: Have you had the chance to look at the G arch spec?
[12:45] <SteveA> i guess the point is, you can use "bzr get" for it, but this will be slow right now.
[12:45] <jblack> Getting a new branch for review is good
[12:45] <SteveA> niemeyer: no, i haven't looked at any stuff from the G-Men for a while
[12:46] <niemeyer> Humm.. G-Men sounds.. humm G.. :)
[12:46] <SteveA> jblack: so, you might also point out that the reason to use rsync today is that we're waiting for the fast stuff to land in bzr
[12:46] <niemeyer> SteveA: Let me know if you do, please..
[12:46] <SteveA> niemeyer: men in black :-)
[12:46] <jblack> Done.
[12:46] <jblack> Sure.
[12:47] <jblack> Done
[12:48] <jblack> Ohh. the owner of spacepants.org is using bzr.
[12:49] <lifeless> jaq
[12:53] <SteveA> jamesh, stub, spiv: what's happened about the   sqlobject =='f'  to sqlobject?
[12:53] <cprov> BjornT: looks daf (or me, not sure) already merged his branch by accident ...zero diff locally too, I'll remove the branch from PendingReviews
[12:54] <spiv> jblack: why are you looking at spacepants.org?
[12:55] <spiv> jblack: I am curious :)
[12:55] <spiv> SteveA: stub was going to do the necessary surgery to sqlobject, I thought
[12:55] <jblack> spiv: because I was searching for "RHEL" and "bzr"
[12:56] <SteveA> spiv: phonecall?
[12:58] <stub> SteveA: I'll be sorting that tomorrow
[01:01] <SteveA> ok
[01:10] <jblack> spiv: He has something called bugtool
[01:11] <salgado> SteveA, do you know in what port shipit is running on production?
[01:11] <SteveA> salgado: same as launchpad is
[01:16] <daf> cprov: I don't think it was me
[01:17] <SteveA> bug 31299
[01:17] <Ubugtu> malone bug 31299 in launchpad "bad URLs some error pages" [Normal,Confirmed]  http://launchpad.net/bugs/31299
[01:17] <cprov> daf: so do I ;), that's way the zero diff is weird
[01:17] <SteveA> salgado: ^^^^
[01:18] <salgado> ah, good. thanks SteveA
[01:18] <cprov> daf: anyway, I can't investigate it right now, high priority things on soyuz
[01:32] <carlos> cprov: hi
[01:32] <carlos> did you see my email?
[01:33] <cprov> carlos: hi, yes, did't have time to sort it yet
[01:33] <carlos> cprov: I have another problem with that branch. Do you have sometime to help me?
[01:34] <cprov> carlos: yes 
[01:35] <carlos> cprov: I'm adding a new test
[01:36] <carlos> to test the translations upload
[01:36] <carlos> and I get: pmount_0.9.7-2ubuntu2_amd64.deb: Unknown architecture: 'amd64'.
[01:36] <carlos> cprov: but I already created the distrorelease 'dapper'
[01:36] <carlos> and the distroarch amd64
[01:36] <cprov> carlos: did you add an correspondent distroarchrelease for amd64
[01:36] <cprov> ohh
[01:37] <cprov> carlos: send me the test,
[01:37] <carlos> just a second...
[01:37] <cprov> carlos: ok
[01:39] <carlos> cprov: https://chinstrap.ubuntu.com/~dsilvers/paste/fileigZV4z.html
[01:40] <salgado> jamesh, still around?
[01:43] <cprov> carlos: send me also the changesfile, please
[01:46] <carlos> cprov: https://chinstrap.ubuntu.com/~dsilvers/paste/fileFpM2ZU.html
[01:52] <cprov> carlos: here i can't find you key -> UploadError: Signing key not found within launchpad.
[01:53] <carlos> cprov: that key is Kinnison's one
[01:53] <carlos> it should be there
[01:53] <cprov> carlos: uhm ...
[01:56] <cprov> carlos:keys imported, now got FileNotFound, which is good, send me the files 
[01:56] <carlos> ok
[02:00] <carlos> cprov: sent
[02:00] <cprov> carlos: thx
[02:12] <cprov> carlos: look on this https://chinstrap.ubuntu.com/~dsilvers/paste/fileXUSEDH.html, it passes here and points you are missing pmount source in dapper 
[02:12] <carlos> cprov: yeah, I saw that other error, but the arch error is still there....
[02:13] <cprov> carlos: you were probably appending data to nascentupload, don't do it anymore, work with your own test
[02:13] <cprov> carlos: here I don't have the arch error, run this new one and see if it pass
[02:13] <carlos> I'm using distroreleasequeue.txt
[02:14] <carlos> anyway, I will add the new test as you suggest
[02:14] <carlos> cprov: thank you!
[02:15] <cprov> carlos: ok, try to work with this separated test (less moving parts) then I can help you on demmand, by copying it in my tree everytime you need me to run it for you
[02:23] <carlos> cprov: your test works here
[02:23] <carlos> so It's a matter of fixing the missing pmount package and I suppose that's all
[02:23] <carlos> thank you
[02:23] <cprov> carlos: fine, sort out the missing source 
[02:24] <cprov> carlos: yes yes, be happy ;)
[02:36] <doko_> could somebody enlighten me, why gcj-4.1_4.1ds8-0ubuntu8 was rejected with "Uploads to dapper are not accepted." ?
[02:38] <salgado> stub, around?
[02:41] <Kinnison> do that's a good one
[02:41] <Kinnison> doko_: ^^
[02:42] <carlos_> cprov: hi, sorry, my line went down
[02:42] <doko_> Kinnison: ?
[02:42] <carlos_> cprov: did you see my question?
[02:43] <Kinnison> doko_: when did that reject happen?
[02:43] <cprov> carlos_: nop, type it again, please
[02:43] <carlos> cprov: I checked it and I already have a pmount sourcepackage in our sample data
[02:43] <doko_> Kinnison: solved, that was still jackass ...
[02:43] <carlos> cprov: so I suppose it's missing s source upload into the system, right?
[02:43] <Kinnison> doko_: oops :-)
[02:44] <cprov> carlos: not for dapper, I guess
[02:44] <carlos> cprov: what's the table to do that?
[02:44] <carlos> cprov: I thought the SourcePackage object was created automatically 
[02:44] <carlos> from the SourcePackageName and DistroRelease
[02:45] <cprov> carlos: uhm, nop ... there is no SourcePackage in DB world, but a SourcePackageRelease published in a given DistroRelease
[02:46] <carlos> cprov: ok
[02:46] <cprov> carlos: query SourcePackagePublishing, for a that name and that version within dapper distrorelease. 
[02:47] <carlos> soyuz testing is really a pain in the ass....
[02:47] <carlos> will do that after lunch
[02:47] <carlos> cprov: thanks
[02:48] <cprov> carlos: I'll be here to help you
[02:48] <carlos> cprov: when are you going to merge your branch?
[02:49] <carlos> see you later
[02:49] <cprov> carlos: in RF ? no established ETA yet, depends on the reviewer's
[02:50] <carlos> so it's ready to review, right?
[02:50] <carlos> ok
[02:57] <stub> salgado: pong
[02:59] <salgado> hi stub, I'm having some issues trying to write a sql query. can you give me some help?
[03:01] <stub> salgado: sure
[03:03] <salgado> so, we have the MirrorProbeRecord, where we store when a mirror was last probed (together with the log file). I need to do a query to get the mirrors that need probing. these should be the mirrors that were never probed or that were probed more than N hours ago
[03:07] <salgado> stub, https://chinstrap.ubuntu.com/~dsilvers/paste/fileJX1jTn.html is what I have so far, but I think that's not the right way to do it. apart from the fact that it won't do what I want
[03:11] <stub> salgado: Does https://chinstrap.ubuntu.com/~dsilvers/paste/file1ArzpA.html give you the results you want?
[03:13] <stub> use 'is true' btw instead of = true
[03:14] <stub> salgado: https://chinstrap.ubuntu.com/~dsilvers/paste/file6uGRaw.html with the 'enabled' flag check 
[03:16] <salgado> stub, yeah, that seems to does the job. I'll write a test just to make sure. thank you!
[03:19] <mpool> thanks for making the login timeouts more reasonable!
[03:20] <kiko> morning
[03:21] <mpool> hi kiko
[03:21] <mpool> i was just saying
[03:21] <mpool> "thanks for making the login timeouts more reasonable!"
[03:22] <mpool> anyhow, goodnight
[03:24] <kiko> enjoy both
[03:26] <kiko> stub, rollout planned for tomorrow? what revno?
[03:31] <bradb> hey kiko. I think I've come up with a pretty simple macro API for keeping the search filter, than I can land (or get into code review at least) today including giving +assignedbugs the new look and feel, and possibly having time to migrate another of the reports today. should i do it, or should i still drop it?
[03:31] <kiko> that's interesting
[03:31] <kiko> if it's simple, give me an overview of how it works
[03:33] <bradb> the macro would expect certain variables (default nothing): status_filter_links, searchtext, package, etc. it would use tal:conditions to know which of these need to be rendered. the views could have a base mixin class for common filter criteria extraction, and could specialize as needed.
[03:35] <bradb> actually, it would be more like searchtext_filter_link and package_filter_link
[03:35] <kiko> how would the view provide these variables?
[03:37] <bradb> kiko: the view for +assignedbugs wouldn't bother providing package_filter_link, where the view for +packagebugs would provide it with a method, like getPackageBugsFilterLink => tal:define="package_bugs_filter_link view/getPackageBugsFilterLink"
[03:37] <stub> kiko: I'm thinking of r3123 with r3128 cherry picked
[03:39] <kiko> bradb, it might be easier for the macro to use the view directly
[03:39] <stub> kiko: But I'm open to opinions
[03:39] <bradb> kiko: It could do.
[03:41] <stub> kiko: r3126 should probably go out too
[03:41] <kiko> stub, that sounds like a good plan, though I'd try to pick r3126 too -- basically let the support tracker stuff bake.
[03:41] <kiko> right
[03:42] <kiko> matsubara has a fix for bug 31158 that might be nice too, if we can land it now
[03:42] <Ubugtu> malone bug 31158 in soyuz "BinaryPackageRelease page is crashing because of portlet details" [Normal,In progress]  http://launchpad.net/bugs/31158
[03:54] <ddaa> holy shit...
[03:55] <ddaa> the sourcepackage field in productseries is just plain wrong...
[03:55] <ddaa> a series can be associated to multiple source packages...
[03:57] <ddaa> see database.ProductSeries.setPackaging
[03:57] <kiko> what does the field link to?
[03:57] <ddaa> it's not actually a field in the database
[03:57] <ddaa> it's an input in the series/+source form
[03:57] <ddaa> in the database is something that exists somewhere in the packaging tables
[03:58] <kiko> packaging sounds right, though
[03:59] <ddaa> look at database.ProductSeries.setPackaging
[03:59] <ddaa> that will update any number of existing associations, or create a new one...
[04:00] <ddaa> looks to me like a simple text input is not the right UI for that kind of functionality...
[04:00] <ddaa> nevermind it has nothing to do with RCS imports...
[04:01] <ddaa> don't scratch too hard, or you'll end up with no HEAD again ;)
[04:04] <kiko> what happened?
[04:04] <kiko> anyway
[04:04] <kiko> bradb, I think you should leave the filter stuff for later.
[04:04] <bradb> kiko: ok
[04:04] <kiko> it sounds like it will get in the way, and if we centralize the forms it is easy to add it in to the single central location, later.
[04:05] <kiko> stub, are you on vacation today?
[04:05] <bradb> I'm removing it on a separate branch then, so that we can get the code back if needed, whilst not leaving it sit there unused in the codebase.
[04:05] <kiko> sounds good
[04:06] <kiko> bradb, what did bug 3123 actually fix?
[04:06] <Ubugtu> malone bug 3123 in python-numeric "python-numeric-tutorial package does not depend on python2.3 but requires it" [Normal,Confirmed]  http://launchpad.net/bugs/3123
[04:06] <kiko> oops sorry
[04:06] <kiko> bradb, what bug did r3123 actually fix?
[04:07] <bradb> kiko: Just the bug in the errors report. I couldn't find a bug report open for it.
[04:07] <stub> kiko: sort of
[04:07] <kiko> bradb, how did it happen?
[04:07] <kiko> a null bugtask delta?
[04:08] <kiko> stub, cprov wanted to ask you to do some work on mawson if you could
[04:08] <kiko> cprov, email stub of the details, is my suggestion, anyway
[04:08] <cprov> kiko: nevermind, I'm talking with him
[04:09] <bradb> kiko: The BinaryPackageName vocabulary was returning an int instead of the BPN object, so in the specific case where a BPN is filled in for a task, it can look like a change was made when one wasn't, and thus it gets processed through the change machinery, causing an empty task delta.
[04:09] <bradb> Because the code that checks if a change was really made would be comparing a BPN id to a BPN object
[04:10] <kiko> I see
[04:10] <kiko> bradb, do you think it happened when changing a bugtask's binary package name?
[04:11] <bradb> no, that would accidetally work correctly
[04:11] <bradb> i /think/ it happens when you submit a "Comment on this change" without having changed anything.
[04:11] <kiko> so what would crash? not changing it? :)
[04:11] <kiko> I see
[04:12] <bradb> Normally you get an error that says that you submitted a change comment without changing anything.
[04:13] <kiko> cprov, did Kinnison manage to finish off the work to support pockets?
[04:13] <kiko> non-release pockets, in particular
[04:13] <kiko> stub, do you know if anyone is working on the fix for boolean columns?
[04:13] <cprov> Kinnison: not yet, we are working on it 
[04:14] <kiko> I  see
[04:15] <stub> kiko: I'm looking at that tomorrow
[04:18] <kiko> stub, thanks
[04:27] <kiko> stub, in your reply to the Vocabulary... email I sent, I had two questions
[04:27] <kiko> a) did you do any code changes or would you like to delegate this to salgado?
[04:28] <kiko> b) how do you "redo the ORDER BY" to use the index?
[04:32] <ddaa> stub: can you set the owner of https://launchpad.net/people/ddaa/+branch/gnome-app-install/main and https://launchpad.net/people/ddaa/+branch/update-manager/dev to mvo, please?
[04:33] <ddaa> (using "admins" priv)
[04:34] <kiko> ddaa, is there no "reassign" yet?
[04:34] <Alinux> hello, when Dapper's lauchpad import ?
[04:35] <ddaa> kiko: you mean somethnig like bug #29863 ?
[04:35] <Ubugtu> malone bug 29863 in launchpad "Workflow to transfer ownership" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/29863
[04:36] <ddaa> kiko: as far as I know, there is nothing to implement any of the use cases.
[04:36] <ddaa> kiko: there is Branch.author, but it's for a different use case.
[04:38] <kiko> ddaa, that's what I was referring to. it would be nice to have..
[04:38] <ddaa> kiko: well, it's not going to happen soon since it was marked as wishlist... feel free to expand on the strawman I proposed.
[04:39] <ddaa> kiko: in the meantime, an admins intervention is required.
[04:51] <dilys> Merge to devel/launchpad/: [trivial]  required MirrorProbeRecord indexes (r3132: Stuart Bishop)
[04:54] <ddaa> mvo: your branches are set up and linked from the productseries, now you just need an admin to make you the owner of the branches.
[04:54] <ddaa> here is the list of people you can nag: https://launchpad.net/people/admins
[04:54] <mvo> ddaa: thanks
[04:55] <ddaa> I had to file like 3 or 4 new bugs related to that user's email...
[04:56] <ddaa> mvo: can you handle replying to launchpad-users?
[04:56] <mvo> ddaa: hm, clicking on https://launchpad.net/products/update-manager/+series/main gives me a oops 
[04:57] <ddaa> what... the...
[04:57] <mvo> ddaa: I'm not on launchpad-users, sorry. my mail awaits moerations there too
[04:57] <mvo> ddaa: OOPS-44A491 if that helps
[04:57] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/44A491
[04:57] <kiko> I'll approve
[04:58] <ddaa> FUCKING BUGGY PRODUCTSERIES DIE DIE DIE
[04:58] <ddaa> here's what you get when you have functionality with no owner, no use case, and nobody who cares...
[04:59] <ddaa> mvo: I'll clear the ProductSeries.branch, I bet that's the culprit...
[04:59] <ddaa> I sort of believe that field was actually never used
[04:59] <mvo> ddaa: I answered the mail "gnome-app-install, update-manager sources?" on ubuntu-desktop/launchpad-users now
[04:59] <mvo> ddaa: thanks for tracking that issue 
[05:00] <ddaa> mvo: fixed
[05:00] <ddaa> holy fuck
[05:01] <ddaa> mvo: thanks a lot, you helped me uncover a critical bug I needed to be aware of for the bzr transition.
[05:02] <ddaa> this transitions starts to really feel like bug slalom, or dodging bugllets, or whatever...
[05:02] <ddaa> I mean really, all the bugs in the system are the main design constrainsts...
[05:03] <mvo> ddaa: thanks, I can see the bazaar branch now (but the old cvs branch is still there too)
[05:04] <ddaa> mvo: sure, it's still being updated, I see no reason to remove it
[05:04] <ddaa> Arguably, it should not be in the productseries, but I filed a bug about that.
[05:05] <mvo> ddaa: it's not used for development anymore, maybe it can be moved to a less prominent place?
[05:05] <mvo> ddaa: or renamed to "OLD" or something?
[05:05] <ddaa> rename the productseries to OLD?
[05:05] <ddaa> man, it's your main productseries...
[05:06] <mvo> ddaa: it isn't anymore, the main one is the bzr branch. and I seem to be unable to change that myself
[05:06] <ddaa> it's your main productseries
[05:06] <ddaa> productseries contains rcs import
[05:06] <ddaa> that's a bug in my opinion
[05:06] <ddaa> you cannot have rcs import w/o productseries
[05:07] <ddaa> we will be able to clear up the rcs details when the bzr branch for the import is registered and published, but right now it would cause the data to just never be converted.
[05:07] <ddaa> well, actually it's probably already converted, but won't be published
[05:07] <ddaa> We can do that if you think it's right not to publish the bzr branch for that RCS import.
[05:08] <daf> ddaa: re your bug:
[05:08] <daf> "not possible" -- the UI doesn't support it?
[05:08] <daf> or it's a permissions problem?
[05:08] <ddaa> daf: which bug, which "Not possible"?
[05:08] <mvo> all the fuss started because CVS is no longer my main branch for u-m and g-a-i. I would be happy to change that myself in launchpad but apparently I'm unable to. so I would like to have some way to indicate that it is no longer the mainline
[05:08] <daf> ddaa: bug #31308
[05:08] <Ubugtu> malone bug 31308 in launchpad "Cannot set branch associated to a productseries" [Normal,Unconfirmed]  http://launchpad.net/bugs/31308
[05:08] <daf> "t's currently not possible to set the branch associated to a productseries."
[05:09] <ddaa> daf: there's no UI for that. And actually the productserie page OOPSes when you set the branch with sql.
[05:09] <ddaa> Will comment on the bug.
[05:09] <daf> thanks
[05:09] <daf> including an OOPS reference might be helpful
[05:09] <ddaa> mvo: I understand that, but the "main branch" concept in launchpad is current braindead.
[05:10] <ddaa> add in an importd bug
[05:10] <mvo> ddaa: so there is no way to change a "main branch" once it was setup? (with the current lp)?
[05:10] <ddaa> mvo: so the only options I can give you is either leave the productseries as it is, or clear the RCS details and never have the RCS import updated again and never have it published as baz.
[05:11] <ddaa> mvo: there's no main branch concept in launchpad. There is a main productseries.
[05:11] <ddaa> mvo: I weep too
[05:11] <ddaa> this stuff is braindead
[05:11] <mvo> ok, please keep it as it is then people in gnome-cvs translate there it would be good to have that stuff importet
[05:11] <ddaa> I just did not realise how serious it was before we had the ability to register branch...
[05:12] <mvo> I will add some comment in the bzr branches stuff and hope that interessted people read it and get the bzr stuff instead of the cvs one
[05:13] <ddaa> mvo: I'm really sorry for the trouble, but when I told you the rcs import stuff was in dire shape I was not weening. I just know how seriously broken it's broken, and you just happen to hit most of road bumps (and find some new ones too).
[05:13] <ddaa> mvo: in that sense, you are an invaluable help to me :)
[05:15] <mvo> ddaa: ok, thanks. I'm happy that it will help fixing the issues. I will be able to work around the issues until then :)
[05:26] <dilys> Merge to devel/launchpad/: Fixes https://launchpad.net/products/soyuz/+bug/31158 (BinaryPackageRelease page is crashing because of portlet details) r=kiko (r3133: Diogo Matsubara)
[05:30] <carlos> cprov: ok, so I have the sourcepackagerelease but it's still failing
[05:31] <carlos> cprov: I think it's related to the manifest entry I choosed
[05:31] <cprov> carlos: manifest isn't really important, IFAICS
[05:31] <carlos> cprov: let me show you the new test
[05:31] <matsubara> kiko: https://launchpad.net/products/launchpad/+bug/31287 Could you try to access this bug?
[05:32] <cprov> carlos: sure
[05:32] <carlos> cprov: https://chinstrap.ubuntu.com/~dsilvers/paste/file7CyY91.html
[05:35] <cprov> carlos: right, you have to create a Build for amd64 arch
[05:35] <cprov> carlos: and pass it via to the policy
[05:35] <carlos> how?
[05:36] <cprov> carlos: spr.createBuild()
[05:36] <carlos> ok
[05:37] <kiko> matsubara, targetname is forbidden to me.
[05:37] <cprov> carlos: also to publish the just-created sourcepackagerelease
[05:37] <kiko> stub, r3133 would be nice as well, soyuz topcrasher
[05:37] <matsubara> kiko: same with me and salgado.
[05:39] <ddaa> daf: I commented on bug 31308
[05:39] <Ubugtu> malone bug 31308 in launchpad "Cannot set branch associated to a productseries" [Normal,Unconfirmed]  http://launchpad.net/bugs/31308
[05:41] <kiko> bradb, can you check on permissions for bug 31287? seems busted.
[05:43] <bradb> hm, weird
[05:43] <kiko> not only weird, it's a bug :)
[05:43] <kiko> or perhaps not, but..
[05:44] <bradb> yes, almost surely a bug
[05:45] <salgado> isn't that a bug that was filed as private?
[05:46] <kiko> it might have been, but are there no subscribers?
[05:46] <bradb> it's almost surely a privacy-related bug. i'm just trying to confirm that it is what i think it is.
[05:50] <bradb> reproduced locally
[05:50] <bradb> It would have been easy to overlook before because most of us were admins.
[05:50] <kiko> thank god somebody decided to revert that, but matsubara and salgado were never admins that I know of
[05:51] <bradb> they probably weren't looking at a lot of private bugs
[05:51] <bradb> there aren't many for LP
[05:51] <kiko> tru
[05:51] <kiko> add test and fix and we can cherry-picketh
[05:51] <bradb> yeah
[05:52] <salgado> what would be the fix for that? (just curious)
[05:53] <bradb> This is actually already tested in the privacy stored, and perms denied is the right error here, but the perms denied appears to be happening when rendering the ZPT, instead of when traversing the URL, which causes it to spit out an exception, instead of a human-readable "not allowed here" type page.
[05:54] <bradb> s/privacy stored/privacy story/
[05:54] <bradb> salgado: I /think/ the error may be in the page perms config, but I'm verifying that now.
[05:55] <salgado> right, but I'd expect that the launchpad team would've been subscribed to that bug when it was filed
[05:55] <bradb> salgado: Not if it were reported private.
[05:55] <bradb> The SecurityTeams spec is set to address this hostility.
[05:55] <salgado> ah, right
[05:57] <bradb> right, here's the problem:
[05:57] <bradb>     <browser:pages
[05:57] <bradb>         for="canonical.launchpad.interfaces.IBugTask"
[05:57] <bradb>         class="canonical.launchpad.browser.BugTaskView"
[05:57] <bradb>         permission="zope.Public">
[05:57] <bradb>       <browser:page
[05:57] <bradb>         name="+index"
[05:57] <bradb>         template="../templates/bugtask-index.pt" />
[05:57] <bradb> zope.Public, when it should be launchpad.View.
[05:58] <kiko> hey stub?
[05:58] <dilys> Merge to devel/launchpad/: [trivial]  remove the search filter UI. plan to resurrect it at the London sprint. (r3134: Brad Bollenbach)
[06:12] <ddaa> kiko: replied to your mail with CC to the launchpad mailing list
[06:12] <kiko> thanks 
[06:12] <ddaa> kiko: your suggestion was wrong, and I ended up writing a long explanation of why... I thought it would be of interest to other peopel.
[06:13] <kiko> saying "your suggestion was wrong" isn't a good way to garner support...
[06:15] <jbailey> In Malone, what's the difference between "milestone" in the status field, and targetting a fix at a release?
[06:15] <kiko> jbailey, the latter seems to be a bad suggestion
[06:16] <bradb> jbailey: milestones are a forward-looking goal, targeting a fix to a release is for backport/security fixes. this ui sucks.
[06:17] <ddaa> kiko: sorry I did not mean it to get out this way...
[06:18] <bradb> jbailey: Making this UI suck less is on my top 5 priorities list, among some other tasks involving making bug listings/batch/searching suck less.
[06:18] <jbailey> Hmm,okay.
[06:19] <jbailey> In this case I'm targetting a fix to a release because I'm uploading to -updates.
[06:19] <jbailey> So I want to track the upload to Hoary and Breezy separately.
[06:19] <jbailey> So it looks like I sould target a fix to the release.
[06:19] <ddaa> kiko: put another way "registered branches cannot be a superset of authored branches because there are distinct overlapping sets".
[06:19] <jbailey> Thanks for the help. =)
[06:19] <bradb> jbailey: yep, that's right. no prob.
[06:20] <kiko> ddaa, have you considered that it may be that the end-user does not benefit from this separation?
[06:20] <ddaa> I have, and they do.
[06:20] <ddaa> I can find the specific bug where that was discussed, if you want.
[06:20] <kiko> I've read it. I'm asking because I, as an end-user, see things in a similar manner as the user initially suggested in said bug report.
[06:21] <kiko> that going to registeredbranches and not seeing branches he registered /and/ authored is confusing.
[06:21] <kiko> so I'm suggesting that 3 + 2 + 4 might be a better solution
[06:21] <kiko> however
[06:21] <ddaa> kiko: that's an interesting solution
[06:21] <kiko> I don't want to discuss this any further than this, as I have a busy Monday :-)
[06:22] <ddaa> I'm not dismissing what you are saying now, but what you said initially.
[06:23] <ddaa> kiko: so you suggest 1+3 for authoredbranches and 2+3+4 for registeredbranches?
[06:23] <bradb> Is it normal that our "Not allowed here" page shows an exception?
[06:23] <kiko> exactly
[06:23] <kiko> bradb, only for launchpad devels, I think
[06:23] <bradb> kiko: I'm looking at this page with the no-privs user locally.
[06:24] <ddaa> kiko: my concern is that I think that the places where the model does not match reality are important to see easily...
[06:24] <ddaa> I'm not really happy with the current trade-off either.
[06:24] <bradb> Hm, but I'm a dev in production, so screw that.
[06:24] <kiko> ddaa, right, I think that /we/ as launchpad people find that distinction important, but I don't know about the end user
[06:24] <bradb> stub: Is it normal that our "Not allowed here" page shows an exception?
[06:25] <carlos> cprov: ok, next step... How could I publish the package?
[06:25] <kiko> it is not normal, bradb 
[06:25] <kiko> it should only be so for launchpad devels
[06:25] <kiko> are you sure no-privs is not in launchpad devels?
[06:26] <bradb> Yeah, I checked that: No Privileges Person is not an active member of any Launchpad teams.
[06:26] <bradb> I'm wondering if we also have a config that says always show tb's in dev.
[06:26] <ddaa> kiko: you have a point... I guess we'd need to ask users. You know that old rule: when in doubt, do what's most useful to you, then you know it will match the expectations of at least one user.
[06:27] <cprov> carlos: invoke its correspondent IDistroReleaseQueueSource.publish()
[06:27] <kiko> that's reasonable
[06:28] <cprov> carlos:  then move the resulted SSPPH to status PUBLISHED
[06:28] <carlos> ok
[06:29] <bradb> kiko: ah, check it out:
[06:29] <bradb>         # If the config says to show tracebacks, or we're on the debug port,
[06:29] <bradb>         # or the logged in user is in the launchpad team, show tracebacks.
[06:29] <bradb> it all makes sense now
[06:29] <kiko> yeah
[06:45] <carlos> cprov: this is not working... the queue is empty
[06:46] <carlos> cprov: https://chinstrap.ubuntu.com/~dsilvers/paste/fileCmeZoJ.html
[06:46] <carlos> cprov: the for loop does not executes any iteration
[06:51] <cprov> carlos: on sec
[06:52] <carlos> ok
[06:52] <cprov> carlos: you only have DRQ after perform the an upload 
[06:53] <carlos> so I need to upload the tar.gz?
[06:53] <carlos> ok
[06:53] <carlos> dude, this is soooo complicate. The test Is getting big and big to just test a small part of the system
[06:54] <cprov> carlos: in fact you need, since you have shortcut the source upload process, to create the SSPPH record by hand as we do in that method I've pointed you
[06:54] <carlos> I suppose that the fact that I don't know the details about soyuz it's the problem here...
[06:55] <carlos> cprov: so what's the right way to do it?
[06:56] <cprov> carlos: add the the SSPPH record by hand, I think, so at the end you'll have the source published 
[06:56] <kiko> carlos, cprov: would it be easier for carlos to put things in a directory like the sync process does?
[06:56] <kiko> just place them in a directory
[06:56] <kiko> and run process-upload for a specific policy
[06:56] <kiko> would that work?
[06:57] <cprov> kiko: he'd need real source 
[06:57] <kiko> not if you move the source check to the policy
[06:57] <kiko> instead of hardcoding it
[06:58] <carlos> cprov: I have the real source
[06:58] <cprov> kiko: this is not trivial 
[06:58] <cprov> carlos: how big ?
[06:58] <carlos> small
[06:58] <carlos> 36104 bytes
[07:01] <cprov> carlos: I'd not run the tools for it, it's expensive and as dificult as doing what you are doing. 
[07:02] <carlos> ok
[07:02] <cprov> carlos: concentrated in what you need, as soon as you have the source published you binary upload (already done) will pass
[07:02] <cprov> carlos: will send the SSPPH insert for you, one sec
[07:03] <carlos> ok, thank you
[07:03] <kiko> one sec, let me go up.
[07:05] <bradb> BjornT: For the "API" of a ZPT macro, is it more idiomatic for it to expect certain variables to exist, or for it to expect the view to have certain methods, or does it matter?
[07:10] <BjornT> bradb: good question, i'm not quite sure. i would say it depends on the situation, so it doesn't matter that much. choose what seems the easiest thing to do.
[07:10] <bradb> ok
[07:16] <dilys> Merge to devel/launchpad/: [trivial]  fix bugtask view permissions so the 'Not allowed here' page shows the correct exception when user visits a private bug without launchpad.View permissions. (This is already tested to ensure that a 403 Forbidden is raised.) (r3135: Brad Bollenbach)
[07:18] <kiko> carlos, I now understand better what you are doing -- simulating a build that uploads translations to rosetta, right?
[07:18] <carlos> kiko: right
[07:18] <kiko> I thought there were tests that did that already,but there are none
[07:19] <carlos> kiko: if the test works, then we can start doing dapper imports
[07:19] <kiko> yeah, I see.
[07:19] <carlos> We have tests for the imports
[07:19] <kiko> but not for builds :)
[07:19] <carlos> but not for the glue between soyuz and rosetta
[07:20] <carlos> right
[07:20] <cprov> carlos: wth -> (16:19:50) carlos <AUTO-REPLY> :  I'm not here ;)
[07:20] <carlos> oh, sorry
[07:20] <cprov> carlos: don't you receive priv ?
[07:21] <carlos> yes, I do
[07:35] <kiko> ddaa, do you know if permissions are broken in https://launchpad.net/products/gnome-app-install/+series/main/+addpackage -- ?
[07:35] <kiko> ddaa, I'd like product owners to be able to add those links..
[07:35] <ddaa> dunno about this page...
[07:35] <ddaa> but I think there's alread a package for gnome-app-install...
[07:36] <ddaa> https://launchpad.net/products/gnome-app-install/+packages
[07:37] <ddaa> There's a bug about this being hidden and useless: bug 31319
[07:37] <Ubugtu> malone bug 31319 in launchpad "Association between source package and product is not discoverable" [Normal,Unconfirmed]  http://launchpad.net/bugs/31319
[07:38] <kiko> is it useless?
[07:38] <kiko> or just too hidden to be useful?
[07:38] <ddaa> useless for navigation
[07:39] <ddaa> and, well, too hidden to be useful, too...
[07:39] <ddaa> the table is not hyperlinked
[07:50] <carlos> cprov: ok, next step done
[07:51] <carlos> but I keep getting "Policy permits only one build per upload."
[07:52] <cprov> carlos: pass the build.id to the policy
[07:52] <carlos> right, I forgot that... sorry
[07:53] <ddaa> cprov: you have admins superpowers
[07:53] <cprov> ddaa: yes, I have
[07:54] <ddaa> can you give mvo ownership of https://launchpad.net/people/ddaa/+branch/update-manager/dev and https://launchpad.net/people/ddaa/+branch/gnome-app-install/main please?
[07:54] <ddaa> and maybe sets the name of the latter to "dev" for consistency, too
[08:06] <carlos> cprov: hmmm... sorry but I don't see a way to link the build with the policy....
[08:06] <cprov> ddaa: mvo: check it, please
[08:08] <cprov> carlos: one sec ... (set MockOptions().buildid = build.id
[08:08] <ddaa> cprov: looks right, thank you
[08:08] <cprov> ddaa: you're welcome
[08:09] <cprov> carlos: you need to use buildd policy too
[08:09] <mvo> cprov: thanks, looks good
[08:11] <carlos> cprov: buildd policy?
[08:12] <cprov> carlos: instead of anything
[08:13] <carlos> ok
[08:13] <carlos> I need to go out for 15 minutes when I'm back I will try that
[08:13] <carlos> cprov: thank you very much!
[08:20] <ddaa> kiko: re product preload, I think it's just because this guy is bored. http://jarufe.monkey.cl/
[08:21] <kiko> that may be
[08:22] <ddaa> http://foros.tux.cl/viewtopic.php?p=11114&sid=e6af236771b13b61fb98ec83fef51e2e
[08:23] <ddaa> I think this guy needs a dating site more than launchpad.
[08:23] <cprov> carlos: when you get back, see this test prototype -> https://chinstrap.ubuntu.com/~dsilvers/paste/filefNbWHF.html, hope it does what you want
[08:24] <carlos> I'm back
[08:26] <carlos> cprov: that's more or less what I did. Thanks!
[08:26] <cprov> carlos: good, did you see that test .. have isolated you tarball.
[08:26] <cprov> carlos: how are you going to process it now ?
[08:27] <cprov> carlos: don't forget to abort the transaction when you finish you test (I forgot)
[08:27] <carlos> cprov: we have code in place for that
[08:28] <carlos> so it's a matter of checking the translation import queue to know if the import was done
[08:28] <cprov> carlos: I'm pushing my branch, you'll need it for a small fix in DRQ interface
[08:28] <carlos> ok
[08:29] <cprov> carlos: tricky, I'm curious to see how your things will work, maybe in the next conference ;)
[08:29] <carlos> cprov: it's easy, Kinnison did a hook on soyuz for translations, let me check where is it...
[08:29] <kiko> matsubara, how's it going?
[08:30] <cprov> DRQC.publish()
[08:30] <cprov> carlos: ^^
[08:31] <carlos> cprov: yes
[08:31] <carlos> cprov: publish_ROSETTA_TRANSLATIONS
[08:32] <cprov> carlos: the magic is in spr.attachTranslationFiles()
[08:32] <carlos> oh, you want those details?
[08:33] <carlos> then best for the next conference, or at least not today... I wan to finish this today and stop.
[08:33] <matsubara> kiko: wanna take a look of what I have so far?
[08:33] <cprov> carlos: sure, as I said, next conf ;)
[08:33] <kiko> matsubara, what are you working on?
[08:34] <cprov> carlos: let me know if you need any other help with upload-and-queue system
[08:35] <carlos> cprov: I don't think so, If this triggers Kinnison's hook, that's all I need. Next step is Rosetta specific
[08:35] <matsubara> kiko: that broken traversal on build problem, and trying to fix a portlet on binary package release page
[08:35] <carlos> cprov: thank you very much for your help
[08:35] <carlos> The test is passing now
[08:35] <carlos> It's time to test my Rosetta stuff ;-)
[08:35] <cprov> carlos: anytime
[08:38] <cprov> carlos: good luck !
[08:38] <ddaa> kiko: I think I construed a convincing scenario of what happened with "prelink", and came to an interesting conclusion.
[08:38] <carlos> thanks!
[08:38] <kiko> matsubara, the broken traversal thing should be trivial
[08:38] <matsubara> kiko: it's already fixed.
[08:39] <kiko> where's the patch
[08:41] <carlos> hmm
[08:41] <matsubara> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileADvMEg.html
[08:41] <carlos> cprov: I need some extra help. I cannot create the entry published as the hook is executed when we publish it
[08:42] <carlos> hmm
[08:42] <cprov> carlos: ?? again, I lost the track 
[08:42] <carlos> sorry
[08:42] <carlos> the source code is published
[08:42] <carlos> then, I upload a binary
[08:42] <carlos> and execute .process()
[08:43] <cprov> right
[08:43] <carlos> but the publish hook are not executed
[08:44] <cprov> carlos: wait you need to execute DRQ.publish()
[08:44] <cprov> carlos: in fact DRQC.publish()
[08:44] <SteveA> daf, matsubara: hi guys.
[08:45] <carlos> instead of NascentUpload.process() ?
[08:45] <matsubara> hi SteveA 
[08:45] <carlos> or before it?
[08:45] <SteveA> i have received a user-support request by email.  someone needs to sign the CoC in launchpad, but is having trouble doing so.
[08:45] <SteveA> i'll reply to the email, and cc matsubara and daf on it.  okay?
[08:45] <SteveA> you can sort out between you who will reply
[08:47] <cprov> carlos: no, that is right, leave it there, since you have upload an NEW bin to dapper you need to accept then the 'process-accepted' can publish it or by hand you can directly publish it 
[08:48] <cprov> carlos: I'm extending the test for you
[08:48] <carlos> ok
[08:50] <matsubara> SteveA: ok
[08:54] <cprov> carlos: add this before kill librarian 'queue_item.customfiles[0] .publish(MockLogger())'
[08:54] <cprov> carlos: spr.attachTranslationFiles() is broken
[08:54] <SteveA> thanks
[08:55] <carlos> cprov: that's the point for this ...
[08:55] <cprov> carlos: I see :)
[08:55] <carlos> cprov: from where could I get queue_item?
[08:55] <carlos> Oh, I have it already
[08:55] <carlos> sorry
[08:56] <cprov> carlos: yup
[08:57] <carlos> cprov:  ForbiddenAttribute: ('customfiles', <DistroReleaseQueue at 0x35989f0c>)
[08:58] <cprov> carlos: (17:28:11) cprov: carlos: I'm pushing my branch, you'll need it for a small fix in DRQ interface
[08:58] <cprov> carlos: you need my branch or fix it by hand in yours
[08:58] <carlos> oh
[08:58] <carlos> ok
[08:58] <carlos> that's the fix
[09:00] <AlinuxOS> carlos, buenas dias :)
[09:01] <AlinuxOS> when there will be Dapper in Rosetta ? :)
[09:01] <carlos> AlinuxOS: hola :-)
[09:01] <AlinuxOS> ;)
[09:25] <dsas> hi, there are two teams in launchpad that are seemingly the same team. One has the various members of the doc team as members, but no packages, the other has the tech board as a member but no-one else and owns the doc packages
[09:26] <dsas> The teams being ubuntu-doc and ubuntu-doc-lists, should the two teams be merged together?
[09:33] <Seveas> dsas, you'd better discuss that with the members of those teams
[09:35] <dsas> well Corey Burger of the docteam said it seems that it's likely, I'll ask someone from the tech board too.
[10:01] <dsas> Seveas: there's no need for a merge afterall, sorry.
[10:39] <luka74> Is Malone down? I get error: OOPS-44C718 when trying to submit bug 
[10:39] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/44C718
[10:39] <luka74> (or just clicking on "Choose..." for package)
[10:40] <matsubara> luka74: known problem, that is bug 30979. 
[10:40] <Ubugtu> malone bug 30979 in malone "Oops in popup to select a Ubuntu package" [Normal,Fix committed]  http://launchpad.net/bugs/30979
[10:41] <kiko> let me see
[10:41] <kiko> luka74, this should be fixed in production by tomorrow noon UTC
[10:42] <luka74> OK, actually on "Add" bug I get different code: OOPS-44D752.
[10:42] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/44D752
[10:42] <luka74> (I try to add bug to "linux-image" package)
[10:50] <sivang> Seveas: how does Ubugtu know where the traceback of an OOPS ?
[10:50] <Mez> godamn this annoying package thing
[10:51] <kiko> sivang, it just uses a hardcoded URL 
[10:51] <kiko> Mez, what's p?
[10:51] <Mez> Is there a simple way in malone to import a bug from debian's PTS
[10:51] <Mez> kiko: pacakge was the wrong word
[10:51] <Mez> I meant GPG sig thing
[10:51] <kiko> oh. 
[10:51] <Seveas> sivang, OOPS-(?P<oops>\d+[a-z] \d+) -> https:://chinstrap.ubuntu.com/~jamesh/oops.cgi? + match.group('oops')
[10:52] <kiko> I don't think debzilla has been ported yet.
[10:52] <Mez> kiko: damn - It's annoying cause am using malone as central bug tracking - want to bring in bug from debia n -have to make it myself then link
[10:53] <kiko> that's annoying, yeah. I need to check with mdz what the status is on debzilla, if he needs us to port it.
[10:53] <Mez> Seveas, I'm assuming the OOPS lookup is meant to be protected?
[10:54] <luka74> BTW: submit to "linux-686" package works - strange!
[10:54] <kiko> protected?
[10:54] <Mez> kiko: looking at https://chinstrap.ubuntu.com/~jamesh/oops.cgi asks me for username and password
[10:55] <kiko> chinstrap is private, yeah
[10:55] <kiko> we need to move this stuff elsewhere
[10:55] <kiko> reason it's private is just that it shares responsibility with other apps
[11:26] <kiko> Can somebody check out https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-13/D752 and file a bug as relevant?
[11:26] <kiko> BjornT or SteveA or mpt or someone?
[11:27] <kiko> gone!