=== dand [n=dand@dyn-85.186.137.18.tm.upcnet.ro]  has joined #launchpad
=== j-a-meinel [n=jameinel@adsl-75-51-62-134.dsl.chcgil.sbcglobal.net]  has left #launchpad [] 
=== dand [n=dand@gw.datagroup.ro]  has joined #launchpad
=== shawn___ [n=shawn@netblock-68-183-69-197.dslextreme.com]  has joined #launchpad
=== joejaxx is now known as SysAdministrator
=== SysAdministrator is now known as joejaxx
[12:57] <ddaa> I am once again confused by the launchpad security framework :(
=== rrittenhouse [n=tad@cpe-76-188-35-66.neo.res.rr.com]  has joined #launchpad
[01:01] <thumper> ddaa, whazzup?
[01:01] <ddaa> trying to implement the stuff with import timestamps
[01:01] <ddaa> but putting it in the launchpad content class, instead of in importd
[01:01] <ddaa> and it's like an uphill battle against launchpad stuff
[01:01] <ddaa> very frustrating :(
[01:03] <ddaa> all the more frustrating that importd completely bypasses the security framework, and all the launchpaddy stuff, and talks directly with the content class.
[01:03] <ddaa> But proper launchpad tests are not entitled to the same privileges
[01:03] <thumper> hmm.. I understand your frustrations
[01:03] <ddaa> I get a ForbiddenAttribute for the new attribute
=== mtaylor [n=mtaylor@206.173.9.2.ptr.us.xo.net]  has joined #launchpad
[01:03] <ddaa> and I've got no clue why
[01:05] <ddaa> ... maybe I forgot to set the layer...
=== jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl]  has joined #launchpad
[01:06] <jelmer> hi
[01:06] <jelmer> Anybody in here with access to pqm.ubuntu.com?
[01:07] <ddaa> the control panel is crashing
[01:07] <ddaa> it happens when there's a merge that makes it unhappy
[01:07] <jelmer> That's probably what happened
[01:07] <ddaa> it does not mean that pqm is broken
[01:07] <jelmer> I sent in my first merge request 5 minutes ago...
[01:08] <ddaa> it's just the display that's broken
[01:08] <jelmer> ah, ok
[01:08] <jelmer> ddaa: btw, I've fixed the utf8 issue in bzr-svn
[01:08] <ddaa> cool, tell me when you've fixed your branches
[01:08] <jelmer> Ok, will do
=== Keybuk [n=scott@quest.netsplit.com]  has joined #launchpad
[01:29] <ddaa> okay... this whole notion that a unit-test for a content class must go through the security framework is broken
[01:31] <jamesh> ddaa: check the zcml (productseries.zcml?)
[01:32] <ddaa> ah!
[01:32] <ddaa> actually it does not have to! I was just being confused
[01:33] <ddaa> jamesh: it's okay, I just assumed that because the test was in lib/canonical/launchpad/tests/ it was a victim to the importfascist
[01:33] <ddaa> Thus, loads of problems.
[01:33] <jamesh> ideally the tests should use the same environment as the code uses when it runs
[01:33] <ddaa> it does
[01:33] <jamesh> not doing so has been a source of bugs in the past
[01:34] <ddaa> importd just calls directly into the content class
[01:34] <ddaa> and anyway, I'm just trying to unit test a method of the content class
=== anandanbu [i=phoenix@59.92.112.143]  has joined #launchpad
=== anandanbu [i=phoenix@59.92.112.143]  has left #launchpad [] 
[02:09] <thumper> jamesh: ping
[02:32] <jamesh> thumper: pong
=== thumper on phone
[02:35] <thumper> jamesh: I was looking a bit more that the complete branch revision spec
[02:36] <thumper> and unfortunately the sql you specified doesn't exactly work, 
[02:36] <thumper> but that's ok
[02:36] <thumper> I like the idea
[02:36] <ddaa> jamesh: interesting factoid
[02:36] <ddaa>         assert UTC_NOW == None
[02:36] <ddaa>         assert UTC_NOW != None
[02:36] <ddaa> both are true...
[02:36] <jamesh> ddaa: as expected ...
[02:36] <jamesh> ddaa: both result in an SQLExpression
[02:36] <thumper> ddaa: try is None
[02:36] <ddaa> but self.assertEqual does ==, not "is"
[02:37] <ddaa> and NULL translates to None
[02:37] <ddaa> so self.assertEqual(series.datelastsynced, UTC_NOW) does not work
[02:37] <jamesh> >>> str(UTC_NOW == None)
[02:37] <jamesh> "(CURRENT_TIMESTAMP AT TIME ZONE 'UTC' IS NULL)"
[02:37] <jamesh> >>> str(UTC_NOW != None)
[02:37] <jamesh> "(CURRENT_TIMESTAMP AT TIME ZONE 'UTC' IS NOT NULL)"
[02:37] <thumper> jamesh: but if we can put off the feature until postgresql 8.3 then the "with recursive" sql join should be implemented
[02:38] <ddaa> jamesh: any clue how I can express "check this attribute is UTC_NOW"?
[02:38] <ddaa> mh... maybe str...
[02:39] <jamesh> ddaa: I'd suggest taking the value of datelastsynced beforehand, and then call obj.sync() afterwards and check that the value is different
[02:39] <jamesh> sync() will reget the field values from the database, expanding the UTC_NOW constant to an actual date value
[02:39] <thumper> jamesh: I prefer the adjacency model of tree storage, especially since the revisions will be in many different "trees", and that way, you keep a clean model
[02:39] <jamesh> thumper: how does this fit in with stub's work?
[02:40] <thumper> jamesh: I don't think it does, I grabbed his branch this morning but haven't looked at it
[02:40] <thumper> what he was doing was preorder tree storage
[02:40] <jamesh> thumper: the model I proposed was from before I knew of stub's dag word
[02:40] <jamesh> s/word/work/
[02:40] <thumper> however that works great for graphs that don't change much
[02:40] <thumper> and the model doesn't work too well for nodes that are in many trees
[02:41] <ddaa> jamesh: it would be a bit weaker than what the test wants to express... specifically it's "If import_branch.last_mirrored is None, importUpdated just sets datelastsynced to UTC_NOW."...
[02:41] <ddaa> it does not want to test that the method set the datelastsynced attribute to "something", but UTC_NOW
[02:41] <ddaa> wrapping the things in str() works
[02:42] <ddaa> it just needs a small comment
[02:42] <jamesh> ddaa: checking against the constant UTC_NOW is a bit fragile, since the field value will change on sync() or a commit
[02:42] <ddaa> self.assertEqual(str(series.datelastsynced), str(UTC_NOW))
[02:42] <ddaa> jamesh: from what you say, this should be robust
[02:43] <jamesh> thumper: well, in effect the Revision/RevisionParent tables form one big DAG ...
[02:43] <ddaa> AssertionError: 'None' != "CURRENT_TIMESTAMP AT TIME ZONE 'UTC'"
[02:43] <jamesh> that covers all the branches we know about
[02:43] <thumper> jamesh: yeah, but traversing that right now is a pita
[02:44] <thumper> I really think there should be a rev_id for the parent that is null if it's a ghost
[02:44] <thumper> simpler joins
[02:44] <jamesh> thumper: what I mean is: would it be possible to get the branch scanner to update a table using stub's layout
[02:44] <jamesh> and is that representation useful for the web UI
[02:45] <thumper> there is a function in the postgresql/contrib tablefunc.connectby
[02:46] <thumper> jamesh: the problem with the preorder traversal dag storage is that it works for *one* dag, not overlapping ones
[02:46] <thumper> others use forrests and add a forest id
[02:46] <jamesh> thumper: you mean that it doesn't really help if we want information about a subset of the dag?
[02:46] <thumper> which is effectively adding an extra row for each branch/revision
[02:46] <ddaa> thumper: I am not sure I get what you mean by "the revisions can be in many different trees", but the idea of the Revision and RevisionParent tables is that they represent the fraction of the _global_ database that the supermirro sees.
[02:46] <jamesh> we've got one dag
[02:46] <jamesh> and each branch is only concerned with a subset of that dag
[02:47] <thumper> jamesh: but our dag goes the wrong way :-)
[02:47] <ddaa> at least at the moment, if there is a ghost in only one branch, the dag stored in the database does not know about it
[02:48] <jamesh> thumper: really?
[02:48] <thumper> ddaa: we are discussing some work that is going on by stub to look at dag storage using preorder traversal trees
[02:48] <thumper> preorder tree traversal doesn't work if you have multiple roots, but that could be munged with a fake one
[02:48] <jamesh> thumper: you mean the fact that the subset is selected by the head of the tree, rather than the initial rev
[02:49] <thumper> jamesh: yes
[02:49] <ddaa> I understand that there's is some work in progress to allow easily finding all the branches associated to a revision and all the revisions associated to a branch without the need of an explicit branch-revision N-N table
[02:49] <thumper> ddaa: yep that's it
[02:49] <jamesh> thumper: can we get useful info if we start from the head rev and traverse backwards?
[02:50] <ddaa> thumper: I was pointing out that although the N-N table would have faithfully represented ghosts as found in branches, I do not think it is a design goal.
[02:50] <thumper> also inserting to the tree requires an update to all parents
[02:50] <thumper> to update left and right values
[02:51] <thumper> in order to get the simple insertion (which will be happening a lot with the branch scanner), you really want some form of adjacency model
[02:51] <thumper> which is what you jamesh originally suggested, and a "form" of it is in place now (but without explicit ids)
[02:52] <thumper> ddaa: yes the N-N model is not ideal
[02:52] <thumper> and something we want to avoid
[02:52] <ddaa> did you get what I said about "faithfully representing that A branch does not have those revisions" not being a design goal?
[02:53] <ddaa> as in "those revisions are ghosts in A branch but not in this other"
[02:53] <thumper> ddaa: too many negatives
[02:53] <ddaa> nevermind
[02:53] <ddaa> it's getting late here
[02:53] <thumper> ddaa: I think I understand what you mean
[02:53] <thumper> ddaa: no idea why you are still awake
[02:53] <thumper> sleep man!
[02:54] <ddaa> woke up late, went to the movies, have an urgent coding task
[02:54] <ddaa> but thanks to jamesh help, I'm now unstuck
[02:54] <ddaa> so, beddy time
[02:55] <thumper> I was looking at the lp bzr branch, and there are around 14000 revisions in the ancestry and 4300ish in the revision history
[02:55] <thumper> I'm also mildly concerned of any coded recursive searches to get the ancestry
[02:56] <jamesh> yep
[02:56] <thumper> even though the recursive depth to get the entire ancestry is likely to be < 20
[02:56] <jamesh> the latency'll kill you
[02:56] <thumper> all it takes though is one branch that had 50 or 100 revisions prior to being merged to kill it
[02:57] <thumper> there is the contrib function that aparently has much successful use by the wider community
[02:57] <thumper> ideally we'd have the "with recursive" sql statement (coming in 8.3)
[02:58] <thumper> I read an interesting article on "staircase join" being added to postgresql by some uni students
[02:58] <thumper> but it was never merged to mainline development
[02:58] <thumper> thereby effectively adding tree awareness to the db
[02:58] <thumper> effectively the same as "with recursive"
=== thumper back to thinking on email for branches
=== thumper off to collect daughter from school, bbs
=== quail_linux [n=quail@unaffiliated/quaillinux/x-000001]  has joined #launchpad
=== jimmythegeek [n=jimmythe@168.156.99.36]  has joined #launchpad
[03:11] <jimmythegeek> I'm having trouble editing the ubuntu documentation for Cacti.  I ran into a problem with the package and would like to share my findings.  Launchpad says I'm already logged in but ubuntu.com says to log in to edit
[03:17] <jimmythegeek> ah, never mind.
=== jimmythegeek [n=jimmythe@168.156.99.36]  has left #launchpad [] 
=== stub [n=stub@ppp-58.8.12.128.revip2.asianet.co.th]  has joined #launchpad
=== thumper [n=tim@166-179-30-77.jamamobile.co.nz]  has joined #launchpad
=== doko_ [n=doko@dslb-088-073-065-036.pools.arcor-ip.net]  has joined #launchpad
=== WebMaven [n=webmaven@ip72-193-220-34.lv.lv.cox.net]  has joined #launchpad
=== _thumper_ [n=tim@166-179-25-75.jamamobile.co.nz]  has joined #launchpad
=== _thumper_ is now known as eric-the-viking
=== eric-the-viking is now known as thumper
=== lifeless [n=robertc@ppp245-86.static.internode.on.net]  has joined #launchpad
[05:35] <Ubugtu> New bug: #62887 in linux-source-2.6.17 "Intel wireless 3945 not configured properly with Edgy Beta" [Undecided,Needs info]  http://launchpad.net/bugs/62887
[05:46] <Ubugtu> New bug: #73645 in linux-source-2.6.17 "Failure to detect Intel Pro/Wireless 3945 ABG" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73645
[06:01] <Ubugtu> New bug: #68658 in Ubuntu "Intel PRO/Wireless 3945ABG wifi card supported but not loaded by default" [Undecided,Needs info]  http://launchpad.net/bugs/68658
[06:19] <SteveA> thumper: stub said yesterday that he'd had some ideas about representing branch data in the database
[06:20] <thumper> hi SteveA
[06:20] <SteveA> morning
[06:20] <thumper> I had a look at the tree preorder storage stuff
[06:20] <thumper> and I'm not convinced
[06:21] <thumper> I have grabbed stub's branch, but haven't looked at it yet
[06:21] <SteveA> I don't know if these were new ideas not yet committed to code
[06:22] <SteveA> maybe arrange a voice call with stub sometime
[06:22] <thumper> sounds like a plan
[06:22] <thumper> I'm cooking dinner right now, I'll be back around in a few hours#
=== SteveA goes to try and get another hour or two of sleep before matt revell arrives
[08:07] <thumper> back
=== shawn___ [n=shawn@adsl-70-231-246-176.dsl.snfc21.sbcglobal.net]  has joined #launchpad
=== stu1 [n=stub@ppp-58.8.12.133.revip2.asianet.co.th]  has joined #launchpad
=== stu1 is now known as stub
=== mdke_ is now known as mdke
=== carlos [n=carlos@84.77.101.254]  has joined #launchpad
[09:05] <carlos> morning
[09:36] <mdke> can you guys delete release series?
[09:36] <mdke> if so please delete https://launchpad.net/products/ubuntu-doc/main (no idea why it exists)
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #launchpad
[09:41] <jamesh> mdke: there appear to be translation templates attached to that series
[09:41] <jamesh> and packaging links
=== owh [n=onno@59.154.24.148]  has joined #launchpad
[09:43] <owh> Greetings, just wondering what protocol is. I've been adding tags to a couple of bugs - that is, things that are related to ThinkPads - seeing that I have one of those and I figured I'd start helping out, but is there a set procedure that I should be aware of?
[09:43] <jamesh> owh: it's worth asking the developers of the product/distro in question when using a new tag
[09:44] <jamesh> owh: e.g. on #ubuntu-devel if you are tagging Ubuntu bugs
[09:45] <SteveA> morning!
[09:45] <SteveA> (again)
[09:45] <owh> jamesh: Well, the only "new tag" was one that was already in the overall list, vaio, which appeared new for pcmcia-cs, but not for the overall list if you know what I mean.
[09:45] <mdke> jamesh: please delete it anyway, if that's possible
[09:45] <mdke> not entirely sure how it is packaged in breezy amsn, but still
[09:45] <owh> jamesh: It was a bug to do with a thinkpad and a vaio machine, and I tagged it accordingly.
[09:45] <jamesh> mdke: file a ticket: https://answers.launchpad.net/products/launchpad/+tickets
[09:45] <mdke> jamesh: sure
[09:46] <owh> I figured that the point of the tag was so that you could find bugs across different packages etc, using a tag.
[09:46] <owh> is that correct?
[09:46] <jamesh> owh: if the tag name was already in use for Ubuntu, I'm sure they wouldn't mind you using it
[09:46] <jamesh> provided you use it consistently
[09:46] <jamesh> yeah
[09:47] <owh> So, will I be standing on anyone's toes if I keep "cleaning and pruning"?
[09:47] <SteveA> stub: about PG 8.2, do the client libraries stay the same?
[09:47] <owh> Or should I cease and desist?
[09:47] <jamesh> owh: best to ask on #ubuntu-devel
[09:47] <owh> Cool, will do. Tah.
[09:47] <jamesh> owh: or on one of the Ubuntu mailing lists
[09:48] <owh> Thanks for that jamesh.
[09:48] <stub> SteveA: I don't think they have broken the network protocol, so I think so. psycopg and old psql binaries should work fine. But this is why we test things first :)
=== seb128 [n=seb128@ANancy-151-1-36-79.w83-196.abo.wanadoo.fr]  has joined #launchpad
[10:00] <owh> jamesh: Is there anything I need to know about #ubuntu-devel, there's 187 people in the room, six folks talking and no-one paying any attention to me. Did I break an unwritten rule I don't know about?
=== elmo_ is now known as elmo
[10:11] <jamesh> owh: not sure.  Probably try asking again later
[10:11] <owh> Tah jamesh.
=== owh goes of to exercise patience :-)
=== doko_ is now known as doko
[10:13] <BjornT> owh: if it's about ubuntu bugs, you might want to try #ubuntu-bugs instead.
[10:13] <owh> Hmm, that's a fair suggestion BjornT.
[10:14] <jamesh> I didn't know #ubuntu-bugs existed
=== joachim-n [n=joachim@ACCFCB76.ipt.aol.com]  has joined #launchpad
=== danilo-out is now known as danilos
=== carlos_ [n=carlos@84.77.99.212]  has joined #launchpad
=== carlos_ is now known as carlos
[10:57] <BjornT> stub: staging seems really slow at the moment. is it doing anything special?
[11:00] <Ubugtu> New bug: #75585 in rosetta "po import notification tests refactoring to share more code" [Low,Confirmed]  http://launchpad.net/bugs/75585
=== matthewrevell [n=matthew@e190084.upc-e.chello.nl]  has joined #launchpad
=== WebMaven [n=webmaven@ip72-193-220-34.lv.lv.cox.net]  has joined #launchpad
[11:10] <Ubugtu> New bug: #68646 in language-pack-ru "Russian l11n in tsclient is broken" [High,In progress]  http://launchpad.net/bugs/68646
[11:19] <carlos> stub: ping
=== Keybuk [n=scott@quest.netsplit.com]  has joined #launchpad
[11:20] <stub> carlos: pong
[11:21] <carlos> stub: dude... I hate you.... you caused 7 conflicts in pagetests that I changed completely :-(
=== carlos cries ...
[11:21] <carlos> stub: The pillar URL change, will fail if I revert your pagetest changes?
[11:21] <stub> I've been having to do the reverse since last week keeping the branch alive ;)
[11:22] <stub> carlos: Probably - the old URLs are now redirects to the new URLs.
[11:22] <carlos> so browser.url will be different
[11:22] <carlos> ok
[11:22] <carlos> that's fine then
[11:22] <stub> Better to use your pagetest, and just trim any /distros/ or /products/ or /projects/ from your URLs
[11:22] <stub> And change /rosetta to /translations
[11:22] <carlos> ok
[11:23] <carlos> thanks for the hint
[11:23] <stub> Its all pretty mechanical
[11:32] <BjornT> stub: ping
[11:32] <stub> BjornT: pong
[11:33] <BjornT> stub: the Bugs page on staging causes a timeout. if you look at https://devpad.canonical.com/~jamesh/oops.cgi/2006-12-13/S8, could it be that an extra index is needed?
[11:40] <stub> BjornT: The slowest SQL statement takes less that 2.5 seconds. Time is spent rendering.
[11:42] <stub> BjornT: Probably because that query returns 30000 odd rows
[11:43] <BjornT> stub: hmm, right. i'll take a look at it, it should render only ten of the rows.
[11:44] <stub> No LIMIT or OFFSET is in that query
[11:53] <BjornT> stub: the thing is that i need 10 unique bugs, not 10 unique bugtasks, and it's not trivial to get that with the existing search methods.
=== salgado [n=salgado@200-171-140-32.dsl.telesp.net.br]  has joined #launchpad
[11:53] <BjornT> i guess i could do a quick hack and put a limit in there, and deal with it properly later, though.
[11:55] <stub> Sounds like you need to be selecting DISTINCT Bug.*, and then retrieving the bugtasks with a second query if you need that information.
[11:59] <BjornT> yeah. but given that this will block the planned rollout, i rather do as little as possible for now.
=== matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br]  has joined #launchpad
=== niemeyer [n=niemeyer@201.14.38.176]  has joined #launchpad
=== cprov-afk is now known as cprov
=== niemeyer [n=niemeyer@201.14.38.176]  has joined #launchpad
=== jinty [n=jinty@172.Red-83-36-43.dynamicIP.rima-tde.net]  has joined #launchpad
=== somerville32 [n=somervil@fctnnbsc15w-156034086016.nb.aliant.net]  has joined #launchpad
=== LarstiQ waits for stub to return
=== pschulz01 [n=paul@202.174.42.5]  has joined #launchpad
=== Seveas [n=seveas@ubuntu/member/seveas]  has joined #launchpad
[02:01] <Ubugtu> New bug: #75604 in launchpad "Marking products 'abandoned'" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75604
=== matthewrevell [n=matthew@e190084.upc-e.chello.nl]  has joined #launchpad
=== ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net]  has joined #launchpad
=== static [n=emurphy@194.18.118.70.cfl.res.rr.com]  has joined #launchpad
=== carlos -> lunch
[03:04] <salgado> cprov, you just reverted my changes to PendingReviews. :/
[03:05] <cprov> salgado: oops, sorry.
[03:05] <cprov> salgado: editmoin is faster ;)
[03:06] <salgado> if it was faster I'd have reverted yours
[03:08] <salgado> doesn't it warn you when somebody else is editing a page?
[03:08] <cprov> salgado: no
=== cprov is now known as cprov-lunch
=== static_ [n=emurphy@194.18.118.70.cfl.res.rr.com]  has joined #launchpad
[03:15] <cprov-lunch> kiko: can you have a look at #68675 ? who is responsible for PQM machine updates ?
[03:17] <kiko> cprov-lunch, I think it's the admins, so file an RT request?
=== flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca]  has joined #launchpad
[03:17] <kiko> also, carlos or you could fix that by simply putting some ellipsis in the test
[03:18] <kiko> but.. no big deal.
[03:18] <kiko> elmo, ping?
=== kiko is now known as kiko-fud
=== carlos [n=carlos@84.77.99.212]  has joined #launchpad
[03:25] <Ubugtu> New bug: #75615 in rosetta "f-spot doesn`t have po files" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75615
=== matsubara is now known as matsubara-lunch
=== cprov-lunch is now known as cprov
[03:57] <cprov> kiko-fud: nop, but IMO best thing to do should be installing the backported apt.
=== sabdf1 [n=sabdfl@217.205.109.249]  has joined #launchpad
[04:00] <carlos> cprov: if you are talking about the test error I reported
[04:00] <carlos> cprov: that will be required for every single server where we will run tests
[04:00] <cprov> carlos: I can't see any problem if they are dapper
[04:01] <carlos> cprov: sure, I'm just pointing it
=== quail_linux_ [n=quail@unaffiliated/quaillinux/x-000001]  has joined #launchpad
[04:01] <carlos> or stub will get crazy with test failures
[04:04] <cprov> carlos: yes, I agree that it could be tricky considering our complex infrastructure.
=== frafu [n=frafu@vodsl-10046.vo.lu]  has joined #launchpad
=== tonyyarusso [n=anthony@ubuntu/member/tonyyarusso]  has joined #launchpad
[04:15] <tonyyarusso> Heyo - not sure if this is possible to work around, but here's the deal:
[04:16] <tonyyarusso> The e-mail address I have associated currently with my LP account has a spam filter set to allow only users / domains in an allow list.  Since being added to Ubuntu Members, I was subscribed to a "bug" (the developers thanks one ;) ), and when people add comments to it, the e-mails show up as from their personal e-mails, not identifying as launchpad in any way, and so get caught.
[04:17] <tonyyarusso> Would it be possible for bug comments subscription e-mails to show up as from @launchpad.net so I could just allow that domain, or do you have any other suggestions?
=== aa_ [n=ali@pida/aa]  has joined #launchpad
[04:21] <aa_> hi, am I being blitheringly incompetent, but I can't add a new ssh key. Amazingly I already have added 2 keys and they are fine.
[04:22] <aa_> is it instant?
[04:22] <aa_> I mean is the key added isntantly?
=== frafu [n=frafu@vodsl-10046.vo.lu]  has left #launchpad [] 
[04:23] <salgado> aa_, yeah, it should be
[04:23] <salgado> do you get any errors?
[04:23] <aa_> just Permission denied (publickey).
[04:24] <aa_> and doing ssh -v it is definitely offering the key
[04:24] <carlos> tonyyarusso: I don't think that's possible, sorry
[04:24] <aa_> let me try again with my new knowledge that it is instant
[04:24] <carlos> tonyyarusso: could you filter also based on email headers?
[04:24] <tonyyarusso> carlos: Actually, hold that thought - I may have just answered my own question
[04:24] <carlos> ;-)
[04:25] <aa_> hm...how distressing
[04:25] <tonyyarusso> carlos: Adding bounces@canonical.com did it!  Sweet.
[04:25] <aa_> I guess I should check the key thaqt is imported into the bazaar
[04:26] <tonyyarusso> nvm me :)
[04:30] <Ubugtu> New bug: #75620 in launchpad "Unable to unsubscribe to bug assigned to team" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75620
[04:37] <aa_> any suggestions on what to do? I am just plain stuck unable to commit. I have checked the key is the same as the uploaded key, and that the key is being offered
[04:38] <aa_> should I be able to ssh bazaar.launchpad.net ?
[04:40] <flacoste> kiko-fud: daily reminder that SupportTrackerRenaming is waiting for your review :-)
=== j-a-meinel [n=jameinel@adsl-75-51-62-134.dsl.chcgil.sbcglobal.net]  has joined #launchpad
=== matsubara-lunch is now known as matsubara
=== danilos is now known as danilo-out
=== quail_linux_ [n=quail@unaffiliated/quaillinux/x-000001]  has joined #launchpad
=== carlos -> out
[05:08] <carlos> kiko-fud: you also owe me a review for translation form in read only mode ;-)
[05:08] <carlos> see you!
=== aa_ [n=ali@pida/aa]  has left #launchpad [] 
=== lbm [n=lbm@82.192.173.92]  has joined #launchpad
=== asw [n=asw@karuna.med.harvard.edu]  has joined #launchpad
=== kiko-fud is now known as kiko
=== frafu [n=frafu@vodsl-10046.vo.lu]  has joined #launchpad
=== jkakar [n=jkakar@204.174.36.228]  has joined #launchpad
=== sabdf1 is now known as sabdfl
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #launchpad
[06:00] <BenC> yo lp'ers
[06:01] <BenC> I have a special request. I will, within a week, need all active linux-source-2.6.19 bugs transfered to linux-source-2.6.20 with a little blurb saying "Please reconfirm this bug against 2.6.20, in feisty now"
[06:01] <BenC> would someone be willing to do this for me, roughly 60 bugs?
[06:06] <matsubara> BenC: you could mail stub to do a sql magic for you or ask the bugsquad team, how does that sound?
[06:06] <BenC> matsurba: Sounds great, thanks
[06:07] <BenC> rather prefer a sql change to avoid human error, and wasted energy
[06:09] <matsubara> nobody gets my name right :(
[06:09] <matsubara> anyway, just mail stub, cc launchpad and he'll probably help you out with that.
[06:09] <LarstiQ> matsubara: I do!
[06:10] <matsubara> LarstiQ: you probably cheated and used nick completion :P
[06:10] <LarstiQ> even without tabcompletion, it sounds too japanese to get wrong
[06:10] <BenC> matsubara: Sorry :)
[06:13] <matsubara> BenC: np. I'm getting used to it. I should change my name to foobara, that way developers won't ever type it wrong. :)
[06:13] <BenC> hehe
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #launchpad
[06:31] <kiko> cprov, can you give me the full diff in a pastebin?
[06:32] <cprov> kiko: let me check devpad first
[06:33] <kiko> oki
[06:33] <cprov> kiko: https://devpad.canonical.com/~jamesh/pending-reviews/cprov/launchpad/trivialities/full-diff is up to date
=== kiko looks
=== flacoste is now known as flacoste_lunch
=== ajmitch [n=ajmitch@port166-123.ubs.maxnet.net.nz]  has joined #launchpad
=== flacoste_lunch is now known as flacoste
=== Ubug2 [n=bugbot@ubuntu/bot/ubugtu]  has joined #launchpad
=== cprov is now known as cprov-out
=== WebMaven [n=webmaven@ip72-193-220-34.lv.lv.cox.net]  has joined #launchpad
=== quail_linux_ [n=quail@unaffiliated/quaillinux/x-000001]  has joined #launchpad
=== jamesh [n=james@203-59-208-48.dyn.iinet.net.au]  has joined #launchpad
=== jamesh [n=james@203-59-208-48.dyn.iinet.net.au]  has joined #launchpad
[08:43] <kiko> BjornT, was the fix for bug queries you landed ar r4324 what fixes https://devpad.canonical.com/~jamesh/oops.cgi/2006-12-12/S18 -- ?
[08:43] <kiko> s/ar /as /
[08:47] <sabdfl> salgado: cool timing to be working on those mails today :-)
[08:48] <salgado> sabdfl, indeed; I commented that with kiko a few minutes ago
[08:49] <kiko> sabdfl, mindreading? we're getting there
[08:49] <kiko> sabdfl, my random ubuntu bugs bounty is getting results!
=== matsubara is now known as matsubara-afk
=== thumper [n=tim@222.152.39.218]  has joined #launchpad
[09:30] <sabdfl> bounty?
=== Keybuk [n=scott@syndicate.netsplit.com]  has joined #launchpad
=== matsubara-afk is now known as matsubara
[09:54] <kiko> sabdfl, I've promised 10 DVDs to the group that nukes out all unconfirmed bugs with no packages assigned!
[09:54] <kiko> sabdfl, that's about 1200 bugs
[09:54] <kiko> well, /was/. apparently today it's 900 something
[09:55] <thumper> kiko, which DVDs?
[09:55] <kiko> thumper, 10 dvds of their choice
=== LarstiQ would go for 5 dapper, 4 edgy and 1 feisty dvd.
[09:55] <kiko> vf
[09:56] <kiko> think "gone with the wind"
[09:56] <thumper> kiko: monty python box set is 1 or 4?
[09:56] <kiko> thumper, 4
[10:05] <BjornT> kiko: no, r4324 fixes another oops (https://devpad.canonical.com/~jamesh/oops.cgi/2006-12-13/S8). i'll land a similar fix for this oops, though.
[10:05] <kiko> BjornT, is it the same sort of problem?
[10:06] <BjornT> kiko: yeah. i practically copied the code from the filebug one.
[10:07] <kiko> copying the code... hmmm. red flag! should this be refactored or fixed more widely, BjornT?
[10:08] <BjornT> the problem was that the code iterates through a large result set, thinking it should be cheap since it only iterates over about then items. but it seems that sqlobject listifies the result.
[10:08] <kiko> well, once you hit the resultset, that's it
[10:08] <kiko> it is materialized
[10:09] <BjornT> kiko: it should probably be refactored, yes. but i don't think it's a problem that can be fixed more widely.
[10:09] <kiko> BjornT, hmmm, right
[10:10] <kiko> BjornT, what you would need to do is always provide a limit for how many rows you'd want to query
[10:10] <kiko> we could forseeably limit all our queries 
[10:10] <kiko> mmmmm
[10:11] <BjornT> kiko: yeah, my quick fix was to only fetch 4 times as many results that i want to return. i'll fix it properly later by adding a method to IBugSet that queries the Bug table directly, instead of going through BugTask as it's done today.
[10:12] <kiko> will you need to do bookeeping manually -- i.e. omit dupes, for instance?
[10:12] <BjornT> what do you mean?
[10:13] <kiko> BjornT, well, BugTaskSet.search() helps you by setting things up so the query is "right"
[10:13] <kiko> for instance, dupes are omitted by default
[10:14] <kiko> will you have to do a manual query in this place?
[10:14] <kiko> I also am curious as to how you will be able to do this query directly on Bug if you want to filter by product/distro.
[10:16] <BjornT> kiko: well, yes. but for the most duplicated bugs case, by definition duplicate bugs will be omitted.
[10:16] <kiko> right
[10:17] <BjornT> kiko: right. i haven't thought through have to limit on BugTask attributes efficiently yet. that might be a problem, i'll ask stub or someone about it when i do it.
[10:18] <kiko> have to limit -- or how to limit?
[10:18] <BjornT> might have to query the BugTask table first to get all the bug ids, then fetch the Bug instances.
[10:19] <BjornT> then it should be possible to re-use code from BugTaskSet even
[10:20] <kiko> yes
[10:20] <kiko> there could definitely be an option to do that.
[10:20] <kiko> it might be weird to have bugtaskset return bugs/bug ids though
[10:21] <BjornT> kiko: i was mostly thinking of refactoring out the code that generates the sql queries.
[10:22] <kiko> that would be a possibility too
[10:22] <kiko> but public API for that? 
=== kiko shudders
[10:22] <BjornT> yeah, i know...
=== cprov-out is now known as cprov
=== asw [n=asw@karuna.med.harvard.edu]  has joined #launchpad
=== kiko is now known as kiko-afk
=== aa_ [n=ali@pida/aa]  has joined #launchpad
=== matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br]  has joined #launchpad
=== somerville32 [n=somervil@fctnnbsc15w-156034086016.nb.aliant.net]  has joined #launchpad
=== sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl]  has joined #launchpad
=== belito [n=user@201.240.250.48]  has joined #launchpad
=== mtaylor [n=mtaylor@206.173.9.2.ptr.us.xo.net]  has joined #launchpad
=== jml [n=jml@220-253-139-252.TAS.netspace.net.au]  has joined #launchpad
=== rrittenhouse [n=tad@cpe-76-188-35-66.neo.res.rr.com]  has joined #launchpad
[12:04] <radix> hmm, it took me a while to figure out how to find a bug I filed that was marked as a duplicate (or the bug which it duplicated)
[12:04] <radix> because the "bugs I'm subscribed to" doesn't show *either*
[12:04] <radix> is that a bug I should file against launchpad?
=== asw [n=asw@karuna.med.harvard.edu]  has joined #launchpad
[12:15] <mtaylor> on the Register a new release page, it mentions adding a URL but there is no place to add a url.