[12:08] <mdke> s/3 or 4/10 or 11
[12:12] <sfllaw> We shall try to tell you soon.
[12:12] <mdke> sfllaw, mm?
[12:12] <sfllaw> Well, for some definition of soon.
[12:12] <mdke> and what definition of we?
[12:13] <sfllaw> mdke: Hi.  I'm the new guy.
[12:13] <mdke> hello, are you on malone?
[12:14] <sfllaw> https://launchpad.net/people/sfllaw
[12:14] <mdke> ah, I thought you meant you were working on launchpad
[12:15] <salgado> lifeless, noted that
[12:15] <sfllaw> Oh no.  We're going to be doing this the old fashioned way.
[12:15] <mdke> kiko's last comment on bug #3796 tends to suggest that duplicates aren't included in most bug lists, not sure though
[12:15] <Ubugtu> Malone bug 3796 in malone "Duplicated bugs still show up as New in a list of bugs (also affects the Latest bugs portlet)" [Normal,Confirmed]  http://launchpad.net/bugs/3796
[12:15] <kiko> eu?
[12:15] <salgado> lifeless, would you like to review that branch or shall I fix this and resubmit it for review?
[12:15] <kiko> mdke, they aren't -- in any [by default]  that I know of
[12:16] <mdke> kiko, oh, I just don't understand geek-speak then
[12:16] <mdke> so all those 10k ubuntu bugs are probably lots of dups?
[12:16] <kiko> I was agreeing with you!
[12:16] <mdke> oh damn
[12:16] <lifeless> salgado: I've emailed you :)
[12:16] <kiko> heh
[12:16] <mdke> kiko, I got excited there for a moment
[12:17] <kiko> as I said -- they aren't [displayed by default] 
[12:17] <lifeless> salgado: I'd say, fix it, and the duplicate code, then resubmit it
[12:17] <kiko> I fixed the last bug I knew there, which was in the recent bugs portlet
[12:17] <mdke> k
[12:17] <mdke> so there are 10k real bugs, that is crazy
[12:19] <salgado> lifeless, great. thank you
[01:00] <baconbacon> 10k but for many apps
[01:00] <baconbacon> ...about 16k apps iirc
[01:00] <lifeless> its < 1 per app
[04:15] <PenguinOfDoom> How do I increase the severity of a bug?
[04:15] <PenguinOfDoom> oh, it's per-distribution
[04:15] <PenguinOfDoom> grumble
[05:05] <nictuku> "Your subscription to this team has been deactivated. You can't join this team. " what does this mean? I was banned from the group?
[08:39] <carlos> morning
[08:47] <sivang> morning all
[08:51] <carlos> stub: hi, around?
[08:51] <stub> carlos: yes
[08:51] <carlos> I'm having problems with the code updates you do on mawson in the afternoon, or at least I think that's the problem...
[08:52] <carlos> I breaks the language pack exports
[08:52] <carlos> s/I/It/
[08:52] <stub> I don't do code updates on mawson. Do you mean asuka?
[08:52] <carlos> http://mawson.ubuntu.com/~carlos/rosetta-dapper-2006-04-24.log
[08:52] <carlos> sorry, asuka, yes
[08:52] <carlos> I have lock problems
[08:53] <stub> I can't stop that without disabling the afternoon code updates. They were really only needed for the sprint, so I don't have a problem with that.
[08:53] <carlos> stub: would the problem be: 
[08:53] <carlos>         for (id,) in cur.fetchall():
[08:53] <carlos>             yield POTemplate.get(id)
[08:54] <carlos> would it be fixed if I create a list first? and stop using the cursor?
[08:54] <stub> Not really - locks you open remain that way until you commit or rollback.
[08:54] <carlos> hmmm, no, the break is when doing the query....
[08:55] <carlos> yeah, and another process is doing the lock
[08:55] <carlos> stub: well, disabling the code update would fix it now, but when we move this script into production...
[08:55] <stub> You are competing with a script that removes and rebuilds the permissions on all the tables - no way you can avoid locking. This is why we shutdown the production launchpad for database updates.
[08:55] <carlos> it would be worse
[08:55] <carlos> ok
[08:56] <carlos> so you think it would not be an issue on production?
[08:56] <lifeless> carlos: can you reschedule teh exports to not conflict ?
[08:57] <carlos> I did it already
[08:57] <carlos> Let me see how long it takes now and try to find a better time to execute it....
[08:57] <carlos> stub: when does the morning update finish?
[08:58] <carlos> the one with the database mirror included
[08:58] <stub> carlos: If it triggered by the database updates, then this won't be an issue on production
[08:58] <carlos> ok
[08:59] <carlos> my export script takes around 3 hours 
[09:01] <carlos> and I would need as close as possible to the db mirror to be able to test it earlier instead of one day after doing changes on production (like new .pot/.po imports)
[09:01] <carlos> stub: I'm executing it at 12:30 (mawson time)
[09:01] <stub> You shouldn't get too close, as the finish time isn't that fixed
[09:02] <carlos> yeah, that's why I moved it later, but seems like I moved too late and the afternoon update broke it again
[09:02] <stub> Start at approx 8:30 and finish approx 12:00 server time
[09:03] <stub> I'll disable the midday update
[09:03] <carlos> that means I should delay it a bit more or the afternoon update should be done later (3 hours after the morning update is a bit early, isn't it?)
[09:04] <stub> It was requested at that time for the sprint.
[09:04] <stub> Like I said - it is pretty pointless now that the sprint is over
[09:04] <carlos> stub: I think lifeless prefer that we leave it there instead of removing it
[09:04] <carlos> lifeless: ?
[09:05] <lifeless> I don't care
[09:05] <lifeless> I think steve might
[09:06] <lifeless> and its night to have staging really close to prod
[09:06] <lifeless> plus the po exports really should not be broken every time we sprint
[09:06] <lifeless> -> should solve it permanently
[09:06] <stub> it is just a code update - doesn't make any difference to data freshness
[09:06] <lifeless> I'm talking code!
[09:07] <stub> po exports shouldn't be running on staging.
[09:07] <lifeless> sorry, I meant 'close to HEAD'
[09:07] <lifeless> language packs are .. mo exports  not po, sorry.
[09:08] <lifeless> I meant language packs though
[09:09] <carlos> lifeless: well, the po export should move to production servers before next sprint
[09:11] <carlos> we are runing them on staging because that give me much more flexibility, but I hadn't to change any code recently related to them, or at least I hadn't to change any code that would not wait for the usual review and rocketfuel merge procedure, atm we are running there rocketfuel code directly
[09:17] <lifeless> so why not run on production now ?
[09:18] <stub> he is chicken ;)
[09:19] <lifeless> squawk squawk squawk
[09:23] <carlos> :-P
[09:23] <carlos> lifeless: if I get a full run today, and works as expected, I will start planning its movement to production
[10:04] <mpt_> stub, are you able to cherrypick r1815?
[10:18] <carlos> lifeless: hi, we had a weird behaviour with bzr, I'm not sure if it's related but it happened with the revision number change, the r3488 that is know now as r1814 (I think that was the last commit with the old revision numbers)
[10:18] <carlos> lifeless: I added a new file on that revision and merged it into rocketfuel
[10:18] <carlos> but rocketfuel doesn't have that file
[10:19] <mpt_> carlos, lifeless said that the revision numbers will all fix themselves once he finds that bug
[10:19] <carlos> and my mirror has it so I'm sure I didn't forget its addition
[10:20] <carlos> mpt_: do you mean that the missing files is a known bug?
[10:20] <carlos> mpt_: or just that the revision number will be fixed?
[10:20] <carlos> in that case, is not just the revision number, but data lose...
[10:25] <ddaa> carlos: the revno thing should not affect the merge logic, I think.
[10:26] <mpt_> carlos, I don't know anything about any missing files
[10:26] <ddaa> whether a branch has new stuff compared to another one is based on the revid of the tip
[10:27] <ddaa> carlos: what is your branch with the problem?
[10:35] <SteveA> hi
[10:37] <carlos> ddaa: chinstrap:/home/warthogs/archives/carlos/launchpad/bug-2529
[10:37] <carlos> SteveA: hi
[10:40] <carlos> hmmm
[10:40] <carlos> ddaa: seems like it's there now...
[10:40] <stub> mpt_: Probably. I was going to do a production update today and bring it in then.
[10:41] <mpt_> great
[10:41] <SteveA> mpt_: aren't you on holiday? :-)
[10:42] <mpt_> SteveA, yes, but I said I'd be on IRC some of the day
[10:43] <ddaa> carlos: well, if you say the file is in rocketfuel now, no need for me to investigate.
[10:45] <carlos> ddaa: right, thank you
[10:46] <carlos> stub: the migration script for the cherry pick you did for me is now on rocketfuel, could you execute it now?
[10:47] <stub> carlos: Do you know what revision it landed in?
[10:48] <carlos> stub: well, I know the revision where it should be, and is the same you cherry picked...
[10:48] <carlos> I didn't ask for any other merge since then
[10:49] <carlos> r3488 or r1811 with the new numeration
[10:49] <stub> Do you have a rough idea on how long it will take to run?
[10:50] <carlos> stub: no, but I don't think it would take more than one hour, it depends on the number of POFiles we have in our database
[10:51] <carlos> I think it would do the job in 15-20 minutes
[10:51] <carlos> but that's only a guess
[10:51] <carlos> if you want
[10:51] <carlos> I could time it on staging
[10:51] <stub> no - rough is fine.
[10:55] <carlos> ok
[11:00] <stub> Looks like rolling out head is the thing to do - almost everything landed since friday are desirable cherrypicks
[11:13] <stub> Launchpad will be going down in just over 45 minutes at 10:00 UTC for its regular code update. Estimated downtime is 15 minutes.
 carlos, pitti: I don't see any translations on rookery from the last OOo build?
 doko: hm, maybe you still had NO_PKG_MANGLE defined?
 pitti: no, and that wouldn't explain that carlos had something imported
[11:45] <stub> Launchpad will be going down in 15 minutes at 10:00 UTC for its regular code update. Estimated downtime is 15 minutes.
[11:45] <carlos> doko: I don't control rookery tarballs, I cannot do anything there...
[12:05] <BjornT> mpt_: ping
[12:05] <mpt_> BjornT, pong
[12:06] <BjornT> mpt_: do you have any suggestions how to make it possible to unsubscribe a team, without adding another menu item?
[12:07] <mpt_> BjornT, the current UI structure kind of requires another menu item
[12:08] <mpt_> hmmm, unless ...
[12:08] <mpt_> ... unless "Subscribe" becomes "Subscribe/Unsubscribe" if a team you are a member of is subscribed to the bug
[12:09] <mpt_> and then the resulting "Subscribe/Unsubscribe" page has radiobuttons for the things you want to do
[12:09] <mpt_> (*) Subscribe me
[12:09] <mpt_> ( ) Unsubscribe Team I'm a Member Of A
[12:09] <mpt_> ( ) Unsubscribe Team I'm a Member Of B
[12:09] <mpt_> That would be a gross hack, but it would avoid adding a menu item
[12:10] <mpt_> Ideally, this would be done by the people/teams that you had permission to modify in the list of subscribers having checkboxes
[12:11] <mpt_> To unsubscribe yourself or a team you're a member of, uncheck the relevant box
[12:12] <SteveA> well
[12:12] <SteveA> there are a number of states
[12:12] <BjornT> yeah, i'll go for the "Subscribe/Unsubscribe" solution for now. it's quite easy to do, and the menu won't get any longer than it already is.
[12:12] <SteveA>  - not subscribed
[12:12] <SteveA>  - subscribed as me
[12:12] <SteveA>  - subscribed as team / teams
[12:12] <SteveA>  - subscribed as me and team / teams
[12:12] <SteveA> the menu item can say
[12:12] <ddaa> hey SteveA
[12:13] <SteveA>  - unsubscribe
[12:13] <SteveA>  - unsubscribe my team
[12:13] <SteveA>  - unsubscribe me and my team
[12:13] <SteveA> in the (hopefully) rare case you want to unsubscribe a team, but not yourself, we can either offer a UI, or you unsubscribe it all, and resubscribe yourself 
[12:13] <mpt_> Three menu items?
[12:13] <SteveA> no
[12:14] <SteveA> well, yes
[12:14] <SteveA> but only one ever visible at one
[12:14] <SteveA> once
[12:14] <BjornT> SteveA: so, if the menu item says 'unsubscribe my team', how do i subscribe myself?
[12:14] <ddaa> is Launchpad eligible for SOC?
[12:15] <mpt_> SteveA, that would be two extra page loads for the rare case, and the same number of page loads for every other case
[12:16] <SteveA> BjornT: it would say "unsubscribe me and my team"
[12:17] <mpt_> so, what is the advantage of doing it that way?
[12:17] <SteveA> ah...
 (*) Subscribe me
[12:17] <SteveA> so, that wasn't a type
[12:17] <SteveA> typo
[12:17] <SteveA> (how ironic i typo the word typo)
[12:17] <BjornT> SteveA: i don't quite understand. if one of my team is subscribed, but i'm not, what will it say?
[12:17] <SteveA> i was confused by one radio button being "subscribe me" and the rest being "unsubscribe team"
[12:18] <SteveA> mixing "subscribe" and "unsubscribe" in the same control is confusing
[12:18] <mpt_> Yes, it is
[12:18] <mpt_> We already have such evilness for unmarking duplicates
[12:18] <mpt_> but the alternative is to add another menu item
[12:18] <mpt_> or to add more page loads
[12:19] <SteveA> my overall point, confusion aside, is that we can make the menu item give more of a clue as to what it is offering
[12:19] <SteveA> by making it more context-specific
[12:24] <BjornT> well, it's hard to get much information into the item and still have it short enough to fit into the menu box.
[12:25] <SteveA> a person going into a waste-disposal device, vs a group of people going into the same waste disposal device ;-)
[12:25] <jordi> carlos?
[12:25] <SteveA> mpt_: magic dhtml extra menu items...
[12:25] <carlos> jordi: hi
[12:26] <mpt_> Soylent Green Subscriptions
[01:35] <Keybuk> uh, help
[01:35] <Keybuk> sync-source is bailing out most of the time saying things like:
[01:35] <Keybuk> E: bsdgames_2.17.orig.tar.gz (from bsdgames) returns multiple IDs ([(1332643,), (1494584,)] ) for orig.tar.gz.  Help?
[01:46] <elmo> Keybuk: that shouldn't happen, that means there are multiple different orig.tar.gz's with different content, that's stunningly bad
[01:46] <elmo> Keybuk: and it's not a sync-source problem
[01:46] <Keybuk> the content is the same in both Ubuntu and Debian, if that's what you mean ?
[01:46] <elmo> no, I mean in soyuz
[01:47] <Keybuk> Kinnison says that the uploader may be just making duplicate aliases for the same actual .orig.tar.gzs
[01:47] <Keybuk> it's doing this for pretty much every package I'm trying
[01:47] <elmo> sync-source already deals with that
[01:47] <elmo> it has an explicit "is the sha1 and size the same?  if so, ignore it" check
[01:47] <Keybuk> so who has to be beaten up to get this fixed?
[01:48] <Kinnison> elmo: yargh, okay I need to looksee
[01:48] <elmo> keybuk: well, probably not me, but I need to run to a meeting anyway
[01:49] <Keybuk> Kinnison: thanks *hug*
[02:02] <cprov> morning guys
[02:02] <mpt> bradb, pong
[02:06] <matsubara> good morning!
[02:09] <bradb> mpt: Was going to ask you to have a look at the UI for the fix for bug 977. (It's in rf.)
[02:09] <Ubugtu> Malone bug 977 in malone "Commenting on bug should optionally subscribe you" [Major,Fix committed]  http://launchpad.net/bugs/977
[02:10] <mpt> That would require me to go off IRC to get rocketfuel
[02:10] <mpt> Have a demo/screenshot?
[02:10] <mpt> or shall I just look at it tomorrow?
[02:14] <bradb> mpt: Tomorrow'd be fine.
[02:14] <bradb> It's nothing life changing.
[02:15] <mpt> ok
[02:26] <ddaa> matsubara: good catch
[02:26] <ddaa> I mean bug 41164
[02:26] <matsubara> ddaa: ?
[02:26] <Ubugtu> Malone bug 41164 in launchpad "IPerson.getBranch() should return only one result" [Critical,Confirmed]  http://launchpad.net/bugs/41164
[02:26] <ddaa> critical db constraint missing
[02:26] <salgado> lifeless, around?
[02:26] <matsubara> ddaa: thanks to the oops report :)
[02:27] <ddaa> no idea how that ended up this way, I cannot believe I just _forgot_ to add that constraint
[02:28] <matsubara> ddaa: can you fix it?
[02:29] <ddaa> Should be trivial to fix.
[02:29] <ddaa> well, that also means that some form do not do proper input validation
[02:29] <ddaa> but that's MUCH less of a problem
[02:42] <Keybuk> ok, that's kinda interesting
[02:42] <Keybuk> my sync queue just got moved to failed, not accepted
[02:43] <Keybuk> no errors, just lots of
[02:43] <Keybuk> 12:41:44 WARNING Exception during processing made it out of the main loop.
[02:43] <Keybuk>  -> http://librarian.launchpad.net/2339224/lEYjJjYCKy0XmqVqfzZaazPPLYK.txt (No To: header)
[02:47] <salgado> Keybuk, I think there's a bug reported for that
[02:47] <salgado> yep, bug 40958
[02:48] <salgado> Ubugtu, you slacker!
[02:48] <Ubugtu> Malone bug 40958 in qprocd "all sync attempts fail" [Normal,Confirmed]  http://launchpad.net/bugs/40958
[02:48] <Keybuk> *sigh*
[03:11] <kiko-zzz> cprov, is that codepath not tested?
[03:11] <kiko> hey BjornT 
[03:11] <carlos> see you later
[03:12] <kiko> hey carlos 
[03:12] <cprov> kiko: barely only, I think we never reached this subtle situation
[03:12] <carlos> kiko: hey dude!
[03:12] <kiko> did you give matsubara a hand trying to figure out that crasher in rosetta?
[03:12] <BjornT> hi kiko 
[03:12] <kiko> cprov, really? isn't it that all syncs are busted?
[03:12] <carlos> kiko: which crash?
[03:12] <kiko> carlos, the TypeError?
[03:12] <matsubara> kiko: yes he did.
[03:12] <kiko> the only rosetta crasher open that I know of
[03:12] <kiko> ah cool
[03:12] <carlos> kiko: I talked with matsubara last week
[03:12] <cprov> kiko: yes, I think so
[03:13] <carlos> matsubara: but did you manage to reproduce it?
[03:13] <kiko> cprov, so what I'm saying is that we are not functional-testing the sync process
[03:13] <matsubara> carlos: unfortunately, no
[03:13] <cprov> kiko: just investigate that zakame issue 
[03:13] <kiko> carlos, well, notice that there are /two/ string 13s in the form
[03:13] <carlos> matsubara: let's talk when I'm back from lunch about it, ok?
[03:13] <kiko> carlos, how could that be possible?
[03:13] <kiko> anyway k
[03:13] <matsubara> carlos: ok.
[03:13] <carlos> kiko: no idea ;-)
[03:13] <kiko> carlos, seems to be user-dependent too
[03:14] <carlos> kiko: I don't even know how is possible that we get a python list dump there....
[03:14] <kiko> i.e. BjornT sees two string 13s but matsubara and I only see one.
[03:14] <kiko> carlos, it happens when there are two fields with the same form name.
[03:14] <kiko> that's how you get the python list
[03:14] <cprov> kiko: I'd say so, it's not properly tested, as you can see 
[03:14] <carlos> kiko: oh, that's good
[03:14] <kiko> yeah
[03:15] <carlos> I mean if you found a way to reproduce it
[03:15] <kiko> carlos, we'll need to find out what codepath causes two string 13s to be displayed
[03:15] <carlos> kiko: I need to leave now, I will take a deeper look when I'm back
[03:15] <carlos> thanks for the extra info
[03:15] <carlos> kiko: right
[03:15] <matsubara> kiko: it's string 14. The garbage I told you in string 13 is the html that should be rendered as the second 14 textarea
[03:15] <kiko> sorry
[03:15] <kiko> string 13
[03:15] <kiko> string 14
[03:16] <carlos> I guess it depends more on your locale preferences or IP address
[03:16] <kiko> matsubara, that "garbage" is actually entered by the translator, I suspect
[03:16] <kiko> carlos, exactly what I think
[03:16] <carlos> ok
[03:16] <carlos> see you later!
[03:16] <matsubara> kiko: do you think so? I run a diff between the html generated by opera and by firefox and there's no difference
[03:17] <kiko> matsubara, I am /sure/ there is a difference
[03:17] <kiko> matsubara, and, for the 10th time, this is /not/ browser-dependent
[03:18] <kiko> it most likely depends on the user's calculates languages
[03:18] <matsubara> I understood that and I'm not saying it's browser dependent.
[03:18] <kiko> but you said "opera" versus "firefox" above!
[03:23] <ddaa> mh... apparently, the db constraint just got forgotten...
[03:23] <ddaa> how embarassing
[03:25] <ddaa> stub!
[03:25] <stub> ddaa!
[03:25] <kiko> heya guys
[03:25] <ddaa> can you make a itsy bitsy littly db patch like, right now, with a cherrypick?
[03:26] <ddaa> I'll try phrasing what I want in sql if you want.
[03:26] <stub> sql or english
[03:26] <ddaa> in english
[03:26] <ddaa> drop all Branch with duplicate (owner, product, name), keep the one with smallest id
[03:27] <ddaa> add unique branch constraint on (owner, product, name)
[03:28] <stub> ok
[03:28] <ddaa> note that product may be NULL, dunno how that can affect unique matching
[03:29] <ddaa> the delete should delete just 2 rows
[03:30] <kiko> ddaa, that constraint needs a code check, I assume?
[03:30] <ddaa> kiko: code check?
[03:30] <kiko> well, something to avoid OOPSing when it happens
[03:30] <ddaa> well, the form that allowed violating the unspoken constraint definitely needs fixing
[03:30] <ddaa> and other forms too
[03:31] <ddaa> but that's a low priority
[03:31] <kiko> if it generates an OOPS it is high priority
[03:31] <kiko> you don't need to do it yourself though
[03:31] <ddaa> I mean lower than fixing the db constraint.
[03:31] <kiko> just make sure it gets done
[03:31] <ddaa> since the constraint violation cause _everything else_ to blow up
[03:32] <kiko> you mean not having the constraint I guess
[03:32] <kiko> yeah
[03:33] <ddaa> it's a "violation" in that a lot of things rely on that constraint, in the code (selectOneBy) and in the design.
[03:33] <kiko> indeed
[03:33] <ddaa> mh...
[03:35] <ddaa> stub: please run the following query and mail me the output before running the delete in production: select branch.id, branch.owner, person.name as owner_name, branch.product, product.name as product_name, branch.name from (select owner, product, name from branch group by owner, product, name having count(*) > 1) as dup_branch join branch using (owner, product, name) join person on branch.owner = person.id join product on branch.produ
[03:35] <ddaa> it may require some cleanup on the supermirror filesystems
[03:35] <stub> ddaa: pastebin please - that got cuttoff.
[03:36] <ddaa> https://chinstrap.ubuntu.com/~dsilvers/paste/filejTBhBh.html
[03:37] <ddaa> basically, I just want to know which branches got deleted, because the branch mirroring stuff does not care about that constraint
[03:38] <stub> ddaa: https://chinstrap.ubuntu.com/~dsilvers/paste/fileay8ntH.html
[03:38] <ddaa> stub: you have already applied the constraint?
[03:39] <stub> ddaa: Not yet
[03:39] <stub> ('ddaa', NULL, 'fred') and ('ddaa', NULL, 'fred') should conflict I assume?
[03:40] <ddaa> yes
[03:40] <ddaa> NULL product == pseudo product with name '+junk'
[03:46] <stub> ddaa: Done
[03:47] <ddaa> thank you, I'm looking forward to see it landing in RF
[03:52] <kiko> stub, we're only rolling out head-ish next week, right?
[03:54] <stub> kiko: Almost everything that had landed since last week was either requested for cherry pick, or was a good candidate for a cherry pick. So yes - one off.
[03:54] <kiko> stub, wonderful. next tuesday, then?
[04:03] <bradb> SteveA: Any chance of some code review love today?
[04:04] <kiko> bradb, what's up?
[04:04] <bradb> Code review blockage
[04:04] <kiko> that was obvious; more specifically?
[04:04] <bradb> also, a decision on binary package name, as per my email
[04:05] <kiko> I thought we had agreed to just put it in the description. I don't care about data migration, it's your call.
[04:05] <bradb> kiko: Yeah, it's already in the description, just the data migration issue. But if you don't care, then I say we just blow it away. We'll offend two or three people, and life will go on.
[04:07] <kiko> "Have you ever killed anybody? Me? No. But I hurt someone's feelings once."
[04:07] <bradb> heh
[04:21] <sivang> kiko: hehe
[04:21] <kiko> what movie is that from sivang?
[04:25] <SteveA> bradb: you know i'd love to give your code some lovin'
[04:27] <Kinnison> stub: is it possible to create temporary tables inside a transaction when connected as user 'ro' ?
[04:31] <Kinnison> actually, that question goes to anyone who might know
[04:33] <bradb> SteveA: !
[04:34] <SteveA> tough love
[04:34] <bradb> booty call
[04:35] <SteveA> the bradb code review booty call
[04:35] <SteveA> i like it
[04:35] <bradb> heh
[04:36] <SteveA> ddaa: why is the docs stuff in my review queue?
[04:36] <stub> Kinnison: Dunno ;-)
[04:37] <Kinnison> stub: hhe
[04:37] <Kinnison> stub: it seems it is permissible
[04:37] <Kinnison> just with much shorter queries now
[04:38] <SteveA> jamesh: nice improvements to the pending reviews page!
[04:40] <Kinnison> if I have a table with three columns in it, namely aliasid, filename and sha1, how can I select all the rows which have a unique (filename,sha1) tuple?
[04:43] <SteveA> bradb: i'm looking at bug 36866 now, in preparation for the code review
[04:43] <Ubugtu> Malone bug 36866 in malone "Searching for bugs after selecting a certain status from the Right-Hand-Menu resets the search" [Major,In progress]  http://launchpad.net/bugs/36866
[04:43] <SteveA> bradb: one thing about bug reports like this: always edit the description to include an actual URL to start the process from
[04:43] <SteveA> that way, looking at the problematic workflow is much easier for someone looking at the bug
[04:43] <SteveA> matsubara: please note the above too
[04:45] <bradb> SteveA: updated :)
[04:48] <matsubara> SteveA: ok
[05:00] <kiko> Kinnison, select distinct on (filename, sha1)
[05:00] <kiko> Kinnison, you can use that in a subselect if necessary
[05:01] <kiko> and order by to choose which row you want
[05:01] <Kinnison> kiko: yah, someone gave me that in another channel just now, thanks dude
[05:01] <kiko> if you need some help using it let me know as I rewrote some code to use it recently
[05:01] <Kinnison> thanks, I think I've got the answer I needed, but I may be back for more hints
[05:02] <kiko> carlos, ping?
[05:10] <ddaa> SteveA: not sure why doc-bazaar is in your queue, after you replied to to lifeless' question during your vacation, I made some changes to the README, quicked it back to needs-review, then it went dormant. Only this week was I asked to get it moving again, so I said I already did...
[05:11] <ddaa> at some point in the meantime, I guess it was moved out of spiv's queue (who is in vacation if I am correct)
[05:12] <ddaa> SteveA: I guess your review is requested to confirm that the level of build documentation (good) and cross-referencing (none so far) is satisfying.
[05:13] <stub> ddaa: That constraint is causing branch-pages.txt to fail (possibly others too)
[05:13] <ddaa> duh?
[05:13] <ddaa> ???
[05:13] <ddaa> no way _adding_ this constrain would cause anything to fail
[05:14] <ddaa> except some forms with insufficient validation
[05:14] <stub> https://chinstrap.ubuntu.com/~dsilvers/paste/fileYAYBeQ.html for the constraint that needs to land in rocketfuel....
[05:15] <ddaa> stub: yes
[05:15] <stub> https://chinstrap.ubuntu.com/~dsilvers/paste/fileJRit8h.html for the failure
[05:16] <ddaa> holy fucking christ :(
[05:16] <ddaa> cascading breakage
[05:16] <ddaa> I'll be working on fixing the tests and stuff, right now
[05:17] <stub> ddaa: ok. It would be great if you can land that db patch as patch-40-49-1.sql
[05:21] <stub> ddaa: The person merge tests are also failing - we need to decide how to handle duplicates caused by a merge.
[05:21] <ddaa> *argl*
[05:22] <stub> I don't think we can delete them, so we might just have to leave them in the db as noise
[05:22] <ddaa> stub: we should append "-N" to the name, where N is an integer.
[05:22] <ddaa> i.e. name-1, name-2, etc.
[05:22] <stub> Ahh... yes. that is a good idea.
[05:23] <stub> I'll sort the people merge code if you like.
[05:23] <ddaa> there might be better ways to do it, but I people merge is rare corner case, so that will be good enough
[05:23] <ddaa> stub: I'd like if you could
[05:24] <ddaa> send me a paste, when you have
[05:24] <mdke> is spiv on vacation, does anyone know?
[05:24] <ddaa> mdke: he is
[05:24] <Kinnison> stub: Would there be anything wrong with coalescing libraryfilealias records?
[05:24] <mdke> ddaa, thanks. When is he back?
[05:24] <ddaa> mdke: back at the end of the week
[05:24] <mdke> great
[05:25] <mdke> good telepathy too
[05:25] <Kinnison> stub: I.E. if two lfa records have the same name, content, mimetype and expiry, reduce it to one lfa by updating FKs everywhere else?
[05:27] <carlos> kiko: pong
[05:27] <kiko> carlos, read my mind, I was about to reping
[05:27] <kiko> so 
[05:27] <kiko> you have more database corruption. :)
[05:27] <carlos> not really read your mind, I just came back from lunch :-D
[05:27] <carlos> I have more database corruption?
[05:28] <kiko> carlos, yes. when and why did you choose to tal:replace="structure  inside the pomsgset textarea?
[05:28] <carlos> I don't remember
[05:28] <stub> Kinnison: If you do that, we lose the ability to determine the last access time of the individual aliases (as there is now only one)
[05:28] <stub> Kinnison: Apart from that, no problem at all
[05:28] <carlos> can you point me to the code so I can try to get the context?
[05:29] <kiko> carlos, look at the pomsgset translation template.
[05:31] <carlos> I'm there
[05:31] <carlos> <tal:content replace="structure python:pomsgset_view.getTranslation(index)" />
[05:31] <cprov> Kinnison: last_access is only important for gc, if we set it for now it will just prevent them to be removed for a while. Does it sound right ?
[05:31] <carlos> are we talking about that?
[05:32] <Kinnison> cprov: I was just imagining chosing the most recent last_access
[05:32] <kiko> carlos, yes.
[05:32] <stub> Kinnison: Removing LibraryFileAliases will cause URLs that used to work to stop working, so we don't want to add this to the Library garbage collector. Just special cased in areas we feel are worth the extra complexity.
[05:32] <kiko> carlos, when and why did that structure get added there.
[05:32] <Kinnison> stub: right
[05:32] <Kinnison> stub: that's a good point, removing an LFA renders a URL nonfunctional
[05:33] <Kinnison> This might be a one-off for sourcepackages so I'll look into doing a one-off script instead
[05:33] <stub> Are you creating a large number of dupes or something?
[05:33] <stub> That will never be garbage collected?
[05:34] <carlos> kiko: last time i touched that code was with my branch to split out the pomsgset specific template from the pofile-translate template
[05:34] <carlos> kiko: I don't know if I added it then
[05:35] <carlos> kiko: about why, I don't know
[05:35] <carlos> let me check if it's on that branch...
[05:35] <kiko> carlos, okay. it is wrong.
[05:35] <carlos> kiko: don't we have a bzr blame yet?
[05:36] <carlos> it's really useful to know the revision when a code line was touched....
[05:36] <kiko> carlos, we have bzr annotate.
[05:36] <carlos> lifeless, mpool:  ^^^
[05:36] <kiko> carlos, but I have little time, so let's go over why it is wrong.
[05:36] <Kinnison> stub: at some point, a large number of dupes was created
[05:36] <Kinnison> stub: I'm trying to work out if it's still going on
[05:36] <kiko> carlos, what happens when an end-user types into a translation textarea the following literal text: "Foo <em>bar</em> baz"
[05:36] <Kinnison> stub: so I need to clear the dupes
[05:36] <carlos> kiko: let me read some extra code first, please...
[05:36] <kiko> carlos, what do we save to the database?
[05:37] <kiko> carlos, there is no extra code to read -- the error is there. :)
[05:37] <stub> How large though? Is it significant in a table designed to hold tens of millions of records?
[05:37] <kiko> carlos, I have 5m
[05:37] <Kinnison> stub: It's significant in a tool sense
[05:37] <carlos> ok
[05:37] <Kinnison> stub: tools are crashing because of finding more than one lfa for a given filename in a given distro pool
[05:37] <carlos> kiko: I guess the form submission should escape the '<' and '>' chars
[05:38] <carlos> so we get &lt; and &gt;
[05:38] <kiko> carlos, the browser does that for you. we correctly store in the database "<" and ">".
[05:38] <kiko> carlos, the problem is when we /render/ the translation in the page.
[05:38] <stub> Kinnison: Ok. So we can either merge the dupes, or fix the tools to choose an arbitrary file in that case.
[05:38] <kiko> what happens is you end up with a <textarea> that can contain HTML elements.
[05:38] <kiko> carlos, have you ever tried, for instance, to type in </textarea> into a translation?
[05:39] <carlos> right
[05:39] <carlos> kiko: no, I havent
[05:39] <kiko> carlos, test it in a local tree to see what happens. 
[05:39] <kiko> carlos, now, this is very unfortunate
[05:39] <carlos> kiko: I know that the 'structure' thing should not be there
[05:39] <kiko> right
[05:39] <Kinnison> stub: I want to merge the dupes because it's good for the tools to rant in case they're not dupes but a bug which has allowed different contents into the pool
[05:39] <kiko> because it has caused some weird side-effects that need to be dealt with
[05:39] <carlos> because the html tags are preserved that is what you are pointing at
[05:39] <kiko> right
[05:39] <kiko> carlos, we have translations now that include portions of the translation template
[05:39] <Kinnison> stub: we used to have a bug which has allowed three broken orig.tar.gzs to happen
[05:40] <Kinnison> stub: Celso and I corrected that bug, but now we need to cleanup so we have an easier time of it debugging any future issue
[05:40] <kiko> carlos, we will need to look for translations that contain the text </textarea> and fix them.
[05:40] <stub> Kinnison: ok. If you don't remove the existing LFAs, but just change the stuff that points to them to point to the canonical entry, then existing URLs won't break.
[05:40] <kiko> carlos, hopefully there are not too many
[05:40] <kiko> carlos, but it will require a script to fix them I suspect
[05:40] <carlos> let me check the number...
[05:41] <kiko> carlos, can you a) do an analysis on staging and tell me how many are broken b) add a test c) fix the bug and d) email me cc:launchpad with the details? :-)
[05:41] <Kinnison> stub: aye, but won't librariangc then remove the unreferenced LFAs ?
[05:41] <carlos> kiko: we have 5 translations with '</textarea>'
[05:41] <Kinnison> stub: given the only things using the LFA URLs are the internal tools I'm fairly happy if they disappear anyway
[05:41] <kiko> carlos, wonderful. 
[05:41] <stub> Kinnison: And if the number of irrelevant LFA entries becomes a size problem, we can update the librariangc to remove unreferenced library file aliases that have not been accessed in the last 6 months or something.
[05:42] <kiko> carlos, if you implement "translation search" we can fix them using rosetta :-)
[05:42] <carlos> a) yes, b) yes, c) yes d) yes
[05:42] <kiko> thanks!
[05:42] <kiko> I love jackpots!
[05:42] <carlos> :-P
[05:42] <Kinnison> stub: aah cool
[05:42] <carlos> kiko: so, is this related to the problem matsubara is fixing?
[05:43] <kiko> carlos, this is the exact same problem, but I have assigned matsubara to something else -- I think this is something you're better off testing and fixing.
[05:44] <carlos> kiko: I'm not asking for matsubara to fix it, I'm just asking to know if I need to deal also with the other bug ;-)
[05:44] <ddaa> stub: okay for me to send https://chinstrap.ubuntu.com/~dsilvers/paste/filezQs3xR.html with r=stub?
[05:44] <kiko> carlos, yeah, and no, it's just one bug. 
[05:44] <carlos> kiko: ok, seems like this came from my branch, or at least it's there too
[05:45] <kiko> carlos, yeah, tough luck, your bug, you fix it :)
[05:45] <carlos> :-P
[05:45] <ddaa> (might need extra adjustment, full test suite running)
[05:45] <stub> ddaa: Sure, but it won't land without the people merge code being updated too
[05:46] <ddaa> ha, I did not realise that this was actually breaking on people merge...
[05:46] <carlos> kiko: so do you want a migration script or just leave them and fix with the search feature when it's implemented?
[05:46] <stub> ddaa: Do you need it landed now, or do you want to pass the branch over to me to land?
[05:46] <kiko> carlos, a) how long is the search feature going to take to get done b) can you at least contact the owners of the pofiles and tell them what is wrong so they know and can fix it?
[05:47] <stub> ddaa: The people merge code is paranoid - it analyzes the database schema and fails when it detects a structure we are not explicitly handling that it can't deal with itself.
[05:47] <ddaa> the sooner the better, I do not know what people merging look like, but I'm willing to give it a shot. Not sure I will have the time tonight though, as I'm on a collision course with my SO.
[05:48] <stub> ddaa: ok. I'll apply your patch and land a fix tomorrow.
[05:48] <carlos> kiko: a) I don't have any idea as the spec is not even approved b) Will do as soon as the 'structure' tag is removed and they can actually fix it
[05:48] <kiko> carlos, agreed. 
[05:48] <kiko> carlos, I'd love the spec, at least a small part of it, to be implemented soonish.. but get your dapper shoes polished first. 
[05:49] <carlos> dapper thing is almost done
[05:49] <kiko> wonderful
[05:49] <carlos> at least the critical part, I need to ask some extra removals and I think we can deal with whatever is missing from time to time
[05:50] <carlos> kiko: there are 'only' 2000 entries on the queue from the 29000 we had last week
[05:51] <kiko> carlos, wonderful -- does this mean that the translation statistics for today are going to look great?
[05:51] <carlos> kiko: they should, but they are not looking great....
[05:52] <carlos> kiko: the export log says that we have twice the number of pofiles we had last week, but pitti's email says we have no changes...
[05:52] <carlos> something went wrong here...
[05:53] <SteveA> bradb: !
[05:53] <carlos> hmm, and pitti is not around so I cannot check it with him now...
[05:53] <carlos> kiko: if you look at http://mawson.ubuntu.com/~carlos/rosetta-dapper-2006-04-25.log vs http://mawson.ubuntu.com/~carlos/rosetta-dapper-2006-04-21.log
[05:53] <carlos> kiko: you can see the difference
[05:54] <carlos> we had a problem with the exports from 22 until today, a lock was breaking the exports, but we fixed it today
[05:54] <kiko> carlos, perhaps that's the problem -- the script ran too early?
[05:55] <kiko> carlos, that looks awesome!
[05:55] <carlos> kiko: not sure, I need to check with martin 
[05:55] <kiko> ok
[05:56] <carlos> kiko: yeah, and most of those changes are just KDE being imported... I think KDE is 2/3 of dapper's .po files
[05:56] <kiko> wow
[05:57] <carlos> yeah they split them a lot
[05:57] <carlos> ok, let's fix some bugs ;-)
[05:58] <carlos> kiko, matsubara: thanks for debugging the problem
[05:58] <kiko> carlos, no worries, enjoy 
[05:58] <kiko> and matsubara was right after all
[05:58] <kiko> it /was/ browser dependent
[05:59] <kiko-fud> carlos, make sure your test catches the fact that "<" and ">" are /not/ present inside the textarea content
[06:00] <kiko-fud> carlos, it's tricky making pagetests that ensure that something is not in the page
[06:01] <carlos> kiko-fud: well, I don't think is so tricky, just test for &lt; and &gt; if they are not there, '<' and '>' would be there, right?
[06:01] <kiko-fud> carlos, well, sorta -- what if the sampledata has a literal &lt; in it?
[06:02] <stub> There are funky new tools in Z3.2 for writing page tests and page test like things easier - just needs someone to go through and work out what is useful to us and throw together some examples.
[06:02] <kiko-fud> maybe you should just test that the view's getTranslation method returns a string with no "<" or ">" in it, and fiddle with sampledata adding a string that contains it.
[06:02] <carlos> it will appear as &lt; but never as '<', right?
[06:02] <SteveA> stub: bjorn and i were talking about that over lunch
[06:02] <SteveA> stub: i asked bjorn to try using the new stuff for his current work
[06:02] <SteveA> see how it goes
[06:02] <kiko-fud> time for fud
[06:02] <SteveA> and then we can write new docs depending on how that goes
[06:03] <carlos> kiko-fud: yeah, the idea is to submit and fetch texts that has a '<' char
[06:03] <carlos> the form should not have it ever
[06:04] <Kinnison> stub: when did librariangc last run?
[06:04] <carlos> SteveA, stub: I guess it would mean that we will need to rewrite our pagetests, right?
[06:04] <SteveA> yes, over time
[06:04] <carlos> kiko-fud: enjoy it
[06:04] <SteveA> we'll just rewrite the ones we touch, to start with
[06:04] <carlos> ok
[06:05] <stub> If I'm right, it will be much easier rewriting a failing pagetest than fixing a broken one - I find fixing them is really fiddly and time consuming
[06:05] <SteveA> yeah
[06:08] <mdke> I think " status: fix released" should work when in a bug mail, what do you guys think?
[06:11] <Kinnison> stub: I'm concerned that I'm finding duplicated LFC records
[06:12] <stub> Kinnison: Hmm... looks like the cron job has gone missing
[06:12] <kiko-fud> mdke, sounds reasonable. doesn't it?
[06:12] <Kinnison> stub: it's been missing a long time then
[06:13] <Kinnison> stub: any chance of it being started pretty soon?
[06:13] <Kinnison> stub: then I'll hold off on my stuff until the LFCs are coalesced
[06:13] <stub> Sure.
[06:13] <Kinnison> thanks
[06:13] <Kinnison> it'll be easier to just use lfa.content rather than having to drill into lfa.content.sha1 and lfa.content.filesize
[06:14] <Kinnison> probably quicker too :-)
[06:15] <mdke> kiko-fud, well, I tried closing two bugs that way. It would be useful for those people who made a vague attempt at reading the documentation, but didn't really do so thoroughly
[06:20] <BjornT> mdke: i agree, it should work. could you please file a bug about it?
[06:20] <mdke> BjornT, you bet
[06:23] <mdke> BjornT, bug 41329
[06:23] <Ubugtu> Malone bug 41329 in malone "allow spaces in status name when changing status by email" [Minor,Unconfirmed]  http://launchpad.net/bugs/41329
[06:24] <BjornT> thanks
[06:26] <ddaa> stub: here is a doctest for branch handling when merging people
[06:26] <ddaa> https://chinstrap.ubuntu.com/~dsilvers/paste/fileraBhNY.html
[06:27] <ddaa> I have to run now, I might not have the time to do any more today. Anyway, you can do the sql stuff better and faster than me even in your sleep.
[06:29] <ddaa> stub: and one w/o broken line breaking: https://chinstrap.ubuntu.com/~dsilvers/paste/fileJ6Ax6x.html
[06:42] <saik0> Launchpad Ubuntu CoC signing problem https://launchpad.net/distros/ubuntu/+bug/41334
[06:42] <Ubugtu> Malone bug 41334 in Ubuntu "Cannot sign Ubuntu Code of Conduct 1.0.1" [Normal,Unconfirmed]  
[06:45] <sfllaw> saik0: I can confirm it.
[06:45] <sfllaw> I tried to sign it yesterday.
[06:45] <sfllaw> No dice.
[06:46] <sfllaw> 1.0 works, though.
[06:46] <carlos> kiko-fud: pitti's script was run 7 minutes before the language pack generation finished
[06:46] <carlos> kiko-fud: he's running it again now. and we moved it 30 minutes later
[06:46] <carlos> to prevent this to happen again
[06:46] <saik0> sfllaw, same. I can sign 1.0 fine
[06:48] <salgado> saik0, sfllaw, that's a bug in launchpad actually
[06:50] <salgado> stub, are we running head on production?
[06:50] <saik0> salgado, can you file launchpad bugs in launchpad?
[06:51] <salgado> yeah, sure. https://launchpad.net/products/launchpad
[06:53] <saik0> salgado, thanks. wow, why could'nt I find that
[06:56] <salgado> saik0, probably because it's (unintentionally) well hidden. :/
[07:06] <carlos> see you later tonight
[07:08] <stub> salgado: yes
[07:18] <salgado> cprov, are you using mawson's db?
[07:18] <salgado> stub, are you going to be around during the next 15min or so?
[07:18] <cprov> salgado: yes, it has edgy oppened
[07:18] <salgado> cprov, and you're running a launchpad instance there, I guess?
[07:19] <cprov> salgado: yep
[07:19] <salgado> cprov, which codeline?
[07:19] <cprov> salgado: it's not mandatory, though
[07:19] <cprov> salgado: current
[07:20] <cprov> salgado: it has lp-upstream (lastest or so)
[07:20] <cprov> salgado: if you need update, I don't mind
[07:21] <salgado> yeah, I saw that... I'm going to run the mirror-prober script from there. don't think it can cause you any harm
[07:23] <cprov> salgado: it must not ;), no problem 
[07:24] <mdz> bradb: is it possible to have the "subscribe me" checkbox closer to the "add comment to this bug" rather than having to mouse down below the comment box to uncheck it?
[07:24] <Seveas> mdz, heh, I was about to complain about that one too 
[07:25] <mdz> bradb: those of us who trawl through a lot of bugs without wanting to be subscribed would appreciate it
[07:34] <bradb> mdz: I'm confused. You have to scroll down to hit the button to submit the comment, so how is it more effort to uncheck that box when it's near the submit button? (not that I'm saying the UI's great, just curious.)
[07:35] <mdz> bradb: because I click it before I type in the comment, so that I don't forget
[07:36] <mdz> so my clicks go: add a comment, uncheck subscribe me, focus the comment box, then submit
[07:36] <bradb> ah, so you're saying that where it currently is, it's easy to forget to uncheck it before submitting
[07:37] <mdz> maybe; personally I see it immediately, notice that I want to change it, and do it right away
[07:39] <bradb> ah, ok, i know the feeling
[07:39] <bradb> mpt was going to look at that UI tomorrow to smooth it out, so I'll send him an email noting what you guys said
[07:39] <mdz> thanks
[07:40] <mdz> I like the checkbox, by the way; too often I've had to subscribe someone who commented because i need to ask them a question
[07:41] <bradb> yeah, should make life a little easier, i hope
[07:45] <Seveas> I even didn't see the checkbox, I use <enter> to send the comment 
[07:45] <Seveas> and the checkbox wasn't visible 
[07:48] <Seveas> lp broken? I get timeouts...
[07:49] <Seveas> started ~1 minute ago
[07:51] <Seveas> ah, works again
[08:06] <jordi> carlos: ping
[08:07] <jordi> https://launchpad.net/people/uzbek/+review was never added to ubuntu translators
[08:07] <jordi> err
[08:07] <jordi> https://launchpad.net/people/ubuntu-l10n-uz
[08:31] <sits> ah fudge
[08:31] <sits> I didn't mean to start an argument on the devel mailing list with my bug voting comment
[08:32] <mdke> sits, it's not an argument, don't worry.
[08:33] <sits> I dunno. One of the replies was kind of long
[08:33] <mdke> that's not a bad thing. We should move channel if you want to discuss more though
[08:34] <sits> you know you've failed to express yourself properly when someone starts talking about elitist developers
[08:34] <sits> mdke: oh right
[08:34] <sits> which channel?
[08:34] <mdke> sits, #ubuntu-devel?
[08:35] <sits> ok
[08:42] <SteveA> kiko: ping
[08:46] <kiko> SteveA, sorry, see privmsg need 5 more minutes :-/
[08:51] <bradb> salgado: Any chance of a followup to the bug dates review today?
[09:02] <cprov> bradb: how do you build an rfc2047 compilant recipient for sending email from malone ? is there any specific code ?
[09:03] <kiko> or BjornT 
[09:03] <kiko> carlos, I saw we generated another report.. but it still says we miss some 300 templates
[09:04] <bradb> cprov: No idea. Maybe BjornT would know.
[09:07] <BjornT> cprov: do you mean generating: 'Name <email>', where Name can contain non-ASCII characters?
[09:07] <kiko> yes
[09:07] <BjornT> ok, then use canonical.launchpad.mail.format_address
[09:08] <kiko> why don't you use it for the recipient name in Malone mail?
[09:08] <kiko> BjornT, also, I wonder whether that code is actually in accord to rfc-2047.
[09:09] <BjornT> don't know, should we? at the moment we use only the email address, i think that's enough
[09:09] <BjornT> kiko: what makes you think it doesn't work as specified in rfc 2407?
[09:12] <kiko> BjornT, I think we should, but I'm not picky.
[09:13] <SteveA> rfc 2047 ?
[09:13] <SteveA> oh, 2407
[09:13] <kiko> BjornT, because I think rfc2047 is a bit more complicated than that -- at least the code we have from katie does it differently.
[09:13] <SteveA> rcf 2407 ?
[09:13] <kiko> are you guys crazy
[09:13] <kiko> 2 0 4 7
[09:13] <kiko> 2407 is something else
[09:13] <BjornT> yes, 2047
[09:14] <SteveA> hurra
[09:14] <SteveA> nothing to do with triple DES encoding of IP domain thinggie
[09:14] <BjornT> kiko: where can i see the katie code? i'd like to see what it does.
[09:14] <kiko> cprov, can you email the code to BjornT?
[09:14] <cprov> BjornT: apparently, there are fancy things related with names containing '.' and ',' in the rfc. Nonetheless, I; m going to use your format_address
[09:16] <cprov> BjornT: look at lib/canonical/archivepublisher/utils.py on fix_maintainer function
[09:17] <kiko> anyway
[09:18] <BjornT> bradb: if you're going to use testbrowser you can get r3499 from bjorn/launchpad/bugwatches-rework, it modifies test.py so that you can use testbrowser. you also need to install python-mechanize.
[09:18] <SteveA> BjornT: we should make that a formal dependency
[09:18] <kiko-afk> bradb, what BjornT is saying is "wait a week"
[09:18] <bradb> hmph
[09:20] <BjornT> SteveA: yes, i was going to do that tomorrow. what's the procedure for adding a dependency to launchpad?
[09:20] <SteveA> i don't know anymore
[09:20] <SteveA> ideally, get the dependency added to the launchpad-dependency packages
[09:20] <SteveA> jeff b. would do that
[09:20] <SteveA> stu would know better
[09:20] <kiko-afk> pretty much
[09:22] <BjornT> yeah, i'll ask stub tomorrow.
[09:22] <SteveA> ok
[09:23] <stub> http://stuartbishop.net/Software/EmailAddress/index.html handles Unicode email addresses, including Unicode domain names.
[09:23] <stub> I have no idea about launchpad-dependancies. I submit them into Launchpad and waited until Lifeless updated things last time.
[09:23] <BjornT> kiko-afk, cprov: format_address produces an rfc 2047 compliant string.
[09:24] <cprov> BjornT: okay, will use it 
[09:24] <SteveA> BjornT: please email launchpad dev list, and cc jeff b. about adding that dependency.
[09:25] <bradb> SteveA: So, re: the patch for bug 36866, it's not really feasible to write a test that /really/ tests what the bug report is about until we can use zope.testbrowser.Browser.
[09:25] <Ubugtu> Malone bug 36866 in malone "Searching for bugs after selecting a certain status from the Right-Hand-Menu resets the search" [Major,In progress]  http://launchpad.net/bugs/36866
[09:25] <SteveA> bradb: that's not going to be long.  i think you can wait, and meanwhile, you can get it working on your own branch, ready to merge
[09:26] <bradb> ok
[09:26] <bradb> I was planning to convert all of bugtask-search-pages.txt to use z.tb.B anyway. Should make it much more readable.
[09:27] <bradb> BjornT: So, even still, I'll need to merge from your branch first?
[09:27] <cprov> BjornT: are the doupble quotes expected in __"Zak B. Elep" <zakame@ubuntu.com>__ ?
[09:27] <BjornT> cprov: yes, since it contains '.'
[09:27] <kiko-afk> aha
[09:28] <cprov> BjornT: when sending emails, the To: headers remains only the email 
[09:28] <kiko-afk> BjornT, did you look at the code in fix_maintainer?
[09:28] <cprov> BjornT: uhmmm
[09:31] <BjornT> kiko-afk: i looked at it briefly. 
[09:32] <kiko-afk> it does weird things
[09:33] <bradb> BjornT: Can you give me just the diff for test.py so I don't have to merge the whole branch?
[09:37] <BjornT> kiko-afk: yeah, it looks kind of broken, but i'm not sure what format the input is in.
[09:37] <BjornT> bradb: well, you don't have to merge the whole branch, just the revision i gave you. but hold on, i'll give you the diff.
[09:38] <cprov> BjornT: DISPLAYNAME <EMAILADDRESS>, as docummented in tests/test_utils.py
[09:39] <cprov> BjornT: to have that much obsolete code sounds really depressing, it might have something special from debian
[09:40] <ddaa> grah... I'm so bad at SQL :(
[09:40] <BjornT> cprov: what about if DISPLAYNAME contains characters that need to be quoted?
[09:41] <ddaa> anybody feels like teaching me, or should I just wait for stub to do the hard work tomorrow?
[09:41] <cprov> BjornT: it does weird things like returning '<EMAIL> (NAME)'
[09:42] <lucasvo> how can I register a project in launchpad? does it cost anything?
[09:42] <lucasvo> is it possible to have commercial projects in launchpad?
[09:42] <ddaa> profit!
[09:42] <ddaa> lucasvo: you just need a launchpad account
[09:42] <BjornT> cprov: only if DISPLAYNAME contains '.' or ','. there are a lot of other characters than need quoting.
[09:43] <ddaa> you can register anything, but the system is mostly designed to be useful to free software projects
[09:43] <ddaa> but any openly developped project can benefit
[09:43] <lucasvo> ok
[09:44] <ddaa> the sabdfl has some plan for "private" projects and distros, mostly for things that are planned to be released eventually, but it's not there yet (and it's a difficult problem)
[09:44] <cprov> BjornT: but this format is compilant with rfc2047 ? I mean the '<email> (DISPLAYNAME)'
[09:44] <ddaa> though I'm sure you will have his ear if you have some money to put in it :)
[09:46] <lucasvo> ddaa: ok, thanks
[09:51] <BjornT> cprov: AFAIK, yes. but what would be interesting to know is the restrictions of the Maintainer and Changed-By fields are. what characters can DISPLAYNAME contain, and are they properly quoted.
[09:52] <BjornT> bradb: https://chinstrap.ubuntu.com/~dsilvers/paste/file41BJqa.html
[09:53] <bradb> BjornT: thanks
[10:04] <bradb> BjornT: Hm, it seems that our version of python2.4-clientform doesn't work with z.tb.B
[10:05] <bradb> AssertionError: ClientForm >= 0.2.1a is required
[10:05] <kiko-afk> bradb, is that dapper?
[10:06] <bradb> very dapper
[10:06] <BjornT> bradb: really? what did you do to get that error?
[10:07] <bradb> BjornT: ran a simple test that uses z.tb.B
[10:07] <BjornT> bradb: can you paste the test somewhere? i did some simple tests and it worked.
[10:08] <cprov> BjornT: so, using the default format_address seems to be a fair solution, I miss an API based EmailAddress content class
[10:10] <bradb> BjornT: Just:
[10:10] <bradb>     >>> from zope.testbrowser import Browser
[10:10] <bradb>     >>> browser = Browser()
[10:10] <bradb> is enough
[10:11] <bradb> Are your packages right up to date?
[10:11] <BjornT> bradb: hmm, that works for me. what's the traceback?
[10:11] <bradb> I just updated as of 10-15 mins ago
[10:11] <BjornT> bradb: yes, i updated today, not long ago. i'll update again now.
[10:13] <bradb> BjornT: https://chinstrap.ubuntu.com/~dsilvers/paste/file7gbgJ3.html
[10:17] <kiko> salgado, ping?
[10:19] <salgado> kiko, pong
[10:19] <BjornT> hmm, i have the 0.2.0.99-1 package installed, but ClientForm.VERSION returns '0.2.1b'
[10:19] <kiko> salgado, privmsg
[10:19] <kiko> BjornT, no /usr/local versions installed?
[10:19] <bradb> BjornT: 
[10:19] <bradb> >>> ClientForm.VERSION
[10:19] <bradb> '0.1.17'
[10:21] <BjornT> kiko, bradb: i just uninstalled the package, resulting in that i couldn't import ClientForm. i installed it again, and it still shows 0.2.1
[10:21] <BjornT> bradb: 0.1.7 seems wrong, though. do you have any old versions installed?
[10:22] <bradb> er, yeah, looking at the pkg version, i must have an old one floating around
[10:22] <bradb> an old CF, that is
[10:24] <bradb> __file__ tells all
[10:24] <kiko> stop waving red herrings around
[10:40] <kiko> BjornT, remind me -- do we now notify by email when the remote bugwatch's status changes?
[10:44] <BjornT> kiko: no, not yet. it's next on my list after the current bug watches work.
[10:46] <kiko> BjornT, thanks. and I had another consideration.
[10:46] <kiko> BjornT, you know the plan to do away with priority?
[10:46] <BjornT> yeah
[10:46] <kiko> well
[10:46] <kiko> I was thinking. what will we do about other bug trackers that implement it?
[10:47] <kiko> I mean, that information doesn't really map well 1-to-1 with our Importance.
[10:47] <kiko> and any conversion we do will just end up being confusing, won't it?
[10:47] <BjornT> i'd imaging we map it into importance. other bug tracker's statuses don't map 1-to-1 to our statuses, we still map them.
[11:01] <salgado> kiko, https://dogfood.ubuntu.com/distros/ubuntu/+mirror/brazilllll
[11:01] <salgado> no time outs during the last probe
[11:05] <lifeless> moin moin
[11:06] <kiko> salgado, you are DE MAN
[11:06] <kiko> salgado, however, I should tell you one thing
[11:07] <kiko> that list is VERY long and not really sorted or sortable
[11:07] <kiko> so I'm asking myself if the tabular format is actually appropriate
[11:08] <kiko> or if we should, instead, have multiple tables
[11:09] <salgado> or if we should do that only for the in-developement distrorelease and the latest stable one?
[11:09] <salgado> and have some more concise for the other ones?
[11:09] <kiko> right
[11:09] <kiko> let's ask the people who matter!
[11:09] <salgado> anyway, I've already asked these questions myself
[11:10] <kiko> oh!
[11:10] <salgado> I first wanted to check with mpt if he has any suggestions. before start stripping things off 
[11:10] <kiko> okay, cool
[11:11] <kiko> salgado, how long timeout are you using there?
[11:11] <salgado> you don't wanna know!
[11:11] <salgado> with 40 seconds I got lots of timeouts. then I changed it to 90 seconds and didn't get any
[11:15] <kiko> salgado, I guess that's.. okay
[11:19] <kiko> salgado, the breadcrumbs on that page.. seem wrong.
[11:20] <salgado> why? It's the same as in other pages under /distros/ubuntu/, isn't it?
[11:20] <kiko> salgado, colour-coding the status would help as well, perhaps
[11:24] <kiko> salgado, what happened to the content on that page?!
[11:24] <kiko> I was showing it off to mdz!
[11:25] <salgado> I did another probe
[11:25] <mdz> hehe
[11:25] <mdz> demo effect
[11:25] <salgado> and this one failed
[11:25] <kiko> with 90 seconds, no less?
[11:25] <kiko> you sandbagged my demo. snif
[11:25] <lucasvo> is it possible to change the email address in launchpad?
[11:25] <salgado> it takes less than one minute to probe that mirror
[11:26] <salgado> kiko, the content should be back quickly
[11:26] <kiko> okay
[11:26] <salgado> yes, it's back now
[11:27] <salgado> you need to tell me when you're demoing something that I'm testing.
[11:27] <kiko> yeah yeah
[11:28] <salgado> lucasvo, yes, it is. on your personal page you should see an 'Email Addresses' link
[11:28] <salgado> lucasvo, on the top left corner
[11:28] <lucasvo> Your preferred contact address for all Launchpad e-mail is:
[11:28] <lucasvo> I want to change this
[11:29] <salgado> lucasvo, in this case you need to add a new one and confirm it
[11:30] <lucasvo> ic, ok
[11:30] <lucasvo> salgado: thanks
[11:30] <welshbyte> lucasvo: 1) add new email address and confirm 2) set new email address as contact address 3) remove original email address
[11:38] <lucasvo> hm, strange, I can't sign the COC
[11:38] <lucasvo> it reports a str error
[11:38] <lucasvo> http://pastebin.com/681853
[11:39] <kiko> https://launchpad.net/products/launchpad/+bug/39547
[11:39] <Ubugtu> Malone bug 39547 in launchpad "Code of Conduct 1.0.1 signatures not accepted" [Normal,Confirmed]  
[11:39] <kiko> lucasvo?
[11:40] <lucasvo> yeah
[11:40] <lucasvo> kiko: thank
[11:41] <jordi> good night lp!
[11:51] <viajero> hi, anyone around?
[11:55] <welshbyte> hm i've just realised that i have a duplicate launchpad account that i registered a while before the one i now use and must have forgotten about
[12:00] <lucasvo> welshbyte: just delete it :)
[12:01] <welshbyte> lucasvo: i might do, if i could remember the email and password i used to log into it :)
[12:02] <lucasvo> welshbyte: you can try to search there: https://launchpad.net/people