[00:12] <wgrant> maxb: OK, now I'll run that test..
[00:12] <wgrant> Let's see how it goes...
[00:14] <wgrant> maxb: Runs fine here.
[00:14] <wgrant> I'm confused.
[00:14] <wgrant> You have a few other tests failing that work for me, don't you?
[00:15] <maxb> one other - LaunchpadOnKarmic is up to date
[00:16] <wgrant> maxb: Ah, hadn't seen that latest change.
[00:18] <maxb> right, let's see if it's arch-specific
[00:18]  * maxb runs it on netbook....
[00:18] <wgrant> I would try on amd64, but that means cleaning out sourcedeps which I don't have a good process for yet.
[00:20] <maxb> rm -rf eggs/* && for d in sourcecode/*/; do (cd $d && bzr clean-tree --force --ignored --unknown --detritus); done
[00:20] <wgrant> I suppose so!
[00:21] <maxb> I guess if you're lucky you can leave the eggs
[00:21] <wgrant> They should be version/arch-specific
[00:22] <wgrant> So yes.
[00:22] <wgrant> We'll see.
[00:22]  * maxb has been caught out by py2.5/UCS4 vs. py2.5/UCS2
[00:22] <wgrant> Hm.
[00:22] <maxb> I'd forgotten about a Python I had in /usr/local/bin/
[00:23] <wgrant> Somebody broke Python 2.6 like that in late Jaunty, I recall.
[00:23] <wgrant> Caused a lot of things to die in strange ways.
[00:24] <wgrant> Fortunately most had missing symbols, so it was obvious.
[00:24] <maxb> Right, well I've reproduced the DONE != ACCEPTED one on entirely separate Karmic installations on different hardware, one amd64, one i386, so I've no idea how it's passing for you! :-)
[00:26] <wgrant> Intriguing.
[00:26] <maxb> package-diff.txt is grinding away on the netbook now
[00:26] <wgrant> I might try cleaning out my ~/launchpad and starting from scratch.
[00:30] <wgrant> Overkill perhaps, but I can't see anything else wrong :/
[00:32] <maxb> package-diff.txt failure likewise reproduced
[00:32] <wgrant> Damnit.
[00:50] <weled> Hi, how to manage update ? rocketfuel-get and what ?
[00:52] <wgrant> Would a branch to convince rocketfuel-setup to use bzr+ssh for the initial download be accepted?
[00:52] <wgrant> It still forces http.
[00:58] <maxb> Isn't that deliberate?
[00:59] <wgrant> It was.
[00:59] <wgrant> Not sure there's any reason for it to be now.
[00:59] <wgrant> spm: Is LP still
[00:59] <wgrant> ... still hot?
[00:59] <wgrant> There was server-side support to force HTTP, which has probably been turned off now.
[01:00] <wgrant> So I don't know why it's forced in the client too.
[01:00] <maxb> how did the server know?
[01:01] <wgrant> There's a config option which specifies products whose development focus branches should only resolve to HTTP, not bzr+ssh.
[01:01] <wgrant> Added just before the release.
[01:06] <intellectronica> sinzui: maybe you know what's the new deal with lazr branches?
[01:08] <spm> wgrant: I may be missing the thrust of the discussion, but you could always - aiui - branch using http. It's a much lighter process at the cost of having the branch parent be not so helpful
[01:08] <thumper> lp is not hot any more :)
[01:08] <thumper> wgrant: we could update it
[01:08] <wgrant> spm: And it daaaaaaaamn slow.
[01:08] <lifeless> wgrant: http is used when you haven't done lp-login
[01:08] <wgrant> lifeless: I know.
[01:08] <wgrant> But rocketfuel-setup explicitly uses an HTTP URL to lessen the load.
[01:09] <wgrant> Which probably isn't a valid concern any more.
[01:09] <lifeless> wgrant: if the rocketfuel-get script either overrides HOME, BZR_HOME, or that setting specifically, ...
[01:09] <lifeless> oh, it does what?!
[01:09] <lifeless> insane
[01:09] <lifeless> in the membrane
[01:09] <lifeless> I keep saying this; there is no good evidence that the load is lighter over http
[01:09] <lifeless> and some serious reason to believe that its /a lot higher/ at the moment.
[01:09] <lifeless> because we have bugs.
[01:09] <wgrant> 2a over HTTP really really sucks.
[01:10] <lifeless> yes
[01:10] <wgrant> Although it's not much better over bzr+ssh at the moment.
[01:10] <lifeless> it makes millions of requests rather than 5
[01:10] <wgrant> (using latest nightly on the client, and LP as the server)
[01:11]  * thumper doesn't use rocketfuel-* scripts
[01:12]  * wgrant only uses rocketfuel-setup
[01:12] <lifeless> wgrant: interesting. it should still be streaming
[01:12] <wgrant> lifeless: It is.
[01:12] <wgrant> But at ~100kbps
[01:12] <wgrant> Oops. KB/s.
[01:12] <wgrant> But still very very slow, even from the UK.
[01:13] <thumper> ha crap
[01:13] <thumper> there is a failure on the devel builder
[01:13] <thumper> soyuz bindarypackagerelease-views.txt
[01:14] <lifeless> wgrant: whats your link capable of?
[01:14] <lifeless> and when did you move to the UK ? :P
[01:14] <wgrant> thumper: There was a testfix for that one this morning, wasn't there?
[01:14] <thumper> was there?
[01:15] <thumper> wgrant: yes there was
[01:15] <wgrant> lifeless: 10Mbps. I can nearly saturate that from a UK host normally.
[01:15] <thumper> thanks for the heads up
[01:15] <wgrant> thumper: It was the same one? (I can't see buildbot)
[01:16] <thumper> wgrant: it seems so
[01:16] <lifeless> wgrant: have you alerted sysadmins? bzr should saturate the link.
[01:17] <lifeless> spm: ^
[01:17] <thumper> lifeless: how do we test where the blockage is?
[01:17] <wgrant> lifeless: Let me test a host just near LP to see how the bandwidth is now...
[01:17] <elmo> what are youguys talking abou
[01:17] <elmo> the rewrite script is fucked
[01:17] <elmo> you know this
[01:18] <wgrant> This is bzr+ssh, though.
[01:18] <elmo> I know you know this
[01:18] <lifeless> elmo: wgrant is saying that the bzr+ssh streaming performance is underpar
[01:18] <elmo> oh
[01:18] <elmo> sorry
[01:18] <thumper> :)
[01:18] <lifeless> thumper: I'd start by looking for swapping
[01:18] <lifeless> thumper: failing that it might finally be a reproducible case of the problems the python VCS PEP guy had
[01:19]  * lifeless starts a stream up
[01:19] <thumper> lifeless: maybe
[01:20] <wgrant> I'm getting 600KB/s from the UK now, so it does seem to be an LP problem.
[01:21] <lifeless> I'm seeing 50-80 KB/sec - 40-160kbits, on a 1500kbit link
[01:22]  * lifeless tries mysql
[01:22] <elmo> can y'all try downloading a large file from  the librarian to rule out general network issues?
[01:22] <wgrant> woah.
[01:22] <lifeless> elmo: yup, I was just looking for one
[01:22] <wgrant> bzr is eating around a gigabyte of RAM.
[01:22] <elmo> http://launchpadlibrarian.net/28202431/dia_0.96.1-7.1_0.97-2.diff.gz
[01:22] <elmo> lifeless: ^-- is one I have in my browser history that isn't tiny
[01:23] <jelmer> ~.
[01:23] <wgrant> That sits at around 500KB/s for me.
[01:24] <wgrant> Although it's not precisely large.
[01:24]  * wgrant fetches a buildd chroot.
[01:24] <lifeless> 3,730,692    101K/s   in 36s
[01:24] <lifeless> elmo: ^
[01:25] <wgrant> Hrm.
[01:25] <wgrant> bzr is now streaming at ~350KB/s
[01:25] <elmo> super, so not my problem ;-)
[01:26] <wgrant> So much better, but still not as good as it could be.
[01:26] <wgrant> ... and back below 100KB/s
[01:26] <lifeless> elmo: did you just disown all of codehosting? :)
[01:26] <lifeless> possibilities:
[01:26] <lifeless>  - ssh windowing problem
[01:27] <lifeless>  - bzr networking issue
[01:27] <lifeless>  - bzr performance problem
[01:27] <wgrant> bzr is eating hundreds of megabytes of RAM at the moment.
[01:27] <wgrant> Even branching lp:launchpad locally.
[01:27] <wgrant> Both 1.17 and bzr.dev.
[01:27] <wgrant> How odd.
[01:28] <elmo> lifeless: no, but there are other people available right now more qualified and suited to diagnose operational LP issues, as opposed to operational network issues
[01:28] <lifeless> elmo: I was just teasing
[01:36] <rockstar> I need claws to say something like "Hey, it looks like you're trying to do a code review in this email.  Did you remember to sign it?"
[01:43] <lifeless> wgrant: is it still very slow for you?
[01:44] <lifeless> wgrant: can you wireshark and see if the window is closing up (would indicate bzr not reading fast enough)
[01:50] <lifeless> wgrant: who is your isp?
[01:52] <sinzui> intellectronica: ping
[01:52] <intellectronica> sinzui: hi
[01:52] <sinzui> I'm going to reply to your email.
[01:53] <sinzui> I think I know the answer. But I heard last week that we should not submit
[01:53] <sinzui> intellectronica: If leonardr gave the all clear than you can
[01:54] <intellectronica> what, push to the lazr-developers branch?
[01:54] <sinzui> intellectronica: their two branches listed in my email, the pqm one that launchpad uses and the official lazr.restful, which you must prepare a patch for (mine did not apply cleanly)
[01:54] <intellectronica> leonardr reviewed my branch, so presumably he's ok with that
[01:54] <sinzui> intellectronica: lazr.restful. I presume so to
[01:54]  * sinzui looks to both branches
[01:55] <intellectronica> my branch is of the laze-developers one, so it applies cleanly. it doesn't apply cleanly against the pqm-managed one, but it shouldn't be hard to prepare a patch for that. it's a really simple change
[01:55] <sinzui> okay
[01:55] <intellectronica> the question is, how do it get my change in?
[01:56] <intellectronica> should i submit to pqm, which is targeting an outdated branch, or somehow get it into the lazr-developers branch. and if the latter, how do i then get my changes used in LP?
[01:56] <sinzui> for he pqm one, yes
[01:59] <intellectronica> sinzui: you sure? it seems to me that what we're using in LP is the newer branch (from casual inspection of the code)
[02:00] <sinzui> I am sure you need to submit to two places with different rules
[02:00] <intellectronica> no, actually i may be wrong. maybe it is the pqm branch we're using
[02:00] <sinzui> intellectronica: I need to put this in an email. I cannot think or type quickly at the moment
[02:01] <sinzui> intellectronica: we are using the pqm. we then backport to our branch
[02:01] <intellectronica> sinzui: you can probably imagine what state i'm in. i'll look at this again in the morning and i'm sure everything we'll be clearer :)
[02:02] <sinzui> okay. You will have an email which will help
[02:02] <intellectronica> sinzui: thanks a lot!
[02:05] <lifeless> wgrant: ping
[02:06] <lifeless> wgrant: I suspect you weren't using bzr+ssh
[02:07] <wgrant> lifeless: Sorry, was in transit to work.
[02:07] <lifeless> 9684KB   153KB/s | Fetching revisions:Inserting stream
[02:07] <wgrant> It certainly was.
[02:07] <lifeless> lp: appears to still use http
[02:07] <wgrant> ISP is Optus (Cable)
[02:07] <wgrant> Right.
[02:07] <wgrant> But I gave it bzr+ssh explicitly.
[02:07] <lifeless> bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel ?
[02:07] <wgrant> Precisely.
[02:08] <lifeless> ok, well thats good to know
[02:08] <wgrant> bzr.log agrees that it was using that.
[02:08] <lifeless> owever, I see my adsl saturated
[02:08] <lifeless> which is good
[02:19] <lifeless> wgrant: if you can reproduce, please be getting tcpdumps
[02:19] <lifeless> and filing bugs
[02:19] <lifeless> if its a bzr bug, we want to fix it
[02:19] <lifeless> if its an operational issue we want to fix it
[02:23] <thumper> I'm going to be around but not near my computer for a while while I help with a submission to stop a huge building go up across the road
[02:23] <thumper> rockstar: if you need me, text :)
[02:44] <lifeless> thumper: when you get back
[02:44] <lifeless> is lp: meant to still force http? if its not, then something isn't deployed.
[02:46] <thumper> lifeless: I'm not back yet, but the change has landed but hasn't been rolled out
[03:13] <wgrant> lifeless: I think it's probably a general bzr problem, not specific to streaming. It's really slow and memory hungry even doing a local branch. Can you try to reproduce?
[03:13] <wgrant> (branching 2a lp:launchpad from a local shared repo to a new branch outside the repo.
[03:14] <lifeless> wgrant: do you have the C extensions?
[03:17] <wgrant> lifeless: The only .so I can see is _patiencediff_c.so. This is the ~bzr-daily-ppa build.
[03:18] <lifeless> then you don't
[03:18] <lifeless> check in bzrlib/bzrlib/
[03:19] <lifeless> james_w: around?
[03:19] <wgrant> lifeless: Let's try Karmic's 1.18rc1, which might be more sane...
[03:25] <wgrant> lifeless: That's muuuuuch better locally.
[03:25] <lifeless> file a bug please
[03:25] <lifeless> assign to james_w
[03:25] <lifeless> on bzr
[03:26] <wgrant> Although it's still eating lots of RAM and CPU, it's much faster.
[03:26] <wgrant> Will do.
[03:26] <wgrant> Thanks.
[03:26] <lifeless> its caused by the bug I've filed about builds on karmic doing WEIRD SHIT with were the .so's go
[03:26] <lifeless> but the daily debs should seperately be erroring/requiring the .so's
[03:26]  * wgrant disappears for lunch.
[05:01] <jtv> spm, g'f'day mate!
[05:01] <spm> jtv: hey!
[05:01] <jtv> an Australian dared me to pinpoint his accent last night, and I couldn't even say for sure whether he was British or not.
[05:01] <spm> :-)
[05:02] <jtv> In all fairness, he was from Adelaide, born in London, from two English parents.  It all happened because I caught a few words his friend said and went "he's from Manchester, isn't he?"
[05:03] <jtv> (Apparently he lived in London and only betrayed bits of his original accent given sufficient beer)
[05:04] <jtv> spm: but seriously, I've got two CP requests up for the codehosting server... any chance we can do them nowish?
[05:04] <spm> jtv: funny you should ask...
[05:04]  * jtv cowers behind laptop
[05:04] <spm> both (plus 2 others) have passed testing
[05:04] <jtv> no wait, this thing is expensive
[05:04]  * jtv cowers in front of laptop
[05:05] <jtv> ...was there a "but" coming?
[05:05] <spm> I was in the process of re-cowbowing the changes preparatory to pushing when a ... bigger priority fail hit
[05:05] <spm>  -ETOOMANYFAILURES
[05:05] <spm> that seems to have recovered sufficiently atm, that I should be able to get back on the CP in <5
[05:05] <jtv> catch (const exception &e) { puts(e.what()); }
[05:05] <spm> heh
[05:06] <jtv> (I mean, "what happened, Steve?")
[05:15] <thumper> puts?
[05:15] <thumper> ew
[05:16] <thumper> std::cerr << e.what() surely
[05:16] <thumper> and it should be "catch (exception const& e)"
[05:16] <thumper> ask me why some time
[05:17] <jtv> thumper: that's ugly... like "1 == x" because some people _might_ occasionally write assignment instead of comparison.
[05:17] <lifeless> thumper: the whitespace for the &?
[05:18] <jtv> btw if you're going to std::cerr << e.what() then don't forget the eol.
[05:18] <thumper> << '\n'
[05:18] <thumper> const& on the RHS of the type
[05:18] <jtv> thumper: now now, who's being all old-school a-better-C here?
[05:19] <thumper> cerr flushes automatically, so explicit not needed
[05:19] <jtv> thumper: the const and the & have basically nothing to do with each other... the const qualifies the exception, not the &
[05:19] <jtv> I know clog flushes automatically, but cerr..?
[05:19] <thumper> jtv: we need beer and time to talk this through
[05:19] <wgrant> Now now people. Let's keep the channel Python-friendly.
[05:19] <thumper> cerr yes
[05:19] <jtv> thumper: aye to that!
[05:19] <thumper> wgrant: why?
[05:20] <wgrant> thumper: C++ is too much like Java.
[05:20]  * jtv screams
[05:20] <jtv> We were here first.
[05:21]  * wgrant kicks Python 2.4 to death.
[05:22] <jtv> wgrant: "don't kill it yet, we still need it"
[05:38] <thumper> spm: are you un-paniced yet?
[05:38] <spm> nope
[05:41] <thumper> I'll go away and check back later...
[05:44] <lifeless> thumper: oh doh, I should have noticed the const positioning
[05:44] <lifeless> of course, its a PITA.
[05:50] <wgrant> maxb: Running 'make check' on karmic amd64 with 2.4 has so far given me a LayerIsolationError in timeout.txt, but package-diff.txt just passed fine. I think LP might hate you.
[05:50] <wgrant> maxb: This is all freshly downloaded and installed.
[06:39] <thumper> I want pizza
[06:40]  * thumper is thinking of Poppa's pizza
[06:48] <lifeless> mmmmm
[06:48] <lifeless> do not be tempting me like that
[06:52] <thumper> spm: reminder to re-enable pqm :)
[06:52] <spm> oo. ta. will do.
[06:58] <wgrant> Why must PQM be turned off for CPs?
[07:00] <lifeless> the same machine is used to validate the production branch changes
[07:00] <lifeless> wgrant: e.g. 'why can't you run two lp test suites at once on the same machine'
[07:01] <wgrant> lifeless: Ah. I thought buildbot was all EC2, so the CP tests would be on another instance.
[07:01] <wgrant> But that makes sense.
[07:26] <poolie> spm: are you working on this now?
[07:26] <spm> poolie: bzr access? very much so.
[07:26] <spm> the CP went sour in a big way
[07:27] <poolie> cp?
[07:27] <spm> cherry pick
[07:28] <wgrant> Ooh dear.
[07:29] <spm> we've reverted - so back to where we were; but still open to the HTTP errors. :-/
[07:30] <poolie> i actually really like sour cherries
[07:32] <wgrant> Was it the rewrite stuff that was CPed?
[07:32] <spm> poolie: a sincere thank you! jokes during a crisis are *always* appreciated :-)
[07:32] <wgrant> poolie: They are good, yes.
[07:32] <spm> wgrant: amonst some other bits, yes.
[07:43] <poolie> spm, ssh seems to still be down
[07:44] <spm> poolie: yes; trying a hopefully fixed update. should be back now.
[08:23] <adeuring> good morning
[08:38] <jtv> hi adeuring!
[09:01] <bigjools> morning
[09:01] <gmb> Morning.
[09:11] <jtv> hi bigjools, hi gmb
[09:18] <wgrant> Why is my postgres eating a couple of gigabytes of disk after a test run failed due to a lack of disk space?
[09:18] <wgrant> Is it told not to clean up, or something?
[09:22] <bigjools> autovacuum not running?
[09:22] <wgrant> I was thinking that.
[09:22] <wgrant> But I don't see why it wouldn't be.
[09:23]  * wgrant checks more carefully this time.
[09:23] <gmb> I've had it vanish silently on me before.
[09:23] <gmb> But it's been a while since that happened (might even have been back when we were on PG8.2 rather than 8.3)
[09:23] <wgrant> I shall watch more carefully this time.
[09:27] <wgrant> This has probably happened all five times I've run 'make check' now, but the first three times I didn't realise it was the database.
[09:27] <wgrant> So it seems unlikely that autovacuum is going missing.
[09:33] <mrevell> Morning
[10:58] <deryck> Morning, all.
[11:24] <Fly-Man-> morning thumper
[11:27] <mrevell> hey Fly-Man-, thumper's most likely afk ... it's late Friday evening for him
[11:27] <Fly-Man-> mrevell: Ahh, he's the Australian one ?
[11:28] <Fly-Man-> mrevell: morning btw :)
[11:28] <mrevell> Fly-Man-: Heh, New Zealand -- I think it's a capital offence to confuse the two. Morning :)
[11:28] <Fly-Man-> sorry thumper ;)
[11:28] <Fly-Man-> mrevell: I asked a question yesterday about the launchpad download
[11:29] <Fly-Man-> as it seems the version is still the 2.2.6 version
[11:29] <mrevell> Fly-Man-: The LP source code?
[11:29] <Fly-Man-> and i'm part of the beta team
[11:29] <mrevell> Fly-Man-: Ah, the version number that appears in the footer on edge?
[11:29] <Fly-Man-> and it seems the beta site is running a lower version then my local launchpad
[11:29] <Fly-Man-> which surprises me ...
[11:29] <Fly-Man-> mrevell: Yes, the source that you can get
[11:30] <Fly-Man-> My local version is
[11:30] <Fly-Man-> Launchpad 2.2.6 (r9108)
[11:30] <Fly-Man-> the version from edge is
[11:30] <wgrant> edge only updates every 24 hours, and it updates from a branch that is always several hours out of date.
[11:31] <wgrant> So yours is very probably newer.
[11:31] <Fly-Man-> Launchpad 2.2.6 (r9041)
[11:31] <Fly-Man-> wgrant: yes, but thumper also mentioned that the new 2.2.7 version should be available as download as well
[11:32] <Fly-Man-> but I can't seem to find that one anywhere
[11:32] <wgrant> Fly-Man-: There's no '2.2.7' version.
[11:32] <wgrant> It's all the same branch.
[11:32] <wgrant> But the version number hasn't been changed yet.
[11:32] <mrevell> Fly-Man-: The version number that shows in the footer isn't all that reliable. Usually it is but it's actually just a text string that's manually updated.
[11:32] <Fly-Man-> Ooo, so the version I download is the "2.2.7" ?
[11:32] <mrevell> Fly-Man-: The version you download is whatever is the latest version
[11:32] <mrevell> 2.2.7 only exists as a snapshot in time on the live production server
[11:33] <Fly-Man-> Ahh, that makes perfect sense
[11:33] <mrevell> So, the version you download is 2.2.7 plus whatever has been committed since the 2.2.7 release.
[11:33] <Fly-Man-> Ahhh, that's good :)
[11:34] <Fly-Man-> so I don't need to perform the rocketfuel-setup every time to get the latest version
[11:34] <Fly-Man-> but can just pull the version with bzr
[11:35] <Fly-Man-> but now a question that might be a hard one ....
[11:35] <mrevell> Fly-Man-: Or run utilities/rocketfuel-get
[11:35] <Fly-Man-> "How to get the code importer function to work"
[11:36] <Fly-Man-> and clean up the projects that I don't need in there
[11:36] <Fly-Man-> because thumper mentioned that the codeimporter should work
[11:37] <Fly-Man-> but then had to fire fight something on the site
[11:37] <wgrant> What exactly are you trying to do?
[11:37] <Fly-Man-> I am trying to import the SVN trunk from a server
[11:38] <Fly-Man-> to see if I get the same errors that the launchpad.net gets
[11:38] <Fly-Man-> to analyse where it might go wrong
[11:38] <Fly-Man-> and also planning on the Git import
[11:38] <wgrant> All of the Code guys are hopefully asleep, so there's probably not much help around for that right now.
[11:39] <mrevell> abentley should be around in two or three hours
[11:39] <Fly-Man-> so I can match the problem and see where that might have a patch/fix that might help
[11:39] <wgrant> Git is easy to test.
[11:39] <wgrant> Just install bzr-git and try to check the repo out with it.
[11:40] <wgrant> SVN is harder, because cscvs is old and confuses me.
[11:41] <Fly-Man-> k, bzr-git doesn't come up when I do a apt-cache search bzr
[11:41] <Fly-Man-> so I might not have the right repository's set
[11:48]  * Fly-Man- does a lightbulb above his head
[11:48] <Fly-Man-> See, I was right about 1 thing ...
[11:48] <Fly-Man-> https://code.edge.launchpad.net/~vcs-imports/opensim/svn-trunk
[11:48] <Fly-Man-> if I check it out with bzr svn-import url
[11:49] <Fly-Man-> it gives an error
[11:49] <Fly-Man-> when I check it out without the trunk
[11:49] <Fly-Man-> it's importing ...
[11:56] <wgrant> Fly-Man-: LP doesn't use bzr-svn.
[11:57] <Fly-Man-> okay ...
[11:57] <wgrant> It uses cscvs, from which you want to swiftly escape.
[11:57] <Fly-Man-> So in other words, cscvs does the things different
[11:57] <wgrant> Yes.
[11:57] <wgrant> Completely.
[11:58] <Fly-Man-> and a code change would be required to make it go from cscvs to bzr-svn /
[11:58] <wgrant> Yes, but there are bigger problems with the transition.
[11:59] <wgrant> I believe it is on the list for post-3.0
[12:01] <Fly-Man-> I keep wondering why it gets those messages on the SVN
[12:01] <Fly-Man-> WARNING N changeset 1
[12:01] <Fly-Man-> WARNING N changeset 2
[12:01] <Fly-Man-> and then it just "poofs"
[12:05] <wgrant> gmb, bigjools: So, autovacuum is running as it should, and even manually vacuuming doesn't help :(
[12:06] <gmb> Hrm.
[12:06] <bigjools> o\
[12:08] <wgrant> 'make schema' almost cuts it back to where it started. So I'm pretty confused.
[12:48] <Fly-Man-> mrevell: I just found a simular bug like the one I have
[12:48] <Fly-Man-> and it seems Paul Hummer is working on that
[12:49] <Fly-Man-> Would it be wise to match the bug I made and put it on that bug report as well ?
[12:49] <mrevell> Ah, that's good to hear -- he's on US mountain time so he'll be around in two or three hours
[12:49] <mrevell> Fly-Man-: If you've already made a bug report, you can mark it as a duplicate of the one Paul's working on
[12:49] <Fly-Man-> k
[14:14] <Fly-Man-> wgrant: 2009-08-14 13:09:34 ERROR   No mail box is configured. Please see mailbox.txt for info on how to configure one.
[14:14]  * Fly-Man- doesn't see a mailbox.txt file anywhere ?
[14:23] <Fly-Man-> kfogel: Goodafternoon kfogel
[14:24] <Fly-Man-> kfogel: You were gone when I was finished
[14:24] <Fly-Man-> but here's the page to the local setup
[14:24] <Fly-Man-> https://dev.launchpad.net/Running/LocalNetwork
[14:26] <kfogel> Fly-Man-: reading now
[14:26] <Fly-Man-> k
[14:27] <kfogel> Fly-Man-: is this only for machines on your local network?  Would it work for machines on the WAN too?
[14:28] <kfogel> Fly-Man-: IOW, I'm wondering if the name of this page should be "RemoteAccess" or something
[14:30] <kfogel> Fly-Man-: the summary at the top says "This page tells you how to change the Launchpad so you can access it on your own machine."  I think maybe that's too vague?  After all, that's what the normal Running instructions give.  Your tutorial is about something bigger: the ability to access Launchpad from a *different* machine than the one it is running on (right?).
[14:32] <Fly-Man-> kfogel: It will work on a Wan as well
[14:33] <kfogel> Fly-Man-: so, let's rename the page.  It's not linked to from anywhere yet, right?
[14:33] <Fly-Man-> But for a WAN I would suggest using a DNS server that an register
[14:33] <Fly-Man-> it's only registered at the Running page
[14:33] <kfogel> Fly-Man-: I'm sorry, I didn't understand your last sentence.
[14:33] <kfogel> oh
[14:33] <kfogel> linked
[14:33] <Fly-Man-> yes
[14:33] <kfogel> you used "register" twice, but with different meanings :-)
[14:34] <Fly-Man-> sorry, Dutch ;)
[14:34] <kfogel> heh
[14:34] <kfogel> Fly-Man-: we can fix the Running link, no problem
[14:34] <Fly-Man-> RemoteAccess could be a good name for that
[14:34] <Fly-Man-> but then it needs a step with it for Wan usage
[14:34] <kfogel> so, first: let's rename the page.  then, if it needs any tweaks to explain difference between LAN and WAN access, maybe you can put those in?
[14:34] <Fly-Man-> "If you want to use it on a Wan, please make sure you can access a DNS server to setup the values"
[14:34] <kfogel> Fly-Man-: I can rename right now and fix Running, if yuo wnt.
[14:34] <Fly-Man-> go ahead :)
[14:34] <kfogel> "you want", sorry
[14:35] <kfogel> typo
[14:35] <kfogel> ok
[14:36] <kfogel> Fly-Man-: all done
[14:36] <kfogel> Fly-Man-: fixed summary bar too
[14:36] <Fly-Man-> k
[14:36] <kfogel> Fly-Man-: I'll leave the WAN changes to you, since you know the material better
[14:36] <Fly-Man-> Well, that's the easy part ;)
[14:39] <Fly-Man-> kfogel: done ;)
[14:40] <kfogel> Fly-Man-: thanks!
[14:40] <Fly-Man-> Yw
[14:40] <Fly-Man-> and now to find the people that can explain the parts that I miss
[14:40] <Fly-Man-> like the setting up of the cron jobs
[14:40] <Fly-Man-> I have seen that some jobs run normally
[14:41] <kfogel> Fly-Man-: "When you have done this correctly, then you will be able to use the local launchpad application within your own WAN"
[14:41] <Fly-Man-> and some need additional fixing
[14:41] <kfogel> LOL -- I wish I had my own WAN! :-)
[14:41] <Fly-Man-> kfogel: You don't ;) ?
[14:42] <kfogel> Fly-Man-: mind if I tweak to "the WAN"?
[14:42] <Fly-Man-> it's already tweaked ;)
[14:43] <kfogel> Fly-Man-: see it now, how does this wording look?
[14:43] <Fly-Man-> nice
[14:43] <Fly-Man-> looks good to me
[14:43] <kfogel> Fly-Man-: cool
[14:44] <Fly-Man-> kfogel: But now the configuration part ...
[14:44] <Fly-Man-> because I see MANY python scripts in the cron-scripts folder
[14:44] <Fly-Man-> some do something
[14:44] <Fly-Man-> but i found out the hard way, some are related to the launchpad.net version
[14:44] <kfogel> Fly-Man-: I am about as knowledgeable as you are about those...
[14:45]  * Fly-Man- smiles
[14:45] <Fly-Man-> Aha, and I was thinking you're the Guru master ;)
[14:46] <Fly-Man-> But who would be the ones to ask those Q's /
[14:46] <Fly-Man-> so we can make the configuration of those index on the Wiki as well ?
[14:46] <Fly-Man-> mrevell already told me maybe abentley  would be one of them
[14:47] <Fly-Man-> but the best part is the SSL certificate that's invalid :|
[14:48] <jmux> Hi. I've set up Launchpad and now want to use sync-source to sync the Debian sources into my launchpad? I've found the ArchiveAdministration wiki page, but this references an update-source script in a ~/syncs directory. Is the content of ~/syncs available somewhere?
[14:59] <maxb> kfogel: Fly-Man-: A further comment on that page - IMO it's too wordy by far. I'd prefer to strip all tutorial-esque information out and turn it into a document on what you change
[14:59] <Fly-Man-> maxb: Feel free to edit it :)
[14:59] <maxb> Well, I'm always a bit hesitant about deleting other's content
[15:00] <Fly-Man-> maxb: Go ahead :)
[15:00]  * Fly-Man- approves to it
[15:00] <james_w> jmux: it is 'run "update-sources" in ~/syncs', rather than 'run ~/syncs'
[15:00] <kfogel> Fly-Man-: I'm not a Launchpad guru by any means.  Still learning.
[15:00] <james_w> jmux: I'm not sure where update-sources comes from though
[15:00] <Fly-Man-> kfogel: *grin*
[15:00] <Fly-Man-> Same here
[15:00] <Fly-Man-> but so far, I have gotten some experience
[15:00] <maxb> Launchpad doesn't like me
[15:00] <kfogel> maxb: ?
[15:00] <Fly-Man-> now to get those cron scripts to know
[15:01] <Fly-Man-> and understand when they should be run
[15:01] <Fly-Man-> then we can make another page on the Help how to set those up
[15:01] <maxb> wgrant and I are running exactly the same code on Karmic with Python 2.4, and the tests pass for him but fail for me
[15:02]  * Fly-Man- grins
[15:02] <Fly-Man-> Hmm, for some reason I just started the code importer .... *laughs*
[15:03] <jmux> james_w: But where do I get the content of ~/syncs from?
[15:03] <james_w> jmux: by running update-sources
[15:03] <james_w> ~/syncs contains the output of the script, not the script itself
[15:04]  * Fly-Man- laughs
[15:06] <Fly-Man-> kfogel: Seems that I have the code importer working as well ...
[15:06] <jmux> james_w: ah ok - so do you have this update-sources script? It's not in the ubuntu-archive-tools
[15:07] <james_w> I don't think it's part of Launchpad
[15:07] <james_w> I think it's just a convenience script hacked on top
[15:08] <james_w> do you have sync-source.py?
[15:10] <beuno> salgado, the comment for breadcrumbs in your stand up made me both laugh and cry
[15:11] <jmux> Yes it's in scripts/ftpmaster-tools
[15:11] <salgado> beuno, but don't worry, I have a plan :)
[15:12] <beuno> salgado, ...and that's why I like you so much.
[15:15] <james_w> jmux: update-sources just needs to provide Sources files of the appropriate names for the series that you would like to sync from
[15:15] <james_w> see the read_Sources function
[15:20] <jmux> james_w: I know, but I thought this update-sources script would do this downloads for me
[15:20] <james_w> it would
[15:21] <james_w> it's just a bunch of wgets though
[15:56] <Fly-Man-> kfogel: It seems that the local version of Launchpad has the same issues with the SVN import as the website
[15:58] <kfogel> Fly-Man-: at least now you're in a position to debug :-).
[15:59] <Fly-Man-> kfogel: Yeah, that's a good thing
[15:59] <Fly-Man-> because I told wgrant before that with the bzr svn-import it worked like a charm
[16:00] <Fly-Man-> but the system is using something different
[16:00] <Fly-Man-> so that's the bottle neck
[16:27] <Fly-Man-> Anyone, i have succesfully imported a branch on a local Launchpad
[16:27] <Fly-Man-> but it doesn't show up on the page itself
[16:27] <Fly-Man-> is there a cron task to run to make it parse ?
[16:29] <salgado> Fly-Man-, I think that's what the branch scanner does, but I don't know where exactly that script lives
[16:30] <Fly-Man-> okay, that one I found :)
[16:32] <EdwinGrubbs2> sinzui: do all pages load the style-3.0.css, or is it just the pages using 3.0 templates?
[16:32] <sinzui> just 3.0
[16:33] <sinzui> EdwinGrubbs: 3.0 loaded YUI-reset that destroys most of the style that 2.0 is predicated on
[16:36] <Fly-Man-> salgado: that branch scanner did notthing
[16:45] <Fly-Man-> hmm, nope, there seems to be no branch-import being done :|
[16:46] <rockstar> Fly-Man-, hi.
[16:47] <Fly-Man-> Hello rockstar
[16:47] <rockstar> Fly-Man-, push the branch to launchpad, then run the following commands:
[16:47] <rockstar> bin/py cronscripts/supermirror-pull.py
[16:47] <rockstar> make scan_branches
[16:48] <Fly-Man-> rockstar: that looks like the thing I needed ;)
[16:48] <rockstar> Fly-Man-, I thought so.  :)
[16:50] <Fly-Man-> rockstar: does that need to be run by cron as well ?
[16:50] <rockstar> Fly-Man-, it is on production, but for development, I'd only manually run it.  You shouldn't have to push branches that often.
[16:51] <rockstar> If you're trying to write a test, there are bettor tools for writing the test.
[16:51] <Fly-Man-> rockstar: It's not a test ;)
[16:52] <Fly-Man-> Trying to update the Wiki for the ppl that want to use the Launchpad to pull their stuff in
[16:52] <rockstar> Fly-Man-, ah, as in, a separate instance?
[16:52] <Fly-Man-> and so far, i'm collecting about 150 OOPS messages :p
[16:52] <Fly-Man-> rockstar: Have you read the Running page ?
[16:52] <Fly-Man-> https://dev.launchpad.net/Running
[16:53] <Fly-Man-> at the end of the page
[16:53] <Fly-Man-> we made a new page
[16:53] <Fly-Man-> https://dev.launchpad.net/Running/RemoteAccess
[16:53] <Fly-Man-> how you can get the LaunchPad to show up on the outside of the system
[16:53] <Fly-Man-> so you can play with it from another pc
[16:53] <rockstar> Fly-Man-, see https://dev.launchpad.net/Code/HowToUseCodehostingLocally
[16:54] <rockstar> Fly-Man-, I'm sure I've seen how to run it to show up on the outside of the system. It's just some apache config.
[16:55] <Fly-Man-> And the update on the client side through hosts file or DSN entries
[16:55] <Fly-Man-> But I see some nice things that I didn't know on that page
[16:56] <Fly-Man-> but good that you are here rockstar
[16:56] <Fly-Man-> because I think you have the solution to another problem i'm having
[16:56] <Fly-Man-> with the GIT and SVN pulls on the launchpad.net
[17:00] <rockstar> Fly-Man-, I'm not here for too much longer today.
[17:00] <Fly-Man-> rockstar: K, then I will keep it short
[17:00] <Fly-Man-> There's a bug report in from me
[17:02] <rockstar> Fly-Man-, what's the bug number?
[17:02] <Fly-Man-> grabbing
[17:03] <Fly-Man-> https://bugs.edge.launchpad.net/launchpad/+bug/412974
[17:03] <mup> Bug #412974: git import failing on project opensim <Launchpad itself:New> <https://launchpad.net/bugs/412974>
[17:03] <Fly-Man-> thanks you mup :)
[17:08] <rockstar> Fly-Man-, I'll take a look at it.
[17:08] <Fly-Man-> rockstar: thank you very much :)
[17:09] <Fly-Man-> Your page also fixed some of the problems I had with bazaar :)
[17:09] <Fly-Man-> so thanks again rockstar for that page
[17:33] <dobey> can someone look at OOPS-1322EC233 ?
[17:49] <dobey> i am having one hell of a time trying to view the branches i own :(
[17:56] <matsubara> dobey, bug 396593
[17:56] <mup> Bug #396593: Person branch listing page timing out <timeout> <Launchpad Bazaar Integration:Fix Committed by thumper> <https://launchpad.net/bugs/396593>
[17:56] <matsubara> dobey, should be rolled out tomorrow to edge
[17:57] <dobey> matsubara: ah ok, cool
[17:57] <dobey> thanks
[17:57] <matsubara> np
[18:05] <mrevell> see you Monday guys
[18:06] <Fly-Man-> mrevell: Have a good weekend :)
[18:06] <mrevell> thanks, you too :)
[18:14] <james_w> anyone know what "python setup.py test" does different to just running nosetests?
[18:14] <james_w> I'm getting failures with the former that I don't get with the latter
[18:14] <james_w> with wadllib, sorry
[18:16] <james_w> ah, it seems to be going via unittest
[18:27]  * kfogel is away: looooooooonch
[18:28] <Fly-Man-> have a good lunch :)
[18:46] <Fly-Man-> This doesn't sound good:
[18:46] <Fly-Man-> ./rocketfuel-setup: line 372: 19483 Segmentation fault      bzr branch http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/ $LP_TRUNK_NAME ERROR: Unable to create local copy of Rocketfuel trunk
[18:58] <beuno-lunch> sinzui, could you give deryck and myself some insights on bug 413611
[18:58] <mup> Bug #413611: Convert the comment add templates to 3.0 UI <Launchpad Bugs:In Progress by deryck> <https://launchpad.net/bugs/413611>
[19:08] <Lantash> @danilos: Would you mind telling me what triggers the import of a translation file after its approval? I'd like to test-drive my fix for #392154.
[19:08] <mup> Bug #392154: translator-credits show two contributor lists <Launchpad Translations:Triaged> <https://launchpad.net/bugs/392154>
[19:09] <danilos> Lantash: cronscripts/rosetta-poimport.py will take care of it, but note that file should have been uploaded as 'Published' upload
[19:09] <danilos> Lantash: 'User' uploads are basically like editing through the web UI
[19:27] <james_w> garr, that's annoying
[19:27] <james_w> the problems are cause by discrepancies between simplejson's python and C implementations of the same code
[19:29] <james_w> http://code.google.com/p/simplejson/issues/detail?id=40
[19:32] <salgado> beuno, is it intentional that some links to people on https://code.edge.launchpad.net/~salgado/launchpad/cached-menus/+merge/9599 point to lp.net/~person and others point to code.lp.net/~person?
[19:33] <beuno> salgado, no
[19:33] <beuno> bug
[19:33] <beuno> sinzui is suppose to make that all better, I think
[19:33] <salgado> beuno, where should they all point to?
[19:34] <beuno> salgado, lp.net/~person
[19:34] <sinzui> beuno: salgado The fix is landed.
[19:35] <salgado> sinzui, what's the fix?
[19:36] <sinzui> beuno: salgado The fmt:link DTRT. fmt:link:bugs willl force a link to pugs for person and pillars. fmt:url is unchanged because when you decide to mess with the URL or text, you have committed to thinking about the issues
[19:36] <sinzui> salgado: I have not had time to announce it.
[19:36] <sinzui> broken links are broken because the TAL is not using the official way we make links to people
[19:39] <sinzui> salgado: you can also use fmt:url:bugs to make a url to the bugs app
[19:43] <salgado> sinzui, that's a nice change, but fmt:url seems to behave the same way.  at least for people
[19:43] <salgado> or am I reading it wrong?
[19:45] <sinzui> salgado: fmt:link defaults to mainsite. fmt:url does not. My reasoning is that since we are only supposed to use fmt:url in rare cases, we probably do not want default ebhaviour
[19:45] <sinzui> salgado: fmt:url:mainsite will do what fmt:link does for person
[19:46] <salgado> that makes sense, but the signature of PersonFormatterAPI.url is "def url(self, view_name=None, rootsite='mainsite'):"
[19:49] <salgado> sinzui, ^
[19:51] <sinzui> huh!
[19:51] <sinzui> salgado: I think I screwed up.
[19:54] <sinzui> salgado: I did intend to make URL do that and for pillars too. I decided after looking at several examples that when we work with fmt:url, we have already rejected the default behaviour. I thought I reverted all def url()
[19:55] <salgado> sinzui, indeed, it's only for people/teams that url() behaves this way
[19:56] <sinzui> No test broke. That is interesting in itself
[19:56] <sinzui> Well I'll prepare a fix if you do not.
[19:59] <salgado> sinzui, I won't have time for that today
[20:00] <Lantash> danilos: Thanks alot for your help!
[20:00] <Lantash> Is it possible to run bin/lint.sh on a 9.04 machine somehow? And running the full test suite on the Amazon EC2 cloud doesn't seem to be possible for external contributors either (it's highly unprobably that the fix breaks any tests though). Would you recommend me to propose a merge for ~lantash/launchpad/bug-392154? Am I supposed to send the Contributor Agreement PDF to you or to Kiko Reis?
[20:01] <sinzui> salgado: that is fine I can get to it by Monday
[20:05] <Ursinha> I love the song of commit 9114
[20:12] <salgado> beuno, do you have some time to talk about breadcrumbs?
[20:12] <beuno> salgado, I do. IRC or skype?
[20:12] <salgado> beuno, skype. should be quick
[20:13] <beuno> salgado, sure, give me 15'?
[20:13] <salgado> sure
[20:15] <sinzui> barry: I updated your /people bug
[20:18] <beuno> salgado, https://edge.launchpad.net/ubuntu/jaunty/+lang/af
[20:20] <salgado> launchpad.net/tangocms/trunk/+pots/tangocms-aliases/es/+translate
[20:21] <EdwinGrubbs> sinzui: Why does the base-layout.pt include the context/title in the heading slot, when the location portlet already has the context/title from the fmt:location_heading?
[20:21] <sinzui> EdwinGrubbs: they will not be the same when printed
[20:22] <EdwinGrubbs> sinzui: huh, they are the same on the edit pages.
[20:22] <sinzui> EdwinGrubbs: beuno We need to change s names in the base-layout. because the parts are not what we intended
[20:23] <sinzui> EdwinGrubbs: beuno: The location portlet is a branding-watermark. The heading-slot is now the final breakcrumb location
[20:23] <sinzui> EdwinGrubbs: See: https://launchpad.dev/firefox/trunk/+edit
[20:24] <sinzui> firefox branding, trunk series location, page_title or task it Edit
[20:25] <beuno> uhm
[20:25] <beuno> what?
[20:25] <sinzui> beuno: I think every engineer mis uses the heading-slot because they think that is where the page_title goes to make the <h1> and <title>
[20:29] <sinzui> beuno: I have this hole in my distro page. I really want to add one more portlet that is guaranteed to be present for all distros. Is there something  from the page you want to see.
[20:30] <beuno> sinzui, ah
[20:30] <beuno> how can we fix that?
[20:34] <barry> sinzui: thanks i saw that.  probably will end up finishing that monday morning
[20:35] <sinzui> beuno: cprov: I moved the package search into a nice portlet. I see there is a very nice ppa search form. IS there user demand to search ppas from the ubuntu page?
[20:35] <beuno> sinzui, there's nowhere else to do so
[20:35] <sinzui> may be we need  a section that points to ubuntu.com to get ubuntu and flavors
[20:36] <sinzui> oh!. We do not say anything about kubuntu on the ubuntu page.
[20:36] <cprov> sinzui: yes, flavour do not exist in soyuz (UI)
[21:04] <gary_poster> salgado: hey.  have you thought about the policy for how to manage source for our non-standard distributions (the one-offs we produce, like we did briefly for Storm and that I've done for other reasons) that kiko-afk asked us to talk about?
[21:04] <gary_poster> do you want to talk about that sometime soonish?  this evening, or Monday or something?
[21:08] <salgado> gary_poster, I haven't, sorry.  Monday sounds good to me
[21:09] <gary_poster> salgado: np.  ok cool.  ping me sometime then, or I'll ping you.
[21:13] <beuno> barry, https://staging.launchpad.net/bzr
[21:13] <beuno> barry, try to edit the programming language
[21:17] <barry> beuno: somebody br0x0red my beautiful ui
[21:19] <beuno> barry, yes, just a heads up as it will hit edge tomorrow  :)
[21:19] <barry> beuno: good thing tomorrow is saturday!
[21:19] <beuno> barry, no it's not
[21:19]  * barry might as well file the bug for it now though
[21:19] <beuno> it's friday+1
[21:19] <barry> beuno: monday-2
[21:20] <beuno> see, I didn't want it to sounds depressing
[21:20]  * barry invokes warsaw's second law
[21:20] <beuno> damn
[21:20] <barry> beuno: in all seriousness, i'm putting money on it being a bug in lazr-js
[21:21] <beuno> barry, probably
[21:21] <beuno> some things still seem to be too fragile
[21:21] <barry> s/some things/all of javascript/
[21:21] <beuno> heh
[21:23] <barry> beuno: on the bright side, the page otherwise looks great :)
[21:24] <barry> see, i can be optimistic
[21:24] <barry> lpbug 413793
[21:24] <mup> Bug #413793: inline editing doesn't play nicely with launchpad 3.0 UI <LAZR Javascript Library:New> <https://launchpad.net/bugs/413793>
[21:25] <beuno> barry, yeah, I'm lovin 3.0
[22:13] <beuno> rockstar, thumper, I've spent my afternoon working on the branch index page
[22:13] <beuno> maybe I'll get it into a RFC state
[22:13] <beuno> by the end of the day
[22:13] <beuno> if not, early next week
[22:43] <flacoste> mthaddon: can you set the default review team of https://code.edge.launchpad.net/~launchpad-pqm/canonical-identity-provider/trunk to the ~launchpad?
[23:32] <wgrant> maxb: I just ran the entire test suite, after giving it enough RAM and disk. Everything passed.
[23:32] <wgrant> I have both ~launchpad/ppa and ~maxb/launchpad, with no other custom bits in the stack. Is that your config?