[12:25] <lifeless> Kinnison: has stub run the transaction on staging for you yet ?
[12:54] <cprov> lifeless: not yet, AFAIK. Could you try that ? kiko have some arguments against it, though
[12:55] <mdz> gah, I wanted to talk to cprov
[12:55] <kiko> gah
[12:55] <mdz> now he gets a bug report instea
[12:55] <mdz> d
[12:55] <kiko> well
[12:55] <kiko> not against it though
[12:57] <mdz> kiko: against what?
[12:58] <mdz> bug 52595
[12:58] <Ubugtu> Malone bug 52595 in soyuz "Unable to fetch dist-upgrader from queue" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52595
[12:59] <kiko> Kinnison's SQL query
[01:01] <mdz> kiko: I don't see that file on drescher so I assume it's in the librarian.  would it be possible to get a copy of it?
[01:02] <kiko> mdz, hmm, probably, but I don't actually know how
[01:07] <kiko> mdz, cprov will be back from home soon enough, though.
[05:00] <mpt> Goooooooooooooooood afternoon Launchpadders!
[06:01] <jamesh> hmm
[06:01] <jamesh> if I add an attachment as the first message in an LP bug it doesn't show up in the main body of the page: only the portlet
[06:04] <mpt> By "as the first message" do you mean the description, or the first comment?
[06:05] <jamesh> first comment
[06:05] <jamesh> which happens to contain the same text as the description so is not displayed
[06:07] <jamesh> (I've also got basic SF tracker import going, btw)
[06:42] <mpt> jamesh, so let me get this straight
[06:42] <mpt> someone reported a bug
[06:42] <mpt> then you added a comment that was identical to the initial report, except with an attachment added?
[06:43] <jamesh> mpt: no.  This is with the SF.net importer I'm writing
[06:44] <mpt> oh
[06:44] <mpt> So sf.net allows bug reports that include an attachment in the description
[06:44] <jamesh> mpt: I imported a bug from SF.net where the initial comment also added an attachment
[06:44] <mpt> whereas Malone doesn't expect that
[06:44] <mpt> I see
[06:44] <jamesh> not quite
[06:44] <jamesh> a malone bug has a list of messages attached to it which are the comments
[06:45] <jamesh> if the bug description text matches the first message's text exactly, then that message is not displayed on the bug page
[06:45] <jamesh> (this is what leads to the apparent comment duplication when you edit the bug description)
[06:45] <mpt> yes.
[06:46] <jamesh> attachments hang off the messages, and I hung attachment off the first message
[06:58] <jamesh> mpt: I wonder if a better heuristic would be to only show the bug description if it differs from the first message
[06:58] <jamesh> rather than only show the first message if it differs from the description
[06:58] <jamesh> ?
[07:00] <spiv> jamesh: that sounds better to me
[08:48] <SteveA> morning
[08:51] <jamesh> hi SteveA 
[08:51] <SteveA> morning james
[08:51] <SteveA> I see you made some progress on the SF import stuff for python
[08:51] <jamesh> yeah
[08:52] <SteveA> awesome
[08:52] <jamesh> I guess we'll be able to put our name on the competition page soon
[08:53] <spiv> SteveA: hello
[08:56] <SteveA> hi spiv
[08:56] <SteveA> jamesh: yep.  as soon as we have the test server up with email, and the data imported
[08:57] <jamesh> SteveA: so far, the import code doesn't have any special casing for python, so should be usable if other SF-using projects want to make the switch.
[09:00] <SteveA> excellent!
[09:00] <SteveA> jamesh: did you report the ekiga crash bug?
[09:07] <carlos> morning
[09:14] <SteveA> hi carlos
[09:15] <jamesh> SteveA: I haven't.  didn't really have much info for a crash report
[09:15] <SteveA> ok.  I guess you'll change the ulimit for core dumps when we have the next call
[09:16] <jamesh> or run ekiga under gdb from the start
[09:16] <jamesh> although I am tempted to just use shtoom
[09:17] <spiv> I can't make shtoom work for some reason.
[09:18] <spiv> It says "received packet with unknown PT 1" if I try any of Canonical addresses.
[09:19] <spiv> The fwd.pulver.com echo test rings, but then hangs up immediately, maybe due to not finding common codecs?
[09:19] <SteveA> things should all use GSM as a minimum
[09:20] <spiv> The debugging from shtoom isn't hugely informative, despite being rather verbose.
[09:21] <SteveA> hassle anthony :-)
[09:21] <SteveA> tell him you want to switch from ekiga and he'll help :-p
[09:21] <spiv> Hehe.
[09:27] <spiv> Well, building pygsm didn't make any difference, so it's probably not codecs.
[09:31] <jamesh> just tried shtoom to voip.canonical.com myself and get the same error as spiv
[09:33] <spiv> Well, it's not just me then :)
[09:34] <spiv> shtoom claims to have been tested with asterisk.
[09:45] <spiv> SteveA: can I have a pre-impl call with you about bug 49991
[09:45] <Ubugtu> Malone bug 49991 in launchpad-bazaar "browse supermirror branches with bzr server" [High,Confirmed]  http://launchpad.net/bugs/49991
[09:48] <SteveA> spiv: sure.  i'd prefer it to be in a while, as there will be loud vacuuming happening here soon
[09:48] <spiv> SteveA: Fair enough.  I'll occupy myself with other things...
[10:20] <jordi> carlos: oi
[10:20] <carlos> jordi: hi
[10:25] <jordi> carlos?
[10:47] <SteveA> jamesh: I don't see the zope specs on staging any more :-(
[11:09] <jamesh> SteveA: I guess staging got updated then
[11:11] <jamesh> SteveA: should be back soon
[11:11] <SteveA> ok, cool
[11:15] <jamesh> done.
[11:20] <SteveA> spiv: ping
[11:21] <SteveA> jamesh: what do you think about doing a daily cron job on staging to update the specs sometime after the database update?
[11:25] <jamesh> SteveA: probably a good idea.  Do you know what time would be good?
[11:26] <SteveA> I don't.  Stu would
[11:26] <jamesh> I'll ask him when he's around aain
[11:29] <spiv> SteveA: pong
[11:30] <SteveA> hi spiv 
[11:30] <SteveA> call?
[11:30] <spiv> That'd be good.  What protocol? :)
[11:31] <SteveA> let's try the canonical spi
[11:31] <SteveA> um sip
[11:32] <spiv> Ok.
[11:33] <spiv> I just got the machine-gun fire.
[11:33] <SteveA> oh poo
[11:34] <SteveA> say something
[11:34] <SteveA> i heard you
[11:34] <SteveA> elmo: ping
[11:34] <SteveA> maybe elmo can debug this half conversation...
[11:35] <SteveA> let's try again
[11:35] <SteveA> i'll call you this time
[11:35] <spiv> I'm ready, I think.
[11:37] <SteveA> how did you change the codec?
[11:37] <spiv> I didn't.
[11:37] <spiv> I haven't changed those settings at all, though I have looked at them.
[11:37] <SteveA> found it
[11:38] <spiv> I get the impression that the louder sounds you make come through fine, it's the quiet ones that get turned into an alien clicking at me while underwater.
[11:39] <spiv> But as I can't hear the sounds that get mangled, that's just guesswork :)
[11:39] <SteveA> ok, i'm using pcmu now
[11:39] <SteveA> i had to totally disable gsm
[11:40] <spiv> It's wierd how first time it said GSM for both In and Out, and the second time, when you called me, it was PCMU.
[11:41] <spiv> I hear nothing.
[11:41] <SteveA> seems to be hung
[11:42] <SteveA> your voicemail
[11:43] <spiv> I apparently have 2 voice mails.  I'll get getting them...
[11:43] <SteveA> no
[11:43] <SteveA> don't
[11:43] <SteveA> they are stupid
[11:43] <spiv> Heh, ok.
[11:43] <SteveA> they are stupid things where i hung up before leaving a message
[11:43] <SteveA> it is a lame voicemail system
[11:43] <SteveA> it just made me leave anothe rvoicemail
[11:43] <SteveA> try calling me
[11:43] <spiv> Ok.
[11:45] <SteveA> change to pcmu
[11:45] <spiv> Ok.
[11:45] <SteveA> to do that, go into prefs
[11:45] <SteveA> disable gsm
[11:45] <stub> spiv: I assigned you as implementer of https://launchpad.net/products/launchpad/+spec/stop-spurious-test-failures
[11:45] <SteveA> move pcmu up
[11:45] <spiv> stub: ta
[11:46] <spiv> No good?
[11:46] <SteveA> try again
[11:46] <spiv> Ok
[11:46] <SteveA> my audio module thing crashed
[11:48] <spiv> Very odd.
[11:48] <SteveA> this is bollocks
[11:48] <SteveA> let's use skype
[11:48] <spiv> Ok.
[11:54] <iwj> Is there some way someone with magic access to LP could help me out with unsubscribing from 34112 ?
[11:54] <iwj> I'm "also notified" and it has about twenty duplicates.
[11:54] <spiv> SteveA: http://goffredo-baroncelli.homelinux.net/bazaar
[12:07] <spiv> Oh, you dropped off?
[12:07] <SteveA> yes
[12:08] <spiv> I don't notice immediately because there's no machine gun fire.
[12:08] <SteveA> i made the mistake of briefly suspending the skype process
[12:09] <Kinnison> iwj: of the 1004 bugs you have a subscription record for, none are 34112
[12:16] <spiv> Hmm, gone again.
[12:16] <SteveA> yes
[12:16] <SteveA> me again
[12:16] <spiv> Got an itchy trigger finger?
[12:16] <SteveA> this time, i tried to switch to desktop 2
[12:16] <SteveA> and turned off my wireless for 1 second instead
[12:16] <SteveA> and this confused skype
[12:16] <spiv> Ah.
[12:16] <spiv> Why must all software be crap? :)
[12:17] <iwj> Kinnison: That's nice.  But I'm getting mail for 34112.
[12:17] <Kinnison> iwj: you must be subscribed to one of its duplicates or something
[12:17] <iwj> Yes.  As I say it has about twenty.
[12:18] <SteveA> ian is in the "also notified" list
[12:18] <Kinnison> SteveA: unfortunately nothing in the UI makes it clear what that is composed of and why he's there
[12:18] <iwj> Since the UI doesn't provide a way for me to find out where that's coming from I was wondering if someone with DB access could run a quick query.
[12:18] <iwj> To save me visiting twenty different bug pages (and perhaps sub-pages).
[12:22] <SteveA> i just visited the pages
[12:23] <SteveA> and i didn't see you listed as a direct subscriber on any of them
[12:26] <iwj> I'm probably the contact for some package that one of the dupes has a task for.
[12:26] <SteveA> that list should have link titles
[12:26] <SteveA> that say where the subscription comes from
[12:26] <iwj> Indeed.  I filed a bug about that :-).
[12:27] <iwj> The only reason I'm chasing 34112 specifically is because it generates lots of junk.
[12:28] <ddaa> jamesh: lifeless: feedback welcome on https://launchpad.net/products/launchpad-bazaar/+spec/vcs-imports-knits-upgrade
[12:36] <Chawnskie> Hi All.
[12:40] <Chawnskie> I've reproduced bug 48556: Installing 6.06 on an ASUS s96j laptop w/ Intel 945PM chipset.
[12:40] <Ubugtu> Malone bug 48556 in linux-source-2.6.15 "ACPI-0517: ****Error Method parse/execudion failed" [Critical,Fix committed]  http://launchpad.net/bugs/48556
[12:40] <Chawnskie> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/48556
[12:40] <Ubugtu> Malone bug 48556 in linux-source-2.6.15 "ACPI-0517: ****Error Method parse/execudion failed" [Critical,Fix committed]  
[12:42] <Chawnskie> Does anybody know of a snapshot build with a fix?
[12:45] <SteveA> hi
[12:45] <SteveA> that sounds like something for #ubuntu
[12:45] <SteveA> rather than #launchpad
[12:46] <Chawnskie> SteveA:  Hi.
[12:46] <Chawnskie> I tried there first, but it's a bit of a mess and got no response.  :-/
[12:47] <SteveA> here, we only care about bugs in the launchpad service
[12:47] <SteveA> not about bugs in linux or ubuntu
[12:47] <Chawnskie> Ahh, sorry.  I'll go wait for it to calm down in #ubuntu and then ask again :-)
[12:54] <ddaa> Chawnskie: when #ubuntu is calm, that usually means your connection has dropped :)
[01:00] <Chawnskie> :-)  Cheers.
[01:13] <carlos> stub: hi, around?
[01:16] <stub> carlos: yes
[01:17] <carlos> stub: How could I represent something like:
[01:17] <carlos> SELECT pofile.id | NULL AS pofile .....
[01:17] <carlos> stub: that means that pofile would be NULL
[01:17] <carlos> and I want to return NULL in that case
[01:19] <stub> I don't understand sorry.
[01:19] <stub> If pofile.id is 24, what should be selected? If pofile.id is NULL, what should be selected?
[01:20] <carlos> say that I have a OUTER JOIN that joins two tables and that we could have one of those tables join without value
[01:20] <carlos> in that case, a pofile row would not exist
[01:20] <carlos> and thus, pofile.id is not valid because there is not such row
[01:21] <stub> pofile.id would be NULL in that case
[01:21] <stub> The row exists, it just contains nothing but NULLs
[01:21] <carlos> I see
[01:21] <carlos> stub: ok, thanks
[01:42] <carlos> daniloo: hi
[01:43] <carlos> daniloo: do you have a new nick every day? ;-)
[01:49] <daniloo> carlos: no, just the irc connection died
[01:50] <carlos> oh, I didn't see you were connected as danilos ;-)
[01:51] <danilos> it's crap there is already one danilo on freenode :)
[01:56] <carlos> danilos: yeah, I got 'carlos' because previous owner stop using it for 3 months
[01:57] <carlos> perhaps is the same case here ;-)
[01:57] <carlos> danilos: btw, did you get my email with the source code link and bug links?
[01:58] <danilos> carlos: yup, but you naturally didn't get my response :)
[01:59] <danilos> lp is huuugeee :)
[02:01] <carlos> danilos: right, I didn't get it
[02:01] <carlos> danilos: yeah, but you don't need to touch the whole tree ;-)
[02:02] <carlos> danilos: I could guide with your fix bug fix
[02:02] <carlos> so you know more or less the layout we are using
[02:03] <danilos> carlos: sure, but I first need to get it, and it takes a while at 256kbps :)
[02:03] <danilos> I'll probably make a lunch break while it downloads
[02:04] <carlos> sure
[03:20] <stub> I got distracted and missed todays rollout. Anyone going to cry if I put it off until tomorrow quiet time?
[03:36] <salgado> stub, would it be possible to do the roll out before running the shipit export script?
[03:37] <stub> I'll turn off the shipit export and run it after the rollout. It will just run a few hours later than normal.
[03:40] <SteveA> re
[03:45] <jamesh> SteveA: I was looking at modifying the security policy in webapp/authorization.py to allow calling sync/syncUpdate on SQLBase instances, but I'm not usre whether that is the right place
[03:46] <jamesh> SteveA: the checkPermission() method in that file doesn't seem to be the right level, and isn't called when accessing attributes not covered by the security declarations
[03:47] <SteveA> ah, of course
[03:47] <SteveA> I had forgotten about that
[03:48] <jamesh> it just gets a permission name and an object, rather than an object + an attribute name
[03:48] <SteveA> so, a simpler thing would be
[03:48] <SteveA> to register those names as allowed at the level of the checker
[03:49] <SteveA> which is all getting rather complicated
[03:49] <SteveA> so I think go for the function that unwraps the instance, and calls syncUpdate() on it
[03:49] <SteveA> that is simple to understand
[03:49] <jamesh> fair enough.
[03:49] <SteveA> and will continue to work whatever we do
[03:56] <digistones> hello everyone
[04:02] <spiv> SteveA: elmo solved my ekiga problem.  Apparently "silence detection" actually means "make the other person sound like a drowning alien insect".
[04:05] <salgado> is it a known problem that the "E-mail me about changes to this bug report" checkbox you see when commenting on a bug is not working anymore?
[04:08] <salgado> bradb, the "E-mail me about changes to this bug report" checkbox you see when commenting on a bug doesn't seem to work anymore. have you noticed that?
[04:09] <salgado> I mean, is there a bug open already?
[04:10] <bradb> salgado: By "doesn't work" do you mean you check it but don't get subscribed to the bug?
[04:10] <salgado> exactly
[04:10] <bradb> salgado: In production?
[04:10] <salgado> bradb, in production and in one of my local branches
[04:11] <ddaa> where can I find documentation/examples to write testbrowser-based pagetests?
[04:11] <SteveA> spiv: ah.  i didn't have that turned on
[04:12] <matsubara> ddaa: lib/zope/testbrowser/README.txt
[04:12] <ddaa> matsubara: thanks
[04:12] <SteveA> ddaa: but note also that we have some standard 'browser' instances ready for you to use
[04:12] <SteveA> logged in and ready
[04:12] <bradb> salgado: Looking into it now.
[04:13] <ddaa> SteveA: where can I find them?
[04:13] <salgado> bradb, cool, thanks
[04:14] <matsubara> ddaa: https://launchpad.canonical.com/PageTests
[04:14] <ddaa> matsubara: thanks lot
[04:15] <matsubara> ddaa: np
[04:23] <bradb> salgado: I just sync'd to rf, and it worked for me in both the status edit form, and the comment form at the bottom of the bug page. Can you reproduce it on current rf?
[04:24] <salgado> bradb, just tried on staging and it worked fine. sorry for the noise
[04:25] <bradb> cool
[04:59] <kiko> bradb, remind me of one thing
[04:59] <kiko> bradb: did you by any chance make bugattachment's message column nullable?
[04:59] <kiko> say no 
[04:59] <bradb> kiko: nope
[05:00] <bradb> i just made it possible to attach a file without filling in the comment
[05:00] <bradb> the attachment is still associated to a message though
[05:04] <jamesh> bradb: what do you think of changing the bug page template to hide the bug description if it is equal to the first comment, rather than hiding the first comment?
[05:15] <bradb> jamesh: I'd prefer neither, tbh. The right way to do that, IMHO, is to never show the description as a comment
[05:17] <jamesh> bradb: the problem I ran into is importing bugs that have an attachment on the first comment, which doesn't show up if first comment == description
[05:19] <bradb> jamesh: Can you just show the attachments of the first comment under the description?
[05:19] <jamesh> bradb: I suppose so.  we'd want to not show them in the case where first comment != description though
[05:19] <jamesh> bradb: it seems simpler to only show description if it differs from the first comment though
[05:20] <bradb> jamesh: Simpler to implement, I agree.
[05:20] <bradb> But it's hard to explain why a bug doesn't have a description.
[05:20] <bradb> And then suddenly does.
[05:21] <jamesh> people also get confused why a new comment suddenly appears if they edit the description
[05:21] <bradb> jamesh: Yep, bug 5935
[05:21] <Ubugtu> Malone bug 5935 in malone "bug description seems duplicated" [Medium,Confirmed]  http://launchpad.net/bugs/5935
[05:21] <jamesh> I'd think "description doesn't display til you edit it" is easier to understand than "first comment doesn't display til you edit the description"
[05:21] <bradb> I wrote about a solution to this problem to launchpad@, I think it was.
[05:22] <jamesh> anyway, it is mostly a cosmetic issue
[05:22] <bradb> i.e. "This bug report has been modified since it was originally reported. _View the original report_.
[05:22] <bradb> "
[05:22] <jamesh> the attachment is still available in the portlet (assuming the user notices it ...)
[05:22] <salgado> SteveA, have a minute to chat about a shipit problem reported by marilize?
[05:23] <SteveA> salgado: I will in 10-15 mins
[05:23] <salgado> SteveA, cool. should I ping you again later, then?
[05:23] <bradb> jamesh: I think that when we implement KeepingBugsConcise (which is basically just collapsing the original description if the description is updated), this will seem a lot more obvious.
[05:23] <SteveA> salgado: ok
[05:24] <bradb> it can probably be implemented pretty quickly too
[05:25] <bradb> i think i'll try doing that after i do the landscape hack today
[05:26] <jamesh> bradb: for the SF import, would it be easy to move milestones around afterwards if I create them on the wrong product series?
[05:26] <jamesh> (or if we later add new series that would be better homes for those milestones)
[05:31] <bradb> jamesh: I think it should be a simple db update. Just confirming something...
[05:32] <jamesh> bradb: if it is, then I'll finish the milestone import code.  That'd be everything except converting categories to keywords
[05:33] <jamesh> which would probably provide a decent first import once we've got the testing LP instance set up
[05:37] <bradb> jamesh: Sweet! Yeah, I think it's easy to move ms's around with a simple UPDATE.
[05:41] <salgado> SteveA?
[05:42] <SteveA> salgado: hi
[05:42] <SteveA> can we talk on ekiga?
[05:43] <salgado> sure
[05:43] <salgado> but I just realized ekiga threw away my config
[05:43] <salgado> will have to do it again
[05:55] <SteveA> I just saw some code pass by in the review list like:
[05:55] <SteveA>   comments = sorted(comments.values(), key=lambda x: x.index)
[05:55] <SteveA> please, don't use "x"
[05:56] <SteveA> because "x.index" is meaningless
[05:56] <SteveA> unless you're marie curie
[05:56] <SteveA> call it "comment.index" or something
[05:56] <ddaa> foobar.index
[05:56] <SteveA> yeah... then we'd all go into hospital
[05:57] <SteveA> for diagnosis using foobar rays
[05:57] <spiv> Isn't that a place to use operator.attrgetter?
[05:57] <SteveA> well spotted spiv
[05:57] <spiv> Which avoids the 'x' problem entirely, but not naming anything ;)
[05:57] <malcc> SteveA: I don't generally disagree that variable names should mean something, but here the need to use a variable name at all in this bit of python syntax chicken-sprinkling is just an artifact, that's just how you spell "sort on index"
[05:58] <SteveA> malcc: pythons can eat chickens whole.
[05:58] <ddaa> duh, I've been writing a vcs-imports-test-plan for almost two hours
[05:58] <ddaa> it's making progress, but it's starting to make me want to cry
[05:58] <bradb> I'm so hungry I'll die if I don't go to Subway right now.
[05:58] <spiv> malcc: so use operator.attrgetter and be happy :)
[05:58] <SteveA> but in any case, someone can read:    key=lambda comment: comment.index   and understand it immediately
[05:59] <SteveA> but this needs you to look at more context:   key=lambda x: x.index
[05:59] <spiv> malcc: but I find that if I can't give a meaningful name to something, there's a problem, and if I can, then there's no good reason not to.
[05:59] <SteveA> when I read that, I ask myself "what is .index being got from?"
[06:00] <SteveA> the answer is "x", so I need to read other code to answer "what is x here?"
[06:00] <ddaa> I started being very detailed (almost pseudocode), but now I'm being force to be higher level, and even then I cannot find a reasonable way to specify satisfying code coverage...
[06:00] <spiv> I agree with Steve.  The less context required to comprehend a piece of code, the better.  That principle applies at many scales: expressions, statements, functions, modules.
[06:00] <SteveA> if it says "comment", I don't need to ask that question.  clearer code.
[06:00] <SteveA> at what cost?
[06:00] <SteveA> the cost of a few characters of typing
[06:00] <SteveA> and arguably reduced maintenance, increased clarity for all readers in the future
[06:01] <SteveA> I, for one, welcome our new python-eating chicken overlords.
[06:01] <ddaa> it is my experience that any loophole in that stuff will turn into a bug when implement by someone who do not really understand it, but functional tests cannot be reasonably exhaustive without going combinatorial...
[06:02] <SteveA> ddaa: get 75% of the way there, and then talk it over with a reviewer
[06:02] <SteveA> salgado: what's up?
[06:02] <spiv> Talking it over with another person might help you find a better way to express the requiresments.
[06:02] <spiv> requirements, rather.
[06:02] <ddaa> I'll post it to launchpad@ when I think I have vaguely touched all the important points...
[06:03] <SteveA> ddaa: call a reviewer for a chat before then
[06:03] <SteveA> otherwise you may well get caught in the perfectionist trap again
[06:04] <LarstiQ> SteveA: and the code is a bit less general, but not a problem for this lambda
[06:04] <SteveA> if the code were more general, it should become a function, with a docstring explaining the general case
[06:04] <SteveA> one reason a small lambda is okay is because it is so simple it is self-documenting
[06:05] <SteveA> general-purpose lambdas I find scary
[06:06] <ddaa> jamesh: BjornT: somebody up for a call? Need a reviewer to keep me sane.
[06:11] <salgado> SteveA, one of the server's disks stopped here, sorry
[06:18] <kiko> salgado, I need to kick the server once again though
[06:30] <mdz> cprov-lunch: if a build goes into dep-wait because, e.g. it is in main and build-depends on a package in universe, will the dep-wait be automatically cleared when the package moves to main?
[07:02] <cprov> mdz: dep-wait auto retry doesn't depend on component, AFAIK. It will be retried next queue-builder run if the package is published. What build ?
[07:23] <mdz> cprov: https://launchpad.net/distros/ubuntu/+source/gnome-python-desktop/2.15.4-0ubuntu1
[07:24] <ruffneck> nice ;)
[07:25] <mdz> cprov: I fixed the overrides for libgnome-media-dev, but I want to know if I need to do anything further for the bulid to be retried
[07:26] <cprov> mdz: it will be handled next queue-builder run, after the current cron.daily
[07:26] <ruffneck> cool
[07:26] <mdz> cprov: ok, thanks
[07:26] <ruffneck> I tried the ubuntu libux live CD
[07:26] <cprov> mdz: if libgnome-media-dev is published it will retry the build
[07:27] <mdz> cprov: and moving between components qualifies as being republished?
[07:28] <ruffneck> sick
[07:33] <cprov> mdz: something is wrong, libgnome-media-dev  was published in universe at 2006-07-11 09:08:05 BRT, your dep-wait build finished at 2006-07-11 14:09:40 BRT, it should have found the dep
[07:38] <cprov> mdz: I will wait this next queue-builder run, if it doesn't rescue the build in question I'll do it manually and investigate the bug in our code
[07:38] <mdz> cprov: s/universe/main/ ?
[07:38] <mdz> cprov: the issue is that libgnome-media-dev is in universe, while gnome-python-desktop (which build-deps on it) is in main
[07:38] <cprov> mdz: no, the first pub was in universe/gnome
[07:39] <mdz> cprov: see above
[07:39] <mdz> this is the question I was asking in the first place
[07:39] <mdz> it needed to be promoted from universe to main in order for the package to build
[07:39] <mdz> but apparently that doesn't clear the dep-wait
[07:40] <cprov> mdz: right, the chroot only looks for dep in main.
[07:41] <cprov> mdz: even if the auto-dep-retry doesn't do the same (it doesn't respect components) the result is expected
[07:41] <cprov> mdz: uhmm, not exactly , we retry the packages more than necessary. This is a bug :(
[07:42] <mdz> cprov: but we didn't retry this one, which actually needs it :-)
[07:43] <cprov> mdz: it might be retried before (the time window from created to built is bigger than usual).
[07:53] <cprov> mdz: https://launchpad.net/+builds/+build/226318, was automatically rescued
[07:57] <mdz> cprov: thanks
[07:57] <cprov> mdz: np
[08:05] <kiko> bradb, good idea!
[08:06] <bradb> :)
[08:08] <kiko> bradb, https://chinstrap.ubuntu.com/~dsilvers/paste/fileDA3vJw.html
[08:12] <bradb> kiko: Where is bugtask necessary for BugTaskComment, btw?
[08:12] <kiko> bradb, bugtaskcomment/fmt:url
[08:13] <kiko> sorry if that wasn't clear 
[08:13] <kiko> but that's why it's required.
[08:13] <kiko> (and yes, I guess we could use ILaunchbag there...)
[08:14] <bradb> or you could build the URL by not using fmt:url
[08:14] <kiko> how?
[08:14] <kiko> fmt:url isn't to blame
[08:14] <kiko> the URL /does/ require a bugtask
[08:15] <kiko> oh
[08:15] <kiko> what /do/ you mean?
[08:15] <bradb> not use fmt:url on the comment object, i mean
[08:16] <bradb> e.g. tal:attributes="href string:${context/fmt:url}/comments/${comment/id}"
[08:16] <kiko> bradb, you mean just link to +comments/index?
[08:16] <kiko> I don't have a context there.
[08:16] <bradb> (or /index...whatever it's supposed to be there)
[08:17] <kiko> but I could use a relative index..
[08:17] <kiko> err a relative link
[08:17] <kiko> BjornT, do you use bugcomment/fmt:url anywhere else?
[08:17] <kiko> bradb, actually, there's a problem with that
[08:18] <kiko> bradb, the page has a self-link which would break
[08:18] <kiko> I guess I could avoid that somehow
[08:18] <bradb> even the page should have bugtask as its context, no?
[08:18] <kiko> I guess it does
[08:19] <BjornT> kiko: no, i don't think i use it anywhere else. the only thing is the self-link as you pointed out.
[08:20] <kiko> BjornT, what do you think of removing bugtask from the bugcomment?
[08:20] <kiko> (and nuking its canonical_url)
[08:21] <BjornT> kiko: i don't see much value in removing it.
[08:21] <kiko> BjornT, have you seen bradb's arguments on the mailing list?
[08:21] <kiko> or perhaps mine
[08:21] <kiko> renaming it to BugTaskComment
[08:22] <kiko> because of the bugtask attribute
[08:23] <bradb> kiko: You can change this: sorted(comments.values(), key=lambda x: x.index)
[08:23] <bradb> to: sorted(comments.values(), key=attrgetter("index"))
[08:23] <bradb> (from operator import attrgetter)
[08:23] <kiko> sure
[08:24] <BjornT> kiko: well, that was the reason i put it in browser at the first place, the bugtask is used since the view needs it. i'd rather have it as it were (i.e. BugComment with a bugtask attached to it.)
[08:24] <BjornT> it is a comment in a bug which needs a bugtask to render properly
[08:24] <BjornT> s/in/on/
[08:24] <kiko> ok, whatever
[08:26] <BjornT> i can agree that BugComment isn't the best name, but it's better than BugTaskComment
[08:28] <bradb> kiko: the bug vs. bugtask naming was the only other concern i had
[08:29] <kiko> yay.
[08:29] <kiko> I'll add a comment explaining how BjornT prefers a class that lies about its true self
[08:31] <BjornT> BugTaskComment is a bigger lie :)
[08:31] <kiko> nha nha nha
[08:38] <bradb> BjornT: Have you started working on keywords? I'm just curious to give jamesh some info about the SF import.
[08:39] <BjornT> bradb: no, not yet. i'll start tomorrow, though.
[08:41] <bradb> BjornT: cool
[08:45] <kiko> wow
[08:45] <kiko> I have such a difficult prospect, getting BugCves right
[08:46] <kiko> hah
[08:46] <kiko> I need to group bugtasks per CVE
[08:46] <kiko> how does one do that, mmmm
[08:50] <bradb> kiko: another speed issue?
[08:50] <kiko> yes
[08:50] <kiko> the cve report page currently lists bugtasks grouped per CVE
[08:51] <kiko> or hmm
[08:51] <kiko> rather CVEs grouped per bug
[08:51] <kiko> (which I find weird)
[08:52] <kiko>             <tal:block repeat="cve bugtask/bug/cves">
[08:52] <kiko> that is the heart of the performance problem.
[08:52] <kiko> I see no way of solving this using SQLObject though
[08:52] <kiko> hmmmm
[08:53] <kiko> what I want is a query that returns bugtask, cve tuples.
[08:53] <kiko> salgado, is there anything in SQLObject that will return that?
[08:54] <kiko> ah
[08:54] <kiko> selectAlso
[08:55] <kiko> how does that help?
[08:55] <salgado> I don't know. never heard of it
[08:56] <kiko> it seems like selectAlso is only useful for order bys
[08:56] <kiko> yep
[08:56] <kiko> that's correct.
[08:56] <kiko> and guess who implemented it?
[08:56] <kiko> http://www.markshuttleworth.com/archives/9
[10:07] <jordi> ha, a danilo
[10:08] <jordi> SteveA: ping?
[10:08] <danilos> jordi: hey man
[10:08] <danilos> jordi: how is it going?
[10:08] <jordi> danilos: when do you dive into Launchpad?
[10:08] <jordi> I'm discussing translation licences. It is LOTS of fun
[10:09] <danilos> I am already starting, should be starting with some bugs so far, and we'll see what I'll do later :)
[10:09] <jordi> coolio
[10:09] <jordi> so you're danilo.segan@c.c already? 
[10:09] <danilos> translation licenses, cool; I'd make them all GPL :)
[10:09] <danilos> yup
[10:09] <jordi> except, some apps are non-free :)
[10:10] <danilos> I know, but that does the trick: you can only use this translation if you GPL the app :)
[10:10] <danilos> j/k, of course :)
[10:13] <carlos> danilos: hey!
[10:13] <danilos> hey carlos
[10:13] <carlos> did you manage to get a full launchpad tree?
[10:13] <carlos> jordi: enjoy it! :-P
[10:13] <danilos> jordi: (if I missed some msgs, it's because my IRC connection died and then transparently reconnected; blah)
[10:13] <danilos> carlos: yeah, I am looking into it now and browsing the buglist :)
[10:14] <carlos> danilos: the most interesting thing for you is at lib/canonical/launchpad
[10:15] <carlos> the other paths are dependencies and infrastructure
[10:15] <danilos> ok
[10:16] <sivang> danilos: this is just being discussed in ubuntu-meeting, moving over to a iRC netowrk that dosn't require to identiy for PM, like OFTC
[10:16] <sivang> danilos: (and Hi btw :) )
[10:17] <carlos> sivang: the bad thing about that is that anyone could stole your nick ;-)
[10:17] <danilos> sivang: (thanks :) ah, and preferably a network where "danilo" is not taken :)
[10:18] <jordi> danilos: nope, didn't miss anything
[10:18] <jordi> is danilo taken in OFTC?
[10:18] <jordi> oftc is the target of that discussion
[10:18] <danilos> jordi: dunno, can check :) if nicknames are not registered, then it probably isn't taken :)
[10:19] <sivang> carlos: hmm, true
[10:20] <sivang> carlos: then you have to use a detached sessions with IRSSI and maintain your nick this way :)
[10:22] <jordi> it's not bad to register to nickserv everynow and then anyway :)
[10:22] <jordi> I once lost my registration at either feenode or oftc
[10:23] <carlos> seems like someone took carlos already....
[10:23] <carlos> let's try to get it. It's not used since more than 4 months... (just same situation when I got carlos here)
[10:24] <danilos> danilo is free (well, not anymore :)
[10:25] <kiko> danilos, are the characters used in your Real Name used in your country?
[10:26] <danilos> kiko: yes, they are just simple Cyrillic
[10:26] <kiko> interesting. do you use mostly cyrillic or mostly latin?
[10:27] <danilos> it depends on person: I mostly use Cyrillic as do many others, others use Latin
[10:27] <danilos> and there are people who use Cyrillic in hand-written texts and Latin on computers
[10:30] <kiko> I see
[10:31] <kiko> danilos, which cyrillic variant do you use?
[10:31] <danilos> kiko: what do you mean? it's a pretty standard cyrillic nowadays
[10:32] <danilos> it's all part of 0x4000x47f Unicode range :)
[10:32] <kiko> danilos, I see. I was under the impression that there were a few variants
[10:32] <kiko> cool then
[10:32] <danilos> not really, except some typographical variants of a couple of letters
[10:33] <danilos> we need better pango support for opentype subst features for those, though :)
[10:33] <sivang> carlos: you can register your nick there, btw
[10:34] <carlos> sivang: It's already registered
[10:35] <kiko> err salgado ping
[10:35] <kiko> you need to prepend the postcode with a ", not a =
[10:35] <kiko> did you just get the comment wrong
[10:35] <kiko> or are you actually using =?
[10:36] <salgado> I'm actually using =
[10:36] <salgado> because that seems to work
[10:37] <kiko> weird
[10:37] <salgado> kiko, you mean that I should use a comma?
[10:37] <salgado> oh, a double quote
[10:37] <kiko> no, quotes
[10:37] <kiko> yeah
[10:37] <carlos> sivang: I just got it ;-)
[10:38] <sivang> carlos: cool!
[10:38] <jordi> kiko: hey dude
[10:39] <kiko> hey jordi
[10:39] <kiko> flacoste, did you manage to talk to SteveA about refactoring the tickettarget thing?
[10:39] <flacoste> kiko: yes, i had a little chat with him yesterday
[10:40] <kiko> flacoste, what did you guys decide?
[10:40] <flacoste> kiko: bottom line was nice idea but not today
[10:40] <kiko> bummer man
[10:40] <flacoste> kiko: he want to do some experience in that area in two weeks
[10:40] <kiko> it's a super-spritely-cool idea
[10:40] <kiko> we will see!
[10:41] <carlos> danilos: do you need me for anything?
[10:41] <carlos> I'm going to have dinner
[10:41] <carlos> and disconnect until tomorrow
[10:43] <danilos> carlos: no, just go ahead :)
[10:43] <carlos> ok
[10:44] <carlos> see you tomorrow
[10:44] <carlos> night!
[10:44] <danilos> carlos: I'll probably start later tommorow (the ISP guy should be coming to fix connection stuff), but I'll be hacking in the meantime
[10:44] <danilos> carlos: g'night
[10:48] <flacoste> I have defined an interface test for ITicketTarget, I would like to collect suggestions as naming convention and location
[10:49] <flacoste> it is currently named BaseTicketTargetTest and lives in lib/canonical/launchpad/interfaces/ftests/test_tickettarget.py
[10:50] <flacoste> I'm considering renaming it to ITicketTargetTest or TicketTargetInterfaceTest
[10:50] <flacoste> any other suggestions?
[11:05] <kiko> flacoste, I like TicketTargetInterfaceTest 
[11:05] <kiko> but I'm not really an authority in these matters.
[11:06] <flacoste> I like it too, i'll wait a little more to see if anybody else has an opinion on this before renaming it
[11:06] <flacoste> kiko: what about the location interfaces/ftests/test_tickettarget.py ?
[11:06] <kiko> sounds correct to me.
[11:32] <bradb> BjornT: around?
[11:42] <mpt_> LarstiQ, surprised why?
[11:52] <LarstiQ> mpt_: the amount of bile
[11:55] <bradb> kiko: do you want to review my landscape hack patch?
[11:55] <kiko> bradb, sure.
[11:57] <bradb> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/file27TeHW.html
[11:58] <kiko> bradb, frown. that's not what we agreed.
[11:59] <bradb> kiko: the security/privacy collapsing is in another branch, in review
[11:59] <kiko> bradb, I want to review /that/ branch -- I can't see how this branch can not depend on that one!
[11:59] <kiko> I r- this branch, fwiw
[12:00] <kiko> I explicitly do not want this special-cased in the submit handler
[12:00] <kiko> instead the UI should change
[12:00] <bradb> kiko: it does depend on that one to some degree. but this branch /could/ land before that one, if time were of the essence (which i thought it was)
[12:00] <kiko> the correctness would be compromised
[12:01] <bradb> kiko: what do you not want special-cased in the submit handler, exactly?
[12:02] <bradb> the special-case code here is completely orthogonal to the security/privacy collapse, as best i can tell. the latter does not preclude the former. it will happen either way.
[12:05] <kiko> the private=True special-case
[12:05] <kiko> the subscription special-case I can understand.
[12:05] <bradb> kiko: the private=True will happen either way.
[12:05] <kiko> hmmm?
[12:06] <bradb> kiko: if the user doesn't select the cb, how else will the bug be forced private if not special-cased?
[12:06] <kiko> bradb, for landscape, there will be no cb.
[12:06] <kiko> I thought my mockup made that clear.
[12:07] <bradb> hm? that's not how i understood it. you said that if they selected the cb, that would also mark it security-related, otherwise it would be forced private.
[12:09] <kiko>     * For landscape, all bugs would be private. Marking security would
[12:09] <kiko>       only make it security-related. All bugs, even private ones, would
[12:09] <kiko>       include the bug contact.
[12:09] <kiko> no
[12:09] <bradb> exactly!
[12:09] <kiko> oh.
[12:09] <kiko> I see
[12:10] <kiko> you want to implement this only on the form post side.
[12:10] <kiko> mmmm.
[12:10] <kiko> so another thing we had disucssed
[12:10] <bradb> kiko: we agreed that i would touch only browser code.
[12:10] <kiko> yeah that sounds okay to me then
[12:10] <kiko> however
[12:10] <kiko> one thing we discussed was modifying createBug
[12:10] <kiko> to accept a subscribers argument
[12:11] <kiko> does your patch do that?
[12:11] <kiko> your other patch I mean.
[12:12] <bradb> kiko: no. the reason i didn't do that is because i can achieve the same effect doing what i do, with less code change required. from the email notification machinery PoV it doesn't make a hoot of a difference if I pass subs as an arg, or sub the bugcontact right after i create the bug