[00:00] <jml> ajmitch, those are bzr-ish errors, unlikely to be caused by a proxy
[00:01] <lifeless> jml: well
[00:01] <firefly2442> What are the programming languages used in Launchpad?
[00:01] <jml> lifeless, NoSuchRevision caused by a proxy?
[00:01] <lifeless> jml: if pack-names gets cached in violation of our request it would cause that symptom
[00:02] <ajmitch> right, and I'd not really paid attention to the bzr+ssh:// part of that
[00:02] <lifeless> neither had I:P
[00:02] <lifeless> bzr+ssh definitely isn't a proxy
[00:02] <jml> firefly2442, Python. Python. Python. :)
[00:02] <lifeless> ajmitch: where are you seeing those errors?
[00:02] <etank> i get this http://paste.ubuntu.com/223935/ when running make schema
[00:02] <firefly2442> thanks
[00:03] <ajmitch> lifeless: on checking various  branches in lp-sourcedeps, when running rocketfuel-get
[00:03] <jml> firefly2442, but you can get the code & look for yourself. :)
[00:03] <jml> so
[00:03] <jml> how can we get the ohloh guys to upgrade their version of Bazaar?
[00:03] <ajmitch> I'm just rerunning it at the moment after killing off the dulwich branch
[00:04] <mwhudson> etank: there's an instruction in that error message
[00:04] <wgrant> Ah, you got /p/launchpad. Good.
[00:04] <mwhudson> jml: don't you have friends at sourceforge now?
[00:04] <jml> wgrant, but we didn't get the name 'Launchpad'!
[00:05] <jml> mwhudson, hmm. there's a thought.
[00:06] <ajmitch> jml: send in the hordes of rabid lawyers?
[00:07] <lifeless> ajmitch: its an error, or something logged in .bzr.log?
[00:07]  * jml looks again at his beautiful diagram
[00:08] <ajmitch> lifeless: an error with a traceback, just waiting on it to reproduce
[00:08] <mwhudson> hey, it would be really nice if an error halfway through make didn't totally screw your working tree
[00:09] <ajmitch> I've found it in .bzr.log if you want it on pastebin
[00:09] <lifeless> sure
[00:09] <etank> mwhudson: i did that and got 'link-external-sourcecode: error: Parent branch not specified, and could not be discovered.'
[00:10] <ajmitch> http://paste.ubuntu.com/223939/
[00:10] <mwhudson> etank: did you run rocketfuel-setup to start with?
[00:10] <etank> mwhudson: yeah.
[00:10] <ajmitch> at least dulwich branched without errors after a careful rm -rf :)
[00:10] <etank> it took quite a few hours to finish
[00:10] <mwhudson> though i have to admit, i can't get make to work either right now....
[00:11] <mwhudson> etank: what's in sourcecode in your branch?
[00:11] <thumper> jml: call?
[00:11] <lifeless> ajmitch: file a bug please
[00:11] <jml> thumper, sure. fire away.
[00:11] <lifeless> ajmitch: it looks like that branch hasn't been upgraded and the converter is running into trouble
[00:11] <ajmitch> ok
[00:11] <wgrant> lifeless: So it was trying to convert to 2a?
[00:12] <lifeless> on the fly yes
[00:12] <lifeless> _fetch_batch
[00:12] <lifeless> is part of IDS
[00:13] <wgrant> That would be because rocketfuel-get was broken earlier, and was creating 2a repos before pulling sourcedeps.
[00:13] <wgrant> Now it just checks them out, so no conversion is required.
[00:13] <jml> thumper, try again please.
[00:13] <mwhudson> ooh
[00:13] <etank> mwhudson: just whatever rocketfuel-setup put there
[00:14] <lifeless> wgrant: regardless, it should have succeeded
[00:14] <mwhudson> etank: can you run python2.4 bootstrap.py --ez_setup-source=ez_setup.py --download-base=download-cache/dist --eggs=eggs
[00:14] <mwhudson> etank: and see what that says?
[00:17]  * gmb calls it a night. T'morrow, folks.
[00:17] <ajmitch> lifeless: what else do you need on https://bugs.edge.launchpad.net/bzr/+bug/402778 ?
[00:17] <ubot3> Malone bug 402778 in bzr "NoSuchRevision error when branching with rocketfuel-get" [Undecided,New]
[00:18] <etank> mwhudson: it said nothing
[00:19] <mwhudson> etank: and does plain 'make' work now?
[00:20] <nellery> will it ever become possible for community contributors to earn commit rights?
[00:20] <jml> gmb, g'night.
[00:21] <mwhudson> nellery: good question!  probably
[00:21] <mwhudson> nellery: though with a DVCS it's not that much of an issue
[00:22] <ajmitch> nellery: given that you can commit & push branches already & most likely propose them for review & merging, I'd say yes
[00:23] <lifeless> nellery: in the sense of committing directly to trunk? no - noone has that right even @ canonical - commits are done by a daemon that runs the test suite
[00:24] <lifeless> nellery: in the sense of being able to submit something to land; as mwhudson says, probably :)
[00:24] <ajmitch> there's info on the wiki about the steps to take for that
[00:32]  * jml grumbles, the point of commit messages is to communicate
[00:34] <MarkusT1> Is there some kind of Launchpad Roadmap available? I was looking for the wiki integration, but all I found is this blueprint (https://blueprints.edge.launchpad.net/launchpad-registry/+spec/launchpad-wiki). It seems everything it links to has been removed from launchpad. I was just curious if there already is a decision on this topic.
[00:35] <mwhudson> jml: rather than defeating obscure regular expressions?
[00:35] <mwhudson> MarkusT1: there's https://dev.launchpad.net/VersionThreeDotO
[00:35] <kfogel> mwhudson, wgrant: what exactly was the rocketfuel problem?
[00:35] <mwhudson> kfogel: i don't know exactly
[00:35] <wgrant> kfogel: Which one? The 2a upgrade one that I referred to?
[00:36] <kfogel> wgrant: "which one"... not reassuring words :-).  Yes, I meant the 2a one I saw in backscroll.
[00:36] <MarkusT1> mwhudson: It seems it's quite empty. So I guess: no decision made on that issue.
[00:36] <spm> mwhudson: obscure regular expressions are cause & effect by an obscure joke by obscure losas
[00:36] <lifeless> kfogel: the sourccode branches aren't in 2a
[00:36] <lifeless> kfogel: and for at least one of them converting on the fly errors
[00:36] <mwhudson> MarkusT1: which issue, sorry?
[00:37] <lifeless> kfogel: bug 402778
[00:37] <ubot3> Malone bug 402778 in bzr "NoSuchRevision error when branching with rocketfuel-get" [Undecided,New] https://launchpad.net/bugs/402778
[00:37] <ajmitch> jml: is this in reference to knowing what pqm is apparantly listening to?
[00:37] <MarkusT1> mwhudsono: The question whether launchpad.net get's a wiki or not. :-)
[00:37] <wgrant> kfogel: rocketfuel-get had a brand new bug which treated all of the source dependencies as if they were SSO and ShipIt. So, to save time, it first branched devel into the target directory, then pulled the dep. This caused the deps to get on-the-fly conversions to 2a.
[00:37] <wgrant> Which is slow and crashy.
[00:37] <kfogel> lifeless, wgrant: thank you, got it.
[00:38] <jml> ajmitch, in particular, it's in reference to the heinous practice of saying rs=me or release-critical=me
[00:38]  * thumper is trying to avoid the firehose that is #launchpad-dev :)
[00:38] <thumper> MarkusT1: launchpad.net will get a wiki
[00:38] <ajmitch> thumper: it's only a few people here causing the trouble :)
[00:39] <lifeless> at least we're past the first hump
[00:39] <thumper> yes, less spraying around now than before
[00:39] <lifeless> I meant downloads actually ;P
[00:40] <thumper> kfogel: should standup minutes go to the launchpad-dev mailing list now?
[00:40] <wgrant> I keep getting intermittent connection resets when talking to launchpad.dev, and the local XML-RPC server seems to do it consistently when I attempt to resolve lp://dev/ URLs.
[00:40] <MarkusT1> thumper: Great news! Is there any announcement on that? (Besides you telling me now :->)
[00:40] <thumper> MarkusT1: there is much work to do for it
[00:40] <thumper> MarkusT1: it is in the planning phase post 3.0
[00:41] <mwhudson> thumper: "XXX on leave for next week" probably shouldn't go to a public list
[00:41] <thumper> MarkusT1: we know what we want to offer, and no-one has done it yet
[00:41] <thumper> mwhudson: good point
[00:41] <kfogel> thumper: I think so.  If there's any company confidential stuff, it can go internal of course.
[00:41] <jml> MarkusT1, https://bugs.edge.launchpad.net/launchpad-project?orderby=-users_affected_count
[00:41]  * thumper looks at his notes again
[00:41] <jml> MarkusT1, it's the single most popular bug on the entire Launchpad project :)
[00:42] <kfogel> thumper: that is, the confidential stuff can be separated out and go internal.  But I think our standup notes should be like bzr's, which are sent publicly AFAIR.
[00:42] <kfogel> jml: no, that's "cheddar"
[00:42] <thumper> kfogel: ok, will do
[00:42] <jml> kfogel, *blink*
[00:43] <wgrant> pkern: Have you succeeded in running publish-distro yet?
[00:44] <MarkusT1> As long as it's on the agenda I'm allright. You guys proved very well how you're able to handle this project. I found the bug report before, I just could not find any official comment on it. Thanks for sharing. This is getting better and better :-)
[00:45] <wgrant> I presume it's just a matter of populating distroseries.lucilleconfig and the librarian properly, then running it in full careful mode.
[00:46]  * thumper updates his trunks
[00:47] <thumper> hmm, what's the chance I actually write any code before lunch...
[00:47] <jml> https://www.ohloh.net/topics/3685?page=1#post_11061
[00:47] <mwhudson> depends how strong your "ignore stuff" field is
[00:47]  * mwhudson is coding
[00:47] <mwhudson> (and gabbing while acceptance tests run...)
[00:48] <pkern> I wonder how uploadpolicy is wired into the system, because that might screw with my tries to add a distroseries for Debian.
[00:49] <wgrant> I might just manually process a PPA upload a publish PPAs for now.
[00:49] <mwhudson> jml: yayness
[00:49] <wgrant> Since the librarian is decidedly file-less, and I can't be bothered working out how to get gina to work.
[00:54] <jml> wgrant, spiv has commented more than once in my hearing that the librarian is an ideal candidate for spinning off into a standalone app, fwiw
[00:58] <kfogel> thumper: barry points out that standup notes can contain vacation times and other personal stuff, and that therefore they shouldn't be public
[00:58] <kfogel> thumper: I think we're going to need to think about this more carefully; I will ponder and post a proposal, but for now do it internally I guess.  I think really we're going to have to have two versions: one with internal stuff and another with public dev stuff.
[00:59] <thumper> kfogel: I checked my standup notes for personal details
[00:59] <thumper> kfogel: I agree we should be careful with what we put in public notes
[00:59] <etank> mwhudson: no make does not run
[00:59] <etank> i get the same error
[01:00] <mwhudson> etank: i can only suggest running the commands make is running one by one (without the ssh.py bit) and seeing what is breaking
[01:00] <kfogel> thumper: but we will need a system that is documented and can be routinized.  We don't want team leads having to improvise this every time.
[01:02] <thumper> kfogel: right
[01:13] <wgrant> What happens with mail in devmode? I expected it to go to /var/tmp/launchpad_mailqueue, but it instead seems to be sent to root.
[01:15] <mwhudson> well yes, it gets sent to root
[01:15] <mwhudson> i once found the code that did that, i can't remember where it is though
[01:26] <bz_g> ping
[01:26] <mwhudson> oh wow
[01:26] <mwhudson> from lp.registry.model.person import *\nAttributeError: \'module\' object has no attribute \'generate_nick\'\n'
[01:26] <mwhudson> not managed that one before
[01:26] <mwhudson> (it's a circular import, of course)
[01:27] <bz_g> Did anyone try/manage to install launchpad on Debian (lenny)?
[01:29] <jml> hmm. I seem to be getting conflicts every time I pull. :\
[01:31] <jml> I guess that's because a directory change is moving through the trunk branches.
[01:35] <jml> bz_g, I don't think anyone's tried yet, that I know of.
[01:37] <mwhudson> it would be nice if different pyflakes warnings came out as different colours in flymake
[01:37] <mwhudson> that sounds kind of hard to achieve though
[01:38] <jml> mwhudson, interesting notion.
[01:38] <jml> mwhudson, have you got pep8.py hooked up to flymake as well?
[01:38] <mwhudson> jml: no
[01:39] <jml> mwhudson, I do, and I'm quite liking it, but I do wish the warnings were differently coloured.
[01:40] <mwhudson> jml: time to read flymake.el a bit i guess!
[01:40] <jml> mwhudson, good luck.
[01:40] <jml> Here is your elisp trowel. Use it wisely.
[01:41] <mwhudson> it has different faces for errors and warnings at leas
[01:41] <mwhudson> t
[01:42] <jml> mwhudson, pyflakes doesn't really distinguish between the two though
[01:42] <mwhudson> right
[01:42]  * jml sometimes wonders if it should have some more reporting options.
[01:42] <mwhudson> i guess it's a regexp somewhere in flymake to try to tell the difference
[01:43] <jml> \o/
[01:43] <mwhudson> heh
[01:43] <mwhudson> it's a warning if the string "warning" appears in the output i think
[01:44] <jml> and an error otherwise?
[01:44] <mwhudson> ah, mildly more complex than that
[01:44] <mwhudson> jml: yeah
[01:52] <wgrant> Hmmmmm. The Soyuz karmaactions are in sampledata/current.sql, but not sampledata/current-dev.sql, so they were missing from my DB. Why would that be?
[01:52] <spiv> mwhudson: you mean flymake is two-faced? :)
[01:52] <mwhudson> spiv: zing!
[01:53] <bz_g> jml: thanks.  Maybe I'll give a go...
[01:53] <mwhudson> wgrant: the sampledata used for tests is not the sampledata that you get when you run make run and poke around
[01:53] <mwhudson> wgrant: i don't know which is which any more :)
[01:53] <jml> we want to reduce the sampledata used for tests
[01:54] <wgrant> The missing karmaaction was crashing things :(
[01:54] <wgrant> Yay, a successfully populated and published PPA.
[01:55]  * mwhudson goes for lunch
[01:59] <MarkusT1> I tried really hard to find the right documentation, but I still have a question left :-) : How do I actually delete projects and users in lp as the foo.bar admin user? I'm able to set projects inactive, but I can't find the "delete" button? :-/
[01:59] <wgrant> MarkusT1: Projects are only ever deactivated.
[02:00] <wgrant> They can't be deleted.
[02:00] <wgrant> Same with people.
[02:00] <MarkusT1> wgrant: Ah thanks. So at least I can stop searching :-)
[02:01] <lajjr> congratz to launchpad-dev team \o/ .
[02:02] <jml> lajjr, thanks :)
[02:05] <lajjr> your welcome great source release. I can't wait to look at the code.
[02:06]  * Snova_ would, but 280 MB is huge for this time of day
[02:08] <lajjr> I download the tar.gz file and it is done, but the ./rocketfuel-setup started 10 mins ago.
[02:09] <lajjr> I think that might be awhile yet :P
[02:09] <wgrant> lajjr: Did you prepopulate the repository with the tar.gz's contents?
[02:09] <lajjr> yep..
[02:09] <wgrant> (also, rocketfuel-setup calls rocketfuel-get, which downloads lots more)
[02:09] <lajjr> it will work right??
[02:10] <wgrant> What is rocketfuel-setup saying it's doing?
[02:10] <lajjr> downloading the deps apache etc.
[02:12] <lajjr> fresh install on a new laptop Jaunty 9.04.
[02:14] <lajjr> You can use the following commands to manage your Launchpad
[02:14] <lajjr> development environment:
[02:14] <lajjr>  rocketfuel-get
[02:14] <lajjr>     Update your copy of devel and the necessary source
[02:14] <lajjr>     dependencies, and make sure all source dependencies are properly
[02:14] <lajjr>     linked in to all the branches you are working on.
[02:14] <lajjr>  rocketfuel-branch foo
[02:14] <lajjr>     Create a new branch of LP called "foo" in
[02:14] <lajjr>     /home/lajjr/launchpad/lp-branches/foo,
[02:14] <lajjr>     with all the source dependencies properly linked in.
[02:14] <lajjr>  rocketfuel-status
[02:14] <lajjr> wow I guess it's done.
[02:15] <maxb> ooi, is there a summary of what couples Launchpad to a specific python version so much more so than other python code?
[02:15] <lajjr> yep it just ran a list with that at the top..
[02:16] <lajjr> rocketfuel etc etc rocketfuel status etc.
[02:16] <wgrant> lajjr: That doesn't tell you much. What does ~/launchpad/lp-branches/devel/sourcecode have in it?
[02:21] <jml> thumper, mwhudson, rockstar: there are still a few untested test plan items
[02:21]  * thumper looks
[02:22] <lajjr> ok hold on.
[02:22] <lifeless> maxb: zope
[02:24] <lajjr> lp-branches lp-sourcedeps
[02:24] <lajjr> nd the script rocketfuel-setup
[02:25] <lajjr> s/nd/and
[02:25] <jml> maxb, we're very close to being able to switch to a more modern python.
[02:26] <thumper> and we can't wait
[02:26] <jml> which will be great for those of us who use karmic.
[02:26] <jml> thumper, indeed :)
[02:28] <ajmitch> jml: given the sort of people who are probably likely to grab a copy of the launchpad source, running on karmic may be a good thing :)
[02:29] <jml> ajmitch, yeah
[02:29] <jml> ajmitch, I'm running in a hardy chroot atm, which is working out ok
[02:29] <ajmitch> it'd save me trying to dig around in makefiles to get simple things like bin/py
[02:29] <jml> ajmitch, but I have a screwed up postgres config which is causing difficulties.
[02:30] <ajmitch> I should probably setup something in kvm anyway
[02:32] <lifeless> one consideration is that we deploy on LTS
[02:32] <thumper> spm: is there going to be a staging update before rollout?
[02:32] <lifeless> so we need to keep working there regardless of the current ubuntu development status
[02:33] <mwhudson> maxb: i bet most blobs of python code as large as launchpad end up fairly tied to a specific python version
[02:34] <mwhudson> jml: looking
[02:34] <jml> mwhudson, thanks.
[02:34] <jml> it takes more work than one might think to support more than one python version reliably.
[02:35] <jml> guh.
[02:35] <mwhudson> it's like 0.0001 units of aggravation per line of code or something
[02:35] <jml> so distracted that I have a half written item in my todo list :\
[02:35] <jml> mwhudson, what is the SI unit for aggravation anyway?
[02:36] <mwhudson> jml: i don't know, i'm sure we can come up with something suitably offensive
[02:36] <mwhudson> jml: the BSOD ?
[02:36] <mwhudson> jml: "the openoffice" ?
[02:36] <jml> hahaha
[02:36] <lifeless> jml: I dunno, we do 2.4/2.5/2.6 quite easily in bzr
[02:37] <lifeless> jml: the clippy
[02:37] <jml> lifeless, I think that's the imperial unit.
[02:37]  * mwhudson plays the "is my code on staging yet" game
[02:37] <mwhudson> lifeless: have you seen http://www.ntk.net/doh/options.html ?
[02:37] <jml> lifeless, I bet you had to change code to support 2.5 and 2.6.
[02:38] <lifeless> jml: yes, but it was pretty painless, and we don't routinely have trouble with new code
[02:38] <lifeless> mwhudson: classic, and no, I hadn't
[02:39] <mwhudson> lifeless: one of the funniest things on the internet i think :)
[02:39] <mwhudson> Annoy me with that sodding paperclib:
[02:39] <mwhudson> ( ) all the time
[02:39] <mwhudson> (*) when i least expect it
[02:43] <spm> thumper: staging restore: Wed Jul 22 02:17:56 BST 2009 Lock file deleted. Script finished
[02:44] <thumper> spm: when was that?
[02:45] <thumper> like half an hour ago?
[02:45] <spm> yup
[02:45] <thumper> spm: but staging is revno 8298, and I need 8301 :(
[02:46] <thumper> spm: why did staging come up with old code?
[02:46] <mwhudson> erm
[02:46] <spm> thumper: mainly as the actual code side happened about 12 hoursish ago
[02:46] <mwhudson> is stable still being merged into db-devel
[02:46] <mwhudson> ?
[02:47] <thumper> :(
[02:47] <thumper> mwhudson: it should be
[02:47] <thumper> 1 failure on db_lp builder
[02:47] <thumper> :(
[02:47] <spm> thumper: I lie. code was updated ~ Tue Jul 21 21:27:44 BST 2009
[02:48] <thumper> WTF?
[02:48] <thumper> why is the doc test printing out javascript code??!?!
[02:49] <mwhudson> lol
[02:49] <mwhudson> i need to test the revision _after_ what is running on both staging and edge
[02:49] <thumper> damn sprite!
[02:50] <thumper> beuno: was that you?
[02:50] <jml> mwhudson, my script says there's 1 revision in devel not in stable, and 4 in db-devel that aren't in db-stable
[02:50] <jml> mwhudson, but that stable & db-devel are up to dae
[02:50] <mwhudson> jml: cool, i was confused for a few minutes, but i've got it figured out now, i think
[02:51] <lajjr> kernel update caused a reboot. lol
[02:55]  * jml has a buildout moment
[02:56] <mwhudson> jml: i made a branch earlier, buildout broke and the easiest thing to do seemed to be to throw away the branch and start again
[02:59] <jml> :\
[02:59] <jml> mwhudson, sometime after the release, we need to make sure that sourcecode/bzr never ever gets created an automated process
[03:00] <jml> mwhudson, there's a great well of hidden errors just waiting to bite us there.
[03:00] <mwhudson> jml: maybe there should be an engineer devoted to working on these things for an entire cycle!
[03:01] <mwhudson> jml: we need to be careful we never import the system bzr somehow too
[03:01] <mwhudson> (god knows how)
[03:01] <jml> mwhudson, hmm.
[03:02] <jml> mwhudson, we could make all of launchpad a bzr plugin & use bzr's api thing
[03:02] <mwhudson> jml: i admit that wasn't a suggestion i was expecting!
[03:02] <jml> mwhudson, :)
[03:04] <lifeless> I likes it
[03:10]  * mwhudson finds canonical.launchpad.scripts.logger.BufferLogger, finds it to be a piece of crap
[03:11] <jml> :)
[03:14] <kfogel> beuno: so what happened with your laptop yesterday?  Did you ever get it working again?
[03:20] <kfogel> sinzui: I changed bug #386797 to invalid; hope that was okay.
[03:20] <ubot3> Malone bug 386797 in launchpad-foundations "Enable distributed content development" [Undecided,Invalid] https://launchpad.net/bugs/386797
[03:21] <sinzui> kfogel: not at all
[03:23] <kfogel> sinzui: not okay?
[03:23] <kfogel> :-)
[03:23] <kfogel> sinzui: "not at all" is ambiguous in this context, but I assume you meant "no problem at all"
[03:24] <sinzui> kfogel: it is okay. Francis would ignore it for a few years. I even suggested that he spend a day Triaging bugs because he could close 50 of them
[03:24]  * jml instruments
[03:24] <jml> closing 50 bugs would be nice
[03:25] <sinzui> Since foundations was the old Launchpad, Francis could easily transfer 50 bugs to each our our porjects
[03:25] <jml> that would be less nice
[03:25] <kfogel> sinzui: I've been a bit hands off about triaging bugs, not knowing if I should be making decisions like that.  Should I be a bit more aggressive and assume that mistakes can be corrected?
[03:26] <sinzui> We should be honest
[03:26] <sinzui> If we really don't intend to do it, close it
[03:26] <thumper> jml: how about: BranchCollection.getTeamsWithBranches(person):
[03:26] <thumper>         """Return the Teams that person is a member of that have branches."""
[03:26] <kfogel> sinzui: agreed.  It's not like the record of the conversation is lost if we close it anyway.
[03:27] <sinzui> Every bug in blueprint, launchpad-answers, and launchpad-registry really should be fixed or implemented. I wish that was true of foundations
[03:27] <spiv> kfogel: right.  The cost of a mistake there is pretty low.  The worst is probably offending the reporter, which is a pretty bad thing to do, but ignoring their report is probably just as bad...
[03:27] <jml> thumper, what's the question exactly?
[03:27] <thumper> jml: comments on a BranchCollection method to return a result set of People
[03:27] <jml> thumper, ahh ok.
[03:28] <thumper> jml: good or not?
[03:28] <thumper> jml: it'd use the _getBranchIdQuery
[03:28] <jml> thumper, my spider sense is tingling
[03:28] <jml> thumper, why do you want it?
[03:28] <thumper> jml: mostly, but tweak for owner
[03:28] <thumper> jml: we need to be able to get the teams that have branches in a given collection for a person quickly
[03:28] <thumper> jml: one query rather than one query per team
[03:29] <thumper> jml: beuno is in 86 teams, and the query is taking 150ms ish
[03:29] <jml> thumper, is this to generate links from the Person branch listing?
[03:29] <thumper> jml: yes
[03:30] <jml> thumper, I feel that it's something of a violation of the spirit of the interface, but I don't have any better ideas right now.
[03:30] <thumper> jml: we already have branch collection returning branches and merge proposals
[03:30] <thumper> jml: we could add a new utility somewhere
[03:30] <thumper> jml: not sure what to call it though
[03:31] <jml> thumper, returning branches is its raison d'etre, and merge proposals are a pretty natural follow on.
[03:31] <thumper> jml: yeah, I know
[03:32] <thumper> jml: but not sure how to get at the collection internals without it being a method on the collection itself
[03:32] <jml> thumper, yeah. me neither.
[03:32] <jml> thumper, I think just put it in there for now, making a comment about how it doesn't quite fit.
[03:32] <thumper> jml: ok
[03:33]  * jml idly wonders why 'reason for being' lacks punch in English.
[03:34] <spiv> jml: "to be or not to be"?
[03:37] <thumper> spiv: that isn't punchy either
[03:43] <jml> instrumenting code :(
[03:46] <jml> mwhudson, I wonder.
[03:47] <jml> mwhudson, how would monkey patching and lazr imports interact, do you think?
[03:47] <mwhudson> jml: lazy imports?
[03:47] <jml> mwhudson, yes.
[03:47] <jml> sorry.
[03:47] <mwhudson> jml: i guess it could get exciting
[03:47] <mwhudson> jml: does ScopeReplacer implement __setattr__ ?
[03:48] <mwhudson> jml: i think i guess where you're coming from
[03:48] <thumper> lazr imports?
[03:48] <jml> thumper, lazy.
[03:48] <mwhudson> jml: lp-serve not logging oops?
[03:48] <thumper> jml: sorry, read that just after hitting enter
[03:48] <jml> mwhudson, I can't hide anything from you, can I? :)
[03:49] <mwhudson> jml: lazy imports --- day before release --- monkey patching --- talking about test plans earlier
[03:49] <mwhudson> jml: it wasn't _that_ hard :)
[03:50] <mwhudson> oh and this brain wave sensor
[03:50]  * jml throws away his aluminium foil hat
[03:50] <jml> I knew it. It *has* to be tin. This one's no good.
[03:50] <thumper> jml: go get your cowboy hat :)
[03:55] <jml> mwhudson, I now have solid evidence that the monkeypatched version is not being called.
[03:55] <jml> mwhudson, what is this ScopeReplacer of which you speak?
[03:55] <mwhudson> jml: it's an implementation detail of lazy imports
[03:55] <mwhudson> bzrlib.lazy_import
[03:56] <jml> oh. bzr-grep usage fail
[03:57] <jml> mwhudson, it looks like it implements __setattr__ beautifully.
[03:58] <mwhudson> jml: new theory required then
[03:58] <jml> dammit. going to have to do this the Right Way.
[03:58] <thumper> damn storm compilation problems
[03:58]  * thumper smacks head on thetable
[03:59] <jml> mwhudson, I think I have a new theory.
[03:59] <mwhudson> jml: does something somewhere do "from bzrlib.trace import log_exception_quietly" ?
[03:59] <jml> mwhudson, bzrlib.smart.protocol imports 'log_exception_quietly' directly from bzrlib.trace before it gets patched
[03:59] <mwhudson> jml: arghlbargl
[03:59] <jml> mwhudson, ...
[04:00] <jml> mwhudson, so I can shuffle around some code, probably.
[04:01] <mwhudson> statement: SELECT Branch.id, Branch.unique_name FROM Branch WHERE false AND Branch.private = false
[04:01] <jml> mwhudson, or I can abandon this approach and do it the right way by giving bzr the appropriate hooks.
[04:01] <mwhudson> that's not a very useful query
[04:01] <jml> no, 'tisn't.
[04:01] <mwhudson> i wonder why storm is generating it
[04:01] <mwhudson> jml: i think the time may have come for the right way
[04:02] <mwhudson> oh ffs
[04:02] <jml> mwhudson, ok. I'll file bugs appropriately and prepare a patch for bzr
[04:03] <mwhudson> jml: cool
[04:03] <jml> mwhudson, the code I've already written in Launchpad was deliberately designed to be easy to switch to hooks
[04:03] <jml> so I should only have to change one or two functions & probably none of the tests.
[04:04] <mwhudson> jml: yay
[04:04]  * jml -> lunch etc.
[04:32] <mwhudson> http://pastebin.ubuntu.com/224061/ :(
[04:38] <thumper> mwhudson: eh?
[04:38] <mwhudson> thumper: circular import
[04:38] <thumper> mwhudson: I think I know why
[04:38] <mwhudson> yeah
[04:38] <thumper> mwhudson: you need to import canonical.launchpad.database first
[04:38] <mwhudson> import * is evil
[04:38] <thumper> it blows
[04:39] <thumper> that it is
[04:39] <mwhudson> bug 402845
[04:39] <ubot3> Malone bug 402845 in launchpad-registry "./bin/py -c 'from lp.registry.model import person' fails due to circular import" [Undecided,Triaged] https://launchpad.net/bugs/402845
[04:39] <mwhudson> thumper: removing import *s from canonical.launchpad.database will help i think
[04:39] <thumper> mwhudson: yeah, but likely to be a world of hurt
[04:39] <thumper> mwhudson: it was a PITA when I did the code ones
[04:39] <thumper> mwhudson: all the page tests :(
[04:40] <mwhudson> thumper: maybe only a continent of hurt
[04:40] <thumper> mwhudson: an Australia of hurt
[04:44] <mwhudson> thumper: want to review https://code.edge.launchpad.net/~mwhudson/launchpad/much-faster-rewrite-map/+merge/9121 ?
[04:44] <mwhudson> lifeless: you might be interested too
[04:44]  * thumper looks
[04:45] <thumper> awaiting diff
[04:45] <lifeless> mwhudson: not really, unless its different than we discussed
[04:45] <lifeless> mwhudson: does it nuke the cache?
[04:45] <mwhudson> fair enough
[04:45] <mwhudson> lifeless: what do you mean?
[04:45] <mwhudson> it still caches
[04:46] <lifeless> how fast is a miss now?
[04:46] <mwhudson> but cache misses are done via 1 direct query
[04:46] <mwhudson> lifeless: < 1 ms i hope
[04:46] <lifeless> thats pretty good
[04:46] <lifeless> I'd really like to nuke the cache
[04:46] <lifeless> or get a stream of updates from the db
[04:47] <lifeless> thats 300K RPS we can serve @ 1ms per query
[04:47] <lifeless> sorry, 300K Requests/5minutes
[04:47] <lifeless> only 7 times our peak yesterday :)
[04:48] <mwhudson> lifeless: i imagine stub would like the database to be able to do something else as well as serve these requests
[04:48] <mwhudson> i guess we'd only peg a core at worst
[04:48] <lifeless> at 1ms each we won't even come close to pegging a core
[04:49] <lifeless> even at yesterdays peak
[04:49] <mwhudson> lifeless: i think there's a good case for a very short cache, because of ".bzr/smart, .bzr/branch-format, .bzr/branch/format"
[04:49] <stub> If it is a problem, we can get a dedicated db for this. I'd also consider if memcache is a good solution - we know we need it in other areas, we just need to integrate it all into the test suite so it is easy to use.
[04:49] <lifeless> mwhudson: I think theres a strong argument for truncating the mapping at .bzr
[04:50] <lifeless> mwhudson: because everything to the right is bzr internals
[04:50] <mwhudson> lifeless: what?
[04:50] <lifeless> the rewriter doesn't need to map foo/.bzr/baz
[04:50] <lifeless> only foo/
[04:50] <mwhudson> right
[04:50] <mwhudson> lifeless: maybe you should look at the code?
[04:50] <lifeless> hmm, also backup.bzr
[04:50] <lifeless> and .backup.bzr
[04:50] <lifeless> mwhudson: perhaps
[04:51] <lifeless> mwhudson: right now, I am trying to finish fixing iter_changes
[04:51] <mwhudson> lifeless: also codebrowse!
[04:51] <stub> I'm still unsure why we need to do substring matching (WHERE foo IN ('a', 'aa', 'aa/a', 'aa/aa') rather than splitting the path on '/' and looking for WHERE foo in ('aa', 'aa/aa')
[04:51] <mwhudson> lifeless: fair enough
[04:51] <lifeless> mwhudson: doesn't codebrowse map itself?
[04:51] <mwhudson> lifeless: only when the request gets to codebrowse...
[04:51] <mwhudson> stub: we don't
[04:52] <mwhudson> stub: my code splits on '/'
[04:52] <stub> ok
[04:52] <mwhudson> stub: splitting on characters is actually wrong as well as just inefficient
[04:52] <lifeless> mwhudson: if my looking at the patch will help you, I will
[04:52] <lifeless> otherwise I trust in review :)
[04:53] <mwhudson> lifeless: ok
[04:54] <mwhudson> lifeless: i only suggested you looked (the second time) because you kept asking questions :-p
[04:54] <lifeless> :)
[04:55] <thumper> mwhudson: -> #launchpad-reviews
[04:57] <stub> Getting rid of the cache or using a shared cache like memcache is needed to avoid weirdness when we scale horizontally - you don't want two different requests accessing different branches because they where served by different Apache's.
[04:58] <stub> I guess we have that problem already though if someone renames a branch.
[04:59] <mwhudson> thumper: i'm there
[05:10]  * wgrant juat managed to convince his local Launchpad to accept a PPA upload, publish it, build it, accept the binaries, and publish them.
[05:10] <spiv> wgrant: woo!
[05:10] <ajmitch> wgrant: great, how much did that take to setup?
[05:10] <ajmitch> & have you documented whatever's missing for the rest of us?
[05:11] <wgrant> ajmitch: I've got notes here.
[05:11] <wgrant> It took a while, as there are almost no docs around...
[05:11] <wgrant> And there are some nice obscure bits.
[05:13] <wgrant> One particularly time-consuming bit was working out why my builds weren't being dispatched. Apparently they will only be dispatched if there is a source published in the archive.
[05:13] <wgrant> Which doesn't make too much sense.
[05:13] <lifeless> well
[05:13] <lifeless> it does, when you consider NEW
[05:15] <wgrant> But we build from ACCEPTED now.
[05:15] <wgrant> I have a suspicion as to why it's like that.
[05:15] <wgrant> But I need to find the bug report...
[05:15] <lifeless> ok, you're the expert :P
[05:17] <wgrant> OK, no, it wasn't what I thought.
[05:27] <Ursinha> just realized today it's exactly one year I joined lp team
[05:27] <thumper> Ursinha: congrats
[05:28] <jml> hello again
[05:28] <Ursinha> thumper, thanks :)
[05:28] <jml> Ursinha, grats.
[05:28] <jml> Ursinha, time flies when you're having fun :)
[05:28] <Ursinha> jml, thanks
[05:28] <Ursinha> jml, well said
[05:28] <Ursinha> I'll quote you in my blog post :P
[05:29] <jml> haha
[05:29] <jml> oh, that reminds me.
[05:29] <jml> what's so funny about ultimo.fm?
[05:29] <Ursinha> jml, lol
[05:29] <Ursinha> jml, that was a bad translation, because last == ultimo in portuguese
[05:30] <Ursinha> but last.fm isn't translatable... :)
[05:30] <jml> Ursinha, I thought it might be something like that :)
[05:30] <Ursinha> jml, :)
[05:44]  * thumper goes to make veggie curry
[05:57] <wgrant> ajmitch: http://williamgrant.id.au/f/1/2009/soyuzness.html
[05:57] <wgrant> Some of that was done some time afterwards, so there might be issues.
[05:57] <ajmitch> nice, thanks
[06:02] <mwhudson> wgrant: wow, very determined of you
[06:03] <wgrant> mwhudson: It looks harder than it is.
[06:03] <jml> some of that should probably be turned into patches.
[06:03] <wgrant> I suspect so.
[06:04] <wgrant> A fair bit of stupidity is needed because the sample data is prehistoric, but I guess that's not easily fixable due to the tests.
[06:04] <wgrant> But a lot of that can go into rocketfuel-setup.
[06:04] <jml> wgrant, the sampledata used by the development config is separate from that used by the testrunner config
[06:04] <wgrant> jml: Oh.
[06:04] <wgrant> Useful.
[06:05] <jml> wgrant, I think if you just get your dev environment set up with the right sampledata & run 'make newsampledata', you should be close to done
[06:05] <jml> I think
[06:05] <jml> it's been a while since I've touched the sampledata, as you can tell.
[06:06] <ajmitch> current-dev.sql?
[06:06] <jml> yeah
[06:06] <ajmitch> I only took a brief look in there, so wasn't sure which to use
[06:07] <wgrant> It seems I should have read database/sampledata/README. It explains all.
[06:08] <jml> I'll gladly review & merge patches that make our docs better / more discoverable.
[06:10] <wgrant> I might run make check tonight to see how long it takes on my laptop...
[06:10] <ajmitch> wgrant: I take it you're doing all this on jaunty?
[06:10] <wgrant> ajmitch: In a Jaunty chroot, yes.
[06:11] <wgrant> Since that was easier than convincing LP to work on Karmic, I suspect.
[06:11] <ajmitch> yes, I've tried a little with it on karmic, didn't get far & didn't really expect to anyway
[06:12] <wgrant> have you tried it on Jaunty?
[06:12] <wgrant> I think rocketfuel-setup should Just Work now.
[06:12] <ajmitch> not yet, I'd rather set it up on a fresh apache & postgres
[06:13] <wgrant> That's what schroot and KVM are for.
[06:14] <ajmitch> yep, I just didn't have time last night after waiting for it all to download
[06:14] <jml> I couldn't get Launchpad running on karmic either, fwiw.
[06:15] <ajmitch> jml: various packages have had their python 2.4 support removed
[06:15] <jml> yeah.
[06:15] <wgrant> I didn't try very hard. Once I saw rocketfuel-setup fail to install launchpad-developer-dependencies from ~launchpad's PPA, I dropped into a chroot.
[06:15] <wgrant> ajmitch: I'm not sure many more have in karmic than in jaunty.
[06:15] <ajmitch> probably not many
[06:15] <jml> well, I tweaked python-support to build for 2.4
[06:15] <ajmitch> but I got to the point of it failing to do anything with bin/py
[06:15] <jml> but not all of our deps use python-support
[06:16] <wgrant> Doing it in a chroot is probably a good idea anyway, as it does like to put stuff everywhere.
[06:17] <ajmitch> so I noticed
[06:17] <ajmitch> I'll have to take care not to destroy the current postgres data I have
[06:18] <jml> another thing we'd like to do is make it so we can run more than one instance of the test suite on the same machine
[06:19] <jml> partly because it's a laudable goal in itself, partly so we can use more than one core
[06:23]  * al-maisan has installed the LP development environment in a (hardy) chroot as well; works like a charm :)
[06:23] <jml> al-maisan, my postgres config is a little dodgy still
[06:23] <jml> probably my fault.
[06:23] <al-maisan> jml: aha
[06:23]  * wgrant now tries to work out how to use gina.
[06:23] <jml> I think it's because my karmic postgres & hardy postgres want the same resources.
[06:24] <al-maisan> jml: like ports..?
[06:24] <jml> al-maisan, yeah, and pid files maybe
[06:24]  * jml hasn't investigated.
[06:24]  * mwhudson is EODing soon, shout if you want me to do anything today...
[06:25]  * al-maisan installed the chroot according to https://wiki.ubuntu.com/DebootstrapChroot and has no issues with postgres
[06:25]  * ajmitch would suggest supplying beer, but it's probably a little far
[06:28] <al-maisan> jml: the PID files are kept here:
[06:28] <al-maisan> CHROOT db-devel $ l /var/run/postgresql/
[06:28] <al-maisan> 8.3-main.pid  .s.PGSQL.5433=  .s.PGSQL.5433.lock
[06:28] <al-maisan> .. and the chroot has it's own /var partition
[06:29] <al-maisan> the config files are here:
[06:29] <al-maisan> CHROOT db-devel $ l /etc/postgresql/8.3/main/
[06:29] <al-maisan> environment  pg_hba.conf  pg_ident.conf  postgresql.conf  start.conf
[06:32] <jml> al-maisan, thanks.
[06:33] <al-maisan> jml: hope it helps :)
[07:19]  * jml moves closer to a power point
[07:52] <stub> Anyone in this time zone who can give me a release-critical?
[07:54] <jml> stub, no.
[07:54] <jml> stub, kiko will be probably be awake soonish.
[07:56]  * jml makes a note to change getAnyPocket to return something other than release
[07:57] <wgrant> Is any particular HTML documentation generator favoured?
[07:58] <jml> wgrant, for API docs?
[07:59] <jml> wgrant, pydoctor for API docs, sphinx for other docs
[07:59] <wgrant> jml: Right.
[07:59] <wgrant> I don't see a make target, so I guess just run it manually?
[07:59] <jml> wgrant, mwhudson wrote pydoctor, and might well have a recipe somewhere.
[07:59] <jml> wgrant, probably run it manually -- I've never tried on Launchpad.
[08:00] <jml> wgrant, I'd be very excited to see a make target though. I just added one to GTG.
[08:00]  * jml pokes around a bit
[08:07] <jml> there are up-to-date api docs online, just not public (yet)
[08:07] <mwhudson> i guess i should move that onto people.canonical.com
[08:08] <jml> mwhudson, is that the same thing as people.ubuntu.com?
[08:08] <mwhudson> jml: yes
[08:15] <wgrant> jml, mwhudson: Ah, I see.
[08:15] <wgrant> They might be useful.
[08:15] <wgrant> There's a lot of code.
[08:15] <jml> you noticed :)
[08:16] <jml> oh that reminds me, I should put bzr-tools.el on the wiki.
[08:17] <jml> wgrant, 'make tags' can also help a lot for navigating the code
[08:17] <kfogel> wgrant: have you built Launchpad yet?
[08:18] <kfogel> (I might be missing backscroll, just got back from afk.)
[08:18] <wgrant> kfogel: Oh yes, I had the webapp working after a bit over 3 hours.
[08:19] <wgrant> I've even had Soyuz bits working today.
[08:19] <noodles775> wgrant: nice!
[08:19] <wgrant> And I'm currently trying to work out how to run a local keyserver.
[08:19] <kfogel> wgrant: er, well, you took less time than I did to do that, and I work for Canonical.  Hats off!
[08:20] <kfogel> hey adeuring
[08:20] <noodles775> kfogel: but wgrant had already deduced most of the launchpad innards a long time ago ;)
[08:20] <wgrant> noodles775: I ended up getting a full upload, build, publish working.
[08:20] <adeuring> hi kfogel
[08:20] <noodles775> wgrant: cool!
[08:21]  * wgrant 
[08:22] <wgrant> Oops.
[08:26] <wgrant> noodles775: Any idea how I'm meant to run zeca/buildd-master? I've been running them manually with twistd for now - some other daemons are registered in canonical.launchpad.scripts.runlaunchpad, so are runnable with bin/run, but not those.
[08:26] <jml> noodles775, hi :)
[08:27] <jml> I just realized that by cunningly getting distracted in the middle of the day I'm in prime-time to get help from soyuz folks for this patch :)
[08:28] <noodles775> wgrant: we don't (at least, I haven't) run the build master et al locally... for local development we usually just depend on the testing infrastructure (see SoyuzTestPublisher), and then test on dogfood...
[08:28] <noodles775> wgrant: but cprov will undoubtedly know more.
[08:28] <noodles775> jml: hi! Which patch?
[08:29] <wgrant> noodles775: Hm, OK.
[08:29] <jml> noodles775, bug 345737
[08:29] <ubot3> Malone bug 345737 in launchpad-code "lp:ubuntu/package should resolve" [High,In progress] https://launchpad.net/bugs/345737
[08:29] <jml> noodles775, sorry, bug 347768
[08:29] <ubot3> Malone bug 347768 in launchpad-code "Allow anyone with upload rights to write to a package branch" [High,Triaged] https://launchpad.net/bugs/347768
[08:30] <noodles775> wgrant might want to look too...
[08:30] <noodles775> oh, you're already subscribed by default, so have probably already seen it ;)
[08:31] <gmb> Good morning ladies, gentlemen and variations thereupon.
[08:31] <jml> I'm not stuck yet. just poking around trying to find how to allow someone to upload to a package.
[08:31] <wgrant> jml: archivepermission is the magic thing.
[08:32] <wgrant> And they're manipulated on IArchive, at least through the webservice...
[08:32]  * wgrant needs to poke around inside the code.
[08:33] <noodles775> jml: why do you want to allow someone to upload a package? don't you just need to check whether someone has permission to upload a package?
[08:34] <pkern> wgrant: Ah, thanks for poking there.
[08:34] <al-maisan> jml: there are 3 types of archive permissions: based on components, source package names and (new!) package sets.
[08:34] <wgrant> pkern: Where?
[08:34] <noodles775> ... and I was about to say, al-maisan is the person to speak to there (having just implemented the new package set permissions)
[08:34] <jml> excellent
[08:35] <jml> al-maisan, so, my mission is to make it such that if you can upload to a package, then you can write to any branch officially linked to that package.
[08:35] <noodles775> al-maisan: is it possible for us to abstract away the fact that there are currently 3 different ways? Or perhaps we already do?
[08:35] <jml> al-maisan, to do this, I need an API for checking to see whether a person can write to a package
[08:35] <jml> and a way of granting such permissions.
[08:35] <al-maisan> jml: that API already exists
[08:35] <jml> (the latter being for unit tests)
[08:35] <al-maisan> let me find it for you.
[08:35] <jml> al-maisan, thanks.
[08:36] <pkern> wgrant: Into the upload rights code. ;-)
[08:36] <wgrant> pkern: Ah.
[08:36] <wgrant> pkern: What did you end up doing with Soyuz?
[08:36] <jml> thumper, why is bug 243135 invalid?
[08:36] <ubot3> jml: Bug 243135 on http://launchpad.net/bugs/243135 is private
[08:38] <al-maisan> jml: IArchive.getPermissions() is the method you'd want to use.
[08:38] <wgrant> al-maisan: Why not IArchive.canUpload?
[08:39] <jml> or check_permissions(sourcepackage, 'launchpad.Edit') for that matter
[08:39] <jml> al-maisan, thanks, looking now.
[08:40] <al-maisan> wgrant: IIRC Archive.canUpload() only operates on components .. but let me look again.
[08:41] <wgrant> al-maisan: component_or_package, it takes.
[08:46] <al-maisan> wgrant: canUpload() eventually invokes getPermissions()
[08:47] <jml> al-maisan, next question, why not check_permissions(sourcepackage, 'launchpad.Edit')?
[08:48] <al-maisan> jml: let me have a look.
[08:48] <jml> thanks.
[08:48] <wgrant> There's no ArchiveSourcePackage, is there?
[08:51]  * gmb achieves inbox 4, is satisfied
[08:51] <maxb> Has anyone else struggled to make LP work on jaunty because of apt installing a broken python2.4 installation? It doesn't seem to have installed any of the python-support/central stuff for the new runtime, and the sys.path doesn't include any directories in /usr/lib !
[08:52] <wgrant> maxb: I haven't seen that - I installed it in a fresh Jaunty chroot last night, and it worked fine (except for the other issues)
[08:53] <maxb> hrm :-/
[08:53] <gmb> maxb: How far have you got with trying to run LP? The LP buildout process creates a bin/py executable with the right sys.path. It also builds all the eggs that you need inside the Launchpad tree rather than polluting your site-packages.
[08:53] <gmb> maxb: Try apt-get reinstall launchpad-developer-dependencies, see if that helps any.
[08:53] <maxb> No, I think it's actually my system install of python that's broken
[08:54] <maxb> python2.4 -c 'import sys; print sys.path'  is missing lots of things which should be there
[08:54] <gmb> Hmm.
[08:54] <maxb> even after purging and reinstalling the package
[08:55] <wgrant> maxb: You even purged python2.4-minimal?
[08:55] <maxb> yup
[08:55] <wgrant> Huh.
[08:55] <maxb> my thought
[08:55] <maxb> meh
[08:55] <maxb>  * my thoughts exactly :-)
[08:56] <al-maisan> jml: check_permission() uses checkPermission() zope.security.management .. how does one configure or hook into the latter?
[08:56] <jml> al-maisan, canonical.launchpad.security is scanned automagically
[08:56] <jml> hmm. and maybe there's some zcml
[08:57]  * al-maisan looks at ./lib/canonical/launchpad/security.py
[08:57] <jml> there's IPackageUpload and IPackageUploadQueue in there
[08:58] <jml> and launchpad.Append on IArchive
[09:02] <al-maisan> jml: hmm .. it looks like the piece you'd like to have still needs to be added to lib/canonical/launchpad/security.py .. sorry
[09:02] <jml> al-maisan, no worries.
[09:04] <jml> al-maisan, I'd be happy to add it, but I'm not sure exactly what to make it do.
[09:04] <jml> bigjools, hello
[09:04] <bigjools>  /away
[09:04] <bigjools> morning!
[09:04] <jml> bigjools, we're just talking about fixing bug 347768
[09:04] <ubot3> Malone bug 347768 in launchpad-code "Allow anyone with upload rights to write to a package branch" [High,In progress] https://launchpad.net/bugs/347768
[09:04] <bigjools> ok
[09:05] <al-maisan> morning bigjools
[09:05] <jml> trying to figure out the best way of asking whether a person has upload rights to a package, and how to grant them said rights (for testing)
[09:06] <bigjools> there's a few checks done in the upload processor
[09:07] <bigjools> unfortunately there's no single call that will give you a yes or a no
[09:07] <jml> bigjools, lp.soyuz.scripts.soyuz_process_upload being the starting point, right?
[09:07]  * bigjools stabs Firefox and the xorg intel driver
[09:07] <jml> bigjools, karmic upgraded the intel driver today. :)
[09:08] <bigjools> jml: no, IArchive.canUpload()
[09:08] <bigjools> let me refresh my memory and then I can talk more sense
[09:08] <jml> bigjools, how do I get to that from an ISourcePackage?
[09:08] <bigjools> and possible reboot
[09:08] <jml> bigjools, cool, thanksn.
[09:09] <bigjools> jml: well you need to know which archive you're uploading to
[09:09] <bigjools> presumably it's based on a distro, do you can use IDistribution.main_archive
[09:09] <bigjools> but that obviously only covers the case where you want to upload to, well, the main archive :)
[09:10] <bigjools> argh, fscking FF and xorg both using over 1Gb resident
[09:10] <wgrant> bigjools: Karmic?
[09:10] <bigjools> jaunty
[09:11] <wgrant> Ah. That would be your problem.
[09:11] <jml> bigjools, that's probably what we want here.
[09:11] <jml> bigjools, since these are for official package branches for a distroseries, pocket.
[09:11] <bigjools> I tried the karmic kernel and xorg driver  a month aho and it was no better
[09:12] <thumper> jml: because the tests aren't there any more :)
[09:12]  * thumper thinks...
[09:12] <bigjools> jml: great, so the next thing to work out is whether there are package-specific permisssions, component-specific permissions then packageset permissions
[09:12] <jml> thumper, yeah. I checked.
[09:12] <jml> thumper, and at their new location, the test modules have been correctly factored.
[09:12] <jml> thumper, so it's a little more fix released than invalid.
[09:13] <jml> thumper, but no big deal.
[09:13] <al-maisan> bigjools: I understood jml merely wants a yes/no answer..
[09:13] <jml> yes.
[09:13] <jml> what al-maisan said :)
[09:13] <bigjools> that's not possible
[09:13] <bigjools> like I already said
[09:13] <jml> ok.
[09:13] <thumper> jml: changed to make you feel better :)
[09:14] <jml> thumper, you're a champ. :)
[09:14] <al-maisan> bigjools: assuming jml knows the destination archive, IArchive.canUpload() should provide the yes/no answer ..
[09:14] <bigjools> al-maisan: no, it can't
[09:14] <al-maisan> please explain.
[09:14] <bigjools> you also need to know the package name, a component name or a packageset
[09:15] <bigjools> you only don't need those if you have a PPA
[09:15] <al-maisan> ah, right.
[09:15] <jml> bigjools, we have the package name, since we have an ISourcePackage.
[09:15] <bigjools> jml: that's a good start :)  but not enough yet
[09:15] <bigjools> you also need to know which component it's headed for
[09:15] <bigjools> and you have to check both
[09:15]  * jml buckles up and sits tight.
[09:16] <bigjools> so start with canUpload(user, package_name)
[09:16] <bigjools> if it works, great
[09:16] <bigjools> if it doesn't, you need to use canUpload(user, component)
[09:16] <jml> bigjools, if I know the distroseries & sourcepackagename, can I can derive the component?
[09:16] <bigjools> yes
[09:16] <bigjools> you need to work out where it's published
[09:16] <bigjools> that was where I was going next :)
[09:17] <bigjools> jml: I'll point you at example code
[09:17] <jml> how bout I just sit quiet for a bit then? :)
[09:17] <bigjools> lib/lp/archiveuploader/nascentupload.py
[09:17] <bigjools> verify_acl() does the upload checks
[09:18] <al-maisan> bigjools: that's a great pointer!
[09:18] <bigjools> jml: you need to know which pocket it's being uploaded to as well, you have a suite somewhere IIRC?
[09:18]  * jml looks
[09:18] <jml> bigjools, yep.
[09:19] <BjornT_> jml: you can also look at BugNomination.canApprove(), which does similar check (except that it doesn't check for packagesets yet)
[09:19] <jml> http://paste.ubuntu.com/224163/
[09:19] <bigjools> jml: ok so you need to look up the SPPH for that package/pocket
[09:19] <bigjools> BjornT_: you need to fix that for karmic :)
[09:19] <jml> that's the test I'm halfway through writing.
[09:20] <bigjools> jml: distroseries.getPublishedReleases() does that lookup
[09:20] <BjornT_> bigjools: how about finally adding a method that gives you a yes/no answer? ;) this is at least the second time we implement these checks.
[09:20] <bigjools> BjornT_: it's not possible
[09:20] <BjornT_> bigjools: that is, second time outside of soyus
[09:21] <jml> bigjools, and once I get the SPPH
[09:21] <BjornT_> bigjools: why not. how can i and jml get a a yes/no answer if it's not possible?
[09:21] <bigjools> there are three different things to check depending on what data you have
[09:21] <bigjools> and which distroseries it is
[09:21] <bigjools> (after karmic)
[09:22] <bigjools> jml: once you get the spph, you can get spph.component, and pass it to canUpload()
[09:22] <jml> bigjools, how will I know which element from getPublishedReleases to use?
[09:22] <BjornT_> bigjools: both jml (i think at least) and i have an ISourcePackage. i.e., we have a source package in a distro series. all information can be derived from that, can't it?
[09:23] <BjornT_> bigjools: if not, then i'm doing something wrong
[09:23] <jml> BjornT_, I do have an ISourcePackage.
[09:23] <bigjools> BjornT_: you need the pocket as well, but after that yes, we could factor it somewhere
[09:23] <BjornT_> bigjools: how do i know the pocket?
[09:24] <bigjools> BjornT_: it depends on where the package is being uploaded to
[09:24] <bigjools> and is data that you need to supply
[09:24] <BjornT_> bigjools: can the same ISourcePackage be uploaded to multiple pockets?
[09:25] <bigjools> it can exist in multiple pockets
[09:25] <bigjools> it can start in say, security, and be copied to updates
[09:25] <bigjools> wgrant, can you think of an example where something would have a different component in a different pocket?
[09:25] <BjornT_> bigjools: so in what way should i fix BugNomination.canApprove()? it doesn't use pockets at all
[09:25] <bigjools> BjornT_: let me check your code
[09:26] <wgrant> bigjools: It might have been done once, but I don't remember. It was certainly discussed with the archive admins, who talked to one of you guys, who confirmed it was possible with SQL, IIRC. I don't remember if it was actually done.
[09:26] <jml> I see you use latest_published_component
[09:26] <al-maisan> NascentUpload.verify_acl() does not seem to use pockets either ..
[09:26] <jml> BjornT_, ^
[09:27] <wgrant> But that's such a strange case it's not worth caring about for this, I don't think.
[09:27] <bigjools> source_package.latest_published_component is perfect
[09:27] <jml> ok
[09:27] <bigjools> al-maisan: not in that specific place, because it already looked them up
[09:27] <bigjools> al-maisan: see getSourceAncestry()
[09:27] <BjornT_> jml: yes. that's why i'd like a method that accepts an ISourcePackage that does the check for me!
[09:28]  * al-maisan looks
[09:28] <BjornT_> s/check/checks/
[09:28] <jml> BjornT_, I'm inclined to agree.
[09:28] <bigjools> BjornT_, jml: yes, I can add something to do that
[09:28] <jml> But I'd like to get to the end of bigjools's explanation :)
[09:28] <bigjools> aaaaanyway
[09:28] <jml> bigjools, well, I'm happy to do so, since I'm working on this problem now.
[09:28] <bigjools> jml: awesome
[09:29] <jml> check_permission(ISourcePackage, 'launchpad.Edit'), I assume.
[09:29] <bigjools> jml: no, IArchive.<something>
[09:29] <bigjools> let me think a but
[09:29] <bigjools> bit
[09:29] <bigjools> because we are trying to fix the security adapter, it won't work for lp.Append on IArchive right now
[09:32] <bigjools> jml: you could change canUpload() so it takes an optional ISourcePackage
[09:33] <jml> bigjools, AIUI, BjornT_ & I are just going to derive the IArchive instance from the ISourcePackage anyway
[09:33] <bigjools> jml: I think that's a bad idea
[09:34] <bigjools> it's tying everything into a single archive
[09:35] <jml> bigjools, I don't see how we can avoid that.
[09:35] <BjornT_> bigjools: i don't see how we could get the right archive, though. all we have is a distribution/distroseries and a source package name
[09:35] <jml> BjornT_, in my case, I also have a pocket.
[09:35] <jml> and a pocketful of broken dreams
[09:35] <jml> but I don't plan on using them.
[09:35] <bigjools> jml, BjornT_: you have to decide which archive you're uploading to, simple fact.  In most cases it's IDistribution.main_archive
[09:36] <bigjools> but there's no way that should go in the security adapter
[09:36] <bigjools> hard-coded I mean
[09:36] <wgrant> Something like latest_published_archive seems to make sense.
[09:36] <wgrant> Which will be either primary or partner.
[09:37] <bigjools> I don't think it does
[09:37] <jml> bigjools, ok. so how about this:
[09:37] <wgrant> How is it significantly different from latest_published_component?
[09:37] <jml> bigjools, I add a method / function / whatever,
[09:37] <jml> bigjools, it takes an ISourcePackage, an IPerson and an optional IArchive
[09:38] <jml> if IArchive is None, it gets it from source_package.distribution.main_archive or whatever is a sane default.
[09:38] <jml> then it does the black handwavey magic that I'm slowly beginning to understand
[09:39] <jml> bigjools, because, in the design of Bugs and Code, there's absolutely know way of knowing the archive beyond that.
[09:39] <jml> no way.
[09:39]  * jml was correcting spelling, rather than adding emphasis
[09:39] <bigjools> :)
[09:39] <bigjools> so
[09:40] <jml> basically all I've got to work with is the stuff in this string: 'lp:ubuntu/karmic-backports/openssh'
[09:40] <bigjools> at some point, you're going to have source package branches and bugs linked to PPAs
[09:40] <bigjools> you don't right now, so assuming main_archive is fine
[09:41] <lifeless> I'd say the per team package branch would map to that team/persons PPA
[09:41] <bigjools> but don't hack that into soyuz code *please*
[09:41] <lifeless> e.g. my subunit branches
[09:41] <bigjools> yes, either way there's an archive involved
[09:42] <jml> bigjools, I was thinking a method on ISourcePackage, actually. that leaves the assumption at quite a high level, and in exactly one place.
[09:42] <bigjools> wgrant: latest_published_component works because packages are not generally in more than one distro archive at once
[09:42] <BjornT_> bigjools: it feels like there should be some object representing a package in a PPA (or rather, a package in a specific archive), no?
[09:42] <wgrant> bigjools: More than one distro component, you mean?
[09:42] <bigjools> no, archive
[09:43] <jml> BjornT_, that sounds right to me.
[09:43] <jml> (or at least a good question)
[09:43] <al-maisan> for anything that starts with 'lp:ubuntu/..' you'd take the corresponding main_archive; for anything that begins with 'lp:~user/..' you'd fall back to the respective PPA (how about users with multiple PPAs though?)
[09:43] <bigjools> BjornT_: that's called a publication
[09:43] <wgrant> bigjools: How's the archive presence relevant to latest_published_component?
[09:43] <BjornT_> bigjools: isn't that tied to a specific version of the package?
[09:44] <bigjools> wgrant: because when you're looking for the publications, it needs an archive a well
[09:44] <bigjools> BjornT_: right
[09:44] <wgrant> bigjools: Oh, true.
[09:45] <BjornT_> bigjools: what i'm looking for is something like ISourcePackage, or maybe even IDistributionSourcePackage. maybe they should be extended to know which archive they belong to.
[09:45] <al-maisan> I should say for 'lp:<distro>/..' one should take the main_archive ..
[09:46] <bigjools> ISourcePackage should really be named IDistroSeriesSourcePackage !
[09:47] <bigjools> let me think about it for a moment
[09:53] <maxb> How do you properly clean a launchpad source tree, including linked sourcedeps?
[09:54] <bigjools> jml: ok I have a plan
[09:54] <bigjools> maxb: make clean does all of that apart from removing the links
[09:54] <bigjools> which I don't think anything does
[09:55] <jml> bigjools, I'm all ears.
[09:55] <bigjools> jml: we need ISourcePackage.lastest_published which will return a publication
[09:55] <bigjools> then you can do spph.component and spph.archive
[09:55] <bigjools> without duplicating queries
[09:56] <jml> what kind of object is a publication, an IPublication?
[09:56] <bigjools> jml: ISourcePackagePublishingHistory
[09:56] <jml> golly.
[09:56] <jml> I can see why you said 'publication' the first time :)
[09:57] <bigjools> lol
[09:57] <wgrant> At least there isn't still a SecureSourcePackagePublishingHistory still in wide use, although it does seem to still exist :(
[09:57] <bigjools> jml: and reviewers always say to us "why are you using spph as a variable name?"
[09:57] <bigjools> wgrant: yes, it needs ripping out
[09:57] <bigjools> I tried once, and ended up in a world of pain
[09:58] <bigjools> jml: does it make sense to you?
[09:59] <jml> bigjools, ummm. let's go through this again from the top
[09:59] <bigjools> okay
[09:59] <jml> bigjools, I get the latest_published
[10:00] <jml> bigjools, then I ...?
[10:00] <bigjools> can I assume that you have an ISourcePackage already?
[10:00] <wgrant> (I'm glad DistroArchSeriesBinaryPackageRelease isn't spelt out in full)
[10:00] <jml> bigjools, yes!
[10:00] <jml> bigjools, branch.sourcepackage :)
[10:00] <bigjools> poifekt
[10:00] <bigjools> so
[10:01] <bigjools> add a new property to it, latest_published (trivial, just return self._getFirstPublishingHistory
[10:01] <bigjools> then you have in your hands a component and an archive
[10:02] <bigjools> this could be encapsulated inside IArchive.canUpload()
[10:02] <bigjools> if you pass it an ISourcePackage
[10:02] <bigjools> the only thing canUpload doesn't check is packageset permissions, I think I need to ask al-maisan why he didn't change it to do that ...
[10:03] <al-maisan> bigjools: it does .. actually.
[10:03]  * al-maisan checked the sources.
[10:03] <bigjools> it does?  great!
[10:04] <bigjools> al-maisan: but I can't see where
[10:04] <al-maisan> bigjools: what eventually gets called is IArchive.getPermissions() and that does the right thing.
[10:05] <bigjools> yes, I see it now
[10:05] <bigjools> fab
[10:05] <bigjools> jml: so that's it, are you comfortable with it?
[10:05] <jml> bigjools, comfortable enough to start, I think.
[10:06] <bigjools> jml: oh actually you can't put it in canUpload
[10:06] <bigjools> d'oh
[10:06] <bigjools> but it's still easy
[10:06] <jml> I was thinking maybe having a canUploadTo on ISourcePackage or something
[10:06] <jml> something will fall out anyway
[10:07] <bigjools> jml: canUploadToArchive would be good
[10:07] <jml> *nod*
[10:07] <bigjools> anyway I have a call now
[10:07] <bigjools> catcha later
[10:07] <jml> and maybe I can do something to stop the duplication between bugs & code here
[10:07] <bigjools> yes
[10:07] <jml> bigjools, np. thanks for the help.
[10:07] <bigjools> jml: np - ping me again if you need more help
[10:08] <jml> bigjools, will do
[10:08] <jml> although I think I'm going to just jot down some notes from this conversation and then switch to working on my talk for tomorrow evening.
[10:10] <jml> mrevell, hello!
[10:10] <wgrant> Quick visit.
[10:12] <jml> He's an efficient man.
[10:13] <jml> anyway, I'm off home.
[10:13] <bigjools> jml: I can write you a summary
[10:13] <jml> bigjools, you can if you'd like, but I think I'll be right from the logs.
[10:14] <jml> bigjools, putting on the mailing list might help more people than just me though :)
[10:15] <jml> I do have to leave though
[10:15] <bigjools> bye!
[10:15] <jml> al-maisan, bigjools, BjornT_: thanks for the help!
[10:15] <al-maisan> jml: my pleasure :)
[10:23] <wgrant> bigjools: So, I managed to get lots of Soyuz bits to cooperate today, but it all seems a bit manual and I'm not sure if I've done anything terribly wrong. http://williamgrant.id.au/f/1/2009/soyuzness.html is my current setup.
[10:24] <bigjools> will check it out in a bit, on a call right now
[10:24] <wgrant> Sure.
[10:26] <stub> jtv: So I've realized that for us, a Storm cache where the size is bounded by the number of objects is not optimal. What we care about is the amount of RAM being used. I was thinking of making a generational cache subclass that bumps a generation whenever num_objects > n and process_ram_usage > r.
[10:26] <jtv> stub: very true.
[10:26] <pkern> wgrant: Hm cool.  I should've taken Ubuntu as an example rather than hacking it to name it Debian.  Anyway I had something like "Unable to find distroseries: lenny" albeit I created that below /debian/.  I thought that UploadPolicies are not properly set up, did you find that wired somewhere?
[10:27] <wgrant> pkern: I used a PPA rather than try to convince primary to publish.
[10:27] <stub> jtv: Unless there is someway of keeping count of the size of individual objects, but process size may still be better for our needs.
[10:27] <pkern> wgrant: I also tried PPA.
[10:27] <wgrant> Although I was able to get Ubuntu primary to publish without --careful, I don't trust that.
[10:28] <wgrant> pkern: I should try a Debian PPA at some point.
[10:28] <jtv> stub: object size is horrendous in any case, except where __slots__ are used.
[10:28] <bigjools> stub: did you see the cache change results I posted to that bug?
[10:29] <stub> bigjools: https://code.edge.launchpad.net/~stub/launchpad/update-storm/+merge/9130
[10:29] <bigjools> wgrant: we only use --careful when we want to re-publish everything.  it's quite devastating
[10:29] <pkern> "Must omit the trailing 'ubuntu', this time. "  I love hardcoded stuff. ;-)
[10:30] <wgrant> bigjools: Right, but I did want to republish everything, as the on-disk archive was empty.
[10:30] <bigjools> stub: (apologies if you replied I've not read my email yet)
[10:30] <wgrant> bigjools: But the librarian files aren't there, so it crashes.
[10:30] <bigjools> wgrant: yes, in the first instance it's what you need
[10:30] <wgrant> bigjools: Even once I supersede/delete all of the pulibcations.
[10:30] <bigjools> oh fucking firefox you piece of shit
[10:30] <wgrant> pkern: I think it probably just uses the distro name, rather than hardcoding it.
[10:30] <wgrant> bigjools: Firefox killed my laptop a couple of minutes after you complained about it earlier.
[10:31] <gmb> Moin + Firefox locked up X completely the other day.
[10:31]  * gmb joins in the two-minute hate
[10:31] <wgrant> That hasn't happened to me in a month or so (this is Karmic).
[10:31] <bigjools> wgrant: yes and mine just restarted without my 10 tabs I wanted saved >:(
[10:31] <wgrant> bigjools: Ahaha.
[10:31] <pkern> wgrant: It's at least hardcoded in activate-ppa by retrieving only ubuntu through ILaunchpadCelebrities.  And I was delighted that debian is available there, too. :-P
[10:32] <bigjools> are you going to work on debianb ppas?
[10:32] <wgrant> pkern: Right, but you should be able to easily change an Ubuntu PPA into a Debian PPA.
[10:32] <wgrant> I'll try that after dinner.
[10:32] <pkern> That's true.
[10:33] <wgrant> (just IArchive.distribution needs touching, AFAICT)
[10:34] <noodles775> wgrant: if it's easier for you, you can also do a lot of that setup on your link using `make harness`
[10:34] <wgrant> pkern: Oh, probably archivearch and archivedependency will need touching too.
[10:35] <wgrant> noodles775: True.
[10:35] <wgrant> But it wouldn't make it much shorter, AFAICT.
[10:36] <noodles775> no, not shorter, but easier to reproduce after the database is reset.
[10:37] <stub> bigjools: I use the sessionsaver plugin which, so far, has never lost my previous session on a crash.
[10:38] <wgrant> Firefox 3.5 seems to be better about recovering.
[10:40] <pkern> I like that you need to quit Banshee to do make run :-P
[10:41] <bigjools> !
[10:46] <jtv> hi henninge!
[10:46] <gmb> pkern: If you turn off the local music sharing options in banshee it stops hogging the port that Launchpad wants.
[10:46] <henninge> Hey jtv!
[10:47] <gmb> pkern: Took a while to figure that one out...
[10:49] <mgdm> what port is that?
[10:51] <gmb> mgdm: I can't remember offhand... It's whichever port you get an "already in use" message about when you try to make run with Banshee running.
[10:56] <pkern> 80 something
[10:56] <pkern> 8085
[10:59] <bigjools> wgrant: "Builds will only be dispatched for archives with published sources" - not quite right, that only happens if the PPA is private.
[10:59] <bigjools> wgrant: did you get a local buildd working then?
[11:00] <wgrant> bigjools: Ahh. Why is that? It won't have a .htaccess otherwise?
[11:00] <wgrant> bigjools: I did.
[11:00] <wgrant> It was pretty easy.
[11:00] <bigjools> very cool, I've never tried
[11:00] <bigjools> because the buildd gets sources from the librarian normally, but we don't do that for private builds
[11:01] <wgrant> Ah.
[11:01] <wgrant> I see.
[11:01] <bigjools> they need to stay sekrit
[11:01] <wgrant> Right.
[11:01] <pkern> private builds ):
[11:02] <wgrant> pkern: Why ):?
[11:02] <pkern> bigjools: Why weren't you able to just tell the librarian that it should give out that files local-only?
[11:02] <pkern> And where are oopses stored btw...
[11:03] <bigjools> pkern: there are two librarians
[11:03] <wgrant> /var/tmp/lp-err
[11:03] <bigjools> because they don't have any access control
[11:03] <bigjools> so one is restricted in the DC
[11:03] <bigjools> the buildds can't see it, otherwise other builds could steal data
[11:04] <pkern> Hm, point.
[11:04] <deryck> Morning, all.
[11:04] <bigjools> oopses are logged, check the config to find out where
[11:04] <pkern> Well, you could sort out access for the outside fetching things only and limit connectivity for the build itself.
[11:04] <bigjools> I don't remember offhand
[11:04] <noodles775> Hi deryck !
[11:04] <pkern> bigjools: wgrant is right (:
[11:05] <pkern> Apart from s/lp-err/lperr/ but well.
[11:05] <wgrant> Ehem.
[11:05] <wgrant> I think I found a hole.
[11:05] <bigjools> gadzooks
[11:05]  * wgrant pokes around a bit more.
[11:05]  * pkern giggles.
[11:06] <wgrant> I'd wondered about how this stuff worked for some time, as it could easily be vulnerable. But looking at it now seems to confirm it.
[11:06]  * wgrant tries, then files a bug.
[11:08] <al-maisan> hmm .. such "discoveries" were to be expected ..
[11:08] <wgrant> Yes.
[11:08] <wgrant> I meant to look for this particular one earlier.
[11:09] <bigjools> wgrant: PM me the bug # when you're done please
[11:13] <stub> jtv: Hmm.... the problem is that for Launchpad I would need to bump a generation when ram usage *for the thread* got too high, and for a generic storm cache when the ram usage by the cache got too high. Otherwise we risk a large object sitting in an idle cache causing other caches to thrash.
[11:14] <stub> jtv: Unless we share the storage for all of these cache instances, so they have one big cache rather than individual ones.
[11:15] <stub> jtv: Or perhaps maintain a list of all of the caches, and bump all of them with num_objects > threshold when the ram limit is exceeded.
[11:17] <stub> I think that would work
[11:17] <jtv> stub: (sorry, on call)
[11:38] <jtv> stub: you could have a shared policy on what would make a nice cache size under current memory pressure.
[11:39] <stub> jtv: But we don't know how many objects would be nice because the memory footprint of each object can be very different.
[11:40] <stub> jtv: Or do you mean bumping the desired object counts up and down until RAM usage is within bounds?
[11:40] <jtv> stub: will that matter so much if we tune it dynamically anyway?  Too much memory pressure -> fewer objects please.
[11:40] <jtv> It'll victimise stores with lots of small objects, true, but how much would that hurt performance?
[11:41] <bigjools> stub: the issue with the cache that you're waiting for an RC on is mentioned on the CRB page, it would be great if you could manage that :)
[11:41] <stub> I'm don't see how that is better than just bumping the caches when the memory limit is reached.
[11:41] <stub> CRB?
[11:42] <bigjools> https://wiki.canonical.com/Launchpad/CurrentRolloutBlockers
[11:42] <stub> bigjools: I probably won't be here, so someone will need to land it for me once it is rc'd.
[11:42] <bigjools> stub: ok, I can do that
[11:43] <stub> bigjools: kiko has an email in addition to the mp request.
[11:43] <bigjools> yeah I saw
[11:43] <bigjools> flacoste can give RCs too
[11:44] <stub> flacoste is on leave I believe
[11:44] <bigjools> ah yes
[11:44] <bigjools> kiko it is
[11:47] <gmb> Argh.
[11:47]  * gmb just punched himself in the face with a mug full of tea.
[11:50] <allenap> gmb: Edwin's bug: https://bugs.edge.launchpad.net/launchpad-registry/+bug/401748
[11:50] <ubot3> Malone bug 401748 in launchpad-registry "Cannot create new project in IE8" [High,In progress]
[11:51] <gmb> allenap: Ta#
[11:56] <bigjools> is that bug on the CRB page?
[11:56] <bigjools> I seem to be the only person updating it
[11:57] <wgrant> bigjools: There's a CRB on dev.launchpad.net now too.
[11:57] <bigjools> only just added
[11:57] <bigjools> without migrating the old page :/
[11:57] <bigjools> ffs
[13:52] <henninge> jtv: ping
[13:52] <jtv> henninge: ?
[13:53] <henninge> jtv: Looking at the pofiles in the queue I see that most of the files are probably still in there because the lang code cannot be determined.
[13:54] <jtv> henninge: hang on, I'm coming.  Just the po files for projects?
[13:54] <henninge> jtv: yes
[13:54] <henninge> jtv: almost 400
[13:54] <henninge> jtv: There is a lot like domain-ll.po
[13:54] <jtv> :(
[13:54] <jtv> ah yes
[13:55] <henninge> jtv: I think that they should be deleted from the queue and the uploaders informed about how to name the files.
[13:56] <jtv> henninge: instead of deleting, we could just let them sit there for now and email the uploaders to say there's a faster way.
[13:58] <henninge> jtv: but even then the po files need to be named properly to be automatically approved.
[13:58] <jtv> henninge: yes, they'd upload new files and discover that it was much faster.
[13:59] <jtv> henninge: once they've done that, we can delete the old uploads.  This is not a part of the queue we should watch daily anyway, so that gives them time to play.
[14:00] <henninge> jtv: oh, I thought "faster way" was bzr uploads ...
[14:00] <henninge> ;-)
[14:00] <henninge> jtv: yeah, we should do that
[14:00] <jtv> henninge: in this case, it's fixing the PO names.  They'll have to do that either way.
[14:02] <noodles> sinzui: have you started a page about updating the new 3.0 templates? If not I can take a look at your branch to get some ideas.
[14:02] <sinzui> I am writing it today
[14:03]  * mars gives up on reading the channel backlog
[14:03] <sinzui> noodles: The work is easy, but there are heading conflicts that may require us to edit every page twice...making the progress report bogus
[14:03] <henninge> jtv: what I meant.
[14:03] <jtv> henninge: we're in violent agreement.  Would you like me to write a canned response and put it up on the wiki?
[14:04] <noodles> sinzui: OK. Let me know if I can take a sneak preview ;)
[14:04] <jtv> Maybe I'll start a new subpage, "approval issues."
[14:04] <henninge> jtv: please do, I'll send them out, then.
[14:04] <jtv> henninge: I mean, auto-approval issues.
[14:04] <jtv> OK.
[14:04] <henninge> jtv: or how busy are you?
[14:05] <jtv> henninge: not very.  Need help?
[14:05] <henninge> jtv: no, no, just wanted to put something else on you.
[14:05] <jtv> henninge: go ahead.
[14:05] <henninge> jtv: I'll move to my office soon, so this is cool
[14:06] <henninge> jtv: oh, sorry.
[14:06] <henninge> ;-D
[14:06] <jtv> henninge: I don't think I follow
[14:06] <henninge> jtv: no, no, just *did* *not* want to put something else on you.
[14:06] <jtv> ahhhh :)
[14:06] <henninge> jtv: ^ what I meant to write
[14:07] <jtv> No worries, CHR is *incredibly* quiet.  I think everyone decided to look up their questions in the source first.  Or maybe our entire user base is just stuck downloading/browsing the code for the heck of it.
[14:07] <henninge> jtv: ok, I'll relocate now.
[14:08] <jtv> ok
[14:24] <noodles> sinzui: I'm just fiddling with a main-only layout, and noticed that style-3-0 is quite specific when applying styles to elements that have been reset (via the yui reset). For example
[14:25] <noodles> sinzui: rather than setting any th element as bold, only those within form table tbody are set to bold...
[14:25] <sinzui> noodles: I think there is a comment that we wanted to restore some of the settings from style.css
[14:26] <sinzui> noodles: reset is complete, there is no style. So strong way was never bold,
[14:27] <sinzui> noodles: I expect the style sheet will get a lot of changes as we get more pages using them
[14:27] <noodles> sinzui: yes, but I'm just confused why style-3-0 would specifically set 'form table tbody th' to font-weight:bold rather than just th.
[14:27] <noodles> Ah, ok.
[14:27] <noodles> I'll do some modifications and than perhaps later chat with you on the diff (after reading your doc of course :) ).
[14:28] <sinzui> noodles: Some ths are not bold on launchpad, so I set a rule that matches how we currently use th bold
[14:28] <noodles> I see.
[14:28] <jtv> pqm still failing?  :-(
[14:28] <sinzui> noodles: we have only two page designs, only one in html, There is a tremendous about of css we will discover
[14:29] <sinzui> jtv. yes, I cannot restart buildbot. I am hoping for gary to come by
[14:36] <sinzui> barry, bac, Edwin, salgado: standup in 2 minutes
[14:43] <barry> Ursinha: ping.  in the registry test plan you mentioned you filed bug 401887, but that doesn't seem to be the right bug number
[14:44] <ubot3> Malone bug 401887 in launchpad "offer "make announcement" on +announcements" [Undecided,New] https://launchpad.net/bugs/401887
[14:48] <Ursinha> barry, argh, paste fail
[14:48] <EdwinGrubbs> sinzui: can you call again, skype wouldn't ring, but I know the rest of the audio works.
[14:49] <Ursinha> barry, bug 402736
[14:49] <ubot3> Malone bug 402736 in lazr-js "Buttons seem not hooked up to js in IE8" [Undecided,New] https://launchpad.net/bugs/402736
[14:49] <Ursinha> I'll fix in the testplan
[14:50] <Ursinha> barry, done
[14:51] <maxb> Does anyone else find themselves routinely running make SHHH= ....
[14:51] <maxb> ?
[14:52] <barry> Ursinha: thanks!
[14:52] <mars> maxb, not personally.  When there are startup errors the extra noise is a welcome debugging aide. :)
[14:52] <Ursinha> barry, sorry for the mess
[14:53] <mars> maxb, say, for example, when you accidentally run two instances side-by-side
[14:53] <maxb> mars: that's the point -  SHHH=(empty string here) turns off the output suppression
[14:53] <barry> Ursinha: no worries
[14:53] <mars> maxb, ah, my mistake
[14:54] <maxb> np, i could have been a lot less terse :-)
[14:54] <barry> Ursinha: though i do not think we need to release critical this bug.  sinzui says that we don't support ie8 officially yet
[14:55] <maxb> Well that was comparatively painless
[14:55] <mars> allenap, ping re: the pages you moved to the dev wiki
[14:55]  * maxb has a launchpad webapp running...... on karmic
[14:55] <mars> cool
[14:55] <allenap> mars: Yeah
[14:55] <mars> maxb, using which Python?
[14:55] <maxb> 2.5
[14:55] <mars> barry, ^
[14:55] <mars> it *is* possible :)
[14:56] <bigjools> heh, but I bet he hasn't run the test suite :)
[14:56] <Ursinha> barry, no problem then, if we don't support officially
[14:56] <maxb> well, no, baby steps...
[14:56] <sinzui> barry: Ursinha: AN RC is needed if there is broken JS that prevents a user from completing a task. We do not care if the task can be completed via AJAX or HTML.
[14:58] <barry> folks.  every week we have two meetings for launchpad code reviewers.  the meetings have always been public.  reviewers are required to attend, but anybody else is also welcome to lurk.  the america/euro version starts in 2 minutes in #launchpad-meeting
[15:00] <noodles> sinzui: A quick question - on the following url, there is a table used to layout "Repository disk usage, Build dependencies" etc.
[15:00] <barry> reviewers -> #launchpad-meeting
[15:00] <noodles> https://edge.launchpad.net/~cprov/+archive/ppa
[15:00] <noodles> sinzui: is that the kind of thing that we want to use a dl for instead, or will we stick with a table for the moment?
[15:01] <sinzui> noodles: yes, that is a good example
[15:01] <Knut-HB> hello together, i have a question/problem concerning the local installation of launchpad. After going through the step-by-step-solution (every seemed to go correct) and when  i then run "make schema && make run" in ~/launchpad/lp-branches/devel/ and when i enter "launchpad.dev" in firefox i get a 503. is there a quick solution for this?
[15:03] <mars> Knut-HB, well, first lets look for a quick diagnosis :)
[15:03] <sinzui> noodles: That layout may change. The onecolumn layout used that style, but you can see the project information has a new layout in https://devpad.canonical.com/~curtis/LP_projectdetail.png
[15:03]  * noodles looks
[15:03] <allenap> mars: re-pong :)
[15:04] <noodles> sinzui: yes, that looks lovely :), it would be great to get something similar for the archive index.
[15:04] <mars> allenap, ah, just wondering if you also moved the wiki pages over? and if so, was it easy to find a place to link them from?
[15:04] <salgado> allenap, is it just me or are the edit icons for inline editing of bug status/importance misbehaving (i.e. only showing up when I hover the mouse over them)?
[15:05] <wgrant> salgado: That happens to me sometimes too.
[15:05] <wgrant> And they sometimes take several seconds to disappear.
[15:05] <mars> Knut-HB, could you kill the server and paste the output of 'make run'?  I want to be sure that the server is in fact up
[15:05] <salgado> wgrant, is there a bug about that?
[15:05] <allenap> mars: Yeah, I moved them over to Bugs/ExternalBugTrackers/Mantis and the other to Bugs/Spec/FormattingBugNotifications
[15:06] <wgrant> salgado: There are a few bugs about that sort of thing, but nothing about that particular issue.
[15:06] <allenap> mars: I also added most of the intermediate pages. They're looking a bit sparse, but they're there.
[15:06] <wgrant> Things were changing, so I didn't file one.
[15:06] <allenap> salgado: Not just you. I think that's a feature. intellectronica?
[15:06] <noodles> Knut-HB: when you run make run, watch the output and verify you see "[-] daemon ready!"
[15:08] <intellectronica> salgado: that's a feature
[15:08] <salgado> wgrant, if I leave the mouse pointer over the place where the link should be, it keeps showing up and disappearing in an infinite loop.  does that happen to you too?
[15:08] <salgado> intellectronica, but not that (^), I hope?
[15:09] <salgado> intellectronica, that happens after the first time the icon shows up and I move the mouse pointer away from it
[15:09] <jtv> sinzui: if gary is at oscon, that doesn't bode well for your pqm restart.  :/
[15:09] <intellectronica> salgado: no, that sounds pretty bad. let me see if i can reproduce
[15:09] <wgrant> salgado: That doesn't, but for the first load on each page it takes one Launchpad-long-time to appear, and another to disappear.
[15:09] <wgrant> It seems to make a request each time.
[15:10] <salgado> intellectronica, when I move the mouse pointer back to it and leave it there for around two secs, it goes into that loop
[15:10] <sinzui> jtv: I am prepared to issue a release-critical empty branch to make buildbot work. I will ask for forgiveness after I see staging updated
[15:10] <intellectronica> salgado: is that locally or on edge?
[15:10] <salgado> intellectronica, edge
[15:11] <jtv> sinzui: non-empty branches sure aren't working...
[15:12] <salgado> intellectronica, it happens only when the pointer is above the place where the icon should be.  if the pointer is above the text, it doesn't happen
[15:12] <intellectronica> salgado: there's a fix that didn't make it to the nightly because of an unrelated failure. could you please try to reproduce locally?
[15:12] <sinzui> jtv: right, I will make a white space change to one of our ugly page templates
[15:12] <salgado> intellectronica, sure
[15:12] <intellectronica> salgado: thanks
[15:12] <jtv> sinzui: so what's breaking it that a branch like that would succeed whereas mine fails?
[15:13] <sinzui> jtv. I do not know. I will find out now
[15:13] <jtv> sinzui: good luck!
[15:14] <salgado> intellectronica, it happens on lp.dev too
[15:14] <salgado> (and I just did a rocketfuel-get)
[15:16] <intellectronica> salgado: :( can you please file a bug and assign to me?
[15:17] <intellectronica> salgado: what browser are you using, b.t.w?
 intellectronica, it happens on lp.dev too
 (and I just did a rocketfuel-get)
[15:29] <mars> hi everyone, need some help debugging a sourcecode dependencies build problem
[15:29] <mars> in a new setup
[15:29] <mars> Here's the 'make schema' output showing the error: http://paste.ubuntu.com/224383/
[15:29] <mars> and the sourcecode/ directory has links in it
[15:30] <mars> BTW, this is in devel/
[15:31] <mars> wgrant, around?
[15:32] <wgrant> pkern: I just successfully uploaded things to both Debian primary and PPA here, and can even access the PPA in the web UI along with Ubuntu ones with a few lines of changes. It just took a bit of lucilleconfigging.
[15:32] <wgrant> mars: Yes.
[15:33] <wgrant> An odd error.
[15:33] <mars> wgrant, just wondering if you saw anyone with problems running link-external-sourcecode in devel/
[15:33] <wgrant> Is that from your machine?
[15:33] <mars> wgrant, this is Knut-HB's new setup
[15:33] <wgrant> I saw somebody complaining of the same thing earlier, IIRC.
[15:34] <mars> Knut-HB, do you have any contents in devel/bin/ ?  Could you paste them please?
[15:34] <mars> that way I know what has and has not been generated by the buildout scripts
[15:34] <wgrant> download-cache should live in ~/launchpad/lp-sourcedeps, shouldn't it?
[15:36] <Knut-HB> mars: http://paste.ubuntu.com/224397/
[15:37] <mars> wgrant, yes
[15:37] <mars> Knut-HB, and devel/download-cache is a valid link?
[15:39] <Knut-HB> when i open "devel/download-cache" i see another folder named "dist". is that correct?
[15:39] <mars> Knut-HB, btw, you may want to restart apache.  Launchpad will not do that for you
[15:39] <mars> Knut-HB, it is.  does dist/ contain a number of .tar.gz files?
[15:40] <intellectronica> salgado: sorry, you may have missed my reply when you disconnected. i asked if you could file a bug with instructions on how to reproduce and assign to me
[15:40] <intellectronica> i still can't seem to reproduce this locally
[15:40] <salgado> intellectronica, will do
[15:40] <intellectronica> salgado: cool, thanks
[15:40] <Knut-HB> mars, after doing a "sudo /etc/init.d/apache2 start" the apache restarted and inside the "dist"-folder are 178 files, a lot are tar.gz
[15:40] <salgado> (I missed your reply indeed)
[15:41] <mars> Knut-HB, good!
[15:41] <Ursinha> sinzui, barry, question: why in item r8865 needstesting in your testplan it doesn't have the Konqueror items to test?
[15:41] <mars> Knut-HB, please try "cd devel/", 'make', then 'make schema'
[15:41] <Knut-HB> ok
[15:41] <sinzui> Ursinha: I do not know the answer to that one. I did not it. I removed the Konqueror 3 since it is not supported.
[15:42] <pkern> wgrant: wow
[15:42] <Knut-HB> after "make" i get several errors, pastebin?
[15:42] <sinzui> Ursinha: I did note that Konqueror 4 was missing, but did not consider to ask why
[15:42] <Ursinha> sinzui, I'm adding by default konqueror 3 browser as C graded, because of people using LTS version of Kubuntu (mars can correct me if I'm wrong)
[15:43] <Ursinha> sinzui, that was removed by hand, since the script is adding all of them automagically when detecting the js tag
[15:43] <sinzui> Ursinha: The test will always fail, We are not fixing them
[15:43] <wgrant> pkern: Have you had luck, or do you want some pointing in the right direction, or do you have significantly better things to do with your time?
[15:44] <sinzui> Ursinha: Do not make k3 take an AJAX test it has no chance of passing. It should only use html
[15:44] <Knut-HB> mars: this is what i get after "make": http://paste.ubuntu.com/224401/
[15:44] <Ursinha> sinzui, do we have to guarantee that it will work as disabled? I assumed so
[15:46] <mars> Knut-HB, ok, hmm
[15:47] <mars> that is frustrating
[15:47] <mars> the directory is there, and it is valid
[15:47] <sinzui> Ursinha: The HTML must work, and that is what need to be tested. AJAX is for A grade browsers only. The K3 tests should verify that the operation still works in HTML (bug subscribe via HTML was lost for a while, so that is a good example of a FAIL that had to be fixed)
[15:47] <mars> Knut-HB, does the directory `/home/test/launchpad/lp-sourcedeps/sourcecode/cscvs' exist?
[15:47] <Knut-HB> mars, checking
[15:48] <mars> Knut-HB, perhaps the sourcecode download broke during transfer
[15:48] <mars> that has happened to other people
[15:48] <Ursinha> sinzui, right, they're being added to the testplans to test not just the ajax, but if the feature is still functional even without js
[15:48] <bigjools> Knut-HB: is your devel branch up to date?
[15:48] <Knut-HB> i was at the laptop all the time watching the progress and the download didn't break or something like that
[15:48] <bigjools> "bzr pull" it
[15:48] <Knut-HB> bigjools: downloaded just yesterday
[15:49] <bigjools> pull again please
[15:49] <wgrant> What about running rocketfuel-get?
[15:49] <bigjools> there was a fix that went in late
[15:49] <Knut-HB> ok, first the checking
[15:49] <mars> wgrant, yep, that's next :)
[15:49] <wgrant> That will update everything and make sure they're checked out properly.
[15:49] <bigjools> don't run fg-get yet
[15:49] <sinzui> Ursinha: then I was mistaken in the intent of the inline edit test
[15:49] <bigjools> rf-get even
[15:49] <wgrant> Although it won't fix the 2a issue.
[15:50] <Ursinha> sinzui, at least I thought that the js testing was about making ajax work and not breaking if it doesn't
[15:50] <bigjools> Knut-HB: when bzr pull finishes, run utilities/rocketfuel-get
[15:50] <Knut-HB> mars: check, folder is there with contents
[15:50] <Ursinha> mars, am I understanding that wrong?
[15:50] <mars> Ursinha, reading back
[15:50] <Knut-HB> bigjools: where do i have to pull? inside the folder "launchpad"?
[15:51] <bigjools> Knut-HB: insde the devel dir
[15:51] <bigjools> that is the trunk branch
[15:51] <Knut-HB> ok, pulling
[15:51] <bigjools> there was an important fix to rocketfuel-get done late yesterday
[15:51] <Knut-HB> ah ok
[15:51] <mars> sinzui, Ursinha, what are the K3 tests written in?
[15:52] <sinzui> mars: this is the test plan, not automated testing
[15:52] <salgado> intellectronica, bug 403066
[15:52] <ubot3> Malone bug 403066 in malone "Icons to edit a bug's status/importance come and go in an infinite loop" [Undecided,New] https://launchpad.net/bugs/403066
[15:52] <Knut-HB> bigjools: ok, pulled, what next? rocketfuel-get?
[15:52] <mars> sinzui, ah, see, that is why I asked :)
[15:52] <bigjools> Knut-HB: yep
[15:52] <intellectronica> salgado: thanks
[15:53] <bigjools> Knut-HB: utilities/rocketfuel-get
[15:53] <Knut-HB> ok, working
[15:53] <bigjools> it will take a while
[15:53] <mars> sinzui, Ursinha, the K3 tests in the test plan should ensure that the functionality is still accessible as HTML in the K3 browser.
[15:53] <intellectronica> salgado: whoa, finally realised how to reproduce
[15:53] <sinzui> herb: buildbot appears to be dead I cannot make it restart. I know this is unlikely. but do you know how to kick buildbot?
[15:53] <intellectronica> this can be very bad for epileptic users
[15:53] <Knut-HB> bigjools: ok, i'll tell you when it's finished
[15:54] <salgado> intellectronica, lol
[15:54] <bigjools> ok thanks
[15:54] <mars> sinzui, Ursinha, that is what defines "C" Grade: we explicitly test that the site still works on a known problematic platform.
[15:54] <herb> sinzui: I can certainly try
[15:54] <Ursinha> mars, so I got that right :)
[15:54] <mars> sinzui, Ursinha, versus "X" Grade, where we don't test, we just assume it's ok.
[15:55] <mars> Ursinha, yep.  The K3 test should check that the AJAX is disabled, and that users can still use the site.
[15:59] <sinzui> mthaddon: herb: buildbot appears to be dead I cannot make it restart. I know this is unlikely. but do you know how to kick buildbot?
[15:59] <mars> sinzui, herb said he would try
[15:59]  * sinzui is still frazzled from yesterday
[16:00] <mars> sinzui, it was buried in the last flurry of messages addressed to you :)
[16:00] <mars> sinzui, frazzled, but fun, no? :)
[16:00] <mars> sorry, should make that more Canadian...
[16:01] <mars> sinzui, frazzled, but fun, eh? :)
[16:02] <sinzui> No. My day sucked because I have a ton of work to complete and too many interruptions to work on it. I really do not want to release code today since I cannot see that any of our landing fixed bugs
[16:03] <Knut-HB> bigjools, ok, finished
[16:03] <Knut-HB> bigjools, what now?
[16:04] <bigjools> Knut-HB: any errors?
[16:05] <mars> sinzui, is there any way I could help?  QA perhaps?
[16:05] <Knut-HB> bigjools, can't find any
[16:05] <bigjools> Knut-HB: ok that's good - try "make schema" now
[16:05] <sinzui> mars: you cannot QA because the code never arrived in staging because buildbot had a heart attack
[16:06] <Knut-HB> bigjools, same errors again =/
[16:07] <bigjools> gah
[16:07] <bigjools> ok
[16:07] <herb> sinzui: The buildmaster appears to have (re)started correctly.
[16:07] <bigjools> can you run rocketfuel-setup again
[16:07] <Knut-HB> ok
[16:07] <mars> sinzui, ah, sorry to hear that.  You enjoy lean: this is something that should go in the "unnecessary waste" category.
[16:08] <sinzui> herb: \o/
[16:08] <sinzui> I can deliver beer to your house later this evening
[16:09] <sinzui> mars: I suppose my frustration is really these moment I feel powerless to fix something
[16:09] <mars> sinzui, I've been building a list of problem areas in the dev process, and the building and landing processes are definitely in the running for "biggest problem right now"
[16:10] <mars> sinzui, if the system was perfect, you wouldn't have to fix anything :)
[16:12] <sinzui> mars: but where would I get my karma from then?
[16:12] <mars> sinzui, you'll never catch flacoste, give up :)
[16:13] <sinzui> mars: I can catch flacoste in 1 week. I choose not to use blueprints until they rock
[16:13] <mars> well, if you fix blueprints, you will close so many bugs that yes, you will be in first place :)
[16:16] <sinzui> bac: should we have our call?
[16:17] <mars> bigjools, do you think a series of environment checks before lp startup would help with diagnosis?  make start-check
[16:18] <bigjools> mars: not a bad idea, but I'd make it a separate target, "make diagnose" or something like that so we can ask for it to be run
[16:18] <mars> bigjools, ah, that is a good name :)
[16:18] <Knut-HB> bigjools, ok, rocketfuel-setup has finished, what next? make schema?
[16:18] <bac> sinzui: yes
[16:19] <bigjools> Knut-HB: if there were no errors, yes
[16:19] <ara> bigjools, I got an error of "Package `launchpad-developer-dependencies' is not installed and no info is available." is it only available in jaunty? (I am running karmic)
[16:19] <Knut-HB> while doing "rocketfuel-setup" i couldn't find any errors but when doing "make schema" i get the usual errors =/
[16:20] <bigjools> okay, I think rf-setup is confused
[16:20] <bigjools> let me check something
[16:20] <Knut-HB> ok
[16:20] <maxb> ara: Yeah, us karmic users need to be trailblazers right now :-/
[16:20] <ara> maxb, ok, thanks
[16:20] <bigjools> ara: yes, jaunty only, LP doesn't yet work in karmic
[16:21] <bigjools> or you can use hardy
[16:21] <maxb> :-P
[16:21] <ara> only *.04 releases? :P
[16:21] <mars> that's the last LTS release, and what we deploy on
[16:21] <bigjools> supported platforms :)
[16:22] <sinzui> bac: https://edge.launchpad.net/launchpad-registry/+milestone/2.2.7
[16:22] <bigjools> Knut-HB: what is in lp-sourcedeps/download-cache/dist/ ?
[16:24] <mars> Knut-HB, what happens if you run 'make download-cache' in devel/ ?
[16:24] <Knut-HB> mars, i'll do it next
[16:26] <Knut-HB> bigjools, http://paste.ubuntu.com/224424/ this is inside the folder
[16:26] <Knut-HB> mars, "make: `download-cache' is up to date.
[16:26] <bigjools> Knut-HB: in devel, do you have a symlink "download-cache" ?
[16:27] <pkern> wgrant: I'm currently at Debconf and people want me to move Debian autobuilding to a new host and discussing stuff with people.  That's the main reason I get distracted at the moment, so I appreciate the pointers and will look at it later today. \-:
[16:27] <Knut-HB> bigjools, yes
[16:27] <bigjools> Knut-HB: at it points to the ../../lp-sourcedeps/download-cache ?
[16:27] <bigjools> s/at/and/
[16:28] <Knut-HB> bigjools, yes it does
[16:29] <bigjools> Knut-HB: does devel have a sourcecode dir?
[16:29] <bigjools> full of symlinks?
[16:29] <Knut-HB> bigjools, i'll check that, just have to check something in
[16:31] <Knut-HB> bigjools, yes, 27 symlinks and one makefile
[16:31] <bigjools> Knut-HB: ok, if you type "make build" now, in devel, what happens?
[16:32] <mars> bigjools, drilling down the Makefile target chain? :)
[16:33] <Knut-HB> bigjools, http://paste.ubuntu.com/224430/
[16:33] <bigjools> mars: trying different things :)
[16:33] <mars> Knut-HB, how about 'make compile' ?
[16:34] <bigjools> Knut-HB: this is bizarre
[16:34] <mars> I suspect it will throw the same error
[16:34] <Knut-HB> bigjools, you won't believe me: the same errors :P
[16:34] <Knut-HB> mars, you just won 1000 points!
[16:35] <mars> ok, lets keep drilling then
[16:35] <bigjools> Knut-HB: rm download-cache and rm sourcecode/* then run "utilities/link-external-sourcecode ../../lp-sourcedeps"
[16:35] <Knut-HB> ok wait
[16:36] <mars> there should really be a GNU Make option that gets it to spit out the targets....
[16:36] <Knut-HB> bigjools, you want to see the output?
[16:36] <bigjools> Knut-HB: no
[16:36] <bigjools> if it's done, try make build
[16:37] <Knut-HB> wow Oo one part of three errors less :D
[16:37] <Knut-HB> "No rule to make target `build'. Stop."
[16:37] <bigjools> lol
[16:37] <bigjools> ok just "make"
 "No rule to make target `build'. Stop."
[16:38] <mars> bigjools, we need a 'make distclean' target :/
[16:38] <bigjools> Knut-HB: ok try "python2.4 bootstrap.py"
[16:38] <bigjools> mars: what would that do over make clean?
[16:39] <mars> bigjools, 'make clean' cleans up the test env.  'make distclean' would kill eggs/, download-cache, apidoc, etc.
[16:39] <bigjools> apidoc is removed by make clean, but ISWYM
[16:39] <Knut-HB> bigjools, http://paste.ubuntu.com/224434/
[16:40] <mars> bigjools, 'make clean' means 'clean up everything from running'.  'make distclean' means 'remove everything that isn't in the source tree, so I can tarball it'
[16:40] <bigjools> Knut-HB: huh, I think we see your problem
[16:40] <Knut-HB> bigjools, really? :D
[16:41] <bigjools> buildout can't get its dependencies
[16:41] <mars> bigjools, what Knut-HB said: really?
[16:41] <bigjools> "Link to http://pypi.python.org/simple/zc.buildout/ ***BLOCKED*** by --allow-hosts
[16:41] <bigjools> I've not seen that before
[16:41] <mars> bigjools, that is expected - it is supposed to grab them from eggs/
[16:41] <mars> afk, biab
[16:42] <mthaddon> kiko: so are you release manager for today?
[16:42] <mars> bigjools, or from download-cache, I don't remember which exactly
[16:42] <bigjools> :)
[16:42] <kiko> mthaddon, indeed I am, how are you?
[16:42] <mthaddon> kiko: depends on how things are looking for the release :)
[16:43] <mars> bigjools, Knut-HB, I think it is the 'bin/buildout' target that is failing
[16:43] <barry> losa ping
[16:43] <mthaddon> barry: hi
[16:43] <mars> or was failing, before download-cache got killed
[16:44] <bigjools> Knut-HB: what is in your devel/bin dir?
[16:44] <mars> Knut-HB, you can always try 'make -d foo' if you want more info about what make is deciding to do
[16:44] <barry> mthaddon: hi.  kfogel asked me to coordinate with you about regenerating the mailing list archives with his new style.  he's at oscon
[16:45] <mthaddon> barry: ok
[16:45] <barry> mthaddon: cool.  let me make sure the wiki page with the instructions is updated
[16:45] <Knut-HB> bigjools, http://paste.ubuntu.com/224437/
[16:46] <barry> mthaddon: actually.  have we rolled out yet?  if not, i think we need to wait until that happens
[16:46] <mthaddon> barry: rolling out 22:00 UTC
[16:47] <bigjools> Knut-HB: that looks ok
[16:47] <barry> mthaddon: cool.  then let's chat again in a few hours, or tomorrow morning.  in the meantime, i'll make sure the wiki has the right instructions
[16:47] <bigjools> Knut-HB: when you ran link-external-sourcecode, did it print a load of symlink info?
[16:48] <Knut-HB> yes
[16:48] <mthaddon> kiko: so are there any more expected items after what's currently in buildbot?
[16:48] <bigjools> I am totally baffled
[16:49] <Knut-HB> bigjools, me too :p
[16:50] <bigjools> Knut-HB: I only have one more suggestion.  Blow away your lp-sourcedeps, and run rocketfuel-get again
[16:50] <Knut-HB> bigjools, hm ok, i do as you say ;9
[16:50] <bigjools> sorry, it will download lots of stuff again :/
[16:50] <Knut-HB> ah, 16 mbit/s connection ;)
[16:50] <bigjools> woo :)
[16:51] <Knut-HB> and it's not my system i'm working on anyway, it's a virtual system on a remote system accessed via ssh so... don't worry :D
[16:53] <Knut-HB> ok, downloading
[17:01] <kiko> mthaddon, so the rollout is at 2200 UTC?
[17:01] <mthaddon> kiko: yep
[17:04] <Knut-HB> bigjools, "Couldn't find lp:~launchpad-pqm/shipit/trunk/, skipping it." is a message i get after rocketfuel-get finished. what now?
[17:04] <bigjools> Knut-HB: do you get that for any others?
[17:04] <bigjools> if not, it's ok
[17:05] <Knut-HB> now i don't think so
[17:05] <bigjools> ok
[17:05] <bigjools> no other errors from rf-get?
[17:05] <Knut-HB> no, couldn't see any
[17:05] <bigjools> rf-get does a "make" when it finishes
[17:05] <bigjools> so that's good
[17:05] <bigjools> let's see if make build works now!
[17:06] <Knut-HB> now make build made some more stuff but quits with errors
[17:06] <bigjools>  /o\
[17:06] <Knut-HB> "no rule to make target `build''"
[17:06] <bigjools> ok
[17:06] <bigjools> make schema
 "no rule to make target `build''"
[17:07] <bigjools> geez
[17:07] <bigjools> "make" gives the same error I guess
[17:07] <beuno> mthaddon, could you rename: https://edge.launchpad.net/research38917 to archive-behavior-research?
[17:07] <Knut-HB> wow, how did you know that? ;)
[17:07] <bigjools> I am psychic
[17:07] <Knut-HB> O.O
[17:07] <bigjools> so
[17:08] <bigjools> let's try make clean
[17:08] <Knut-HB> did a lot of "rm -rf" stuff
[17:08] <bigjools> and make
[17:08] <mthaddon> beuno: done
[17:08] <beuno> mthaddon, you rock, Thanks.
[17:09] <Knut-HB> ok, it's working longer now and so far no errors
[17:09] <Knut-HB> shhh.py is doing something
[17:09] <bigjools> \o/
[17:09] <mthaddon> kiko: so are you expecting any more submissions before the rollout?
[17:10] <Knut-HB> bigjools, is that good?
[17:10] <bigjools> Knut-HB: are you back at the prompt?
[17:10] <Knut-HB> not yet
[17:10] <Knut-HB> is that good too?
[17:10] <bigjools> yeah it takes a while
[17:10] <bigjools> it makes the api docs
[17:10] <Knut-HB> so chances are high it works when this step is finished?
[17:11] <bigjools> let's not go that far yet :)
[17:11] <Knut-HB> hmpf -.- ok :p
[17:11] <kiko> mthaddon, would you be a love and give me a URL to buildbot as my bookmarks died?
[17:11] <bigjools> if it finishes ok, then you need "make schema"
[17:11] <Knut-HB> ok
[17:11] <bigjools> kiko: buildbot.devpad.info
[17:11] <mthaddon> what he said :)
[17:15] <Knut-HB> bigjools, ok, after doing a long time some stuff in the background make finished with "*** No rule to make target `build'. Stop."
[17:15] <Knut-HB> make schema?
[17:15] <bigjools> that's not good
[17:15] <bigjools> your makefile sounds screwed
[17:16] <Knut-HB> sounds not good
[17:16] <bigjools> can you find a build target in it?
[17:16] <bigjools> about line 114
[17:16] <Knut-HB> where can i find the file?
[17:16] <bigjools> top of devel
[17:16] <bigjools> your're in that directory already, right?
[17:17] <Knut-HB> yep
[17:17] <Knut-HB> line 114 says the following
[17:18] <Knut-HB> "build: $(BZR_VERSION_INFO) compile apidoc"
[17:18] <bigjools> ok try make build, in the devel dir
[17:19] <Knut-HB> bigjools, "*** No rule to make target `build'. Stop."
[17:19] <bigjools> !
[17:20] <Knut-HB> bigjools, but i have to go now =/
[17:20] <bigjools> make compile
[17:20] <bigjools> make apidoc
[17:20] <bigjools> ?
[17:20] <bigjools> ah ok
[17:20] <Knut-HB> same errors
[17:20] <Knut-HB> both compile and apidoc
[17:20] <bigjools> weird, you just showed me the makefile
[17:20] <bigjools> make -F Makefile build
[17:21] <bigjools> -f sorry
[17:21] <bigjools> lower case
[17:21] <Knut-HB> error
[17:21] <bigjools> same one?
[17:21] <Knut-HB> would it be the best to just delete the whole launchpad-folder and download it again?
[17:21] <Knut-HB> yes
[17:22] <bigjools> ok, delete lp-branches and re-run the rocketfuel-setup script
[17:22] <Knut-HB> i will asap
[17:22] <bigjools> save it first
[17:22] <bigjools> it's in lp-branches :)
[17:22] <Knut-HB> it's all in the log so i won'T forget ;)
[17:22] <Knut-HB> thanks for the help dude
[17:22] <bigjools> ok good luck
[17:22] <Knut-HB> thanks
[17:23] <kiko> mthaddon, there doesn't seem to be anything critical I've found yet
[17:23] <kiko> so I think it's on-track
[17:23] <mthaddon> kiko: that's what I like to hear :)
[17:36] <Ursinha> ping rockstar
[17:42] <tfmoraes> Hi all
[17:43] <mars> hi tfmoraes
[17:43] <tfmoraes> I have just installed the launchpad
[17:43] <tfmoraes> hi
[17:43] <tfmoraes> Is there a default user?
[17:44] <Ursinha> tfmoraes, foo.bar@canonical.com:test
[17:44] <Ursinha> afair :)
[17:44] <tfmoraes> thank you
[17:45] <tfmoraes> it works!
[17:45] <mars> tfmoraes, you can find the full sample data user list in lib/canonical/launchpad/pagetests/README.txt
[17:46] <tfmoraes> Thanks
[17:47] <Ursinha> tfmoraes, cool :)
[17:57] <mars> Added the default user and password to the /Getting page
[17:57] <mars> should make it easier for everyone else
[17:58] <intellectronica> how do i cause a 404 from python view code? do i raise NotFoundError?
[17:59] <mars> intellectronica, try that first, it might bubble up to the right spot in the publisher
[17:59] <matsubara> tfmoraes, foo.bar@canonical is deprecated. use admin@canonical.com instead for an admin user or test@canonical.com for a regular user
[17:59] <bigjools> mars, add it to the FAQ as well
[17:59] <mars> intellectronica, if it doesn't work, look at raising it from one of the traversal-associated methods of the view
[18:00] <mars> bigjools, ah, matsubara was to /says too late :)
[18:00] <mars> at least the wiki is editable
[18:00] <bigjools> fancy that
[18:01] <mars> matsubara, passwords are still 'test'?
[18:02] <matsubara> mars, yes
[18:05] <tfmoraes> thanks
[18:05]  * gmb EODs
[18:13] <tfmoraes> Other question
[18:14] <tfmoraes> If someone try to access my self-hosted launchpad
[18:15] <tfmoraes> It doesn't locate the launchpad.dev
[18:16] <maxb> It is not accessible other than from the machine it's running on
[18:17] <tfmoraes> Is there a way?
[18:19] <maxb> You'd have to dig into the guts and work out how to reconfigure it
[18:20] <tfmoraes> any tip?
[18:21] <maxb> no, I've only just convinced it to run in the default configuration myself
[18:22] <tfmoraes> thanks
[18:23] <matsubara> tfmoraes, there's a way to make it accessible in your LAN. does it help?
[18:23] <tfmoraes> yes
[18:24]  * matsubara looks for docs
[18:24] <andrea-bs> Hi! Why utilities/rocketfuel-branch does not create stacked branches?
[18:24] <sinzui> tfmoraes: When I want to QA my .dev instance from another machine on my how network. I edit <Proxy *> Allow from 127.0.0.0/255.0.0.0 in /etc/apache2/sites-enabled/local-launchpad
[18:25] <sinzui> tfmoraes: you need to add an allow block for you lan
[18:28] <tfmoraes> to all VirtualHost ?
[18:32] <matsubara> tfmoraes, http://pastebin.ubuntu.com/224529/
[18:32] <matsubara> I'll move the corresponding doc from our internal wiki to the public wiki
[18:32] <matsubara> it just needs some cleanup first
[18:36] <tfmoraes> thanks again
[18:39] <joey> jtv: is that you are a bot? :-)
[18:39] <joey> s/are/or/
[18:39] <henninge> jtv: a bot
[18:39] <jtv> joey: why does everyone want to do Turing tests today?
[18:39] <henninge> joey: a bot
[18:39] <henninge> ;-)
[18:39] <joey> lol
[18:39] <joey> it's just really late for you to be online jtv
[18:40] <joey> here you go henninge, here's your 20 marks
[18:40]  * joey laughs.
[18:40] <jtv> joey: yes, I've been trying to land an RC branch for... a day and something.
[18:40]  * henninge looks for a bank that will still trade them into Euros.
[18:40] <joey> jtv: haven't seen you in ages it seems like. Doing well I hope.
[18:40] <jtv> joey: great, thanks.
[18:40] <jtv> joey: still getting used to not typing "Rinchen"
[18:41] <launchpad> this better jtv ?
[18:41] <launchpad> :-)
[18:41] <Ursinha> lol!
[18:41] <jtv> launchpad: no :)
[18:41] <Rinchen> ok then
[18:41] <jtv> ah, that's better
[18:41]  * Rinchen laughs.
[18:41] <jtv> Yup, just like old times
[18:41] <Rinchen> nameserv just loves me
[18:42] <Rinchen> I grabbed launchpad for the day we add IRC two-way comms into LP
[18:42] <jtv> I usually get messages from the other two brothers, Nick & Chan Serv.
[18:42] <joey> Yeah. Mine are all linked of course so they leave me alone, generally.
[18:44] <maxb> Is it notmal to get Python MemoryError exceptions if your devenv is not beefy enough, or have I stumbled across one of the reasons why LP isn't supported on Python 2.5 yet?
[18:44] <maxb> *normal
[18:49] <henninge> jtv: EOD for me. You can see my work output in rosetta@ ;-)
[18:49] <jtv> henninge: just spotted it.  Impressive!
[18:49] <jtv> Gute Nacht
[18:50] <henninge> jtv: but there is more in the queu for tomorrow. Some were over a month old, I just hope the delay is not annoying people more than it helps.
[18:50] <henninge> jtv: Tschüß!
[18:50]  * henninge needs to learn some Dutch phrases ....
[18:58] <jtv> gah, still no PQM?
[19:09] <jtv> sinzui, still no luck with pqm/buildbot?
[19:09] <sinzui> jtv: I did land to PQM, and herb whipped buildbot to work
[19:10] <jtv> sinzui: my branch is still failing with /bin/false
[19:10] <jtv> any idea why that might be?
[19:10] <jtv> I thought it was the same problem you had.
[19:12] <sinzui> jtv: I did a direct submit to PQM using the --submit-branch option for db-devel
[19:13] <jtv> sinzui: oh, I've been trying to land on devel—also using pqm-submit.
[19:13] <sinzui> jtv: devel will fail, only db-devel can be landed
[19:13] <jtv> why is that?
[19:13]  * sinzui thinks this is a bug in the process
[19:14] <sinzui> because we do not have a sanity check in our build/deploy process to no not to deploy changes to edge if only db-devel is being used
[19:15] <jtv> sinzui: so all this time, "/bin/false" meant "please submit to db-devel instead"?
[19:17] <abentley> Does anyone know why versions.cfg for stable and db-stable requires bzr 1.17 when bzr+ssh://bazaar.launchpad.net/~launchpad/lp-source-dependencies/trunk/ only has bzr1.17rc2?
[19:33] <tfmoraes> Other question
[19:34] <tfmoraes> And the "bzr launchpad-login" ?
[19:35] <tfmoraes> If I try that, it tries to log in the launchap.net
[19:39] <thumper> tfmoraes: it doesn't log in, but it does check that the user exists and has ssh keys
[19:41] <marc0s> hi all
[19:42] <marc0s> should i care about a NoSuchRevision error branching pygettextpo?
[19:42] <marc0s> using rocketfuel-setup
[19:42] <mars> abentley, bzr blame said jml last updated the line, and I see 1.17rc1 here
[19:43] <maxb> Hi, I'm trying to do a perfectly standard setup on LP on Jaunty, and am getting: ImportError: /home/maxb/launchpad/lp-sourcedeps/eggs/storm-0.14stub_storm_launchpad_288-py2.4-linux-i686.egg/storm/cextensions.so: undefined symbol: PyUnicodeUCS2_Format
[19:44] <tfmoraes> I have logged in the launchpad with  foo.bar@canonical.com
[19:44] <tfmoraes> and the username is name16
[19:44] <mars> marc0s, you can always try rocketfuel-get after rf-setup finishes.  If there is a problem, it will re-fetch it.
[19:45] <mars> tfmoraes, yep, long time holdover
[19:45] <maxb> marc0s: IIRC someone said that is triggered by a bug in rocketfuel-get, now fixed. The first thing to try would be to ensure your LP devel branch is up to date, delete the pygettextpo local branch, and try again.
[19:45] <tfmoraes> then I tried "bzr launchpad-login name16"
[19:45] <tfmoraes> And it shows bzr: ERROR: The user name name16 is not registered on Launchpad.
[19:46] <mbt> Just curious, does LP do administration in its UI, or is that all external to the Web app?
[19:46] <pkern> There is some in the UI.  But not administration of LP itself, AFAICS.
[19:47] <tfmoraes> But I've registered her ssh keys
[19:47] <marc0s> thanks mars and maxb i'll try now with rocketfuel-get
[19:47] <tfmoraes> and the user exists
[19:47] <abentley> mars: I think you're out of date.  This was done in revno 8970
[19:47] <mbt> Yeah, I was thinking a "superuser" type of user in LP that could go around and do things like delete projects, etc., though having a way to install a DB with zero data would probably serve a similar purpose.
[19:48] <mars> abentley, yep 8969 here
[19:48] <mars> mbt, some of that stuff has to be done in the DB directly
[19:49] <mars> tfmoraes, are you trying to point bzr launchpad-login at your local LP instance?
[19:50] <tfmoraes> yes
[19:50] <mbt> mars: And I assume there are no scripts that do this?  I haven't had a chance to browse the entire source tree yet, but it seems that good 'ol psql is your friend there.
[19:50] <kiko> mthaddon, did we unjam PQM?
[19:50] <mthaddon> kiko: was it jammed?
[19:50] <mars> mbt, you would have to ask the Launchpad Operational System Administrators (a.k.a LOSAs)
[19:51] <kiko> I thought jtv suggested it was, but maybe he was confused
[19:51] <mars> tfmoraes, I'm not sure you can do that with the basic plugin.  Might mean a change to the bzr source?  One of the bzr devs in here might know.
[19:51] <jtv> kiko: it kept failing with "/bin/false", I thought sinzui had the same
[19:52] <kiko> mthaddon, at any rate I think what's in buildbot is what will go live unless we find anything critical from then until now
[19:52] <tfmoraes> mars, there is other way to checkout the source code?
[19:52] <kiko> mthaddon, I've asked other leads to review the OOPS listings
[19:52] <mthaddon> kiko: ok, cool
[19:53] <abentley> mars: There's no need to do that.  bzr will use the default user from the ssh config, sabdfl
[19:53] <mthaddon> kiko: 'Commit message [[release-critical=flacoste][ui=none][r=mwhudson][bug=401835] Fix\n\tcommit-translations-to-branch: repeated path error.] does not match commit_re [(?is)^\\s*(?:\\[(?:release-critical=[^\\]]+)\\]\\s*\\[(?:rs?=[^\\]]+)\\]|\\[rs=buildbot-poller\\])]'
[19:53] <mars> tfmoraes, from a local LP instance?  not sure
[19:53] <tfmoraes> mars, yes from local LP
[19:53] <mars> tfmoraes, abentley might know, as he is on the code hosting team :)
[19:54] <abentley> mars: ^
[19:54] <mars> tfmoraes, <abentley> mars: There's no need to do that.  bzr will use the default <abentley> mars: There's no need to do that.  bzr will use the default user from the ssh config, sabdfluser from the ssh config, sabdfl
[19:54] <mars> yay, thanks xchat
[19:54] <kiko> mthaddon, that should work, no?
[19:55] <jtv> no, the regex no longer expects the [ui=none]
[19:55] <sinzui> mthaddon: herb: buildbot completed a build with RC fixes in it. Can staging be updated so that we can verify them?
[19:56] <mthaddon> sinzui: does it include DB updates since the last staging update?
[19:56] <sinzui> mthaddon: I do not think so. /me looks
[19:58] <sinzui> mthaddon: no db changes. templates and browser code  and images.
[19:59] <mthaddon> sinzui: revno 8312?
[20:00] <sinzui> yes
[20:01] <tfmoraes> mars, I added the name16 in ssh config
[20:02] <mars> maxb, do you have /usr/include/python2.4/Python.h on your system?
[20:02] <maxb> Hmm. I'm confused. How can anyone have a working LP devenv on Jaunty when Jaunty's Python is built using UCS4, but one of the LP eggs is built for a Python using UCS2 ?
[20:02] <tfmoraes> Then I do a bzr branch, but it shows this error "You have not informed bzr of your Launchpad ID, and you must do this to ... "
[20:02] <maxb> mars: yes
[20:04] <maxb> tfmoraes: I think you should only be using bzr lp: urls for interacting with the real launchpad. You probably need to use http:// or bzr+ssh:// to talk to your dev instance
[20:04] <tfmoraes> I will try
[20:04] <pkern> I wonder how many knobs I need to push to get an uploader listed for a distroseries. o_O
[20:05] <mars> maxb, how did you find that the egg uses UCS2?  Perhaps I could check my local setup in comparison
[20:06] <maxb> I assumed that based on the text of the error message: "undefined symbol: PyUnicodeUCS2_Format". I could unzip the egg and run nm on the .so - /me does that now
[20:06] <mthaddon> sinzui: staging updated
[20:06] <sinzui> thanks mthaddon
[20:07] <mthaddon> yah
[20:07] <maxb> oh gosh, it's not a prebuilt egg, is it. Hrm
[20:07] <maxb> Gah
[20:08] <maxb> ok, I know what has happened, I didn't find all the places I needed to clean after accidentally building with the wrong python
[20:08] <mars> ah, that could do it
[20:09] <mars> maxb, yep, mine is built with PyUnicodeUCS4
[20:09] <maxb> Hmm, rm -r lp-sourcedeps/eggs/* seems to have borked things quite a bit
[20:09] <mars> just kill the eggs/ directory
[20:10] <mars> it is a make target, 'make' will recreate it
[20:10] <maxb> I seem to have confused the build, now I get an ImportError for pytz
[20:13] <mars> do you have eggs/pytz-2009j-py2.4.egg?
[20:14] <sinzui> EdwinGrubbs: ping
[20:14] <maxb> well no, because I just deleted everything in eggs/ :-)
[20:14] <EdwinGrubbs> sinzui: hi
[20:14] <maxb> I've run "make clean; make" - it's doing stuff
[20:14] <sinzui> Edwin, can you verify that IE 8 can create a project on staging?
[20:15] <EdwinGrubbs> sinzui: yes, I already ran that test and marked it on the wiki.
[20:15] <sinzui> rock
[20:16] <sinzui> EdwinGrubbs: do you agree the sprite is fixed: https://staging.launchpad.net/launchpad-registry/2.2/+addrelease
[20:17] <EdwinGrubbs> sinzui: yes, I hadn't seen that staging was updated with the last few revisions, but it looks good.
[20:18] <sinzui> EdwinGrubbs: it just happened. That is why I am checking.
[20:39] <sinzui> matsubara: ping
[20:40] <matsubara> sinzui, hi curtis
[20:41] <sinzui> matsubara: There are two registry bugs that are still bad, blocked by anther bug we are fixing. I don't think they are an issue because the feature is only used by admins, and the problem will be fix either in a reroll, or Monday when the fix lands on edge
[20:42] <sinzui> matsubara: So I can move the bugs to the rc fixed area, or move them to a 2.2.8 test plan
[20:42] <matsubara> sinzui, you mean the adminteammerge bugs?
[20:43] <sinzui> yes, both of those
[20:44] <matsubara> sinzui, remember that timeouts on staging have a lower threshold. are those timeouts under 25s?
[20:45] <matsubara> and what is the other bug you're fixing that will fix both of those?
[20:45] <kiko> sinzui, they are not rcfixed; they are BAD, I think
[20:45] <kiko> sinzui, and then the decision is to roll out with those items as BAD
[20:46] <sinzui> I have not tested them since they are blocked by the other bug. We believe the other bug is a performance issue for many timeout bugs
[20:46] <sinzui> kiko: understood
[20:46] <matsubara> sinzui, as kiko suggested leave them as BAD and make a note in the test plan pointing to the other bug that will solve both BADs
[20:47] <matsubara> that way we'll know what we're still waiting for the re-roll
[20:49] <sinzui> matsubara: kiko: registry is ready for the rollout
[20:49] <matsubara> thanks sinzui
[20:49] <matsubara> Ursinha, ^
[20:49] <kiko> thanks
[20:49] <Ursinha> me
[20:49] <Ursinha> thanks matsubara
[20:52] <maxb> Is there an open bug for making LP work on Python 2.5? Or any preexisting discussion I can read on the topic?
[20:52] <kiko> maxb, gary will be working on that as soon as he has zope running from buildout
[20:53] <maxb> So I should just keep an eye on this channel then?
[20:53] <sinzui> maxb: look in launchpad-foundations. The issue is a really a story, not a bug, but it is probably in there
[20:54] <maxb> Doesn't seem to be - oh well
[20:59] <mars> maxb, nothing yet, but as kiko said, it's coming: https://dev.launchpad.net/VersionThreeDotO/Foundations
[20:59] <maxb> sure, I'm just curious to follow it as it evolves
[20:59] <Snova_> Why is rocketfuel-setup installing what appears to be an entire texlive setup?
[21:00] <mars> texlive?
[21:00] <Snova_> Well, lots of texlive-* packages, which are probably the reason apt-get is going to download 277 MB when I press y.
[21:01] <maxb> I had a go at coaxing it to run under Python 2.5 on karmic myself, but am stuck on MemoryErrors being thrown from the depths of Zope/TAL
[21:01] <mars> Snova_, somewhere in the launchpad-developer-dependencies chain I would guess
[21:02] <mars> try installing firefox on a server, and you'll be astounded by what it pulls in :)
[21:11] <EdwinGrubbs> bac: did your fix for the team merge timeout land?
[21:11] <bac> EdwinGrubbs: no.  i'm not going to submit for this release
[21:12] <Snova_> Ahah! I think it's python-epydoc; texlive stuff is in the Recommends.
[21:13] <mars> Snova_, or it could be a build-depends - apt-rdepends shows some stuff there, too
[21:15] <bac> EdwinGrubbs: delaying until PQM opens doesn't affect you does it?
[21:16] <EdwinGrubbs> bac: well, it just means that I can't QA my fix for deactivating the members of a team, so it's really not a big deal.
[21:16] <Snova_> mars: Well, installing it without the recommended packages seems to have gotten around it, though something else might want it later. It looks like it's only used for documentation, though.
[21:16] <bac> EdwinGrubbs: yeah, i'm in the same boat for +adminteammerge
[21:27] <shriven> hello. I'm trying to run the rocketfuel-setup and I'm getting errors like this:
[21:27] <shriven> make: *** No rule to make target `install'.  Stop.
[21:27] <shriven> ERROR: Unable to install apache config appropriately
[21:28] <shriven> anyone know whats up?
[21:28] <mars> shriven, could you please put the output of the 'make' error into a pastebin?  That will help us diagnose it
[21:29] <shriven> sure
[21:30] <shriven> mars: when you say the "make" error, what command are you envisioning me running to get said error?
[21:30] <shriven> all I've done so far is ./rocketfuel-setup
[21:30] <mars> shriven, just the output from rocketfuel-setup so far will do
[21:30] <shriven> ok
[21:31] <mars> I'd like to see the last lines, to get an idea about what it was doing
[21:31] <shriven> http://pastebin.ca/1503603
[21:31] <shriven> thats the last 10 lines or so
[21:32] <shriven> I had previously finished the package installation and was just pking around
[21:32] <shriven> so thats all there is
[21:32] <shriven> currently the bzr login just sits... I let it try for a few minutes then hit cntrl-c to it
[21:32] <shriven> and it moved on
[21:33] <mars> it moved on, then dies with this error later?
[21:33] <shriven> yea, just a few seconds later
[21:34] <mars> lets start by checking what rocketfuel-setup is doing at this point
[21:34] <shriven> sure
[21:35] <shriven> just ran it again... this time bzr login seemed to suceed, same apache error though
[21:36] <mwhudson> good morning
[21:36] <mwhudson> shriven: are you a sudoer on this system?
[21:36] <shriven> yup
[21:36] <mwhudson> though it looks like the checkout must have failed
[21:36] <shriven> its a VM
[21:37] <shriven> well I don't see it doing any bzr work at all
[21:37] <dobey> holas wonderful lp hackers
[21:37] <mwhudson> oh
[21:38] <dobey> i was wondering... is there any special reason that branch_merge_proposal.createComment() in the API a) requires the subject argument, and b) doesn't seem to behave the same as if i carete a comment via the lp web ui?
[21:38] <mars> shriven, "sudo make install" in devel/ fails, I'm guessing
[21:38] <mwhudson> shriven: it looks like getting a copy of the branch may have partially succeeded or something
[21:39] <mars> shriven, check the root Makefile, you'll see what the 'install' target is doing
[21:39] <shriven> there is no devel/
[21:39] <shriven> maybe I missed a step?
[21:39] <shriven> I thought I combed over it a few times....
[21:39] <mwhudson> shriven: what files have been created?
[21:39] <shriven> let me go re-read
[21:39] <shriven> just rocketfuel
[21:39] <mwhudson> shriven: ~/launchpad, ~/launchpad/lp-branches, ~/launchpad/lp-branches/devel ??
[21:40] <shriven> nothing exists below launchpad except rocketfuel
[21:41] <shriven> this is where I'm starting at, am I mistaken in doing this? https://dev.launchpad.net/Getting#Getting%20It
[21:42] <shriven> I saw the alternate source code download... I am assuming it really is alternative and rocketfuel will download the source itself?
[21:42] <mars> shriven, it will
[21:43] <shriven> yeah, that must be the part that is failing for some reason
[21:43] <shriven> there really isn't a target for make install
[21:44] <mars> shriven, yes, odd, rf-setup should have failed on line 368
[21:44] <mars> cd $LP_TRUNK_NAME
[21:44] <shriven> yes, I'm just browsing that myself
[21:45] <shriven> or earlier at 354?
[21:46] <mars> yep
[21:46] <shriven> hmmm is it hardcoded somewhere that we must have our launchpad directory at ~/launchpad?
[21:46] <shriven> I put mine in ~/Applications/launchpad
[21:46] <shriven> preferring to do this sort of thing there
[21:46] <mwhudson> shriven: you can create a file ~/.rocketfuel-env.sh that sets some shell variables
[21:46] <shriven> ah!
[21:47] <shriven> yes, ~/launchpad/lp-branches has been created
[21:47] <mwhudson> i think LP_PROJECT_ROOT=~/Applications/launchpad will do what you want
[21:47] <mars> shriven, line 47+ in rf-setup
[21:47] <shriven> ok
[21:47] <shriven> I'll just use the default way
[21:47] <shriven> thanks guys
[21:52] <mars> mwhudson, do you remember what the 'bucket' argument is when creating an image?
[21:53] <mwhudson> mars: is that an argument to ec2-bundle-vol?
[21:53] <mars> yes
[21:54] <mwhudson> no, it doesn't look like i passed it
[21:55] <mwhudson> mars: are you sure you don't mean ec2-upload-bundle ?
[21:55] <mars> mwhudson, ah, sorry, yes
[21:55] <mwhudson> then it's the name of the ami, basically
[21:55] <mwhudson> you want launchpad-ec2test10 or whatever
[21:56] <mars> right, ok, thanks
[21:56]  * mwhudson is extremely glad he kept his notes from when he did all the image diddling
[21:56] <mars> I just did it from the AWS docs
[21:57] <mars> mwhudson, here, I'll bundle the script I have, so you can take a peek
[21:57] <mars> it automates image creation
[21:57] <mwhudson> same here, but it took a while and some hopeful guessing
[21:57] <mwhudson> ah, awesome
[21:57] <mars> and instance configuration
[21:58]  * dobey wonders about this createComment() method
[22:00] <mars> mwhudson, lp:~mars/lp-dev-utils/add-windmill-image-generator/
[22:26] <dobey> hrmm
[22:30] <marc0s> i started over with rocketfuel-setup and i got an ssh key error after apache setup
[22:30] <marc0s> Host key verification failed.
[22:30] <marc0s> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[22:30] <marc0s> any clues on that?
[22:31] <marc0s> i told my real launchpad username to rocketfuel-setup when it asked me for a launchpad username
[22:32] <mars> marc0s, what was the last line of successful rf-setup output before the failure?
[22:32] <mars> so I know how far rf-setup go
[22:32] <mars> got along
[22:33] <marc0s> mars: http://dpaste.com/70131/
[22:33] <marc0s> so you have more lines to check
[22:34] <marc0s> before that, some apache modules were enabled and apache reloaded
[22:35] <mars> looks like it dies around line 373 maybe?
[22:35] <mars> no, that can't be right
[22:36] <mars> line 425+ somewhere
[22:36] <marc0s> or maybe 361 ?
[22:36] <marc0s> let me check 425 ...
[22:37] <mars> marc0s, I would suspect line 485 then - rf-get itself may have died on you
[22:37] <marc0s> yes, the supermirror one
[22:38] <marc0s> if i launch rf-get it dies with the same error
[22:38] <mars> if so, then no worries, you can just run it manually.  The rest of the configuration suceeded
[22:38] <mars> good! :)
[22:38] <marc0s> good? :)
[22:38] <marc0s> how should i continue now?
[22:39] <mars> that means we have narrowed the error down to a single script, probably ssh authentication
[22:39] <marc0s> with the make schema && make run stuff ?
[22:39] <marc0s> ok
[22:39] <mars> well, not having rocketfuel-get may be a problem, it implies you can't fetch stuff over bzr+ssh.
[22:40] <mars> marc0s, did you supply an SSH key for your launchpad user account?
[22:40] <marc0s> not an ssh key from this machine, so i was asking if i should before :)
[22:41] <mars> I think it will work to run an instance of LP, but you won't be able to check in code, or use rf-get
[22:41] <mars> does deve/sourcecode have symlinks in it?
[22:41] <mars> devel/sourcecode
[22:42] <marc0s> not at all
[22:42] <marc0s> just a makefile
[22:43] <mars> hmm
[22:43] <mars> rocketfuel-get runs 'utilities/link-external-dependencies'
[22:44] <mars> which populates devel/sourcecode/
[22:44] <mars> so you won't be able to proceed to 'make schema' without running that, or getting rf-get going.
[22:45] <marc0s> hmm no good news :P
[22:45] <marc0s> do you think uploading the ssh key will let me continue the bzr fetching process?
[22:46] <mars> I'm not sure if it is the key that is the problem, or that it doesn't like bazaar.launchpad.net itself.  You may be able to add that manually to your known_hosts file
[22:47] <mars> marc0s, on a whim, what happens if you try 'ssh bazaar.launchpad.net'?
[22:47] <marc0s> i've uploaded the key and it seems to be fetching more stuff
[22:47] <marc0s> i try
[22:47] <marc0s> No shells on this server.
[22:47] <marc0s> and connectoin closed
[22:47] <mars> ah, nm then :)
[22:48] <mars> you added the key?  and rf-get is running now?
[22:48] <marc0s> it seems to, it's downlading :)
[22:49] <marc0s> hope it finishes before the maintenance downtime scheduled to be in 10 minutes :D
[22:49] <mars> I don't think that will affect it.  It should be a read-only switchover.
[22:49] <mars> not full downtime?
[22:50] <marc0s> ah ok
[22:50] <salgado> sinzui, is distributionsourcepackagecache.py really meant to be in lp/registry?
[22:50] <marc0s> i don't know just seen that on the web after uploading the key
[22:50] <lifeless> how long will the maintenance be?
[22:50] <lifeless> oh, 1 hour
[22:51] <jml> hello everybody
[22:51] <mars> good morning jml
[22:51] <mwhudson> hello jml
[22:52] <Shane_Fagan> I was wondering about apturl in launchpad. I was thinking of writing support for it because I would think it would be quite useful for answers. Would anyone be able to offer some guidance?
[22:53] <salgado> Shane_Fagan, sure!
[22:54] <Shane_Fagan> Ok so im downloading the source at the moment
[22:54] <Shane_Fagan> So give me about 15 minutes and then ill start asking a few questions and hopefully get hacking after that
[22:57] <mars> It would be cool if bzrlib could handle reconciliation between CLI options and CFG file options supplied to a script :/
[22:58] <mwhudson> mars: lp:~mars/lp-dev-utils/add-windmill-image-generator/ looks fairly nice, if still a bit shell script ish
[22:58] <mars> You have to manually merge optparse and ConfigParser into a new class to get that to happen with the stdlib
[22:59] <mars> mwhudson, shell-ish? :)
[22:59] <mwhudson> mars: now write a version that updates the ec2test-ish
[22:59] <mwhudson> mars: well, maybe that's not quite right
[22:59] <mwhudson> mars: copy-and-paste ish from ec2test
[22:59] <mars> yeah, there is a good reason for that
[22:59] <mwhudson> i can believe it
[22:59] <jml> that reminds me
[23:00] <mars> that reason being that I did not want to risk breaking ec2test at all, and I needed some features to be factored out into smaller bits
[23:00] <jml> is ec2test ok to be a bzr plugin?
[23:00] <mars> jml, no one has objected, but gary is away at OSCON - did he have anything to say on the matter?
[23:00] <mars> he did have plans for the script
[23:01] <marc0s> i think the downtime was total :) connection closed to bazaar.launchpad.net
[23:01] <jml> mars, no definitive answer.
[23:01] <mars> but then, he is also quite pragmatic - if a plugin is better and cleaner, I'm sure he would enjoy doing so
[23:01] <barry> jml, mwhudson, thumper are you guys up for meeting in 29m?
[23:02] <mars> jml, how were you going to land the plugin?
[23:02] <jml> barry, yes
[23:02] <mars> land/distribute
[23:02] <barry> jml: fantastic
[23:03] <jml> mars, simply change ec2test.py to a plugin, ask people to symlink it into ~/.bazaar/plugins
[23:03] <mars> jml, why not land it beside ec2test.py as ec2test_plugin.py?
[23:03] <mars> that way we can transition from one to the other
[23:03] <mars> jml, set-based development :D
[23:04] <jml> mars, "why not" is because it's accompanied by other refactorings to ec2test
[23:04] <jml> to make it more module-like
[23:04] <lifeless> sinzui: hai
[23:04] <Shane_Fagan> Damn does bzr stop in read only mode too?
[23:04] <jml> (and because I want to delete the current option parsing)
[23:04] <mars> jml, ok, that still doesn't prevent you from landing one beside the other, does it?
[23:04] <lifeless> Shane_Fagan: yes
[23:04] <Shane_Fagan> Ah crap
[23:04] <jml> mars, no, it just means more work.
[23:04] <mars> lifeless, I take it read-only mode interrupts the SSH connections?
[23:05] <lifeless> mars: we write to the db when the client disconnects, to trigger scanning, public mirroring, etc
[23:05] <mwhudson> barry: yes
[23:05] <jml> lifeless, not anymore, we write to db on Branch.unlock)(
[23:05] <mars> lifeless, ok, so "yes"? :)
[23:05] <mwhudson> i think codehosting is down during r/o mode at the moment?
[23:05] <lifeless> jml: sftp :P
[23:06] <mwhudson> not strictly necessary
[23:06] <mwhudson> lifeless: the same
[23:06] <jml> lifeless, same.
[23:06] <lifeless> ok cool. I don't want to know how you determine unlock for sftp ;P
[23:06] <jml> lifeless, I won't tell you
[23:06] <lifeless> mars: I don't see the correspondence to SSH connections in what I said :)
[23:06] <ajmitch> magic?
[23:07] <abentley> thumper: http://www.w3schools.com/CSS/pr_text_white-space.asp
[23:07]  * ajmitch would like bugs to still be visible when in r/o mode
[23:08]  * jml too!
[23:08] <mars> time to get the family supper
[23:08] <mars> good night!
[23:08] <marc0s> bye mars
[23:08] <marc0s> thanks! :)
[23:11] <Shane_Fagan> Is it ok that the install stopped like that or will it cause problems?
[23:12] <Shane_Fagan> It was in the middle of getting the branch
[23:17] <Snova_> rocketfuel-setup has failed while branching... I hope this hasn't been asked half a dozen times today already, but http://paste.ubuntu.com/225073/
[23:17] <Shane_Fagan> It maybe because launchpad is in read only mode
[23:18] <Shane_Fagan> Im getting this error http://paste.ubuntu.com/225080/
[23:19] <mwhudson> barry: i need to pop out for a few minutes, maybe 10?
[23:21]  * jml looks at the pastes
[23:21] <jml> Snova_, yeah, sorry about that. Launchpad going down interrupted your pull.
[23:21] <Snova_> jml: Just my luck. :P I'll try again tomorrow, I guess.
[23:21] <jml> Shane_Fagan, you'll need to add an SSH key to your Launchpad account to get rid of that error, I think.
[23:22] <jml> Snova_, it'll be up again in less than an hour.
[23:22] <Shane_Fagan> I have one
[23:22] <Snova_> jml: Yes, but this connection is rather slow, and it's getting late.
[23:22] <jml> Shane_Fagan, is your Launchpad account called 'shane'?
[23:22] <jml> Snova_, ahh, ok. no worries then.
[23:22] <Shane_Fagan> shanepatrickfagan
[23:22] <jml> Snova_, better luck tomorrow
[23:22] <Shane_Fagan> Its worked every other time ive tried it
[23:22] <jml> Shane_Fagan, Launchpad is trying to use 'shane' to SSH in.
[23:23] <jml> "bzr: ERROR: The user shane has not registered any SSH keys with Launchpad."
[23:23] <Shane_Fagan> Ah ill switch and see what happens
[23:23] <jml> Shane_Fagan, type: 'bzr launchpad-login shanepatrickfagan' and you should be right.
[23:24] <Shane_Fagan> Nope still the same error
[23:24] <Shane_Fagan> Ill try it after it comes out of read only mode and see
[23:25] <thumper> sinzui: ping
[23:26] <sinzui> Hi thumper
[23:26] <thumper> sinzui: I've got a question about layers and requests
[23:26] <thumper> sinzui: I'm trying to write a test for my oops on demand branch
[23:26] <thumper> sinzui: which needs a current browser request
[23:26] <thumper> sinzui: how can I easily set one up in a unittest?
[23:27] <sinzui> hmm. I think I had to subclass a TestRequest to do that
[23:28] <barry> thumper, jml, mwhudson -> #launchpad-meeting in 2m
[23:28] <thumper> sinzui: have you done it somewhere?
[23:29] <thumper> sinzui: the thing is I'm using the from lazr.restful.utils import get_current_browser_request
[23:29] <thumper> sinzui: in the code I'm testing
[23:29] <sinzui> thumper: I am looking for an example
[23:29] <thumper> sinzui: cool, ta
[23:32] <jkakar> Aargh.
[23:32] <jkakar> I just lost a huge bug comment because Launchpad is (presumably) in read-only mode and still allows AJAX "in-page" actions to run.
[23:33] <Ursinha> jkakar, argh
[23:33] <Ursinha> I'll file a bug about it, if find any
[23:34] <sinzui> thumper: look at
[23:34] <sinzui> from canonical.launchpad.layers import setFirstLayer
[23:34] <sinzui> setFirstLayer(request, 'CodeLayer')
[23:34] <jkakar> Ursinha: Hmm, I wonder if I'm wrong.
[23:34] <sinzui> thumper: it is just a wrapper for:
[23:34] <sinzui> directlyProvides(request, layer, directlyProvidedBy(request))
[23:34] <intellectronica> jkakar: you mean you opened the collapsing form under the bug tasks table and tried to submit?
[23:34] <jkakar> Ursinha: I was on a bug page, clicking "Add comment", entered my comment and then, after clicking "Submit", I got the "Launchpad Offline" page... but I'd loaded the page before LP went down.
[23:35] <jkakar> intellectronica: Nope, I used the collapsing form for adding a comment.
[23:35] <beuno> jkakar, we need to slap a launchpad.Edit on that link
[23:35] <beuno> when LP comes back, we need a bug  :)
[23:35] <jkakar> Ursinha: If I try and load it now I just get the "Launchpad Offline" page.
[23:35] <jkakar> beuno: Ah, okay.
[23:35] <intellectronica> jkakar: ah ok, so nothing to do with ajax
[23:35] <jkakar> intellectronica: Maybe, I'm not sure.
[23:35] <Ursinha> beuno, I'll file one
[23:35] <intellectronica> ideally we should disable forms like that in read-only mode
[23:35] <jkakar> intellectronica: Yes, exactly.
[23:36] <intellectronica> but in this case, if you loaded the page before LP entered read-only mode that wouldn't have helped
[23:36] <jkakar> intellectronica: The only thing is I loaded the page before LP went read-only, so how would it know in that case?
[23:36] <jkakar> intellectronica: I guess it could ping every now and then to see if LP is alive, but that kind of thing is fraught with terribleness.
[23:36] <intellectronica> with ajax, otoh, we could try, tell you that we couldn't save and ask you to try again later, so there's an opportunity for a better experience
[23:37] <jkakar> intellectronica: Ah, duh, of course.  Use AJAX for the form submit.
[23:37] <jkakar> intellectronica: That'd be nice, yeah.
[23:38] <intellectronica> jkakar: yes. that's coming soon anyway
[23:39] <thumper> sinzui: how does that help?
[23:40] <jkakar> intellectronica: Awesome, thanks.
[23:50] <joey> hey kiko, remember that matrix you put together recently of all the weekly meetings?  If you didn't already think of this, that would be good info to have on the dev wiki for the community devs don't you think?