[12:05] <sabdfl> kiko-zzz: got a sec?
[12:19] <Mez> how do I go about including stuff in rosetta for my app
[12:25] <ddaa> spiv: david/launchpad/productseries-branch-oops reviewed, fixed, and pushed
[12:25] <spiv> ddaa: Thanks
[12:26] <ddaa> goodnight
[12:39] <Mez> does LP support pot files for translation?
[01:00] <mpt_> Goooooooooooooooood afternoon Launchpadders!
[01:20] <mez> hmm
[01:21] <mez> lp is timing out on trying to view rosetta import queue
[01:22] <mpt_> sabdfl, an Overview menu may refuse to display if (a) you're using GeneralForm and (b) my 2006-02-menus branch hasn't landed yet
[01:22] <mpt_> (somehow I managed to fix that bug)
[01:23] <sabdfl> mpt_: that's pretty darn impressive
[01:23] <sabdfl> i just filed that bug, and assigned it to stevea
[01:23] <sabdfl> s/stevea/mpt/g for future reference ;-)
[01:24] <sabdfl> mez: yes, there's a known performance issue when we dump a new distro release into rosetta's queue
[01:24] <mez> sabdfl: ah ok :D just wondering :D
[01:24] <sabdfl> mpt_: the main issue turned out to be that the plain pages didn't have any facet specified
[01:24] <mez> people are moaning we dont have translations for katapult
[01:24] <mez> I'm trying to sort that out
[01:24] <sabdfl> the GeneralForm issue is trickier - i didn't look deeply into i
[01:24] <sabdfl> t
[01:31] <Mez> hmm while I'm here... I'd like to bring up (again) the issue of the best way to request backports through launchpad
[01:32] <Mez> as making a bug against a pseudo-package seems the wrong way to do it to me
[01:32] <mpt_> Mez, there's now a menu item specifically for that
[01:32] <Mez> mpt_, you mean the target to release thing?
[01:33] <mpt_> Mez, yes, it's now called "Backport Fix to Releases"
[01:33] <Mez> ah 
[01:33] <Mez> well thats for -updates really isnt it?
[01:33] <Mez> I'm on about -backports
[01:34] <Mez> requests to backport a whole version - not a bugfix 
[01:34] <mpt_> oh
[01:34] <Mez> ;)
[01:34] <Mez> yeah
[01:34] <Mez> bradb got confused about that too
[01:34] <mpt_> Hmm, aren't backports a pocket?
[01:34] <Mez> mpt_, yes
[01:35] <mpt_> (we have GOT to find a better name for that)
[01:35] <mpt_> So cprov or Kinnison would know more about that.
[01:35] <Mez> basically we just want a place where people cna say something like" can i get the dapper version of k3b in breezy"
[01:36] <mpt_> The worst part of it is, we use "pocket" in the "Launchpad FAQ" without explaining it
[01:36] <mpt_> Mez, wouldn't you get people asking for that for every package?
[01:36] <Mez> mpt_ possibly...
[01:37] <Mez> but to be honest - we get requests mainly for things that are like - desktop apps.
[01:37] <Mez> but at the mo  it's all going through a forum which sucks ass
[01:37] <Mez> the original idea was to model backports as a derivative distro in LP
[01:38] <Mez> so requests could be filed against the "distro" and any bugs with backported ackages could be filed against the package in the "distro"
[01:38] <Mez> which seems to be a good idea to me ... but meh - it doesnt seem possible
[01:38] <Mez> I should talk to Kinnison though when he has time
[01:39] <Mez> I was meant to go to cambridge to discuss this whole thing but didnt have the time to
[01:52] <Mez> hmm can someone remove my request to import katapult .pot file?
[01:52] <Mez> apparently someones already been translating it
[03:35] <jblack> kinnison: here good?
[03:35] <Kinnison> sure
[03:36] <jblack> I made launchpad packages that do dependancies and have the new rocketfuel scripts.
[03:36] <jblack> They're my first sets of packages, so I'd like somebody to look them over and smack me up a little bit.
[03:36] <Kinnison> Sure, dump the source somewhere I can grab it and email me a pointer to them
[03:37] <Kinnison> I'll look in the morning
[03:37] <jblack> awesome. thanks
[07:11] <jamesh> stub: staging.ubuntu.com is giving a proxy error
[08:25] <mpt_> well, that's not good
[08:25] <mpt_> power supply isn't working any more :-/
[09:03] <sivang> morning.
[09:07] <sabdfl> hey guys
[09:07] <sabdfl> is there a "refuel" equivalent for launchpad-on-bzr?
[09:09] <sabdfl> something that I can run from the root of a lp working directory, and which will look at a copy of the current built-rocketfuel and merge from each of the relevant sub-trees into my tree?
[09:09] <sabdfl> mpt_: oops
[09:09] <sabdfl> pedal power :-)
[09:09] <jamesh> sabdfl: jblack has been working on such a script
[09:10] <jamesh> I'm not sure where they are though (I think he wanted someone to look over them before getting them widely used)
[09:14] <sabdfl> is there a command to show the tree, and the revisions of each sub-tree?
[09:15] <sabdfl> mpt_: any progress on the 2col main_template?
[09:15] <mpt_> sabdfl, haven't finished that yet sorry
[09:22] <sabdfl> mpt_: np
[09:22] <sabdfl> i have to work elsewhere for a while, if you can land it in the next week, i'm happy
[09:27] <mpt_> ok
[09:45] <carlos> morning
[09:46] <sabdfl> ok, so i can generate a list of the subdirectories that have .bzr in them:
[09:46] <sabdfl> find . -name .bzr | xargs -n 1 dirname
[09:46] <sabdfl> how do i make a command using that, which will cd into each of those and tell me what revision it is at?
[09:50] <carlos> sabdfl: take a look to the rocketfuel-refresh script at https://wiki.launchpad.canonical.com/RocketFuelSetup
[09:50] <jordi> carlos: morning
[09:50] <jamesh> bzr revno
[09:50] <Lathiat> for i in (...); (cd $i; some command); done
[09:50] <Lathiat> ? :)
[09:50] <jordi> carlos: ok, stub did his part on Akan. What's needed now?
[09:51] <carlos> jordi: that stub or lifeless or any other admin do the change from the website, now that the languages are using hte right language code
[09:51] <jordi> ok, should I reopen and assign to LP admins?
[09:51] <stub> jamesh: fixed. The launchpad server did not shut down properly during the staging update, so the new instance could not start up.
[09:51] <jordi> (is this workflow good for all the parts?)
[09:52] <jordi> stub: thanks dude
[09:52] <sabdfl> carlos: ok, willdo
[09:53] <carlos> jordi: yes, as stub fixed only the first part of the bug
[09:53] <jordi> yup
[09:54] <sabdfl> jamesh: how do i take a file (or series of dirs from std in on newlines) and use bzr revno with that?
[09:56] <jamesh> sabdfl: I suppose something like this would work: find . -name .bzr | xargs -n1 dirname | while read dir; do echo -n "$dir "; bzr revno $dir; done
[09:56] <jamesh> that'd print the directory plus revision number
[09:56] <mpt> jamesh, the Pending Branch Summary says "Run Date: 2006-03-02 00:42:15 UTC", and next to mpt/launchpad/2006-02-headings it has "Time" of 02:22. Does that mean my branch was last checked 22 hours ago?
[09:56] <sabdfl> jamesh: you rock, thank you!
[09:57] <jordi> gee, I get timeouts when selecting persons or teams
[09:58] <jamesh> mpt: checking.
[09:59] <jordi> carlos: done
[09:59] <jamesh> mpt: no.  It meant that the checkout/merge/diff took 2 minutes, 22 seconds to complete
[10:00] <mpt> hrmmm
[10:00] <mpt> jamesh, it's just that when I started work today the first thing I did was resolve the 6 conflicts in it, and now there are apparently 9 conflicts in it
[10:00] <mpt> 6 of which are the same
[10:00] <jamesh> mpt: there is a pending-reviews run part way through right now
[10:01] <mpt> and I just pushed again and bzr said "Nothing to do."
[10:01] <jamesh> mpt: doesn't look like you've got any conflicts in the latest run.
[10:01] <mpt> great, thanks jamesh 
[10:01] <jamesh> actually, yes you do
[10:02] <mpt> d'oh
[10:02] <jamesh> there is one conflict
[10:02] <jamesh> https://chinstrap.ubuntu.com/~jamesh/pending-reviews.new/mpt/launchpad/2006-02-headings/full-diff <- in lib/canonical/launchpad/templates/bugtask-backport-fixing.pt
[10:03] <mpt> It can wait till tomorrow afternoon then
[10:04] <jamesh> mpt: the pending-reviews run didn't notice any conflicts while merging.  Is it possible that you committed conflict markers in your branch?
[10:04] <ddaa> hey jamesh!
[10:05] <mpt> jamesh, if I did, our test coverage isn't up to scratch
[10:05] <mpt> I'll check tomorrow
[10:05] <ddaa> mpt: s/if I did, //
[10:06] <ddaa> jamesh: how is it going?
[10:06] <mpt> ohhh, so I did
[10:07] <mpt> +<<<<<<< TREE
[10:07] <ddaa> looks like a palm tree to me
[10:08] <mpt> looks like a scalpel left inside the body cavity after it's sewn up to me
[10:08] <mpt> anyway. dinnertime.
[10:13] <ddaa> hu, jamesh, ping?
[10:14] <ddaa> spiv: pingy?
[10:15] <jamesh> ddaa: sorry.  was getting a drink
[10:15] <spiv> ddaa: pongy!
[10:16] <ddaa> jamesh: spiv: so, "how is it going?"
[10:17] <spiv> ddaa: you should have got bug mail for 32106...
[10:18] <ddaa> spiv: no commit mail, what the status of rename-buttress and productserie-branch-oops?
[10:19] <spiv> stub: ping
[10:19] <spiv> ddaa: I'm just waiting for DBA approval and patch number for rename-buttress
[10:20] <ddaa> spiv: how many hours of work do you have left today?
[10:21] <spiv> ddaa: I'm mainly going to be at work from now until the lp meeting.
[10:21] <stub> spiv: pong
[10:21] <ddaa> spiv: so I guess you do not need me to take over. That would probably just cause needless communication overhead.
[10:22] <spiv> stub: did you get my email about the rename-buttsource branch?
[10:22] <spiv> stub: I'm seeking your DBA blessing
[10:22] <stub> I can't see the email...
[10:22] <ddaa> jamesh: how is the buildbot error reporting stuff progressing?
[10:23] <spiv> stub: Hmm.  That would explain why you haven't responded...
[10:24] <spiv> stub: It was sent to stuart.bishop@canonical.com, and CCed to launchpad-reviews.
[10:25] <spiv> stub: https://lists.ubuntu.com/mailman/private/launchpad-reviews/2006-March/002569.html
[10:25] <stub> Found it in my box. Wasn't following that thread.
[10:26] <spiv> Ah.  I assumed that putting you in the To: field would be enough to bring it to your attention, but I guess not everyone sorts their mail the same way I do...
[10:27] <stub> spiv: approved. patch-40-26-0.sql
[10:27] <stub> spiv: All that means is I get two copies filtered away together.
[10:28] <ddaa> stub: filtering mailing lists on List-Id instead of To would leave CCs in your inbox, some people find that useful.
[10:28] <spiv> stub: Thanks
[10:29] <stub> ddaa: If it has a list-id, it belongs in the list. i like to keep my inbox as just stuff-my-filters-couldn't file to keep it a sane size.
[10:30] <ddaa> stub: that's the point, when your are CCed on a ML message, one of the messages does not get a List-Id header.
[10:30] <ddaa> so people can get your attention with a CC.
[10:31] <stub> ddaa: Nah - then you end up responding to messages that have already been dealt with in the mailing list, and you miss out on all the surrounding context.
[10:31] <ddaa> Okay, I shoud have assumed you knew that already. I did not mean to sound like I was talking down to you.
[10:34] <stub> More like trying to teach an old dog new tricks. I like my system :-)
[10:38] <stub> Has anyone worked out a funky way of dealing with the volume of messages on launchpad-bugs?
[10:41] <ddaa> stub: I sort on List-Id, so I get mail for bugs I subscribed to in my inbox, and I have an evolution vfolder that shows only unread (or tagged) messages. Once a day, I skim over the titles for anything that looks like it would be of interest and mark most of them as "read" without further ado.
[10:41] <ddaa> (that shows only unread messager for that mailing list)
[10:42] <ddaa> I leave reading an classifying of  most new bugs to the Daf Harries Bug Triage One Man Team.
[10:42] <spiv> stub: I hit my "Tab" key a lot.
[10:43] <spiv> stub: I suppose if I put on funky music while I do it...
[10:44] <ddaa> you know so called "graphical" mail readers have a nifty feature called "selection" which allows you to mark several messages as read in one operation :)
[10:45] <stub> carlos: You set status=5 on TranslationImportQueueEntry rows that have is_blocked = FALSE twice. 
[10:45] <stub> carlos: I think one of these should be to update is_blocked = TRUE rows. What status should those have?
[10:46] <spiv> ddaa: so does mutt, but it's typically faster to just hit tab :)
[10:46] <carlos> stub: blocked should be 6
[10:47] <ddaa> okay, evo is sorta an annoyingly slow dog...
[10:47] <carlos> so if is_blocked=TRUE, status must be 6
[10:47] <carlos> stub: thanks for caching it
[10:47] <stub> carlos: I didn't - the constraints did ;)
[10:47] <daf> ddaa: that's not fair, it's a two-man team
[10:47] <carlos> the constraints?
[10:47] <carlos> stub: did you added them?
[10:48] <ddaa> daf: you mean "Daffyd" _and_ "Harries"? Or did I miss something?
[10:48] <carlos> I don't remember any constraint to catch that...
[10:48] <daf> ddaa: matsubara does plenty of triage too
[10:48] <ddaa> oh, thanks for the tip
[10:49] <daf> be careful, or he might triage *you*
[10:49] <ddaa> bug 33370 YAY!
[10:49] <Ubugtu> malone bug 33370 in launchpad "Mechanism for two-column layout" [Major,Confirmed]  http://launchpad.net/bugs/33370
[10:53] <stub> carlos: TranslationImportQueueEntry.content is NOT NULL. However, we are trying to initialize it from POFile.rawfile, which contains NULLs, and this fails.
[10:54] <stub> carlos: Should the NOT NULL constraint on TranslationImportQueueEntry be dropped, or should we skip creating records from POFile's with a NULL rawfile ?
[10:57] <carlos> stub: well, the sql sentences I gave you should do it 
[10:57] <stub> for pofile in POFile.select("POFile.rawimportstatus=2"):     # All entries that are waiting to be imported.     TranslationImportQueueEntry(         path=pofile.path,         content=pofile.rawfile,
[10:57] <carlos> stub: that means that we have a pofile with rawfile null and rawimportstatus  set to 2 or 4
[10:58] <carlos> stub: if the status is 2 or 4, rawfile should not be null
[10:58] <stub> carlos: we have 6
[10:58] <carlos> stub: but is ok if you add a check for 'rawfile IS NOT NULL'
[10:58] <stub> ok.
[10:59] <carlos> stub: hmmm, the 6 is for TranslationImportQueueEntry.status
[10:59] <stub> launchpad_staging=# select count(*) from pofile where rawimportstatus in (2,4) and rawfile IS NULL;
[10:59] <stub>  count
[10:59] <stub> -------
[10:59] <stub>      6
[10:59] <stub> (1 row)
[10:59] <spiv> ddaa: So rename-buttsource is with pqm... have you dealt with BjornT's questions about productseries-branch-oops?
[10:59] <carlos> stub: we are talking here about POFile.rawimportstatus
[11:00] <stub> so not many, but enough to break my initial data migration script ;)
[11:00] <stub> Should I open a bug on them for us to deal with later?
[11:01] <carlos> stub: are those for POFile or POTemplate?
[11:02] <stub> POFile
[11:04] <carlos> hmmm
[11:04] <carlos> select count(*) from pofile where rawimportstatus =4
[11:04] <carlos> stub: what does it returns?
[11:04] <carlos> s/returns/return/
[11:05] <stub> 164
[11:09] <carlos> stub: upps, sorry, select count(*) from pofile where rawimportstatus =4 and rawfile IS NULL;
[11:09] <stub> Now we are violating the unique_entry_per_importer constraint..
[11:09] <stub> carlos: 6
[11:09] <ddaa> spiv: yes, that's the stuff I pushed before going to bed
[11:10] <carlos> stub: ok, that's why I suspected... not a bit issue you can ignore those entries anyway, we are going to remove that code and those db fields
[11:10] <carlos> stub: hmm about that....
[11:10] <carlos> stub: is there anyway to say that the entries that break that constraint should be ignored?
[11:11] <spiv> ddaa: cool, so assuming rename-buttsource merges smoothly, we can merge that immediately too...
[11:11] <ddaa> spiv: yes
[11:11] <ddaa> spiv: I feel compelled to triple check I did the changes correctly, it was a bit late at night yesterday :)
[11:11] <carlos> stub: that means that we have two entries for the same pofile or potemplate from the same importer so it's safe to discard the old one (the one we are migrating is the old one)
[11:11] <spiv> ddaa: :)
[11:12] <stub> carlos: Not in a simple way. You need to construct a WHERE NOT EXISTS clause or something similar to skip them.
[11:12] <carlos> stub: ok, then send me the script and I will add that check
[11:13] <spiv> Any reviewers want to do a quick review (97 lines)?
[11:13] <carlos> stub: there should be a low amount of files on that situation, 2 or 3
[11:13] <ddaa> spiv: then then there's the pull-listing stuff
[11:13] <spiv> ddaa: https://chinstrap.ubuntu.com/~dsilvers/paste/fileDjKFEk.html
[11:13] <spiv> ddaa: That's what I'm trying to get a quickie review of :)
[11:14] <spiv> ddaa: Though you might as well look too :)
[11:15] <carlos> lifeless: hi, could you confirm what ddaa says at https://launchpad.net/products/bzr/+bug/33029 ?
[11:15] <Ubugtu> malone bug 33029 in bzr "UnicodeDecodeError in Testament.as_short_text" [Normal,Unconfirmed]  
[11:15] <carlos> lifeless: just to know if jbailey's packages are missing something or it's a valid bug....
[11:18] <BjornT> spiv: i can review it
[11:18] <spiv> BjornT: Cool.  It's for bug #32106: https://chinstrap.ubuntu.com/~dsilvers/paste/fileDjKFEk.html
[11:18] <Ubugtu> malone bug 32106 in launchpad "Extend supermirror-pull-list.txt for vcs-imports" [Normal,In progress]  http://launchpad.net/bugs/32106
[11:19] <ddaa> spiv: that's fine with me. But I think Branch.pull_url could use a few unit tests.
[11:19] <ddaa> But it's currently well covered by the feature test.
[11:23] <ddaa> oh, duh, there was another bug in my branch :)
[11:24] <BjornT> spiv: the default value of bzr_push_root_url is not a valid url. should it be a url, or should it be named differently?
[11:26] <ddaa> BjornT: it's a local filesystem path
[11:26] <BjornT> ok, then it should be named differently
[11:26] <ddaa> it could be a URL as well, bzr does not care
[11:27] <BjornT> spiv: bzr_imports_root_url should have datatype="canonical.config.urlbase"
[11:30] <BjornT> spiv: it would probably be good for bzr_push_root_url to have a similar validator, ensuring that the path ends with slash. (you don't have to add it now, though)
[11:30] <spiv> BjornT: Hmm, I guess so... the supermirror_root defined just above it is just a string, but has the same concerns as supermirror_root.
[11:30] <ddaa> spiv: yup, it looks like bzr does file:// urls just fine
[11:30] <spiv> Er, bzr_push_root_url
[11:30] <spiv> ddaa: And thus the branch puller will like them?
[11:31] <spiv> ddaa: If you say yes, I'll happily switch to datatype="canonical.config.urlbase" and using urljoin.
[11:31] <ddaa> spiv: unless it fucks with the url before handing them off to launchpad, it should like them
[11:31] <spiv> ddaa: Ok, let's do that.
[11:32] <BjornT> spiv: with those changes, r=bjornt
[11:33] <spiv> BjornT: Thanks.
[11:33] <ddaa> bah, I'm just being paranoid
[11:35] <spiv> rename-buttsource landed ok.
[11:36] <ddaa> I'll land productseries-branch-oops just after that
[11:37] <spiv> ddaa: Ok.  Once you land that, I'll land this freshly-approved bug 32106 branch.
[11:37] <Ubugtu> malone bug 32106 in launchpad "Extend supermirror-pull-list.txt for vcs-imports" [Normal,In progress]  http://launchpad.net/bugs/32106
[11:38] <lifeless> carlos: sorry, whats up ?
[11:38] <ddaa> blah... I'll do the fixing a bit later
[11:39] <ddaa> I think it's irrelevant right now
[11:39] <ddaa> and too excited to code anyway
[11:41] <sabdfl> carlos: can you help me with these scripts?
[11:42] <sabdfl> as I understand it:
[11:42] <sabdfl> ~/lptrees/rocketfuel is special, it us upstream, fully built, full tree
[11:42] <sabdfl> ~/rocketfuel is special, it is where you are supposed to hack
[11:42] <sabdfl> if ~/rocketfuel does not exist, it will be created as a copy of ~/lptrees/rocketfuel
[11:43] <sabdfl> if it does exist, then it is assumed to be a working tree
[11:44] <ddaa> productseries-branch-oops now in pqm
[11:45] <carlos> lifeless: I'm blocked with one branch merge due a UnicodeError raised by bzr
[11:45] <carlos> sabdfl: right
[11:46] <carlos> sabdfl: the idea is that you hack on ~/rocketfuel, if you finish with that branch you can either remove it (after pushing it to chinstrap) or archive it 
[11:47] <carlos> sabdfl: and a new rocketfuel-get will create a new fresh tree to start working on, like 'bzr brach' would do but much faster
[11:47] <sabdfl> ok
[11:47] <sabdfl> and rocketfuel-refresh?
[11:47] <sabdfl> does that merge-in-all-subtrees?
[11:48] <carlos> lifeless: ddaa said that it was already fixed on bzr.dev tree but I still get it using latest jbailey's packages
[11:48] <carlos> sabdfl: yes, updates the subtrees of a working copy
[11:48] <carlos> that's all trees at sourcecode/
[11:49] <sabdfl> mpt: http://www.contentmanagementsoftware.info/blog/hide-portlets-column-plone/blogentry_view
[11:49] <sabdfl> and others like it
[11:51] <lifeless> carlos: what date is the package you are ysing ?
[11:52] <carlos> lifeless: 0.8~200602281718
[11:52] <carlos> lifeless: today's update is lacking bzrtools so I cannot update to it
[11:53] <lifeless> ddaa: what date did you check bzr.dev ?
[11:54] <ddaa> lifeless: the branch we merged in launchpad
[11:54] <jordi> oh lifeless!
[11:54] <ddaa> I understood it was bzr.dev
[11:54] <jordi> lifeless: do you think you'll have a minute to look at my requests of last night?
[11:55] <ddaa> carlos: bug number?
[11:55] <lifeless> jordi: requests ?
[11:55] <carlos> ddaa: 33029
[11:55] <carlos> ddaa: #33029
[11:55] <lifeless> ddaa: it was.
[11:55] <carlos> Ubugtu: dude, do your job!
[11:55] <carlos> ddaa: https://launchpad.net/products/bzr/+bug/33029
[11:55] <lifeless> carlos: it may be in the latest  updates from jbailey
[11:55] <Ubugtu> malone bug 33029 in bzr "UnicodeDecodeError in Testament.as_short_text" [Normal,Unconfirmed]  
[11:56] <ddaa> lifeless: I looked at the log and saw the merge on date 2006-02-18
[11:56] <lifeless> ddaa: hmm.
[11:56] <lifeless> carlos: are you _sure_ its the same bug ?
[11:56] <serix> morning to everybody :-)
[11:56] <ddaa> on http://bazaar-vcs.org/bzr/bzr.dev
[11:56] <carlos> lifeless: let me check to be 100% sure...
[11:57] <lifeless> carlos: cause I dont want you blocked
[11:57] <lifeless> carlos: but it sounds like its a new bug and you should file a report on it
[11:58] <jordi> lifeless https://launchpad.net/products/rosetta/+bug/31835 and...
[11:58] <Ubugtu> malone bug 31835 in rosetta "Akkadian assigned to "ak" code in ubuntu-translators group" [Major,Confirmed]  
[11:59] <jordi> Subject: Rosetta admin requests
[11:59] <jordi> To: launchpad@lists.canonical.com
[11:59] <jordi> Date: Wed, 1 Mar 2006 19:32:44 +0100
[11:59] <jordi> lifeless: those two
[11:59] <lifeless> jordi: oh. Not really, stub should be able to help
[11:59] <lifeless> jordi: I'm in a sprint at the moment
[11:59] <carlos> lifeless: confirmed 100% sure, it's the same error
[11:59] <jordi> lifeless: oh, righto
[11:59] <jordi> stub? around?
[11:59] <lifeless> carlos: can you please pull bzr.dev and confirm it happens with that ?
[11:59] <stub> ?
[11:59] <jordi> stub: it always comes back to you :)
[11:59] <lifeless> carlos: this is to elminate the package as a variable
[11:59] <carlos> lifeless: sure
[11:59] <lifeless> carlos: after that we will know its still present as a bug in bzr.dev - i.e. not fixed.
[11:59] <jordi> stub: can you have a look at 20060301183244.GA20722@nubol.oskuro.net in launchpad list?
[12:00] <stub> jordi: This the same as the bug report?
[12:03] <stub> anyone know where the distro translation groups live in launchpad?
[12:05] <jordi> stub: no, there's another request
[12:05] <stub> jordi: what language should ubuntu-l10n-bn-in be translating?
[12:06] <jordi> bn-IN
[12:06] <stub> What is bn?
[12:06] <matsubara> good morning!
[12:06] <jordi> Bengali
[12:07] <stub> bengali done
[12:08] <jordi> stub: you assigned bn-in to Bengali, or Bengali (India)?
[12:08] <lifeless> carlos: I gotta crash, eyes are betraying me
[12:08] <jordi> needs to  be the latter
[12:08] <stub> Bengali (India)
[12:08] <jordi> stub: thanks
[12:08] <lifeless> please file-or-reopen the bug
[12:09] <stub> jordi: The akan one looks lilke it is already done
[12:09] <lifeless> night all
[12:09] <carlos> lifeless: ok, I'm still waiting to finish the bzr.dev download
[12:09] <carlos> lifeless: good night, and thanks
[12:09] <jordi> stub: check it's assigned to "ak", not "aka"
[12:10] <stub> The language is listed as Akan
[12:10] <ddaa> stub: can you check that pqm is not hung?
[12:12] <stub> ddaa: looks busy
[12:12] <ddaa> thank you
[12:13] <carlos> lifeless: just in case you are still around....
[12:13] <carlos> carlos@aragorn:/tmp$ bzr branch http://bazaar-vcs.org/bzr/bzr.dev
[12:13] <carlos> bzr: ERROR: exceptions.AttributeError: URLError instance has no attribute 'errno'
[12:13] <carlos>   at /usr/lib/python2.4/site-packages/bzrlib/transport/http.py line 188
[12:13] <carlos>   in has
[12:13] <carlos> ddaa: ^^^^?
[12:13] <ddaa> carlos: in pqm, send a request, get a url, and go to the url to see progress on the run, with "-vv" test suite run.
[12:14] <carlos> ddaa: ?
[12:14] <ddaa> So anxious types like me know that it's make progress.
[12:14] <carlos> oh
[12:14] <carlos> sorry, I was asking about the error I got O:-)
[12:15] <ddaa> carlos: it's a bug, Jim.
[12:15] <carlos> so I'm not able to check the first bug due this other bug...
[12:15] <carlos> funny
[12:17] <ddaa> does not seem to happen with latest bzr.dev, though
[12:17] <ddaa> carlos: try that: rsync -av bazaar-vcs.org::bazaar-ng/bzr/bzr.dev .
[12:18] <jordi> stub: hmm. I guess it's correct then
[12:18] <ddaa> it's documented on http://bazaar-vcs.org/OfficialDownloads
[12:18] <jordi> stub: I thought teams were assigned to codes, not to names
[12:18] <jordi> if they were assined to a name, they are probably good to go now, as you changed it in thedb
[12:18] <carlos> ddaa: seems to be working that way. Thanks
[12:18] <jordi> gee, can't type today
[12:19] <LarstiQ> carlos: do you still have your first bug with bzr.dev?
[12:19] <ddaa> spiv: productseries-branch-oops now in rocketfuel, gogogo!
[12:20] <spiv> ddaa: Sweet.
[12:20] <carlos> LarstiQ: yes, I do. I'm getting latest bzr.dev tree to check if it's still there with it and to know if it's a problem with jabailey's packages
[12:20] <stub> jordi: they are assigned to codes. However the UI only displays the name.
[12:22] <jordi> stub: nod. Akan is "ak" now, so I guess that does it.
[12:25] <carlos> ddaa: the error is still there
[12:28] <ddaa> carlos: can you paste the backtrace from the log? Just in case it changed since the first report. Then I'll give you a small patch so we have more data to reproduce the bug.
[12:29] <carlos> sure
[12:31] <carlos> ddaa: done
[12:37] <spiv> Also, what happened to the commits list seems a bit quiet.
[12:39] <ddaa> carlos: try with this patch, so we'll know what's wrong with your testament: https://chinstrap.ubuntu.com/~dsilvers/paste/fileqYaVud.html
[12:39] <ddaa> spiv: looks like your request got blackholed or something
[12:40] <spiv> ddaa: Yeah, it was there for a while...
[12:40] <spiv> I checked the page.
[12:40] <spiv> stub: pqm has apparently eaten my request...
[12:42] <carlos> ddaa: ok
[12:43] <stub> spiv: eaten?
[12:44] <spiv> stub: It was appearing on http://pqm.ubuntu.com/, but now it's not listed, and I don't seem to have a response...
[12:45] <ddaa> and rocketfuel has not changed
[12:45] <Keybuk> ok, weird one
[12:45] <Keybuk> https://launchpad.net/people/keybuk/+packagebugs
[12:46] <Keybuk> says that hotplug has 3 critical and 6 unassigned bygs
[12:46] <Keybuk> if I click on those links, I get zarro boogs
[12:46] <spiv> ddaa: Heh, I just checked that too.
[12:46] <daf> hi Steve
[12:46] <Kinnison> I think some of the portlets show closed bugs
[12:46] <SteveA> hello
[12:46] <daf> how's PyCon?
[12:48] <Keybuk> isn't Picon one of the twelve colonies
[12:48] <stub> spiv: Something odd may have happened. I have an empty log file of the pqm job. pqm's logs arn't helpful (I don't know what 'garh' means, but it seems to be normal)
[12:49] <SteveA> daf: it was good.  i just got off the plane in vilnius
[12:49] <daf> just in time!
[12:49] <SteveA> so i'm having a cup of tea at the airport for the launchpad meeting in 10 mins
[12:50] <spiv> stub: Hmm.  I'll take my chances with submitting a second merge request then.
[12:50] <spiv> stub: Thanks.
[12:50] <ddaa> "garh" usually means "the coder was too lazy to give useful error reporting"
[12:54] <carlos> ddaa: https://chinstrap.ubuntu.com/~dsilvers/paste/file6i030e.html
[12:57] <ddaa> carlos: just what I thought, the accents in your committer id are the problem
[12:57] <Keybuk> bradb: when can we have a /people/keybuk/+bugs-i-care-about page?
[12:58] <Keybuk> (ie. bugs on packages I am the bug contact for)
[12:58] <carlos> ddaa: I didn't change that recently, It worked with the same configuration until this week...
[12:58] <LarstiQ> carlos: strange, it has given lots of people trouble for quite a while
[12:58] <LarstiQ> including me when I stuck kanji in /etc/passwd
[12:58] <carlos> LarstiQ: Included me
[12:58] <bradb> Keybuk: yep, https://launchpad.net/people/keybuk/+packagebugs
[12:59] <ddaa> carlos: that's all the more surprising, but that's clearly the cause of the problem. 'committer: Carlos Perell\xf3 Mar\xedn <carlos.perello@canonical.com>\n'. If you try to .encode('utf-8') that, you have a problem...
[12:59] <bradb> s/yep/we already do/
[12:59] <spiv> stub: hmm, another request for the same merge disappeared too :/
[12:59] <carlos> LarstiQ: I think the solution was to recode the name to use latin1 instead of unicode but I'm not sure
[01:00] <spiv> Oh, I think I typoed the hostname in the URL.
[01:00] <LarstiQ> carlos: feh, that is working around it
[01:00] <carlos> my passwd doesn't have any non ascii char
[01:00] <Keybuk> bradb: that doesn't give me useful reports
[01:00] <Keybuk> bradb: clicking on any of those links does not give me a list of bugs that I want
[01:00] <Keybuk> I just want a list of bugs that it's my job to fix
[01:00] <LarstiQ> carlos: does this come from your email setting in bazaar/branches.conf then?
[01:00] <SteveA> MEETING TIME
[01:00] <SteveA> who is here today?
[01:00] <jblack>  here
[01:00] <BjornT> me
[01:01] <spiv> me
[01:01] <mpt> me
[01:01] <matsubara> me
[01:01] <ddaa> here
[01:01] <bradb> me
[01:01] <Keybuk> bradb: clicking "udev in ubuntu" for example gives me bugs that are open, fixed, rejected, etc.
[01:01] <jamesh> me
[01:01] <carlos> LarstiQ: yes, as ISO. Let's talk later... meeting time
[01:01] <carlos> me
[01:01] <daf> me
[01:01] <SteveA> matsubara: anyone else from brazil here?
[01:01] <SteveA> salgado sends apologies.
[01:01] <SteveA> i have his three sentences.
[01:02] <matsubara> SteveA: not yet.
[01:02] <matsubara> SteveA: I'll call them. just a second.
[01:02] <SteveA> thanks matsubara 
[01:02] <SteveA> lifeless: at today's meeting or not?
[01:03] <ddaa> he said he was crashing about one hour ago
[01:03] <SteveA> == Agenda ==
[01:03] <SteveA>  * Roll call
[01:03] <SteveA>  * Agenda
[01:03] <SteveA>  * Next meeting
[01:03] <SteveA>  * Activity reports
[01:03] <SteveA>  * Items from last meeting
[01:03] <SteveA>  * Launchpad oops milestone report (daf)
[01:03] <SteveA>  * Production / staging (stub)
[01:03] <SteveA>  * Thorough answers needed for fielding questions about where to download Malone/Launchpad, why it's non-Free, etc (mpt)
[01:03] <SteveA>  * Update on support tracker schedule (SteveA, jeffb)
[01:03] <SteveA>  * Keep, Bag, Change
[01:03] <SteveA>  * Three sentences
[01:03] <SteveA> 
[01:03] <SteveA> next meeting... same time next week?
[01:03] <SteveA> any objections, speak now
[01:03] <SteveA> ddaa: okay, i'll count that as an apology
[01:03] <bradb> Keybuk: The advanced search should be in the next rollout, so that you can filter the bugs how you want (and bookmark that.) But I could also easily add a link on +packagebugs for bugs assigned to you.
[01:03] <mpt> I'll be en route to the UK this time next week
[01:04] <SteveA> how about doing it on wednesday next week?
[01:04] <SteveA> spiv: ?
[01:04] <SteveA> mpt: ?
[01:04] <mpt> that'd be fine
[01:04] <SteveA> jamesh: ?
[01:04] <spiv> I'm ok with that time.
[01:04] <SteveA> ok
[01:04] <jamesh> SteveA: wednesday is fine
[01:04] <Keybuk> bradb: I don't just want bugs assigned to me though, I also want bugs assigned to nobody on the packages I'm bug contact for ... as those probably need to be read and assigned to somebody (mostly me)
[01:05] <ddaa> I'm not sure it's gong to be very useful, since we'll all meet a few days after...
[01:05] <matsubara> SteveA: kiko just arrived.
[01:05] <SteveA> the next meeting will be next wednesday at the usual time.
[01:05] <SteveA> ddaa: then it may be a short meeting.
[01:05] <jblack> wednesday
[01:05] <SteveA> i think it will still be useful, particularly for me and kiko planning stuff
[01:05] <SteveA>  * activity reports
[01:06] <SteveA> who's cool, and who isn't exactly the next james dean?
[01:06] <ddaa> uptodate
[01:06] <kiko> ahoy there, sorry for missing time
[01:06] <mpt> up to date
[01:06] <kiko> I am cool
[01:06] <kiko> I am here
[01:06] <jblack> I'm James, but not dean
[01:06] <ddaa> spiv: your merge got blackholed, again :(
[01:06] <kiko> also, cprov has a day off today, as per email, SteveA 
[01:06] <BjornT> i'm up to date
[01:06] <SteveA> i was at pycon, but slack on activity reports all the same...
[01:06] <spiv> I'm up to date
[01:06] <SteveA> kiko: ok.
[01:06] <spiv> ddaa: Hmm, probably another snafu at my end...
[01:06] <carlos> I'm up to date
[01:06] <bradb> Keybuk: We already have that. There's an "Unassigned" link for each package. Unfortunately, they're not all aggregated for all your packages into one report, but we can't handle that speed-wise yet either, unfortunately.
[01:06] <matsubara> up to date
[01:06] <jamesh> I'm not up to date
[01:06] <SteveA> kiko: salgado isn't feeling well.  sent apologies
[01:07] <Keybuk> bradb: that requires me to open ~30 different launchpad pages though
[01:07] <stub> no worries here
[01:07] <Keybuk> bradb: assigned to me and unassigned, for every package in that list
[01:07] <Keybuk> I do that by clicking them all at once with the middle mouse button
[01:07] <SteveA> jamesh: according to the summary of last week's meeting, you were up to date last week
[01:07] <Keybuk> so that's going to nuke launchpad anyway, isn't it?
[01:07] <Keybuk> given this is something I do every day, Malone makes it damned difficult
[01:07] <SteveA> carlos: thanks for bringing yourself up to date after missing it last week
[01:07] <Keybuk> esp. given it's just the bugzilla "My Bugs" functionality
[01:07] <SteveA> mpt: thanks for bringing yourself up to date after missing it last week
[01:08] <SteveA> thanks everyone else who is up to date.
[01:08] <mpt> me? I was just one day out last week
[01:08] <SteveA>  * Items from last meeting
[01:08] <mpt> (and the meetings are at 1am...)
[01:08] <SteveA> none in the summary
[01:08] <bradb> Keybuk: yeah, it's far less than ideal, no doubt. maybe we can revisit this topic after the LP meeting?
[01:08] <SteveA>  * Launchpad oops milestone report (daf)
[01:09] <daf> the good news:
[01:09] <Keybuk> bradb: sure thing
[01:09] <daf> https://chinstrap.ubuntu.com/~daf/bugs/graph.png
[01:09] <daf> exceptions are staying down
[01:09] <SteveA> mpt: i'm going from last week's summary information on MeetingAgenda.  I wasn't there last week.
[01:09] <daf> however, timeouts have been up over the past couple of days
[01:09] <daf> I don't know why
[01:09] <kiko> daf, most of the exceptions in yesterday's report were Retrys
[01:10] <kiko> has there been a traffic spike?
[01:10] <kiko> it would be nice to see how many hits we had and plot that as well
[01:10] <daf> true
[01:10] <daf> I'm getting my data from James' oops summaries
[01:10] <kiko> SteveA, jamesh: is there a way to include total hit count in the summaries? I suspect not easily...
[01:10] <SteveA> kiko: total hits of what?
[01:11] <kiko> webserver hits?
[01:11] <jamesh> kiko: not really.  We are only seeing the failures
[01:11] <kiko> yeah.
[01:11] <daf> we have access to the access logs
[01:11] <kiko> we'd need to do some grepping and wc'ing
[01:12] <daf> yes
[01:12] <SteveA> total hits that resulted in oopses?
[01:12] <SteveA> we can get that from the general logs
[01:12] <SteveA> although, it would be better to use apache logs for that
[01:12] <SteveA> hits probably isn't so useful as pages, though
[01:12] <SteveA> but anyway, not from the oops reports.  i'd ask the admins for access to apache logs for that.
[01:12] <kiko> SteveA, no, I mean total hits, period.
[01:12] <kiko> to be able to verify whether traffic spiked or not
[01:13] <kiko> to be able to reasonably say whether we are improving or not
[01:13] <jamesh> kiko: this is to get some idea of what % of requests result in failure?
[01:13] <mpt> Yes!
[01:13] <kiko> jamesh, well, daf pointed out our timeouts just went up this week. I wanted to know if this was caused by increased traffic, or something else.
[01:13] <jamesh> have we got more not found errors because googlebot and yahoo visited us today, or did we break something?
[01:13] <SteveA>  (my connection here has become very laggy)
[01:14] <kiko> notfounderror is a bug, but daf had a patch for that yesterday
[01:15] <daf> did I?
[01:15] <kiko> isn't that the redirect bug
[01:15] <daf> no, that's a different problem on the login page
[01:15] <kiko> ah
[01:16] <kiko> okay, then that bug isn't fixed yet
[01:16] <daf> anyhow, our running score for fixed/unfixed OOPS bugs is 30%
[01:16] <kiko> I think SteveA has dropped off
[01:17] <kiko> heh
[01:17] <daf> any questions about OOPSes?
[01:17] <mpt> What should be done to get the daily hit counts? File an RT ticket?
[01:17] <kiko> hello SteveA 
[01:18] <SteveA> hello
[01:18] <SteveA> kiko SteveA, jamesh: is there a way to include total hit count in the summaries? I suspect not easily...
[01:18] <kiko> mpt, I think daf is saying that we can get it from the access logs
[01:18] <SteveA> SteveA kiko: total hits of what?
[01:18] <SteveA> SteveA total hits that resulted in oopses?
[01:18] <SteveA> kiko webserver hits?
[01:18] <SteveA> SteveA we can get that from the general logs
[01:18] <SteveA> SteveA although, it would be better to use apache logs for that
[01:18] <SteveA> SteveA hits probably isn't so useful as pages, though
[01:18] <SteveA> SteveA but anyway, not from the oops reports.  i'd ask the admins for access to apache logs for that.
[01:18] <SteveA> SteveA  (my connection here has become very laggy)
[01:18] <SteveA> 
[01:18] <SteveA> that's the last i saw
[01:18] <kiko> hits and pages should be proportional, I think
[01:18] <SteveA> not very reliable internet here at vilnius airport
[01:18] <daf> mpt: I don't htink we need that admins' help
[01:18] <mpt> ok
[01:18] <daf> stub should be able to provide us will all the logs we need
[01:19] <stub> we have access to the apache logs I believe. The launchpad-access.log will also have the information.
[01:19] <mpt> Hopefully Launchpad is increasing in popularity fast enough that error percentages will be more useful than raw error counts :-)
[01:19] <kiko> daf, why stub even? the access logs have the information
[01:19] <kiko> it would be a matter of generating the graph on chinstrap
[01:19] <kiko> (I don't recommend rsyncing the logs)
[01:20] <daf> because I'm not sure how up-to-date the logs on chinstrap are
[01:20] <kiko> they are rsynced every 5 minutes AIUI
[01:20] <jamesh> the logs we need are at chinstrap.ubuntu.com:/srv/launchpad.net, right?
[01:20] <daf> but we can easily verify that
[01:20] <kiko> yes
[01:20] <kiko> correct
[01:20] <daf> MeetingAction: daf to try and extract number of page accesses by day from the chinstrap access logs
[01:20] <SteveA> ok
[01:20] <kiko> rock on daf
[01:21] <SteveA> so, kiko and i will either do, or assign someone to do a simple analysis of the logs we get on chinstrap
[01:21] <SteveA> to get a daily hit count or page count
[01:21] <kiko> SteveA, daf has volunteered already
[01:21] <SteveA> to compare to the oops stats
[01:21] <kiko> (are you still lagged?)
[01:22] <kiko> he is
[01:22] <kiko> okay, let's move on, then
[01:22] <kiko> stub, care to cover production and staging?
[01:22] <stub> Nothing thrilling happening with staging, except that on occasions it doesn't shutdown cleaning causing the restart to fail. I haven't looked into the cause. So ping me if it is down.
[01:22] <stub> There will be a production update next Tuesday if people have fixes they need landed. Please let me know now, otherwise I will skip next week. New hardware for the main database server is now available - switching over will involve maybe 4 hours of downtime.
[01:22] <stub> Ideally, I would like to migrate to PostgreSQL 8.1 at the same time. This of course depends on if testing the migration locally and on staging goes smoothly or if it will take a few weeks to port Launchpad to the new release.
[01:22] <stub> It also depends on if I can look at PostgreSQL 8.1 now or if I need to concentrate on the Retry exception handling (~50 OOPS per day?) and the race condition in the PostgreSQL session machinery (~5 OOPS per day?).
[01:23] <daf> Carlos' import queue work will definitely need rolling out
[01:23] <daf> I don't think it will be ready soon enough to warrant cherry picking
[01:23] <ddaa> stub: we'll need the patch spiv is having trouble merging
[01:23] <carlos> right
[01:23] <daf> ddaa: you're planning to roll out push branches, aren't you?
[01:24] <carlos> stub: I will need either cherrypick it or a rollout 
[01:24] <ddaa> daf: no, just bzr imports
[01:24] <carlos> but I will need to check it first on staging
[01:24] <daf> ddaa: ah, ok
[01:24] <spiv> ddaa: It's just a conflict, I'm sorting it out as we speak
[01:24] <stub> ok. So there will be a rollout on Tuesday, or later if the fixes don't land before Monday.
[01:24] <carlos> to be sure that the import queue is back to life again
[01:24] <daf> stub: last week, I think you said that Z3.2 was nearly done -- how's that going?
[01:25] <kiko> stub, how about we do the hw migration and do the pgsql 8.1 migration later?
[01:25] <kiko> this should give you some time to work on Retry/races
[01:25] <daf> (as I also think you said that Z3.2 would come before PG8.1)
[01:25] <stub> daf: Its taken me a number of days dealing with our test suite and issues involved with the newer testing environment. 
[01:26] <stub> I think all the major problems are solved now. 
[01:26] <kiko> cool
[01:26] <kiko> but what does this mean in terms of priority?
[01:26] <stub> kiko: If I do them seperately, we double our downtime.
[01:27] <kiko> stub, I think that's acceptable
[01:27] <kiko> better dealing with one unknown than two
[01:27] <kiko> (at a time)
[01:27] <kiko> I also think we don't need to delay the hw migration for code work
[01:27] <kiko> which might take time
[01:27] <stub> I want to land the 3.2 work as soon as I can - I've had to touch a large number of files so merging and resolving conflicts will get uglier the longer it sits idle.
[01:27] <kiko> (has anyone tried running LP on 8.1 yet?)
[01:28] <kiko> stub, okay.
[01:28] <stub> I think Mark tried the other day but I don't know how he went
[01:28] <daf> sabdfl: ping?
[01:28] <kiko> stub, so timeline would be: rollout, land z3.2, hw migration, 8.1 work, 8.1 upgrade?
[01:28] <stub> I suspect PG 8.1 will involve a few minor tweaks to the maintenance scripts and that is all
[01:28] <stub> Sure
[01:28] <daf> yes, the maintainance scripts failed when I accidentally ran LP on 8.1
[01:28] <kiko> that sounds like the best plan to me
[01:28] <daf> (I downgraded)
[01:29] <kiko> cool
[01:29] <kiko> anything else on production/staging?
[01:29] <kiko> anyone have stuff that is about to land or needs watching apart from spiv?
[01:30] <kiko> all right, then
[01:30] <kiko> mpt, take it away
[01:30] <carlos> kiko: I do
[01:30] <kiko> carlos, the import queue stuff?
[01:30] <carlos> kiko: I will need a reviewer soon for the 33020 bug
[01:30] <mpt> kiko, that was from last week, it was addressed by a voluminous answer in the FAQ
[01:30] <carlos> kiko: yes
[01:30] <kiko> mpt, did you find the answer acceptable?
[01:30] <carlos> kiko: I'm fixing tests and need to solve a UI issue with daf and It should be ready
[01:30] <kiko> carlos, shop around now for that reviewer (before some of them go to sleep)
[01:30] <mpt> kiko, however, I would be interested in knowing *which* parts of LP have been open-sourced already
[01:31] <kiko> mpt, infrastructure code, AIUI
[01:31] <kiko> zope sqlobject and perhaps some pgsql glue code
[01:31] <mpt> Thanks
[01:31] <carlos> Any reviewer interested on doing a review tomorrow morning or late today? (depending on your timezone ;-)
[01:32] <SteveA> there is also a body of code that mark has said can be open-sourced, when we arrange time to do the work of making it into a stand-alone product
[01:32] <ddaa> "gnarly" if anybody really want to use that...
[01:32] <kiko> SteveA, the faq covers that too, yes.
[01:32] <SteveA> such as the librarian
[01:32] <jamesh> mpt: in general, changes to existing projects have been pushed upstream
[01:32] <SteveA> interestingly, at pycon, enfold systems has a system similar to the librarian, used for plone deployment.
[01:32] <ddaa> jamesh: except for buildbot and cscvs
[01:33] <jamesh> ddaa: those are exceptions, yes.
[01:33] <kiko> anything else, mpt?
[01:33] <mpt> no, that's all
[01:33] <kiko> great
[01:33] <daf> carlos: put it on the wiki
[01:34] <carlos> daf: but I don't have it ready to review...
[01:34] <stub> Z3 fixes, SQLObject fixes and enhancements, Z3 psycopgda enhancements. I don't know if you would count jamesh's pygpgme work as that was personal work rather than Canonical. I don't think any bits of Launchpad itself have been opensourced - it is all work on the 3rd party tools it requires.
[01:34] <carlos> daf: oh, the todo thing...
[01:34] <carlos> daf: right ;-)
[01:34] <kiko> SteveA, jblack do you want to talk about the support tracker?
[01:34] <BjornT> carlos: if no one else volunteers, i can probably review it tonight.
[01:34] <kiko> or let's cancel that because nobody is interested in it :)
[01:35] <kiko> actually
[01:35] <jblack> Ok
[01:35] <kiko> BjornT, remind me -- we still have the ISC work to do for support, right?
[01:35] <daf> ISC?
[01:35] <carlos> BjornT: ok, thanks
[01:35] <kiko> initial support contact?
[01:35] <daf> ah
[01:36] <carlos> daf: done
[01:36] <BjornT> kiko: yes, i'll do ISC next week.
[01:36] <kiko> all right
[01:36] <kiko> BjornT, how's the bugtracker work so far? 
[01:37] <kiko> anyway, moving on
[01:37] <kiko> * Keep/Bag/Change
[01:37] <BjornT> kiko: i've submitted a branch for review. it's practically does what's specified on BugWatches. next step is to provide mail notifications when bug watches are changed.
[01:37] <kiko> BjornT, when status updates happen, you mean?
[01:38] <kiko> 5
[01:38] <BjornT> kiko: yes
[01:38] <kiko> 4
[01:38] <kiko> BjornT, cool. that shouldn't be too much work, should it?
[01:38] <kiko> 3
[01:38] <kiko> 2
[01:38] <spiv> Change: where did the commit mails go?
[01:38] <kiko> 1
[01:38] <ddaa> CHANGE: new pqm service that does not commit, just merge and run the test suite
[01:38] <kiko> spiv, did they stop coming in?
[01:38] <spiv> kiko: I haven't seen any for a day or so, but there are commits in that time.
[01:39] <kiko> last landing I have is from you, r3209
[01:39] <BjornT> kiko: no, not really. i'll put up a small spec about it on the wiki.
[01:39] <kiko> BjornT, or perhaps update BugWatches
[01:39] <kiko> wow
[01:39] <BjornT> kiko: yeah, i could update BugWatches instead.
[01:39] <spiv> kiko: rocketfuel is up to r3218
[01:39] <kiko> there are 18 revisions missing in my mailbox
[01:40] <kiko> I wonder if mail sending from balleny is broken
[01:40] <kiko> I'll look into it
[01:40] <kiko> (man pqm reliability sucks)
[01:40] <kiko> okay
[01:40] <spiv> kiko: Sure, say that when lifeless isn't around ;)
[01:40] <stub> The queue is empty on balleny
[01:40] <kiko> I say it when he is around too
[01:41] <spiv> kiko: FWIW, I'm still getting responses back from it as normal.
[01:41] <jblack> hey, how about those three sentences?
[01:41] <kiko> spiv, stub: perhaps the commits mailing list is broken?
[01:41] <ddaa> email-based user interaction for merge requests suck by design IMO
[01:41] <kiko> yeah yeah. 3 sentences. GO.
[01:41] <mpt> DONE: some wiki work; fixed a bunch of menu bugs and some other bugs
[01:41] <mpt> TODO: get laptop fixed; 2-column layout; finish MaloneFrontPages spec
[01:41] <mpt> BLOCKED: laptop power connection broken; passport hasn't arrived yet
[01:41] <matsubara> DONE: fixed upstream validator bug, fixed bug about backporting fix request not working for packages names with dots. Carnaval!
[01:41] <matsubara> TODO: triage, fix oops report bugs (finish bug on email validation in the new account registration process and others) 
[01:41] <matsubara> BLOCKED: No
[01:41] <jblack> DONE: bzr support, documentation, advocacy, wiki & migration, lp packages
[01:41] <jblack> TODO: Same
[01:41] <jblack> BLOCKED: none
[01:41] <kiko> DONE: holidays in brazil, hacked up some oops bugs, general management
[01:41] <stub> DONE: Zope 3.2 migration work
[01:41] <stub> TODO: Finalize Zope 3.2 migration work, production updates, PostgreSQL 8.1
[01:41] <stub> BLOCKED: No
[01:42] <spiv> DONE: Reviews, librarian bits, SQLObject joins.py backport, supermirror work (both sftp and for ddaa).
[01:42] <bradb> DONE: Landed new bug listings and advanced search. Landed fix for changing package/product updating the Cc list. Landed several other bugfixes.
[01:42] <spiv> TODO: AuthserverCaching
[01:42] <bradb> TODO: Finish off work on optional table/list view and customizable batch size. Other bugfixes.
[01:42] <spiv> BLOCKED: no
[01:42] <BjornT> DONE: reviews. practically finished BugWatches implementation.fixed a few bugs.
[01:42] <bradb> BLOCKED: No.
[01:42] <BjornT> TODO: start on mail notifications for bug watches. finish InitialSupporContact implementation.
[01:42] <BjornT> BLOCKED:no
[01:42] <ddaa> DONE: bzr-imports coding
[01:42] <ddaa> TODO: deploy bzr-imports, support anonymous baz imports
[01:42] <ddaa> BLOCKED: way too excited to do any coding today, also blocked on spiv vcs-imports-pull-list landing.
[01:42] <kiko> TODO: send off commit report, fix final set of oopses assigned to me, management
[01:42] <kiko> BLOCKED: no
[01:42] <carlos> DONE: bug #1681, soyuz <-> Rosetta integration testing and planning, bug #29467, bug #1887, dapper imports, user support, bug #33020.
[01:42] <carlos> TODO: Finish fixing tests for #33020 and get it cherry picked, Answer #1681 review and get it merged, get #1887 merged, Finish POMsgSetPage implementation and get it merged.
[01:42] <carlos> BLOCKED: No.
[01:42] <Ubugtu> malone bug 1681 in rosetta "Viewing a translation page fails in unix2newlines" [Major,In progress]  http://launchpad.net/bugs/1681
[01:42] <Ubugtu> malone bug 29467 in rosetta "Import queue -- allow for mass approvals" [Normal,In progress]  http://launchpad.net/bugs/29467
[01:42] <Ubugtu> malone bug 33020 in rosetta "Rosetta Imports page is not able to handle lot of entries" [Major,Confirmed]  http://launchpad.net/bugs/33020
[01:43] <daf> DONE: #6313, land optional-branch-title, bug triage, meeting summary, improve bug report reports
[01:43] <daf> TODO: #31589, #31381
[01:43] <daf> BLOCKED: no
[01:43] <jamesh> DONE: code reviews, some updates to the branch status code, importd error reporting
[01:43] <jamesh> TODO: handle remaining bugzilla imports (hopefully last time), code reviews, importd error reporting
[01:43] <jamesh> BLOCKED: no
[01:45] <stub> 45 mins. We done?
[01:46] <kiko> sounds good
[01:46] <kiko> thanks guys
[01:46] <daf> MEETING ENDS
[01:46] <carlos> cool
[01:46] <mpt> We don't have kiko's three sentences ;-)
[01:46] <kiko> mpt?
[01:46] <mpt> oh, yes we do
[01:46] <daf> or Steve's
 salgado DONE: ShipItForDapper, MirrorManagement and some random fixes.
 salgado TODO: Get MirrorManagement merged, ShipItForDapper, random fixes.
 salgado BLOCKED: No
[01:46] <kiko> trigger happy?
[01:47] <kiko> steve's DONE probably involves pycon and zope sprinting
[01:47] <carlos> stub: How is going that migration script is there anything I can do to help you? It would be really good to get it done today so I can play a bit with it with our sampledata...
[01:47] <kiko> his TODO involves mostly catching up and finishing the implementation work he started
[01:48] <stub> carlos: Almost done.
[01:48] <Kamion> ddaa: FYI I made a note at the bottom of https://wiki.launchpad.canonical.com/BzrRoundtripSvn about an extant implementation of the same idea in another system
[01:48] <kiko> not BLOCKED as far as I know
[01:48] <kiko> spiv, how's the backport going for joins.py?
[01:48] <carlos> stub: ok
[01:49] <jblack> kiko: We have properties inside
[01:49] <ddaa> Kamion: thank you, I did not occur to me that SVK was similar.
[01:50] <Mez> hmm - is there a rosetta admin here?
[01:50] <kiko> jblack?
[01:51] <ddaa> Kamion: though actually supporting SVK is not an objective. If we can get it at little cost from the bzr roundtrip support, cool. Otherwise, it's at most something to avoid being aggressively incompatible with.
[01:51] <mpt> kiko, https://launchpad.net/products/malone/+spec/simplification has been reviewed by SteveA and is now pending your approval
[01:51] <Kamion> ddaa: fair enough - just noting that at least taking the same approach would probably save time, since we know that approach works. :-)
[01:52] <Kamion> (and is reasonably subversion-idiomatic - it's been discussed on devel@subversion I think)
[01:52] <ddaa> I'll definitely look it into it. But you'll be amazed how easily DVCS can have massively incompatible data models.
[01:53] <LarstiQ> ddaa: reading that irc log reminds me of ForeignBranches
[01:53] <ddaa> LarstiQ: there's definitely some overlap
[01:53] <ddaa> I imagine the "bzr commit on svn" would use a ForeignBranch.
[01:54] <spiv> kiko: jamesh has a review comment I need to think about and deal with, but it's otherwise looking good.
[01:54] <spiv> kiko: I'll either do that tonight or early in my day tomorrow.
[01:54] <stub> carlos: https://chinstrap.ubuntu.com/~dsilvers/paste/fileEolCHa.html
[01:55] <LarstiQ> ddaa: interesting idea
[01:55] <stub> carlos: It applies happily on staging. I *think* it does what you need.
[01:55] <carlos> ok, I will check it. Thank you
[01:55] <carlos> stub: should I put it as part of my DB patch?
[01:56] <stub> carlos: If it does what you want then yes.
[01:56] <carlos> ok
[01:56] <ddaa> Kamion: also, being "svn idiomatic" is really not a goal by itself, since bzr use patterns are (purposefully) very different from svn use patterns. Just from the "SVK - Branch feature list" page, it look like this might scale badly to large numbers of feature branches.
[01:56] <carlos> stub: thank you!
[01:57] <mpt> Keybuk, so, what are all the things you want to see on your Bugs page?
[01:58] <ddaa> Gah... wine people use SVK and GIT...
[01:58] <Mez> hmm
[01:58] <Mez> er - in LP- you can register a release
[01:58] <Mez> but it says something about linking to a URL
[01:58] <Mez> but gives you no place to link to a URL
[01:59] <carlos> stub: hmm from what you said... Could I check on stating the migrated data or did you use another temp database?
[01:59] <ddaa> Keybuk: see Mez
[01:59] <stub> carlos: I haven't committed the changes to staging.
[01:59] <Kamion> ddaa: (svk use patterns, OTOH, are relatively close to bzr use patterns)
[01:59] <Kamion> I take your point about scaling
[01:59] <stub> (applied, but rolled back)
[01:59] <carlos> stub: ok, that's ok
[01:59] <Mez> ddaa: o_O
[02:00] <carlos> stub: hmm what about the path migration I told you we will need manual fixes
[02:00] <ddaa> Mez: I wish I could help, but I never understood releases in launchpad
[02:00] <ddaa> Kamion: I take your point about svk use patterns being similar to bzr's
[02:01] <stub> carlos: If we need to make manual fixes before inserting the new TranslationImportQueueEntry records, then the data migration will need to be done seperately after the patch has been applied. And dropping the old columns will need to wait until the following rollout and be done in a seperate database patch.
[02:02] <ddaa> actually, it's even worse, it looks like the wine people are using _all_ of CVS, SVN, SVK and GIT...
[02:02] <Keybuk> mpt: what I want to see is
[02:02] <mpt> ddaa, let's get them using bzr as well!
[02:02] <carlos> stub: as I told you, that manual data migration could be done now, without any DB schema change
[02:02] <Keybuk> 1) all bugs assigned to me that are unconfirmed-fix committed
[02:02] <carlos> stub: it was a mistake we did with a previous change that we didn't migrate it
[02:02] <Keybuk> 2) all unassigned bugs on packages I'm bug contact for that are the same
[02:02] <stub> carlos: ok then. If we can do it before the rollout then all will be well. 
[02:02] <Keybuk> 3) all subscribed bugs that I'm *not* reporter for, same state
[02:03] <Keybuk> in a single list
[02:03] <mpt> Keybuk, you mean "in the range from Unconfirmed to Fix Committed"?
[02:03] <Keybuk> mpt: yeah
[02:03] <mpt> ok
[02:03] <Keybuk> that's pretty much the definition of "bugs I have to fix/investigate/care about today"
[02:03] <Kamion> ddaa: then they're an ideal torture test for cross-revision-control-system imports :-)
[02:03] <Keybuk> assigned and fix released/rejected = no longer care about
[02:03] <ddaa> mpt: I mean that's scary... Well and SVN are just lame. And GIT and SVK are just ugly hacks...
[02:03] <Keybuk> assigned to someone else = no longer care about (if I'm ordinarily bug contact)
[02:03] <carlos> stub: when will you have time to do that migration? can we schedule it now for tomorrow (or later today if you have time)?
[02:03] <Keybuk> bugs I reported = don't care about from a fix point of view
[02:04] <Keybuk> I may still care about bugs I've subscribed to which I'm not assigned to, and didn't report
[02:04] <sabdfl> stub: pg8.1 gave some errors when trying to build the db
[02:04] <sabdfl> https://chinstrap.ubuntu.com/~dsilvers/paste/fileamuH2O.html
[02:04] <stub> carlos: What do I need to do?
[02:04] <mpt> Keybuk, bugs you've reported that have been made Needs Info you need to deal with, but not the others
[02:04] <stub> carlos: A patch can be prepared using staging, which I can then run on production.
[02:05] <carlos> stub: I described it in my email. First you need to execute:
[02:05] <carlos> UPDATE POFile
[02:05] <carlos> SET path='po/' || language.code || COALESCE('@' || variant, '') || '.po'
[02:05] <carlos> FROM Language
[02:05] <carlos> WHERE POFile.language = Language.id AND pofile.path IS NULL;
[02:05] <carlos> UPDATE POTemplate
[02:05] <carlos> SET path = 'po/' || translationdomain || '.pot'
[02:05] <carlos> FROM POTemplateName
[02:05] <carlos> WHERE
[02:05] <carlos>     POTemplate.potemplatename = POTemplateName.id
[02:05] <carlos>     AND POtemplate.path IS NULL;
[02:05] <carlos> after that, run two queries I gave you and I will provide you with another SQL patch to finish the migration
[02:05] <Keybuk> mpt: needs info I probably have to at least check they haven't given the info, yes
[02:06] <mpt> ok, that's simple enough
[02:06] <mpt> thanks Keybuk 
[02:07] <stub> carlos: This can all be prepared on staging
[02:07] <carlos> sure
[02:07] <stub> carlos: I can't remember if you have enough access
[02:07] <carlos> stub: only read access
[02:07] <stub> Ok. I'll run those two updates now on staging.
[02:08] <carlos> so I need someone to run the UPDATES
[02:08] <carlos> stub: ok, thank you
[02:09] <spiv> ddaa: Another merge landed.
[02:09] <ddaa> spiv: good news, now I'll try to merge that into my baz2bzr branch :)
[02:10] <stub> carlos: Run
[02:10] <carlos> stub: thanks
[02:10] <sabdfl> kiko: good meeting
[02:10] <sabdfl> can we speak by phone?
[02:11] <carlos> stub: first review of your SQL patch looks really good, I think it does exactly what I want. Thank you
[02:11] <stub> sabdfl: Ta
[02:12] <sabdfl> stub: couldn't get further than that, no time to play and it looked like stuff you invented :-)
[02:12] <stub> sabdfl: I don't think those warnings are anything to worry about.
[02:12] <kiko> sabdfl, sorry, was finishing off report. I still need to add the last commits and send it off, can it wait till then?
[02:13] <sabdfl> kiko: sure, i have about 20 minutes before i have to go into other meetings
[02:13] <sabdfl> stub: it failed to start after that
[02:14] <stub> sabdfl: That would be a different issue I suspect.
[02:14] <kiko> cool
[02:31] <bradb> mpt: Did you record Keybuk's feedback from earlier anywhere, or should I open a bug report?
[02:40] <Keybuk> bradb: also malone still seems to say (unassigned) in the bug lists when it's not
[02:40] <bradb> Keybuk: I hope to land the fix for that today.
[02:42] <carlos> see you later
[02:47] <kiko> sabdfl, sent the report. how about that phone call?
[02:47] <sabdfl> kiko: ok, i'll have to be walking
[02:48] <kiko> sabdfl, it can be later if you prefer, I have plenty to do as well
[02:48] <kiko> otherwise, dial in
[02:48] <sabdfl> flush first
[02:49] <kiko> very funny
[02:56] <sladen> https://launchpad.net/products/judy looks like it might need nuking
[02:57] <kiko> indeed.
[03:11] <daf> SteveA: around?
[03:12] <SteveA> daf: yes
[03:12] <daf> I have a temporary workaround for the +sources redirect until you have a proper fix
[03:12] <daf> https://chinstrap.ubuntu.com/~dsilvers/paste/filewUcB44.html
[03:12] <daf> does that look OK?
[03:13] <daf> (my motivation is that this accounts for a large portion of the spurious Not Founds we get each day)
[03:14] <daf> bradb, BjornT: around?
[03:15] <bradb> daf: yeah
[03:15] <daf> /distros/ubuntu/hoary/+source/at/+bug/30498/+target and similar URLs
[03:15] <daf> if I were going to add a redirect for this 404, where would it point to?
[03:15] <daf> the bug page?
[03:16] <bradb> +backport
[03:16] <SteveA> daf: can you rewrite it using request.stepstogo ?
[03:16] <daf> oh, interesting
[03:16] <daf> ok, I'll so that
[03:16] <daf> SteveA: I expect so
[03:16] <SteveA> there's a bug in how you are using the traversal stack
[03:17] <bradb> I didn't bother adding the redirect, because I figured it would be unlikely that there would be bookmarks or other refs to those URLs
[03:17] <daf> bradb: search engines hit it a lot
[03:17] <SteveA> daf, bradb: we shouldn't worry about 404s so much
[03:17] <daf> I'm not hugely worried about them
[03:18] <daf> but (a) they clutter up reports making them harder to read
[03:18] <SteveA> if people mangle the URLs, then we can help them if they seem to be trying to do something useful.  but we should look more to making what they're trying to do more obvious in launchpad
[03:18] <daf> and (b) they're often trivial to fix
[03:18] <daf> the main problem is people accessing URLs that don't exist any more
[03:18] <daf> rather than mangling
[03:18] <SteveA> fixing them leaves cruft around the codebase
[03:18] <SteveA> i don't care about search engine bots accessing urls and getting 404s
[03:19] <SteveA> we should improve the reports, removing unimportant 404s, rather than making launchpad deal with these urls
[03:19] <daf> it's arguably beneficial for LaunchpadGooglification
[03:19] <SteveA> only in the very short term after a URL change
[03:20] <SteveA> it is more important to strive for simplicity in the launchpad navigation code
[03:20] <daf> +sources has been gone for a long time, but we still get many accesses to it
[03:20] <SteveA> from what referers?
[03:21] <SteveA> and what user agents?
[03:21] <daf> from search bots only, as far as I can tell
[03:21] <SteveA> then, we should not fix it
[03:21] <SteveA> the search bots should get 404s
[03:21] <daf> if we don't care about search engines at all, we should ignore them in the OOPS summaries
[03:22] <SteveA> the only 404s we should care about are
[03:22] <SteveA>  - ones where the referer is on a site we care about
[03:22] <SteveA> other ones, we should basically ignore
[03:23] <SteveA> any code that has been added to launchpad to support other causes of 404s should be carefully reconsidered
[03:23] <daf> jamesh: what do you think about not listing OOPSes caused by search bots in the summaries?
[03:23] <SteveA> i think we should list them, but put them in a separate section
[03:24] <SteveA> the scripts are available, so maybe you can look at improving the summaries so that they work better for your processes, daf?
[03:24] <daf> true, I'll give that a go
[03:25] <SteveA> so, the code you showed me just now
[03:25] <SteveA> do we want to keep that?
[03:25] <daf> no
[03:25] <SteveA> okay
[03:26] <daf> I'll reject the associated bug
[03:27] <daf> bradb: https://launchpad.net/products/launchpad/+bug/30959
[03:27] <Ubugtu> malone bug 30959 in launchpad "+sources/something should redirect to +source/something" [Normal,Rejected]  
[03:27] <kiko> ugh
[03:28] <daf> bradb: it's not clear that the last comment is associated with a status change
[03:28] <daf> bradb: you're going to be interleaving metadata changes with the comments at some point, yes?
[03:29] <bradb> daf: Yeah, it's the next "phase" in the relevant spec.
[03:29] <daf> what's the spec called?
[03:29] <daf> that's good to know
[03:30] <bradb> daf: https://wiki.launchpad.canonical.com/BugStatusChangesAsComments
[03:57] <kiko> ddaa, nice work updating the logger code in update-branches!
[03:58] <ddaa> thank you, now I need to roll it out :)
[03:58] <ddaa> will probably do so early next week
[03:58] <ddaa> then you can tell me how like the new output
[03:59] <ddaa> at some point in the not-too-distant future we should also be able to get rid of all those spurious warnings
[03:59] <LarstiQ> carlos: ah, there you are
[03:59] <carlos> LarstiQ: hi
[03:59] <dooglus> hi.  is there some way I can list all the malone bugs I have commented on?
[03:59] <ddaa> by only scanning branches which were pulled since the last scan
[03:59] <ddaa> that's also going to be very much needed once bzr imports get published
[03:59] <ddaa> for simple performance reasons
[04:00] <LarstiQ> carlos: does my last reaction to #33029 clear things up?
[04:02] <carlos> LarstiQ: yeah, I know what you mean now, thanks. But I thought that 'bzr push' updates it already so the download is on sync already
[04:02] <LarstiQ> carlos: sftp push does not update the workingtree, rsync does. In the past the rsync push was used, but not anymore
[04:03] <carlos> oh, I see...
[04:03] <LarstiQ> yeah
[04:03] <LarstiQ> so, is your original problem still showing up?
[04:05] <carlos> I removed the latin1 chars and did the commit. retrying it now after the bzr revert...
[04:05] <carlos> LarstiQ: yeah, still getting the error
[04:05] <LarstiQ> carlos: good
[04:05] <carlos> if my name has the non ascii chars at ~/.bazaar/bazaar.conf
[04:06] <carlos> hmm, wait, it's UTF-8
[04:06] <kiko> BjornT, ping?
[04:07] <BjornT> hi kiko 
[04:07] <kiko> BjornT, can you check out a diff with me?
[04:07] <kiko> https://chinstrap.ubuntu.com/~dsilvers/paste/filepfihdB.html
[04:08] <kiko> BjornT, I'm confused as to why we need to both build and raise the exception /and/ store the exception in the view.
[04:08] <kiko> that seems odd to me
[04:08] <carlos> LarstiQ: confirmed, same problem. I tried using ISO-8859-1 and UTF-8 as the encoding for ~/.bazaar/bazaar.conf and both fail with the same error
[04:09] <ddaa> the committer (and a few other things, like the branch nick) are not properly unicodified in the testatement
[04:12] <BjornT> kiko: SQLObjectAddView doesn't have top_of_page_errors, so if we don't store the error there, we can't display it. we could modify SQLObjectAddView to make this simpler though.
[04:12] <LarstiQ> I can commit with kanji in email, but bzr log certainly prints out the wrong thing
[04:12] <carlos> LarstiQ: I was able to commit until last Tuesday
[04:13] <kiko> BjornT, it seems very strange -- why not just raise WidgetsError() with no string supplied?
[04:13] <LarstiQ> carlos: got the relevant section of bazaar.conf for me?
[04:13] <carlos> or at least I was aware last Tuesday
[04:13] <carlos> LarstiQ: email
[04:13] <carlos> I have now: email=Carlos Perello Marin <carlos.perello@canonical.com>
[04:13] <carlos> and it works, I had before: email=Carlos Perell Marn <carlos.perello@canonical.com>
[04:13] <carlos> and it fails
[04:14] <BjornT> kiko: WidgetErrors expect a list of errors. it's used to determine how many input errors there are
[04:14] <LarstiQ> carlos: thanks
[04:14] <kiko> BjornT, it should be unified then -- it's silly to have the callsite need to store this in a local variable, I feel.
[04:14] <kiko> anyway, my 2c, file a bug if you agree.
[04:14] <LarstiQ> carlos: works here
[04:14] <carlos> LarstiQ: perhaps it's related with the working tree....
[04:15] <carlos> I don't know...
[04:15] <BjornT> kiko: what do you think should be unified? i agree that SQLObjectAddView, SQLObjectEditView and GeneralFormView should be more unified.
[04:15] <LarstiQ> carlos: this area is certainly problematic, so I'm going to look at it now, but I'm not sure what the cause of the exception is
[04:16] <carlos> LarstiQ: just in case it would help you... my locale is en_GB.UTF-8
[04:16] <carlos> LarstiQ: and I'm running dapper
[04:18] <LarstiQ> carlos: ah, I'm running breezy
[04:18] <LarstiQ> and have en_US as a locale, somehow
[04:30] <bradb> Hm, I thought sftp was like 90% faster now? It still seems life-threateningly slow.
[04:30] <stub> Should 'chunkydiff on' still be the default in launchpad.conf? It is currently off (and I'm having much more success with page tests with it being off and am wondering if I should change the comment)
[04:30] <bradb> s/sftp/sftp push/
[04:31] <bradb> jblack: ping
[04:32] <bradb> stub: "success" isn't a word I'd use to describe the current failure output :)
[04:36] <kiko> BjornT, I think supplying the exception message to WidgetsError and then having to store it in the view is awkward, just that. don't you?
[04:39] <BjornT> kiko: yes, it should be enough to raise a WidgetsError, SQLObjectAddView should handle the rest.
[04:40] <kiko> BjornT -- we communicate! cool. could you file a bug?
[04:42] <BjornT> kiko: ok, i'll file a bug about it.
[04:42] <kiko> thanks
[04:46] <ddaa> kiko: it would be nice if I could have a review for launchpad/baz2bzr pretty soon, before I start building on it again.
[04:46] <ddaa> kiko: not asking you specifically, just asking you to ask a reviewer
[05:08] <carlos> stub: around?
[05:08] <stub> carlos: yes
[05:09] <carlos> stub: I'm with the POFile.path and POTemplate.path fixing
[05:09] <carlos> stub: I would want to take another approach as there are a lot of duplicates
[05:10] <carlos> stub: Do you think you would get an sql sentence to represent something like:
[05:10] <carlos>         if variant is None:
[05:10] <carlos>             path_variant = ''
[05:10] <carlos>         else:
[05:10] <carlos>             path_variant = '@%s' % variant
[05:10] <carlos>         # By default, we set as the path directory the same as the POTemplate
[05:10] <carlos>         # one.
[05:10] <carlos>         potemplate_dir = os.path.dirname(potemplate.path)
[05:10] <carlos>         path = '%s/%s%s.po' % (potemplate_dir, language.code, path_variant)
[05:10] <carlos> well, the variant part is already done
[05:11] <carlos> the interesting part is to get the POTemplate.path field, get the dirname of it and use it to create the POFile.path dirname
[05:12] <stub> Should be doable - just need to create a stored procedure to do the os.path.dirname bit. Or maybe do the whole thing and simplify the SQL
[05:13] <carlos> stub: do you think you would have time to do it today before leaving?
[05:13] <carlos> pretty please.... :-P
[05:14] <stub> CREATE OR REPLACE FUNCTION dirname(path text) RETURNS text AS
[05:14] <stub> $$
[05:14] <stub> import os.path
[05:14] <carlos> oh, cheater! you are using python :-P
[05:14] <stub> return os.path.dirname(path)
[05:14] <stub> $$ LANGUAGE plpythonu
[05:17] <carlos> stub: ok, https://chinstrap.ubuntu.com/~dsilvers/paste/filewDTSPu.html
[05:17] <carlos> stub: could you execute that on staging?
[05:18] <carlos> stub: I removed the IS NULL check as that's not true anymore, and, anyway, it's safe to do that
[05:19] <stub> launchpad_staging=# create OR REPLACE FUNCTION dirname(path text) RETURNS text AS
[05:19] <stub> launchpad_staging-# $$
[05:19] <stub> launchpad_staging$# import os.path
[05:19] <stub> launchpad_staging$# return os.path.dirname(args[0] )
[05:19] <stub> launchpad_staging$# $$ LANGUAGE plpythonu IMMUTABLE RETURNS NULL ON NULL INPUT;
[05:19] <stub> CREATE FUNCTION
[05:19] <stub> launchpad_staging=# select dirname('/foo/bar');
[05:19] <stub>  dirname
[05:19] <stub> ---------
[05:19] <stub>  /foo
[05:19] <stub> (1 row)
[05:20] <stub> (need to use args[0]  instead of path due to plpythonu not understanding parameter names)
[05:20] <carlos> oh, ok
[05:20] <carlos> interesting to know htat
[05:21] <stub> carlos: the second sql fragment is broken - POFile.potemplate.POTemplate.id should have an '=' in there instead of the '.' I assume?
[05:21] <carlos> hmm, right
[05:21] <carlos> I'm fixing it atm
[05:22] <carlos> stub: https://chinstrap.ubuntu.com/~dsilvers/paste/filexZPaaa.html
[05:23] <carlos> jordi: hi
[05:26] <stub> carlos: run and committed on staging.
[05:26] <carlos> stub: thanks
[05:27] <kiko> thanks stub good work
[05:29] <carlos> stub: ok now we have "only" 350 entries to fix manually vs the 13000 we got before...
[05:30] <jordi> hi
[05:31] <ddaa> carlos: how does bzr work when you save your committer id in UTF8?
[05:31] <LarstiQ> carlos: if you're not too busy, mind joining #bzr? Zindar just hit what looked like the same unicode bug, but can't reproduce it anymore
[05:31] <ddaa> In a way that is consistent with your locale...
[05:42] <LarstiQ> is it possible to express bug relations, like '#nnn blocked by #nnn'?
[05:44] <kiko> LarstiQ, no, it isn't. 
[05:44] <LarstiQ> is that planned?
[05:44] <kiko> can you describe your use case in an email to launchpad-users?
[05:44] <LarstiQ> sure
[05:44] <kiko> it's the subject of controversy, so it will help if you describe the problem
[05:46] <carlos> ddaa: no UTF-8 but latin1
[05:46] <ddaa> carlos: how does bzr work when you save your committer id in UTF8?
[05:47] <ddaa> bzr expects user data to be consistent with the locale
[05:48] <carlos> ddaa: same error
[05:48] <carlos> LarstiQ: Just a minute I'm on the phone...
[05:48] <ddaa> carlos: thank you
[06:06] <LarstiQ> kiko-fud: does that help?
[06:23] <salgado> BjornT, around?
[06:23] <BjornT> salgado: yeah
[06:26] <salgado> BjornT, I have a branch from mark on my queue which I only saw today. he said he'd like to get this reviewed before the weekend, but I'm affraid I won't be able to do it because of shipit, so I'm looking for someone to take over that branch. would it be possible for you to review it?
[06:31] <BjornT> salgado: hmm, i'd rather that you' push it off to someone else. i've already done quite a lot reviewing this week, and have promised to review carlos branch as well.
[06:33] <carlos> daf: hi, around?
[06:34] <salgado> BjornT, fair enough. thanks anyway
[06:42] <Sanitarium_23> hello everyone... is there anyone here that could help me solve my little problem
[06:42] <Sanitarium_23> about ubuntu
[06:43] <carlos> Sanitarium_23: if you have any problem with Ubuntu, is better that you ask at #ubuntu
[06:43] <Sanitarium_23> thank you carlos
[06:44] <carlos> Sanitarium_23: you are welcome
[07:16] <doko_> bradb: I see that allmost all bugs files for the open.office.org2?-* packages are assigned to the openoffice.org2?-amd64 source package. please could you change that?
[07:17] <bradb> doko_: Malone is getting that from the Soyuz data. How would you prefer it to work?
[07:17] <kiko> LarstiQ, let me check
[07:18] <bradb> doko_: Put otherwise, for cases when one bp name can be part of more than one sp name, we're sort of screwed.
[07:18] <kiko> yeah, it works, thanks
[07:18] <LarstiQ> k
[07:19] <LarstiQ> it might not solve the controversy, but the debian bts folk should have some food for that
[07:19] <kiko> yeah
[07:29] <SteveA> BjornT: i just took that review from salgado.  i'll look at it tomorrow.
[07:33] <doko_> bradb: could you default it to the non amd64 source package?
[07:35] <bradb> doko_: We might be able to do a hack for that. How often does this happen for other BPs and SPs? What are the -foo endings that we should special-case?
[07:36] <doko_> bradb: openoffice.org2-amd64 and openoffice.org-amd64 is the only kind of this crack
[07:38] <bradb> hm
[07:41] <kiko> bradb, can you explain why this is happening?
[07:42] <bradb> kiko: I'm guessing the Soyuz code [0] 's the -amd64 package.
[07:42] <kiko> bradb, I thought this wasn't "soyuz code" but a method we wrote for malone?
[07:45] <daf> carlos: pong
[07:45] <bradb> kiko: Nope. It uses IDistribution.getPackageNames
[07:46] <bradb> Heh, this is lovely:
[07:46] <bradb>         # PublishedPackageView uses the actual text names.
[07:46] <bradb>         for p in publishings:
[07:46] <bradb>             sourcepackagenametxt = p.sourcepackagename
[07:46] <bradb>             break
[07:46] <bradb>         sourcepackagename = SourcePackageName.byName(sourcepackagenametxt)
[07:47] <kiko> bradb, who added getPackageNames?
[07:47] <bradb> kiko: Dunno. It's been around for a long time, I think.
[07:49] <bradb> revno: 2705
[07:49] <bradb> message:
[07:49] <bradb>   r=spiv, mark's soyuz loving.
[07:49] <kiko> okay.
[07:50] <kiko> salgado, have some time for a simple registry review?
[07:57] <kiko> or BjornT?
[07:59] <BjornT> kiko: i can do it soon
[08:02] <kiko> rock and roll
[08:02] <kiko> BjornT, https://chinstrap.ubuntu.com/~dsilvers/paste/fileR2zJUb.html
[08:10] <BjornT> kiko: what does the patch fix/do?
[08:12] <kiko> it: a) makes the product and project listings more consistent b) fixes bug 5596 c) removes some duplicated code in favor of using a small inline template d) fixes the actions portlet for projects
[08:12] <Ubugtu> malone bug 5596 in launchpad "/products/+all and /projects/+all have a dumb title" [Normal,In progress]  http://launchpad.net/bugs/5596
[08:13] <kiko> BjornT, it's mainly factoring code that is already in pro*-listing-detailed out of the mail -all and -index templates 
[08:15] <ddaa> sabdfl: ping
[08:17] <ddaa> sabdfl: I would like to allow vcs imports to be published for products/projects which have not been reviewed. Would you be happy with relaxing this constraint?
[08:18] <kiko> ddaa, perhaps use email so we have this conversation registered in the list?
[08:18] <kiko> this is the sort of thing IRC is particularly bad for
[08:18] <ddaa> mpf... right... I just wanted to get this patch done ASAP, since it's getting in the way for something I need next week.
[08:18] <ddaa> (though I _can_ work around)
[08:18] <kiko> did you get the paramiko issue solved, ddaa?
[08:19] <ddaa> sabdfl: see you on launchpad@
[08:19] <kiko> maybe you can give that rationale in the message as well then
[08:19] <ddaa> kiko: I worked around the immediate problem I had (which involved rsyncing a few gigabytes through chinstrap)
[08:20] <BjornT> kiko: looks good, r=bjornt
[08:20] <ddaa> kiko: but I have still no update on the two RT that are due tommorrow.
[08:20] <kiko> thanks BjornT 
[08:20] <kiko> ddaa, what is the second rt#? I only know of 3241
[08:21] <ddaa> I think I liked to it in a comment...
[08:22] <kiko> BjornT, do you have a suggestion for bug 29778?
[08:22] <Ubugtu> malone bug 29778 in launchpad "add project link to product" [Normal,Confirmed]  http://launchpad.net/bugs/29778
[08:23] <ddaa> kiko: the other one is #3121
[08:23] <kiko> ddaa, what's it about?
[08:23] <ddaa> both requests are about making it possible to publish bzr imports
[08:23] <kiko> the first is about paramiko
[08:24] <kiko> what about the second one?
[08:24] <ddaa> the second one is about the place to sftp to using paramiko :)
[08:24] <kiko> I see
[08:31] <BjornT> kiko: can't we just add a link in the product overview portlet?
[08:31] <kiko> BjornT, we could either link the title (I don't like that very much) or add some text, but what would the text be?
[08:35] <BjornT> kiko: i was talking about adding a link in the product portlet, not in the project portlet. actually, i think the project portlet probably could be removed, it's not very visible anyway.
[08:35] <bradb> kiko: Do you have time to drive-by my fix for bug 6026?
[08:35] <Ubugtu> malone bug 6026 in malone "Oops from changing bug's product when milestone is set" [Normal,In progress]  http://launchpad.net/bugs/6026
[08:36] <kiko> bradb, yes
[08:36] <kiko> BjornT, okay, gotcha
[08:37] <bradb> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileG0BflE.html
[08:41] <kiko> bradb, that code in mailnotification is kinda gnarly
[08:41] <kiko> bradb, and are you sure bugtask_after_notification.product is not-None?
[08:41] <kiko> is it asserted somewhere?
[08:42] <bradb> kiko: Yes, because of the IUpstreamBugTask.providedBy
[08:43] <kiko> okay
[08:43] <kiko> bradb, r=kiko
[08:43] <bradb> kiko: cheers
[08:44] <kiko> bradb, actually
[08:44] <kiko> could you avoid using milestone_cleared entirely and just put the addWarningNotification inside the upper if clause?
[08:47] <bradb> kiko: I'm not sure, because there might be tx issues if the applyChanges fails
[08:47] <bradb> It seemed to me to be safe only after that call
[08:47] <bradb> er, applyWidgetsChanges
[08:47] <kiko> mmmm
[08:47] <kiko> okay.
[08:47] <kiko> not a big deal anyway
[08:53] <matsubara> Anyone using dapper with firefox 1.5.0.1? Could you try to reproduce bug 32950?
[08:53] <Ubugtu> malone bug 32950 in malone "Cannot add comments on any bug report" [Major,Unconfirmed]  http://launchpad.net/bugs/32950
[08:57] <kiko> BjornT, if you can reply to the email Re: Request incoming.. email I just sent you, I'd appreciate it.
[08:57] <kiko> (we will collate into RT)
[09:11] <BjornT> kiko: sure
[09:11] <kiko> thanks
[09:17] <kiko> hey
[09:17] <kiko> does anyone have a V3  RSA PGP key?
[09:19] <LarstiQ> kiko: you just want a v3 key, or from launchpad people?
[09:21] <LarstiQ> kiko: f081195d 
[09:22] <kiko> LarstiQ, well, I want someone who has it to try and register it in launchpad
[09:23] <LarstiQ> Sven Guckes is registered in launchpad, and has a v3 key
[09:23] <kiko> do you know this character?
[09:24] <LarstiQ> know is a strong word, but I could try to ask
[09:24] <kiko> that would be awesome
[09:40] <sabdfl> ddaa: pong
[09:40] <sabdfl> ddaa: sure
[09:40] <ddaa> sabdfl: can you reply to my message on the mailing list?
[09:41] <ddaa> at least for the record
[09:41] <sabdfl> ddaa: ok
[09:41] <ddaa> thanks
[09:42] <lifeless> morning
[09:43] <ddaa> oops, I sent it to rince... resending to ubuntu.com
[09:44] <ddaa> hello lifeless
[09:44] <ddaa> I think yesterday you told me to expect to hear back from you about something, do you remember what it was?
[09:47] <lifeless> ddaa: yes, and you did directly from spiv
[09:48] <ddaa> ok
[09:59] <kiko> matsubara, are you still unable to reproduce bug 33203?
[09:59] <Ubugtu> malone bug 33203 in launchpad "poll: dates are not properly validated" [Normal,Unconfirmed]  http://launchpad.net/bugs/33203
[10:00] <matsubara> kiko: I only tried that day. I thought I had left a comment on the bug.
[10:00] <kiko> you did I believe
[10:02] <matsubara> kiko: no, I didn't. Just opened it here on the browser and there's no comment.
[10:02] <kiko> oh
[10:07] <matsubara> kiko: left a comment there and asked for more details on how to reproduce it. Also changed the status to Needs Info.
[10:08] <kiko> matsubara, is it a dupe of bug 2732?
[10:08] <Ubugtu> malone bug 2732 in launchpad "Adding a poll with a finish date before start date causes error" [Normal,Confirmed]  http://launchpad.net/bugs/2732
[10:09] <kiko> lifeless, saw my email on PQM mail to arch-commits? any clue what's up?
[10:09] <matsubara> kiko: I don't think so because the reporter said he didn't get any error, just a changed date.
[10:09] <kiko> oh
[10:09] <kiko> okay
[10:10] <kiko> carlos, are you aware of bug 31146? is it a dupe?
[10:10] <Ubugtu> malone bug 31146 in rosetta "Too many fields in Polish translation of Ubuntu Documentation (quicktour)" [Normal,Unconfirmed]  http://launchpad.net/bugs/31146
[10:10] <lifeless> kiko: wasn't much detail in your mail, so I'm going to have to dig to figure out
[10:10] <kiko> lifeless, there has been no mail to arch-commits for two days
[10:10] <carlos> kiko: first time I see it...
[10:10] <lifeless> kiko: are you saying that commits go through ok but no mail is hitting the list ?
[10:10] <kiko> there have been multiple commits to PQM meanwhile
[10:10] <kiko> correct
[10:11] <kiko> sorry for the lack of detail, I'm all over the shop today
[10:11] <carlos> daf: still around?
[10:11] <lifeless> ok. Have you asked the mail admins if there are internal glitches? (thats my first stop)
[10:11] <kiko> lifeless, apparently stuart checked balleny and the queue was empty
[10:11] <kiko> that may mean the emails were bounced though
[10:11] <kiko> I haven't asked, no
[10:14] <kiko> matsubara, did you manage to land your code?
[10:14] <BjornT> lifeless: pqm does send out success/failure mails successfully though.
[10:16] <kiko> lifeless, right, BjornT's the man
[10:16] <matsubara> kiko: yes. At least I got the pqm email with the success status. but no word from dilys or the arch-commits list
[10:23] <kiko> ddaa, as you see "email works" ;)
[10:26] <daf> carlos: yes
[10:34] <carlos> daf: I'm going to have dinner soon, would you want to talk later or you prefer to leave it for tomorrow? (I will prepare a prototype tonight anyway)
[10:39] <kiko> daf, ping?
[10:39] <daf> carlos: I suggest you let me know when you have the prototype
[10:39] <daf> kiko: pong
[10:39] <carlos> daf: ok
[10:39] <kiko> daf, how about we move timeout bugs to a separate milestone?
[10:39] <kiko> I get the feeling that the oops milestone is too crowded and that crashes can be directly fixed, whereas timeouts rarely so
[10:39] <daf> carlos: but don't take too long over it!
[10:39] <daf> that's an interesting idea
[10:40] <daf> it doesn't cost us 
[10:40] <carlos> daf: will concentrate on it now and leave the data migration for later, don't worry
[10:40] <kiko> daf, are you +1 on it?
[10:40] <daf> it doesn't cost us much to try it
[10:40] <kiko> daf, right
[10:40] <daf> I'm +0.5 on it, I think
[10:40] <kiko> how about we do the following
[10:40] <kiko> I update the bugs
[10:40] <kiko> you update the wiki docs?
[10:40] <daf> ok
[10:41] <kiko> cool
[10:43] <kiko> daf, are you okay with the name "oops-timeout", or just "timeout"?
[10:43] <kiko> the reason I ask is because both are, in theory, oopses
[10:47] <kiko> daf, ping?
[10:54] <kiko> https://chinstrap.ubuntu.com/~daf/bugs/scrape.py?q=milestone%3Aoops+-status%3Afix_released+-status%3Afix_committed+-status%3Arejected&s=assignee
[10:54] <kiko> this is our current set of crashers
[10:55] <kiko> https://chinstrap.ubuntu.com/~daf/bugs/scrape.py?q=milestone%3Aoops-timeout+-status%3Afix_released+-status%3Afix_committed+-status%3Arejected&s=assignee
[10:57] <daf> cool
[11:18] <kiko> daf, now, we need to assign the crashers and get them fixed by a deadline
[11:18] <kiko> and I mean, a DEADline
[11:19] <lifeless> kiko: I sent a test email
[11:19] <lifeless> kiko: its gone nowhere
[11:19] <kiko> lifeless, how come we get a confirmation mail back from PQM, though?
[11:21] <lifeless> kiko: that is an interested question.
[11:26] <kiko> so it is :)
[11:28] <elmo> umm, stupid bzr question
[11:28] <elmo> I just merged my rf-dak tree with soyuz production and it reverted a bunch of my local changes
[11:28] <elmo> I thought merge was like suppose to do what I want AND find me a pony, not randomly undo my work
[11:29] <LarstiQ> you had committed local changes?
[11:29] <elmo> yes
[11:29] <LarstiQ> Iirc I saw troublesome messages earlier today
[11:31] <LarstiQ> hmm, can't seem to find it
[11:32] <LarstiQ> elmo: I don't know how the branches in question look like, but I don't think that should be happening, no
[11:34] <elmo> [and while, I'm ranting, why on earth does bzr not DEPEND on python2.4-celementtree, gar] 
[11:48] <ddaa> elmo++
[11:48] <ddaa> it just makes no deb packaging sense
[11:52] <daf> carlos: how's it going?
[11:52] <carlos> daf: just came back from dinner...
[11:54] <elmo> oh, I think the 3 way diff imploded
[11:54] <elmo> bzr could really do with sign posting that as very different from a normal conflict