[12:04] <kiko-zzz> three strikes!
[12:04] <niemeyer> jblack: Don't worry too much about it.. my coffee was extremely strong today.
[12:05] <niemeyer> Anyway.. FOOOD!
[12:05] <jblack> have fun
[12:39] <bradb> How do I make an anchor for a moin wiki doc header, like "== Foobar =="? I want it to keep looking like it does now (i.e. not like a link), but be able to link directly to that section from somewhere else.
[12:40] <mdke> HelpOnMacros should have anchor instructions
[12:40] <mdke> bradb, ^
[12:40] <jblack> bradb: Are you doing skype or h.323?
[12:41] <bradb> HelpOnLinking was the first doc I tried, of course.
[12:41] <mdke> if its just a table of contents you're after, use the [[TableOfContents] ]  macro
[12:41] <bradb> mdke: Nope.
[12:41] <mdke> ok, anchor macro then
[12:42] <bradb> jblack: skype
[12:44] <bradb> mdke: you rock, thanks
[12:44] <mdke> np
[12:46] <bradb> mpt: around? i've got a UI to show you shortly
[01:12] <bradb> kiko-zzz: around?
[01:57] <mhz> re
[01:59] <wby87> hi, i got a question, how long does it usually take for the account registration email to be send?
[02:05] <Seveas> few minutes max
[02:51] <jamesh> ddaa's merges in the pqm queue don't look like they'll succeed ...
[02:57] <mhz> Seveas: ping
[03:02] <jamesh> stub: at some point, could you check that the <launchpad_errorreports> sections I added to the production, staging and dogfood configs look okay?
[03:02] <dilys> Merge to devel/launchpad: [r=SteveA]  New page layout: CSS columns, an embryonic sitemap, and a vertical nested menu instead of tabs. (r2893: Matthew Paul Thomas)
[03:02] <jamesh> (the errordir key in particular)
[03:21] <stub> jamesh: Sure. I'll be rolling that code out to staging today so we can see it in action.
[03:50] <jblack> when was udu? 
[03:51] <jblack> pardon, ubz
[03:51] <lifeless> ~ nov 1-14 
[03:55] <jblack> I'm looking at a map of cities within a day's drive..
[03:56] <jblack> I'm in a very good place. it looks to me like I've got over a 100 million people within a day's drive.
[03:57] <LarstiQ> heh, I've got 16 million in this entire country ;)
[03:57] <jblack> I'm 2 hours from new york, 5 hours from washinton DC, 2 hours from philly, 4 hours from baltimore...
[03:57] <jblack> boston is probably 6 or 7..
[04:00] <LarstiQ> BjornT: is https://wiki.launchpad.canonical.com/MaloneEmailInterfaceUserDoc up to date?
[04:04] <jblack> Really? I thought sidney had millions?
[04:04] <ajmitch_> it does
[04:05] <ajmitch_> but it's about 3 & 1/2 hours flying time away
[04:09] <stub> lifeless: Are you still waiting on a chroot jail for the new PQM box?
[04:10] <lifeless> stub: no, its all in my court at the moment
[04:11] <stub> lifeless: ok. Any rough eta? PQM on breezy/PG8.0 is the next step before we can do staging and production upgrades to breezy/PG8.0
[04:11] <lifeless> ah, did not know there was processes depending on me
[04:11] <lifeless> I have to flush a couple of things for bazaar
[04:12] <lifeless> before I get back to testing it
[04:12] <lifeless> in theory its all ready to go modulo an update to the latest launchpad-bzr
[04:13] <stub> I'm thinking of only taking one weeks of leave, so ideally pqm could be running sometime next week and we can update staging around Mon 19th if elmo is free
[04:13] <lifeless> in theory thats not a problem
[04:13] <stub> ok. If it slips it doesn't really matter
[04:24] <stub> Kinnison: Do you have the SQL fragments for adding the new distroarchrelease's for breezy and hoary? They got nuked on staging when I resynced from the production db.
[05:02] <stub> Launchpad will be going down in 30 minutes time, which will also put the Ubuntu wikis into read only more. Estimated down time is 30 minutes.
[05:04] <stub> spiv: I'll need to update the librarian too
[05:04] <spiv> stub: Ok.  Need anything from me for that?
[05:05] <stub> spiv: Nah - I think all the keys are currently setup for me so easier if I do it
[05:05] <spiv> Ok.
[05:09] <stub> lifeless: These tagging instructions I got from you appear to be out of date - they assume 'launchpad/devel' is a branch relative to the PQM user's home directory.
[05:09] <stub> lifeless: I need to tag r2888 as production 1.41
[05:23] <stub> And the bzr.integration in rolloouts is still broken :-(
[05:24] <jblack> I can't find one person on the internet with a installed gnomemeeting and a actual microphone
[05:24] <stub> I'll try integration head
[05:32] <lifeless> stub: the launchpad branch is fixed
[05:32] <lifeless> p.u.c/~robertc/baz2.0/launchpad
[05:32] <lifeless> I have to upload that into sourcecode
[05:33] <lifeless> stub: paste the instructions ..
[05:33] <stub> ok - thanks
[05:33] <stub> sudo to pqm
[05:33] <stub> bzr branch -r 2848 launchpad/devel launchpad/production/1.40
[05:33] <stub> in the pqm home
[05:33] <stub> and copy that to the public copy in /home/warthogs/archives/
[05:33] <stub> I think it is all fine except the launchpad/devel is now found in the archives directory?
[05:33] <lifeless> right, I assumed you'd cd to ~/archives/rocketfuel ;0)
[05:34] <stub> ok ;)
[05:35] <stub> Branching now
[06:17] <stub> database is up (so authserver is fine), but launchpad and the librarian will be down for at least another hour while I branch and test a fresh bzr
[06:19] <lifeless> mmm
[06:19] <lifeless> why do you need to do that ? (I'm not sure why you 'install' bzr at all, just run the copy from sourcecode...
[06:19] <stub> lifeless: I'm branching that p.u.c/bzr/launchpad branch to chinstrap so I can rsync it. Can you make it go faster?
[06:20] <lifeless> just rsync it from rookery
[06:20] <stub> I don't have a rookery account
[06:20] <lifeless> or take a copy of sourcecode/* and then do a bzr pull 
[06:20] <lifeless> yes you do
[06:20] <lifeless> rookery - everyone has an account
[06:20] <stub> I do?
[06:22] <stub> The reason I need to install bzr is so I can do automated installs, rather than manual and error prone installs, and I need to rewrite that bit of the scripts to run stuff direct from the rsynced bzr branch
[06:23] <lifeless> ok
[06:23] <lifeless> I was meaning 'why dont the scripts run from the branch as is'
[06:23] <lifeless> anyway, you should be able to get bzr in about 3 seconds by rsync
[06:27] <stub> Mainly because I hadn't realized it was runnable, and doing the install step made it identical to the paramiko, pybaz, config_manager steps.
[06:27] <lifeless> oh, so paramiko pybaz and config_manager are all runnable in situ
[06:28] <lifeless> do you have the bzr you need ?
[06:30] <stub> Getting there
[06:31] <lifeless> have you rsynced it ?
[06:31] <lifeless> rsync -a rookery:/home/robertc/public_html/baz2.0/launchpad 
[06:32] <jblack> gnomemeeting actually works with us dsl to new zealand dialup
[06:34] <stub> lifeless: Got that branch, but it is still failing on the revert step
[06:35] <lifeless> stub: what branch is it reverting ?
[06:35] <stub> Ahh... the traceback tells me 'files from a previous merge'. I'll clean things out
[06:35] <lifeless> bzr-tree-change
[06:35] <lifeless> if that exists remove it
[06:38] <stub> rsync --recursive --archive --hard-links --compress --delete-after --partial --include=/.bzr --include=/.bzr/** --exclude=* stub@chinstrap.ubuntu.com:/home/warthogs/archives/rocketfuel/launchpad/devel/ /srv/launchpad.net/production/mirror/rocketfuel/launchpad/devel
[06:39] <stub> Running /srv/launchpad.net/production/bin/bzr revert
[06:39] <stub> bzr: ERROR: lib/canonical/zeca/ftests/keys/0x046C6D63.get is already versioned
[06:39] <lifeless> eeeeeerk
[06:39] <lifeless> can I give you a workaround ?
[06:39] <lifeless> bzr branch /srv/launchpad.net/production/mirror/rocketfuel/launchpad/devel new-devel
[06:39] <lifeless> that will give you a good tree in new-devel
[06:40] <stub> Mmm... .but sloooow.....
[06:40] <lifeless> thats local
[06:40] <lifeless> should be fast
[06:40] <stub> I'll try pulling the prebuilt rocketfuel and 'pull --override' the production branch
[06:41] <lifeless> that too should be fast
[06:41] <lifeless> it updates quite reliably with cm update ;0
[06:42] <stub> Last time I tried config manager to build stuff on gangotri it took over 20 minutes.
[06:42] <mhz> hi
[06:42] <mhz> is launchpad off for maintainance?
[06:43] <stub> Is it using faster transports now, or has bzr's sftp been sped up yet?
[06:44] <lifeless> stub: 'update' not 'build'
[06:44] <lifeless> stub: we *have* a good tree, we should be able to manipulate it without doing fresh ones each time
[06:44] <stub> ahh... yes. update didn't exist then ;)
[06:45] <stub> So rsync prebuilt launchpad and cm update to build a fresh tree, and just cm update to update one
[06:45] <lifeless> I think thats a workable theory
[06:45] <lifeless> we'll need to give cm 'switch' or 'overwrite' rather than plain ol update
[06:45] <lifeless> but thats not hard
[06:46] <lifeless> I'm adding that to my TODO
[06:46] <stub> Oh... yes. That would be good. I'll try it with just build for the time being.
[06:52] <jamesh> stub: that gpg key file was removed and replaced by a symlink
[06:54] <stub> $ bzr pull --overwrite sftp://stub@chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/production/1.41
[06:54] <stub> bzr: ERROR: Not a branch: sftp://stub@chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/production/1.41
[06:54] <stub> Anyone see a typo in that, or is this the error jblack confirmed for me the other day?
[06:54] <jamesh> maybe //home instead of /home
[06:54] <jamesh> depending on how old the bzr is
[06:55] <stub> Double slash looks like it worked
[06:55] <stub> bah - pull overwrite didn't ;-(
[06:55] <jamesh> stub: and sftp transport should be a bit faster than it was now, since you can use compression
[06:55] <stub> 0 revisions pulled :-(
[06:57] <lifeless> grrr
[06:57] <lifeless> truncate .bzr/revision-history
[06:57] <lifeless> just by 3-4 lines
[06:57] <lifeless> or 10-20
[06:57] <lifeless> I've just added a todo to triple check the overwrite code
[06:58] <stub> Chop the tail you mean?
[06:59] <stub> Still 0 revisions pulled (although bzr log reports an earlier revision now)
[06:59] <lifeless> yah
[07:00] <lifeless> if want want to cheat
[07:00] <lifeless> chop it back tot he revision you want at the tip
[07:00] <lifeless> (log --show-ids | head) in the production branch will give you that
[07:00] <stub> But I'd then need to revert 
[07:00] <lifeless> yes
[07:00] <lifeless> garh right
[07:00] <lifeless> pull DOES a merge though
[07:00] <lifeless> you can't avoid that code path
[07:01] <stub> I'll need to use config manager to build a fresh tree I think - only way I can think of to avoid needing to pull --overwrite or revert (?)
[07:02] <stub> Apart from manually assembling it
[07:02] <lifeless> so
[07:02] <lifeless> do that on chinstrap
[07:02] <lifeless> then rsync on top of an existing tree
[07:02] <lifeless> for max speed
[07:02] <stub> Good idea.
[07:08] <stub> Ok - all build on chinstrap.
[07:16] <dilys> Merge to devel/launchpad: [trivial]  Add all arcchitectures to staging's Gina configuration (r2894: Stuart Bishop)
[07:20] <stub> librarian back up
[07:23] <stub> launchpad back up
[07:23] <stub> :-)
[07:51] <jamesh> stub: re: bug 5338, would this mean that the same auth cookie would work on both production instances?
[07:51] <Ubugtu> Malone bug #5338: Zope read and write conflicts when reading and saving session data In: launchpad (upstream), Severity: Normal, Assigned to: Stuart Bishop, Status: New https://launchpad.net/bugs/5338
[08:16] <stub> jamesh: Yes
[08:16] <stub> jamesh: So we can turn off server affinity
[08:20] <jamesh> stub: okay, it'll be interesting to see how long I stay logged in after the change then ...
[08:20] <stub> How long do you stay logged in for now btw?
[08:22] <SteveA> morning
[08:23] <jamesh> stub: depends.  Sometimes a day, sometimes an hour
[08:23] <stub> SteveA: Morning
[08:24] <stub> Ooh.... pqm spam.
[08:25] <lifeless> stub: at the moment I stay logged in for < 1 form
[08:25] <lifeless> i.e. login 
[08:25] <lifeless> fill out form
[08:25] <lifeless> discuss a bit
[08:25] <lifeless> click save, get 'not logged in error'
[08:27] <SteveA> lifeless: i *still* need to fix the Vary header thing
[08:27] <lifeless> ;0
[08:27] <SteveA> i need to locate what branch that work is on and revive it
[08:29] <stu1> Wheee.... locked up except for my caps lock and scroll lock lights flashing in unison
[08:29] <lifeless> dude
[08:29] <lifeless> whack ;0
[09:34] <jblack> stevea: You're UP!
[09:34] <lifeless> ewwww
[09:34] <lifeless> TMI
[09:34] <jblack> tmi..
[09:34] <jblack> too much imagination.
[09:34] <jblack> lol
[09:36] <jblack> hmm. kind of hard not to take that the wrong way
[09:36] <sivang> morning all
[09:38] <jblack> hi sivang
[09:39] <jblack> lifeless: Where do we want the new mirrors to go? (the old ones go to http://mirrors.sourcecontrol.net)
[09:39] <lifeless> bzr mirrors ?
[09:39] <jblack> yeah
[09:39] <lifeless> they should be published on bazaar.launchpad.net
[09:40] <jblack> isn't that where the imports go?
[09:40] <lifeless> using the supermirror file system hierarchy naming scheme 
[09:40] <lifeless> yes
[09:40] <lifeless> we're publishing them all in one namespace
[09:40] <lifeless> the bzr sftp server will be listening on bazaar.launchpad.net too
[09:40] <ajmitch_> evening
[09:40] <lifeless> so there is no conflict with the old arch based service
[09:41] <lifeless> elmo has a new ip address on the production supermirror to allow this for sftp already
[09:41] <jblack> Ok. so the current imports are listed at bazaar.launchpad.net and mirrored to mirrors.sourcecontrol.net
[09:41] <lifeless> no
[09:41] <lifeless> they are listed at bazaar.ubuntu.com
[09:41] <lifeless> bazaar.launchpad.net is currently unused
[09:41] <jblack> +click+
[09:41] <lifeless> ;)
[09:42] <jblack> Not sure why we need an extra ip though. virtual hosting doesn't require it
[09:42] <lifeless> SFTP handshaking does
[09:42] <lifeless> like ssl in that respect, host id occurs after key exchange
[09:44] <jblack> I want a new documentroot.
[09:45] <jblack> I don't think we specify the root. I'd like /src/sm-ng 
[09:57] <jblack> stevea: I did manage to get a working gnomemeeting going.
[10:00] <SteveA> gnomemeeting is kinda tricky to get working unless you can configure your NAT routers
[10:02] <jblack> which I had to do. 
[10:02] <jblack> took some effort. I was double natted before I started.
[10:03] <jblack> skype doesn't run here. 
[10:03] <sivang> jblack: you probably need to statically compiled version with QT in
[10:03] <sivang> jblack: that will save you lots of hand dependency resolution of missing deps
[10:03] <jblack> skype has sources?
[10:05] <sivang> hmm, seems not
[10:06] <jblack> Would surprise me. skype is supposed to be proprietary software.
[10:06] <jblack> gnomemeeting was a lot a lot easier to set up this time. relatively, that is.
[10:06] <jblack> Now they tell you how the firewall is in the way, and waht specifically you need to do.
[10:07] <jblack> I can even _receive calls_ (oohhh, ahhh)
[10:07] <jblack> Talked with an old friend from New Zealand
[10:07] <sivang> jblack: skype tells you cannot receive calls?
[10:07] <jblack> skype doesn't start at all.
[10:08] <jblack> no output, no anything. 
[10:10] <daf> that happened to me
[10:10] <daf> then as soon as I started stracing it to see what it was doing, it showed a GUI
[10:10] <jblack> I'm happier that way anyways. gnomemeeting is free software.
[10:11] <daf> I haven't managed to get gnomemeeting working
[10:11] <jblack> poll(
[10:11] <daf> shtoom is great when it works
[10:11] <daf> if it was as just-works as skype, it would be wonderful
[10:11] <jblack> when did you last try gnomemeeting?
[10:12] <daf> a while ago
[10:12] <daf> does it do SIP now?
[10:12] <jblack> its still h323.
[10:12] <daf> ah, ok
[10:12] <daf> I know even less about h323 than I do about SIP :)
[10:12] <jblack> and 326 or 328 or something that helps with nat
[10:12] <jblack> You still have t o map a tcp port, but that's generally pretty easy.
[10:13] <jblack> natted nat confused it, but when I stuck my wireless ap on the outside of the local firewall, punched.. 1070 or some such, it worked great
[10:13] <SteveA> jblack: when you say "skype doesn't run", did you try sladen's apt repository?
[10:13] <jblack> thats where I got it from, yes
[10:14] <SteveA> you know that it takes 45 secs to start?
[10:14] <jblack> I may not have waited that lone.
[10:15] <SteveA> it takes AGES!
[10:15] <daf> gosh
[10:15] <jblack> gah. it did come up.
[10:15] <jblack> I still want to use gnomemeeting
[10:15] <SteveA> i can't punch holes in my nat
[10:16] <sivang> SteveA: slande's repo has a package for the statically linked version?
[10:16] <SteveA> i have no idea
[10:16] <SteveA> it works for me on breezy
[10:16] <jblack> works for me on dapper
[10:16] <sivang> jblack: if it still doesn';t start after you wait 45 seconds, then fetch the tar.gz that stub did, it shoudl work
[10:17] <jblack> this license agreement says it can install spyware
[10:18] <jblack> ohhh. looks like this may be an illegal version of skype too, unless Paul got an excpetion to 3.1
[10:24] <jblack> stevea: you have to punch for skype too, for inbound calls
[10:25] <SteveA> i didn't have to
[10:25] <daf> jblack: I called Steve yesterday with skype, and neither of us did any manual punching
[10:26] <SteveA> i think it uses outbound HTTP polling
[10:26] <jblack> Hmm. 
[10:26] <SteveA> in a number of weeks, we'll be using sip / asterisk kinda stuff
[10:26] <SteveA> when it is set up properly in the DC
[10:27] <jblack> maybe the advanced settings page is wrong
[10:27] <SteveA> until then, i'd like people to use skype, and not get everyone setting up several different systems
[10:28] <jblack> respectfully, I'm not happy about skype
[10:31] <sivang> asterik is cool
[10:31] <jblack> I understand the difficulties of coordinating an organization. I've got it, and I'll use it.
[10:32] <jblack> But I'm disatisfied with this decision.
[10:33] <SteveA> jblack: i appreciate what you're saying.
[10:35] <jblack> I'm ready to receive that phone call when you want. I'd like to keep it short and professional
[10:35] <SteveA> stub: hi.  when will staging next be updated to use new code?
[10:47] <daf> bug 5411
[10:47] <Ubugtu> Malone bug #5411: "list all packages" times out In: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/5411
[11:11] <poningru> bug 1
[11:11] <Ubugtu> Malone bug #1: Microsoft has a majority market share In: Ubuntu, Severity: Critical, Assigned to: Mark Shuttleworth, Status: Accepted https://launchpad.net/bugs/1
[11:50] <stub> SteveA: Staging was updated earlier today, before you came online.
[11:53] <niemeyer> Morning!
[11:53] <stub> Morning
[11:56] <jamesh> stub: looks like the error reports are getting generated okay
[11:56] <jamesh> (for staging)
[11:57] <SteveA> jamesh: the OOPS ids look a little short
[11:57] <SteveA> OOPS-S6
[11:58] <SteveA> i was expecting them to have the same length each time
[11:58] <jamesh> SteveA: yeah.  I guess I could pad them
[11:58] <SteveA> mpt: which do you think is better for end userse?
[11:58] <daf> does the "S" in "S6" change?
[11:58] <SteveA> S is for staging
[11:59] <jamesh> daf: S == staging
[11:59] <SteveA> in production it will be A or B
[11:59] <daf> ah, I see
[12:01] <SteveA> new layout is on staging now
[12:02] <mpt> Goooooooooooooood morning Launchpadders
[12:03] <mpt> SteveA, which out of what?
[12:04] <daf> OOPS-S6 vs. OOPS-S0006
[12:04] <mpt> I don't think it matters in the slightest :-)
[12:04] <mpt> Are they being lined up in a table somewhere?
[12:04] <SteveA> ok, then we'll leave it as is
[12:04] <SteveA> not for users
[12:05] <SteveA> maybe for developers some day
[12:05] <SteveA> jamesh: this is really cool.
[12:05] <SteveA> so, what happens next?  analysis scripts/
[12:05] <jamesh> mpt: also, could you check the wording I added on the exception pages?
[12:06] <jamesh> SteveA: yeah.  I'll base them on what kiko is using
[12:06] <mpt> jamesh, URL?
[12:06] <jamesh> let me check
[12:06] <SteveA> https://staging.ubuntu.com/asdasd
[12:07] <jamesh> launchpad-notfound.pt, launchpad-oops.pt and launchpad-requestexpired.pt
[12:07] <mpt> jamesh, that's fine
[12:08] <mpt> I might do some tweaking later to further discourage people from quoting the never-changing boilerplate in bug reports
[12:09] <stub> Should we have a 'report a bug' link, which prefils the OOPS id, on those pages? Or is that just asking for trouble and dupes?
[12:10] <jamesh> stub: not sure.  The fact that the oops ID has been shown to the user means we have a record of the crash
[12:10] <SteveA> mpt: on the new layout, the menus have a clickable area that is just the text.
[12:10] <matsubara> good morning!
[12:10] <jamesh> stub: we don't want a situation where we have a bug report for every oopsid with a description of "asdf"
[12:10] <mpt> stub, kiko's reports are more accurate and less noisy, and what jamesh said
[12:10] <SteveA> is there a way to make it the entire row area?
[12:11] <mpt> SteveA, ah yes, I tried to fix earlier but it was screwing with the bullets
[12:11] <mpt> I'll have another go
[12:11] <SteveA> do we need bullets?
[12:11] <SteveA> i mean, at the top level
[12:11] <SteveA> i guess so...
[12:12] <mpt> Well now they're not tabs, they can have proper icons
[12:12] <SteveA> the funny thing is, i keep trying to scroll up
[12:12] <SteveA> because the top of the page is so much thinner than i'm used to
[12:13] <mpt> cripes, it's on production already!
[12:13] <SteveA> mpt: do we need "Launchpad >>" at the start of the hierarchy?
[12:13] <SteveA> no it isn't
[12:13] <SteveA> it's on staging
[12:13] <mpt> oh
[12:14] <mpt> how did that happen
[12:14] <mpt> oh, I used Ctrl+Enter
[12:14] <SteveA> i asked stub to update staging
[12:15] <SteveA> 25% is a lot when i'm using the full width of my 1280 screen
[12:15] <mpt> yes
[12:17] <mpt> I think it would be odd to have a hierarchy that *didn't* start with the front page
[12:17] <SteveA> there's the icon
[12:17] <SteveA> }=>
[12:18] <SteveA> mpt: are the columns 25% including margins and gutters ?
[12:19] <daf> mpt: the new menu stuff in staging is interesting
[12:19] <SteveA> do you think it would work to have the whitespace on the extreme LHS and RHS less wide?
[12:20] <SteveA> daf: the menus top left aren't finished.  i need to write some code for them
[12:20] <mpt> SteveA, they're 24%. The gutters are 1% each.
[12:20] <daf> I like the fact that the tabs are gone, I think
[12:20] <daf> I think they were misleading
[12:21] <SteveA> mpt: can you make the whitespace on the extreme LHS and RHS a fixed width?
[12:21] <mpt> yes, I never liked them where they were, but I wasn't in charge of their position
[12:21] <mpt> SteveA, it already is, 1em
[12:21] <mpt> so the layout is
[12:21] <SteveA> try 0.5 em
[12:22] <mpt> [1em margin]  [[24% column]  [1% space]  [50% column]  [1% space]  [24% column] ]  [1em margin] 
[12:23] <mpt> SteveA, I think it would look wrong for the sidebars to be closer to the edge of the window than they are to the rest of the layout (0.5 em < 1% for most screen widths)
[12:25] <kiko> hello morning people
[12:25] <kiko> jamesh, would you like a new copy of the analysis script?
[12:25] <kiko> it fixes the bug ddaa reported
[12:25] <mpt> yeah, it's a bit odd
[12:25] <cprov> morning guys
[12:25] <kiko> the mainloop is braindead in that it read()s the whole files
[12:26] <kiko> but it's probably not too difficult to convert it into a state machine that readline()s the file
[12:26] <kiko> or perhaps you will do things using a different model
[12:26] <kiko> (is jamesh around?)
[12:26] <kiko> daf, what's up with bug 5411?
[12:26] <Ubugtu> Malone bug #5411: "list all packages" times out In: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/5411
[12:27] <kiko> hey salgado 
[12:27] <salgado> yo kiko 
[12:27] <kiko> what's cookin
[12:28] <salgado> need to check if everything is okay with shipit reports and get it running on production
[12:29] <salgado> stub, ping
[12:29] <SteveA> mpt: i looked in my browser at various window sizes (but not various font sizes), and there just seemed to be too much whitespace around the edge of the content/boxes area
[12:29] <daf> kiko: just what it says -- if you ask for a list of all packages, it oopses with a timeout
[12:30] <kiko> daf, have you checked out what sort of SQL is being executed for that page?
[12:30] <SteveA> mpt: and, comparing to production, a little more than before
[12:30] <kiko> I suspect we may need a view for that
[12:30] <daf> kiko: not yet -- just wanted to make a note of it
[12:30] <mpt> SteveA, ah, true, it was 0.75em before
[12:30] <mpt> I'll trim it down
[12:31] <SteveA> mpt: you and i have about half a week to get this polished off, before it goes out to production.  i'll get cracking on the code soon.
[12:33] <kiko> daf, I am saying that because I suspect an sql view will be required to render that..
[12:36] <stub> salgado: pong
[12:37] <daf> kiko: even with a view, the amount of time needed to transfer the data from the DB and render it might still be large
[12:38] <Kinnison> Can individual pages request a bit longer to do their job
[12:38] <Kinnison> E.g. the +all<foo> pages could say "I take a while"
[12:38] <Kinnison> and get maybe 30 seconds or something
[12:38] <SteveA> Kinnison: no.  it would be possible to make it so.
[12:38] <SteveA> i don't think it's all that good an idea
[12:38] <stub> salgado: I've run the country/continent update
[12:38] <kiko> daf, perhaps. it's like 12K packages IIRC
[12:38] <jamesh> kiko: yeah, could you send it to me?
[12:39] <kiko> jamesh, sure.
[12:39] <salgado> stub, do we have revision 2883 in staging? if so, could you run the shipit-reports cronscript there again?
[12:39] <salgado> stub, you've run that on production?
[12:39] <Kinnison> kiko: Not only does it take ages to get the DB entry back, but subsequent construction of the sql objects takes ages too
[12:39] <kiko> jamesh, sent.
[12:39] <Kinnison> kiko: I hit this issue a lot in the publisher
[12:39] <SteveA> Kinnison: but, it might be a pragmatic idea for some short-term cases.
[12:39] <stub> salgado: Yes - 2883 is on staging. I'll rerun the shipit-reports now
[12:39] <stub> salgado: Yes
[12:39] <salgado> stub, do we have 2883 in production too?
[12:39] <kiko> Kinnison, okay, let's take a look at this comparison output!
[12:40] <stub> salgado: Yes
[12:40] <salgado> great!
[12:40] <jamesh> kiko: you can see a sample of the info we are recording in chinstrap:/srv/asuka-logs/2005-12-06/
[12:40] <kiko> jamesh, cool, let me take a look.
[12:40] <Kinnison> kiko: At times, the publisher is dealing with upwards of 190,000 sql objects at a time
[12:40] <kiko> aiee
[12:41] <Kinnison> indeed aiee
[12:41] <Kinnison> or indeed ieee
[12:43] <SteveA> niemeyer: got a sec?
[12:44] <SteveA> actually, i'll add this to the agenda for thursday's meeting
[01:00] <niemeyer> SteveA: Just a minute
[01:01] <SteveA> niemeyer: it's okay, i'll bring the issue up at the next development meeting
[01:12] <niemeyer> SteveA: I'm here.. what is was about?
[01:12] <niemeyer> s/is/it
[01:13] <SteveA> niemeyer: about python's list() __len__ optimisation again
[01:13] <stub> salgado: Shipit reports have  been run on staging
[01:14] <niemeyer> SteveA: Ok.. would you like to talk about this now? I won't be here on the meeting thursday. Unfortunately my flight back home got exactly over the meeting time.
[01:15] <salgado> stub, just saw that. will check with jane if everything is okay.
[01:15] <salgado> stub, will you be around for the next hour?
[01:16] <SteveA> niemeyer: thanks, but it's okay
[01:16] <niemeyer> SteveA: Ok, will be pleased to talk about it if you change your mind.
[01:17] <SteveA> thanks.  after the meeting, i'd like to get your input into it
[01:17] <SteveA> when you're home
[01:20] <daf> kiko: +allpackages uses Distribution.source_package_caches, which is a MultipleJoin on DistributionSourcePackageCache
[01:21] <daf> I vaguely recall something about MultipleJoin being non-optimal
[01:21] <kiko> doesn't multiplejoin do list()s inside it? :)
[01:21] <stub> salgado: probably, yeah
[01:22] <daf> that might be it
[01:22] <stub> salgado: Anything wrong with me just running the report generation on production?
[01:22] <kiko> stub, I don't see what it gains us until silbs has looked at the output
[01:22] <salgado> stub, no, I think it should be safe to run it there
[01:23] <kiko> what's the advantage?
[01:23] <stub> kiko: It means I can run it before I go to bed if nobody has gotten around to approving it by then
[01:23] <kiko> okay.
[01:25] <spiv> daf, kiko: MultipleJoins return lists when arguably you'd expect lazy SelectResults like other places in SQLObject.  Newer SQLObject has SQLMultipleJoin or something that does this.
[01:26] <kiko> right
[01:26] <daf> I'm not sure how much of a penalty it is
[01:26] <daf> given that it's going to use all of the results sooner or later
[01:27] <spiv> The most likely case where it would hurt is batched results.  If a page is only show 20 out of 300 rows, that's likely to be a problem.
[01:27] <spiv> If they'll all be used anyway, then I doubt it's a problem.
[01:27] <daf> no, there's no batching
[01:28] <daf> in which case, I can't think of any obvious ways to make this page faster
[01:28] <spiv> daf: Time for profiling and/or sql statement timing?
[01:28] <daf> looks like it
[01:29] <salgado> BjornT, any idea why  https://launchpad.net/products/launchpad/+bug/2684 wasn't assigned to me, even though stub's email seem to have asked for that?
[01:29] <Ubugtu> Error: I cannot access this bug
[01:31] <stub> Pretty much any page which displays results without batching is broken. Rendering ZCML takes time, and often one or two fast queries need to be run per row, and it all adds up to create a timeout.
[01:33] <daf> hmm, there's something seriously wrong here
[01:33] <daf> I'm loading +allpackages on my local machine
[01:34] <daf> it's been going for about a minute and it's still chewing 100% CPU
[01:34] <kiko> it would help if you weren't running on a 286
[01:34] <stub> daf: select * from pg_stat_activity
[01:35] <stub> daf: Any query in there that looks ugly?
[01:35] <BjornT> salgado: yes, the assignee command has to be right after the affects command. this is fixed in my DefaultAffectsTarget branch. the bug shouldn't have been filed at all, though, i'll make sure to take a look at that.
[01:35] <daf> stub: <command string not enabled>
[01:36] <daf> anyhow, it's Python chewing CPU, not Postgres
[01:36] <stub> Bah.
[01:36] <stub> ok
[01:36] <SteveA> tal:repeat eats CPU
[01:36] <SteveA> especially nested ones
[01:37] <daf> it's still going
[01:37] <SteveA> check the page for a large tal:repeat
[01:37] <daf> smells like an infinite loop
[01:37] <SteveA> and move it to python perhaps
[01:37] <daf>   <tal:per_item repeat="cache context/source_package_caches">
[01:37] <daf> is the only one there
[01:37] <stub> You might see that sort of thing if someone forgot a JOIN clause, in which case PostgreSQL might be generating a few billion rows. If you then try casting that to a list or iterating over it, the bulk of the time would be spent in Python
[01:38] <daf> well, as kiko said, MultipleJoin casts to a list
[01:38] <kiko> multiplejoin does that 
[01:38] <kiko> daf is spot-on
[01:38] <salgado> BjornT, cool. thank you
[01:39] <stub> You can set the timeout in configs/default/launchpad.conf if you want it to die - the traceback will help diagnose
[01:40] <daf> doh!
[01:40] <stub> (assuming any database queries are being done in there - if it really is pure python, the hook won't be invoked and it won't die)
[01:41] <daf> no, I was barking up the wrong tree
[01:41] <Kinnison> wuff wuff
[01:41] <daf> wrong Python process
[01:41] <Kinnison> daf is teh_w1nn0r
[01:41] <daf> \o/
[01:42] <Kinnison>  \o_ . o O ( :-P )
[01:44] <daf> aha, hurrah for working tracebacks in staging:
[01:44] <daf> RequestExpired: (('SELECT name, binpkgdescriptions, binpkgnames, sourcepackagename, binpkgsummaries, distribution FROM DistributionSourcePackageCache WHERE id = 7960',), {})
[01:45] <daf> stub: as you suggested, it's the many many little queries that are killing it
[01:45] <Kinnison> I just love SQLObject
[01:46] <Kinnison> it's so well written
[01:46] <Kinnison> Most of the time it's too damned lazy
[01:46] <stub> working tracebacks on staging? That is interesting - I don't think anyone landed any changes.
[01:46] <Kinnison> and then when you wish it was, it's greedy
[01:46] <Kinnison> sodding thing
[01:46] <stub> I suspect the tracebacks will work on pages that require authentication, and not work on public pages, or something weird like that
[01:46] <daf> Kinnison: in this case, it's the way the TAL is structured that's causing it
[01:47] <daf> stub: er, I'm not logged in
[01:47] <daf> stub: https://staging.ubuntu.com/distros/ubuntu/+allpackages
[01:47] <stub> That is particularly broken then :-/
[01:47] <kiko> daf, sounds like an sql view problem to me -- or a batching problem.
[01:47] <Kinnison> It's an explicitly unbatched page
[01:47] <Kinnison> it's +allpackages
[01:48] <stub> oh... sarcasm
[01:49] <daf> kiko: I think it should be fixable just by changing the Python
[01:49] <stub> Kinnison: If it is unbatched, it is broken. It takes too long to render a 9000 item list, let alone tables and extracting information from the database
[01:50] <stub> (erm - sarcasm for the staging tracebacks, which don't appear to be working magically)
[01:50] <Kinnison> stub: Hmm, so +allpackages should be batched....
[01:50] <daf> stub: I didn't mean any sarcasm -- the tracebacks worked for me
[01:51] <stub> daf: Hmm... even weirder :-/
[01:51] <SteveA> daf/stub: i wasn't getting to see TBs in pages on production or staging.  any idea why?
[01:54] <salgado> I see the tracebacks sometimes, but not always. (of course, I was always logged in)
[01:54] <daf> https://chinstrap.warthogs.hbd.com/~daf/Screenshot.png
[01:55] <daf> stub: I think the immediate problem is that the results from the MultipleJoin are too lazy, so there is an extra SELECT from each object to get the source package name for it
[01:55] <daf> it should be possible to get all the necessary data in one query
[01:56] <stub> daf: We can create a view, and point SQLObject at that. Or just issue raw SQL (we should only use SQLObject where appropriate - not religiously)
[01:57] <daf> I'd go for adding a Distribution.all_source_package_names that uses pyscopg
[02:06] <daf> arg, except that the template also uses package/fmt:url
[02:08] <SteveA> daf: what's the problem there?  do we need to cache urls or do something to make them more efficient?
[02:10] <mpt> daf, thankyou for suggesting a way of getting rid of the ?lpnotification=asdfasdfdasdjhf
[02:11] <SteveA> mpt: we shouldn't have that any more
[02:11] <SteveA> mpt: stub was going to turn it off
[02:11] <mpt> turn off notifications completely?
[02:11] <mpt> or implement something like daf suggested?
[02:12] <stub> mpt: Change the implementation to remove lpnotification=blah, even if it might give odd results in pathalogical cases
[02:12] <\sh> hmmm..is it possible to attach a debdiff or something like this to a bugreport for malone via mailinterface?
[02:12] <stub> (usually involving two browser windows being used simultaneously)
[02:13] <mpt> cool
[02:14] <stub> BjornT: Are email attachments handled my the mailhandler, or was that put off until we had thought through the implications?
[02:14] <spiv> I think the mail handler just dumps attachments into the librarian, and malone then links to them?
[02:15] <BjornT> \sh, stub: no, the mail interface doesn't support attachments yet. it's on my todo list, though.
[02:15] <daf> SteveA: it just means that I can't make the optimisation I thought I could
[02:16] <SteveA> daf: the URL can be determined based on the name
[02:16] <SteveA> daf: let's talk about this a little later, or email me about it
[02:16] <SteveA> i think we can get this to work
[02:16] <stub> daf: If you are working on that +allpackages, the first and best optimization is to add batching if you havn't already. That will likely be enough.
[02:18] <\sh> BjornT: ah k thx :)
[02:19] <jagadish> how long does it take to receive CDs after ordering on the website?
[02:20] <salgado> jagadish, 4 to 6 weeks, usually
[02:30] <salgado> stub, shipit-reports is running on production?
[02:30] <stub> salgado: not yet.
[02:54] <mpt> What's wrong with this? bzr branch sftp://chinstrap.warthogs.hbc.com/home/warthogs/archives/rocketfuel-built/launchpad ./rocketfuel
[02:56] <mpt> It says "Not a branch"
[02:56] <mpt> er, hbd.com
[02:56] <LarstiQ> mpt: if you are using a recent bzr, it is using a relative url
[02:56] <LarstiQ> mpt: does it work if you make it //home instead?
[02:57] <mpt> LarstiQ, no, still "Not a branch"
[02:59] <stub> mpt: rsync that directory to local disk, and branch locally from it. Not only is it faster, but you work around the sftp bug you are seeing
[02:59] <LarstiQ> stub: which bug is that?
[03:00] <stub> LarstiQ: I mentioned it here the other day, and jblack was able to reproduce it. But I never followed it through with a bug report for some reason I can't remember now.
[03:01] <mpt> so I should report that now?
[03:01] <stub> mpt: That would be good. I don't know if it is something specific to our branch or our bzr build.
[03:03] <stub> Any particular reason you are trying to branch that thing anyway? That directory exists to avoid you needing to branch ;)
[03:03] <mpt> I was just following jblack's instructions on how to branch
[03:04] <mpt> since I wasn't really understanding the previous process, and it was producing errors whenever I pushed a new branch
[03:04] <mpt> it's easier for me to see where I am if the branch name is in the path
[03:06] <stub> Indeed. I do it differently though. I have a directory '~/lp' containing a Makefile that does the following:
[03:06] <stub> pristine: .FORCE
[03:06] <stub>         rsync -ravPz --delete-after chinstrap:/home/warthogs/archives/rocketfuel-built/launchpad/ pristine/
[03:06] <stub> .FORCE:
[03:06] <stub> Then in ~/lp, I can create a new branch of head just by doing 'cp -a pristine TheFooBranch'
[03:07] <stub> (well - cp -al, but that is not a good idea unless you are running flcow)
[03:09] <LarstiQ> flcow?
[03:09] <stub> Then to push, the slow way is to just 'cd TheFooBranch; bzr push chinstrap.ubuntu.com:/home/warthogs/archives/stub/launchpad/TheFooBranch' (might need // after chinstrap.ubuntu.com)
[03:10] <stub> LarstiQ: A tool that makes programs automatically break hard links in directory subtrees you specify. Which lets you hard link trees and work on them with your normal tools.
[03:11] <LarstiQ> stub: ah cool, my editor breaks hardlinks by itself, but flcow is certainly useful
[03:11] <stub> The fast way to push is to, on chinstrap, 'cd /home/warthogs/archives; cp -a launchpad/devel stub/launchpad/TheFooBranch' to prime it. Then, locally, to the push as above. It should only take a minute or two rather than the 20mins a push would take without the priming.
[03:12] <stub> LarstiQ: Indeed - editors can be configured, but most of your other tools can't (eg. cp)
[03:17] <stub> mpt: ^^ Might want to give all that a go if it makes sense - I've never been patient enough to time 'bzr branch' from chinstrap to local. It took 20 mins to do hct though.
[03:19] <mpt> ok
[03:24] <bradb> kiko, mpt: (it's only a prototype. no logic implemented) http://69.70.209.33:8086/distros/ubuntu/+source/mozilla-firefox/+bugcontacts
[03:24] <bradb> What do you guys think?
[03:26] <kiko> bradb, is this for IBC?
[03:26] <bradb> yeah
[03:27] <kiko> I thought we weren't doing per-package contacts, but ahm, ah, this populates the maintainership table?
[03:27] <bradb> kiko: no, the packagebugcontact table
[03:27] <kiko> it would be nice to be able to see all the current bugcontacts
[03:27] <bradb> maintainership is going away
[03:27] <kiko> bradb, which we renamed? :)
[03:27] <bradb> yep
[03:27] <bradb> kiko: you can see all the current bugcontacts on that page
[03:28] <kiko> only teams you belong to are shown
[03:28] <bradb> kiko: you seem to be proving once again that people do automatically edit out portlet content though.
[03:28] <bradb> (except for the actions portlet, perhaps)
[03:28] <kiko> oh
[03:28] <kiko> yes, I did edit it out
[03:28] <kiko> apologies
[03:29] <bradb> i understand :)
[03:29] <kiko> maybe say Current bug contacts:
[03:29] <kiko> also
[03:29] <kiko> this is only for NEW mail or for all mail?
[03:29] <bradb> all mail for public bugs
[03:29] <kiko> is there a way of telling if this is a new bug or not in the header?
[03:29] <bradb> not from X-Malone-Bug
[03:30] <bradb> er, X-Launchpad-Bug
[03:30] <kiko> what does it say in new versus old bugs?
[03:31] <bradb> for X-Launchpad-Bug, there is no differentiation. bug the bugmail content itself is different. it says "Public bug reported:"
[03:31] <kiko> hmm
[03:31] <kiko> could we say "new" somewhere along that line?
[03:32] <bradb> didn't we agree at UBZ to not bother making that distinction yet between new bugs and other bugmail?
[03:32] <kiko> maybe we did but it's a use case
[03:32] <mpt> I'm supposed to be on my lunch break ...
[03:33] <mpt> bradb, how about changing "+bugcontacts" to "+subscribe"?
[03:33] <mpt> It doesn't list the bug contacts
[03:33] <mpt> and eventually, it won't be just about bugs
[03:33] <elmo> "Secrecy:  Public"
[03:34] <elmo> that's got to be the most awkard phrasing, evar.  especially for what will be the most common case
[03:34] <bradb> elmo: yep :)
[03:34] <elmo> bradb: ok, it's known?
[03:34] <bradb> elmo: i guess you could say that
[03:34] <mpt> It's one of those heisenbugs that's "known", but not reported in Malone
[03:34] <elmo> oh, but not agreed on.  meh
[03:35] <bradb> kiko: How about we reconsider new vs. not-new after 1.0??
[03:35] <bradb> er, ?
[03:36] <bradb> mpt: yeah, i can rename it to +subscribe
[03:36] <mpt> thanks
[03:36] <kiko> elmo, yeah, it's gross
[03:38] <bradb> mpt: I wonder if the link should say "Bugmail Settings" instead of "Manage Bug Contacts"?
[03:39] <kjcole> kiko, I didn't have a specific use. It just seemed like something to have "handy" for such cases as the topic recently discussed. 
[03:39] <bradb> I was so proud of my context-sensitive FAQ portlet, but nobody else cares, apparently :P
[03:40] <mpt> bradb, well it doesn't let you manage the bugs contacts (if by "contacts" you mean "people who get contacted")
[03:40] <mpt> but I was just mentally going in the opposite direction
[03:40] <mpt> imagining how you could avoid using the word "bugmail" at all
[03:41] <kiko> kjcole, well, it's not that difficult to do -- depending on what you'd accept. A list of people in a webpage is easy. A list of people mailed out periodically to an address is too. An email address that is routed to that list of people is a bit harder.
[03:41] <mpt> so how about the header be something like "Subscription to Ubuntu mozilla-firefox"
[03:41] <mpt> oh!
[03:42] <bradb> heh
[03:42] <mpt> bradb, is it really "only teams you belong to", or is it "only teams you are an admin of"?
[03:42] <bradb> "teams you belong to"
[03:42] <bradb> i.e. we are not nazis
[03:42] <mpt> So any member of a team can change the entire team's subscription?
[03:42] <bradb> correct
[03:42] <mpt> that seems a bit odd
[03:42] <bradb> does it?
[03:43] <bradb> what is a team, if not a /team/?
[03:43] <mpt> oh well, I guess it can be left like that until the first bitter dispute
[03:43] <mpt> which might never happen :-)
[03:43] <bradb> indeed ;) (a good possibly for many changes, IMHO)
[03:43] <bradb> er, policy
[03:44] <kiko> anyway
[03:44] <mpt> but the layout needs rearranging a bit, I think
[03:44] <kiko> I'm okay with the general intent of the page
[03:44] <mpt> yes, in general it's fine
[03:45] <bradb> mpt: If you can think of something that's even more minimalist, I'd be keen to see it. (I was thinking, for example, of collapsing teams by default)
[03:46] <mpt> Subscribe yourself
[03:46] <mpt> Subscribe your teams
[03:46] <mpt> hmmmm
[03:46] <bradb> but you might be unsubscribing them
[03:47] <mpt> Your subscription
[03:47] <mpt> Your teams' subscriptions
[03:47] <bradb> "Does this show all my teams?"
[03:47] <bradb> "Or just the ones I'm an owner of?"
[03:48] <mpt> "Teams you are a member of can be subscribed, so every member is e-mailed."
[03:48] <mpt> checkbox checkbox checkbox
[03:49] <mpt> This interface is going to become 2-dimensional as soon as you can subscribe to more than one thing (e.g. new bug reports vs. changed bug reports)
[03:49] <bradb> I'm a bit leery of the "foo can be bar'd" wording, when the UI makes it clear that foos can obviously be barred.
[03:50] <mpt> yeah, that sentence would be there mainly for the benefit of the first six words
[03:51] <bradb> mpt: If we ever do allow fine-grained subscriptions, I /think/ it should belong in an advanced screen (or in some otherwise disclosure-based UI), to keep Malone as grandma-compatible as possible
[03:52] <mpt> Grandma isn't going to be subscribing to packages, bradb
[03:53] <SteveA> libcrochet
[03:53] <bradb> mpt: No, but aiming for grandma compatibility is what is needed for new users to be happy, IMHO. For more, see my mental movie of kamion trying to close a bug for his first time.
[03:53] <mpt> that's a completely separate issue, bradb
[04:00] <dilys> Merge to devel/launchpad/sourcecode/pybaz: add force_forkexec_spawning and reset_default_spawning to pybaz.backend [r=SteveA]  (r178: David Allouche)
[04:02] <kiko> mpt, can bug 5406 be yours?
[04:02] <Ubugtu> Malone bug #5406: Inconsistant reporting of 'nothing here' In: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/5406
[04:04] <kiko> bradb, you are SO CUTE
[04:14] <salgado> mpt, what's bug 881 about?
[04:14] <Ubugtu> Malone bug #881: Advanced search should be on a separate page In: malone (upstream), Severity: Normal, Assigned to: Brad Bollenbach, Status: Accepted https://launchpad.net/bugs/881
[04:40] <kiko-fud> I'm out for the next 2h doing a university presentation
[04:54] <mpt> kiko-afk, 5406 taken
[05:00] <mpt> salgado-lunch, bug 881 was out of date since I cleaned up the bug listing+form. I've updated it.
[05:00] <Ubugtu> Malone bug #881: Advanced search controls should not show on results pages In: malone (upstream), Severity: Normal, Assigned to: Brad Bollenbach, Status: Accepted https://launchpad.net/bugs/881
[06:25] <bradb> SteveA: I'm starting to use context-sensitive FAQ portlets so that, for example, on the screen where you say "I want all bugmail for this package", you're also dropped a little hint about X-Launchpad-Bug and links to documentation about it. These portlets are potentially "global" in that they can be useful on many different pages. Where do you recommend I register this portlets? (Currently, I've used launchpad.zcml)
[06:25] <bradb> s/this/these/
[06:27] <SteveA> there is a malone.zcml
[06:31] <bradb> yeah, I decided not to use that because the dividing line seems sort of blurry (e.g. this portlet is used on a URL that technically "isn't" in the Malone ns). I don't mind either way though.
[06:33] <SteveA> it's to do with bugs, so put it there i'd say
[06:33] <SteveA> we'll have a closer look at this stuff next week
[06:56] <bradb> ok
[07:10] <Ram[RL] > la registration pour les cd est gratuite?
[07:11] <Ram[RL] > http://shipit.ubuntulinux.org/
[07:11] <Ram[RL] > ?
[07:11] <SteveA> yes
[07:11] <Ram[RL] > merci :)
[07:11] <SteveA> you register, ask for a few cds, and they'll be sent to you some time after
[07:12] <Ram[RL] > au revoir
[07:12] <SteveA> depending where you live, the country's customs people might charge some money
[07:12] <Ram[RL] > :)
[07:12] <SteveA> but we can't do anything about that
[07:12] <Ram[RL] > i known
[07:12] <Ram[RL] > i dont known for the french how many cost
[07:13] <Ram[RL] > the taxe
[07:13] <SteveA> they come from the netherlands, i think
[07:13] <SteveA> so it should be okay
[07:14] <Ram[RL] > :)
[07:14] <Ram[RL] > thx steveA
[07:28] <salgado> SteveA, is it possible to have some menu links change depending on something in the request?
[07:28] <mpt> jblack, ping
[07:32] <dilys> Merge to devel/launchpad: basic ProductSeries doctests [r=SteveA,BjornT]  (r2895: David Allouche)
[07:36] <kiko> hey hey
[07:48] <kiko> niemeyer, snack time?
[07:48] <niemeyer> kiko: Sure, let's go
[07:51] <mpt> snacks? you people have snacks now?
[07:51] <kiko> these southern slackers
[08:00] <SteveA> salgado: yes, it is possible.  what do you have in mind?
[08:06] <salgado> SteveA, I want to change the links to the bug listing pages, depending on whether you're using a simple or advanced form
[08:06] <salgado> let's say you're looking at the advanced version of the +assignedbugs page
[08:07] <salgado> in this case, I want to make the link to the +reportedbugs page take you to the advanced version of that page
[08:09] <SteveA> how do i get to the advanced version of the +assignedbugs page?
[08:10] <salgado> SteveA, you click on the "Advanced..." button, which is not yet in production
[08:11] <salgado> (the same button that is quite hard to find with the new layout)
[08:12] <SteveA> does the page have a different URL?
[08:12] <SteveA> why is "advanced..." a button?
[08:13] <salgado> no, the URLs are the same
[08:13] <bradb> salgado: The only possible way to get the list of teams of which an IPerson is a member is to first use IPerson.myactivememberships and then process TeamMembership objects, right?
[08:14] <salgado> SteveA, it's a button because doing the other option we considered (an expander) is very tricky at this point
[08:14] <SteveA> salgado: that sounds bad to me.
[08:14] <mpt> SteveA, so that if you type a search string and then realize it needs to be an advanced search, you can click "Advanced..." and what you typed will be carried through to the advanced form
[08:14] <SteveA> salgado: you see, someone will not be able to bookmark the advanced form
[08:14] <SteveA> unless the button does a GET i suppose...
[08:14] <mpt> Why are the URLs the same, salgado?
[08:14] <kiko> which it could
[08:14] <mpt> they're not the same now
[08:14] <salgado> yes, the button does a GET
[08:14] <SteveA> even so, it gets the query args confused with the page address
[08:15] <SteveA> i think they should be different basic page URLs
[08:16] <salgado> I can do that. easily, I hope
[08:16] <SteveA> mpt: what do you think about a menu item that goes to different places on different pages?
[08:18] <salgado> bradb, yes, but that won't give you teams that person is an indirect member, as there's no membership records for these (person, team) pairs
[08:18] <mpt> That's already true for all the items in that menu, SteveA :-)
[08:19] <SteveA> i mean, of course, for menu items on a single context
[08:19] <bradb> salgado: ok
[08:20] <mpt> SteveA, I think it's fine -- it's not obviously different places, it's just being nice by remembering the mode you were in
[08:20] <mpt> though it should be temporary, until we get an advanced syntax for simple searches
[08:23] <SteveA> salgado: i just checked the menus code.  menus don't get access to the request.  this could be added reasonably easily, though.
[08:24] <salgado> this is what I had in mind. can I do this as part of this changes I'm doing now?
[08:24] <salgado> s/this changes/these changes/
[08:26] <SteveA> ok
[08:27] <SteveA> i think the easiest thing is to make the menu have a 'request' attribute that the tales code can set after it is instantiated
[08:29] <SteveA> i can refactor it later so that menus are more like views
[08:29] <SteveA> so that they get a request "properly"
[08:29] <SteveA> salgado: please ask me to review the changes you make
[08:31] <salgado> SteveA, sure, but I don't know where's the tales code that's supposed to set the request in the menu.
[08:33] <SteveA> webapp/tales.py and webapp/menu.py and interfaces/launchpad.py and doc/tales.txt and doc/menu.txt
[08:52] <kiko> yo cprov 
[08:58] <bradb> elmo: btw, I filed the "Secrecy" bug at https://launchpad.net/bugs/5436
[08:58] <Ubugtu> Malone bug #5436: elmo reported that bug "secrecy" is confusing In: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/5436
[08:58] <elmo> bradb: rockin, thanks
[08:59] <bradb> np
[09:03] <mpt> home time
[09:26] <kiko> bradb, tell me about bug 4575
[09:26] <Ubugtu> Malone bug #4575: IDistributionSourcePackage.currentrelease documentation is incorrect In: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/4575
[09:26] <kiko> why do you want to use that method?
[09:28] <bradb> kiko: To do things with the current release of that DSP, e.g. show information about it in a portlet on the dsp page
[09:28] <kiko> so that I don't have to read it?
[09:28] <kiko> just kidding
[09:28] <kiko> do you know if the method is used elsewhere?
[09:30] <bradb> dunno
[09:39] <bradb> kiko: (re: #canonical) I don't think the issue with that bug has anything to do with the NeedInfo status, tbh. The underlying issue the wording of pages vs. user goals is confusing.
[09:39] <bradb> s/the wording/is the wording/
[09:39] <kiko> I dunno if wording can explain this problem entirely :-P
[09:39] <bradb> e.g. $distro/+bugs -- what user goal does this page help satisfy?
[09:40] <kiko> find bugs in the distro
[09:40] <kiko> but this bug is specifically about the person bugs pages
[09:41] <bradb> i see what you mean
[09:41] <kiko> I'll comment in the bug
[09:41] <kiko> (bug 4201)
[09:41] <Ubugtu> Malone bug #4201: Bugs with NeedInfo status should be displayed on open bugs query. In: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/4201
[09:41] <bradb> this is where needinfo from: [     ]  could be interesting, to be sure
[09:43] <kiko> right
[10:56] <bradb> kiko: I've got the UI prototyped this morning fully implemented, but still have to modify bug reporting to ensure the PBC's get auto-sub'd. Hopefully it'll be in a review queue by tomorrow afternoon.
[10:58] <dilys> Merge to devel/launchpad: [trivial]  Fix two typos, remove team description from portlet details, fix rosetta/+about and add a pagetest for it. (r2896: Guilherme Salgado, Diogo Matsubara)
[11:00] <kiko> bradb, PBC?
[11:00] <kiko> ah, package bug contacts
[11:00] <bradb> yeah
[11:00] <kiko> ah
[11:00] <kiko> okay, the actual backend of that change
[11:00] <bradb> most of the backend of the change was the UI's, tbh.
[11:01] <kiko> well
[11:01] <kiko> there's the "backend" now which actually does something useful with the information :)
[11:02] <bradb> distro and product bug contacts are already getting sub'd too, just not pbc's yet
[11:02] <kiko> I see
[11:02] <kiko> cool
[11:02] <bradb> then come the reports, i guess, but probably better to wait until after the first merge
[11:02] <kiko> reports?
[11:02] <bradb> maybe
[11:03] <bradb> reports of bugs filed on things for which you are a bug contact
[11:03] <kiko> under people/?
[11:03] <bradb> i'd imagine so
[11:04] <kiko> +assignedbugs is useful
[11:06] <bradb> indeed
[11:08] <kiko> mdz_!
[11:08] <mdz_> kiko: we'll see how long it lasts
[11:08] <mdz_> kiko: I received your resend of that email
[11:09] <mdz_> which means that I had not received the first one, otherwise formail would have eaten it
[11:09] <kiko> I see.
[11:09] <kiko> mdz_, you need to sort out your email. this flakiness is most unwelcome.
[11:09] <mdz_> this flakiness lasted for a couple of hours yesterday morning
[11:10] <mdz_> but if you can recommend a good email hosting provider, I am listening
[11:11] <elmo> mdz: mail.canonical.com has been known to offer pop3 and/or imap
[11:12] <kiko> mdz_, elmo is in the know
[11:12] <kiko> I mean
[11:12] <kiko> rit.edu?
[11:12] <mdz_> elmo: hmm, I did not know that.  But I prefer to host all my mail in one place (work and personal), and prefer to have my personal mail someplace employer-neutral
[11:12] <jblack> elmo: Can I have root on rookery? 
[11:12] <elmo> jblack: no
[11:12] <jblack> darn
[11:13] <elmo> mdz: sure, just offering
[11:13] <mdz_> kiko: I've been hosting my mail there for 8 years
[11:18] <kiko> that doesn't mean it's good
[11:18] <kiko> anyway
[11:21] <mpt> It does mean it's approaching PURL status
[11:22] <kiko> PURL?
[11:28] <mdz_> kiko: well, this is the first problem you've noticed in that time
[11:30] <cprov> kiko: quick look on https://chinstrap.ubuntu.com/~dsilvers/paste/fileLsU7mP.html, 1k2 uploads and only this error atm, any idea ?
[11:31] <kiko> mdz_, I didn't use to send you email this frequently, that's unfair!
[11:32] <mdz_> kiko: details
[11:32] <kiko> cprov, yeah, looks like a package with a "bad" version.
[11:33] <kiko> I think katie is very lenient with versions
[11:33] <kiko> hmm hmmm
[11:33] <kiko> cprov, can you dig out the version string so mdz_ can give you an opinion?
[11:33] <cprov> kiko: looks like a malformed pkg name ... there is a "dot"
[11:33] <kiko> the package name has a dot in it? when why are we complaining about a version?
[11:33] <cprov> mdz_: cnews_cr.g7-38_source.changes
[11:34] <kiko> cprov, look for the Package: and Version: string inside it and paste them in?
[11:34] <kiko> cprov, also, give the package to niemeyer so he can test using it :-)
[11:34] <niemeyer> Yes, please..
[11:34] <elmo> the problem with cnews is that it starts with a non-number
[11:35] <cprov> kiko: rsyncing
[11:35] <elmo> we had this discussion on the lp list already
[11:35] <kiko> the version starts with a non-number
[11:35] <kiko> I see
[11:35] <kiko> did we? /me looks
[11:35] <elmo> policy only says "should" start with a digit
[11:36] <elmo> so dak never enforces that
[11:36] <elmo> but based on how badly dpkg copes with non-digits-as-the-first-letter it should/will later.  but for now, lp needs to not see cnews as invalid, because it's not
[11:37] <kiko> okay.
[11:37] <kiko> elmo, do you have a version verification regexp in dak?
[11:37] <kiko> let me read the launchpad mail dammit
[11:38] <kiko> I see
[11:38] <kiko> elmo, about that regexp.. 
[11:39] <kiko> does one exist?
[11:40] <kiko> cprov, this is an unresolved issue in the uploader I see. the thread is "Tuning Gina Output"
[11:40] <elmo> Setting up sbuild (2005.11.15) ...
[11:40] <elmo> /usr/bin/update-sourcedeps: line 25: wget: command not found
[11:40] <elmo> err
[11:40] <elmo> re_valid_version = re.compile(r"^([0-9] +:)?[0-9A-Za-z\.\-\+~:] +$");
[11:41] <elmo> ^-- rather, is what dak currently uses
[11:41] <kiko> okay
[11:41] <kiko> so epoch and then /anything/ :)
[11:41] <lifeless> morning folies
[11:41] <kiko> how can you tell if a package's version is newer or older than another in that situation, elmo?
[11:42] <elmo> kiko: um, it uses apt_pkg's compare_version function?
[11:42] <kiko> I mean. versions g3 and a2 -- which is newer?
[11:42] <kiko> aha
[11:42] <kiko> I see.
[11:42] <kiko> this is all very enlightening
[11:43] <cprov> kiko: indeed, had almost forgot of that email thread 
[11:44] <kiko> me too
[11:48] <kiko> cprov, so the bad news is that that part of the code will need to be changed to cope with this
[11:48] <kiko> cprov, is the package very big?
[11:48] <cprov> kiko: no have it with me already
[11:50] <cprov> kiko: debootstrap_0.3.1.6ubuntu1 -> priority "None" :( (2 errors in 1577 uploads)
[11:50] <kiko> cprov, look at gina/packages.py -- it has code to deal with these weird situations.
[11:52] <cprov> kiko: instead of deal I would suggest fix, because they are obviously wrong, anyway will look tomorrow
[11:52] <kiko> cprov, that's what I do -- I "fix" them. :-)
[11:53] <cprov> kiko: see http://hillary/~cprov/shit-pkgs/
[11:53] <kiko> that's a /big/ orig.tar.gz ;-(
[11:53] <kiko> cprov, hopefully there will be other packages with broken versions
[11:53] <cprov> kiko: no, you workaround them, fix should be earlier gina | uploader
[11:53] <kiko> cprov, hmmm -- what do you mean?
[11:54] <kiko> I don't work around them, I just set them to other if they are missing IIRC
[11:54] <cprov> Priority = None, deserves REJECTED, IMO
[11:54] <kiko> cprov, you can't do it for auto-sync
[11:54] <cprov> kiko: that's what we do 
[11:54] <kiko> even though you want to
[11:55] <cprov> kiko: I see, default fields for autosync policy
[11:55] <kiko> it's okay to reject regular uploads
[11:56] <kiko> though the dapper uploads may teach us otherwise :)
[11:56] <cprov> autosync renamed to "push it in"
[11:56] <kiko> with prejudice
[11:56] <cprov> better, "push it in, NOW"
[11:58] <cprov> so, good chat, interesting ideas, but I'm starving ... good night hackers, see you tomorrow