[00:01]  * mwhudson FINALLY has an automated test case for bug 120977
[00:01] <mup> Bug #120977: cscvs breaks when a cvs merge creates a file <Launchpad CSCVS:In Progress by mwhudson> <NUnit 2.5:New> <https://launchpad.net/bugs/120977>
[00:01] <mwhudson> unfortunately it has a sleep 60, a timezone dependence and i have to hack the cscvs source...
[00:10] <mwhudson> find . -name '*,v' -print0 | xargs -0 sed -ie 's/^date\t[0-9]\{4\}\.[0-9]\{2\}\.[0-9]\{2\}\./date\t2007.01.01./'
[00:10] <mwhudson> :)
[00:15] <thumper> ew
[00:16] <thumper> mwhudson: at least we won't be running cscvs tests when landing LP branches
[00:16] <mwhudson> yeah
[00:16] <mwhudson> thumper: i have a faster testcase now
[00:16] <thumper> :)
[00:16] <mwhudson> that's what that regexp is about though
[00:17] <ajmitch> ugly but readable, why do you need to rewrite the dates?
[00:19] <mwhudson> ajmitch: oh god
[00:19] <ajmitch> that much pain? :)
[00:19]  * ajmitch won't ask
[00:19] <mwhudson> ajmitch: basically because cscvs looks a week in the past because cscvs
[00:20] <mwhudson> because cvs is a bit vague
[00:20] <mwhudson> but i need stuff to have happened longer ago than that
[00:28] <thumper> OSError: [Errno 13] Permission denied: '/var/tmp/bazaar.launchpad.dev/mirrors'
[00:28] <thumper> :(
[00:28] <thumper> grr
[00:28] <thumper> owned by root again!
[00:28] <thumper> WTF??!?
[00:36] <lifeless> mwhudson: cool
[00:43] <spm> mwhudson: hmmm. interesting. just looking at the numbers of requests in the xmlrpc log - was a delay of ~ 15 mins before the service was restarted onto a new log; and can clearly see a drop in the # of requests. ~ 1/4 ish. Ouchy.
[00:44] <mwhudson> spm: :( !
[00:44] <mwhudson> spm: make build suckiness?
[00:44] <spm> mwhudson: I guess....
[00:45] <spm> mwhudson: ahh. I'd put money on the compression phase holding things up.
[00:45] <mwhudson> spm: oh
[00:46] <mwhudson> spm: well, i have this change that will reduce the number of requests by 75% or so ...
[00:46] <spm> be nice!
[00:46] <spm> as in, would be :-)
[02:29] <thumper> spm: can you bounce the buildbot? the db_lp builder seems fubared
[02:29] <spm> thumper: sure
[02:35] <spm> bleh. looks like the slave is borked
[02:39] <spm> thumper: right that seems to have kicked it along.
[02:41] <thumper> spm: ta
[04:28] <JamalFanaian> So, I think the make schema step of the launchpad setup used to ask me what I wanted the psql username to be, but it isn't on this computer and I keep getting the following error:
[04:28] <JamalFanaian> psql: FATAL:  Ident authentication failed for user "jamal"
[04:28] <JamalFanaian> Could I be doing something wrong?
[04:29] <wgrant> JamalFanaian: make sure you've run utilities/launchpad-database-setup
[04:29] <JamalFanaian> wgrant: ah ok! thanks :)
[04:30] <JamalFanaian> wow, i even went back to the wiki to make sure i didn't miss a step.. bah! lol
[04:30] <JamalFanaian> wgrant: thank you
[04:37] <JamalFanaian> ok so now my next question is, how can i configure it to listen to requests to all ips, or at least the external ip, instead of 127.0.0.88...
[04:38] <JamalFanaian> i'm running it in a vm and copied the hosts directives but changed it to point to the ip of the vm (instead of the local ip), but the request is being delivered to apache's default Vhost
[04:39] <wgrant> JamalFanaian: You want to poke at /etc/apache2/sites-enabled/local-launchpad
[04:39] <JamalFanaian> wgrant: thanks again :)
[04:40] <JamalFanaian> awesome, that works perfectly.. thank you!
[04:40] <wgrant> Excellent.
[05:44] <mars> YUI3 beta 1 adds the YUI test suite! \o/
[05:44] <mars> something good to build on
[05:44] <wgrant> So make jscheck can take even longer?
[05:45] <mars> depends if we add our unit test suite to the acceptance test suite
[05:45] <mars> which we might do, for convenience sake
[05:47] <jtv> spm, g'day!  I'm trying to get the translations-export-to-branch output in my error-reports, but I can't seem to find the right topic or something.  Do you know where these logs go?
[05:53] <mwhudson> i get them
[05:53] <mwhudson> so it's probably some code related topic
[06:07] <thumper> mwhudson: I'm going to get a branch to disable spark lines for now
[06:09] <beuno> thumper, I hate you
[06:09] <wgrant> thumper: I love you.
[06:09] <beuno> it
[06:09] <beuno> it's the wrong solution
[06:09] <thumper> beuno: nothing personal
[06:10] <beuno> I know, but only a handful of people complain, and for the wrong reasons
[06:10] <thumper> beuno: it can be fixed...
[06:10] <thumper> beuno: I'm not deleting the code
[06:10] <thumper> beuno: just disabling for now
[06:10] <lifeless> beuno: I don't think looking ugly is a wrong reason :)
[06:10] <thumper> beuno: we can fix it before 3.0
[06:10] <thumper> beuno: but until it is fixed, I'm making the executive decision
[06:10] <beuno> thumper, I'm very against removing a feature under the users, which benefit them
[06:11] <mwhudson> thumper: ok
[06:11] <lifeless> beuno: we're users too though
[06:11] <mwhudson> thumper: i've got that branch of yours mostly reviewed
[06:11] <thumper> beuno: I don't see the benefit that isn't obvious elsewhere
[06:11] <beuno> thumper, activity
[06:11] <beuno> a lot of users use it
[06:11] <thumper> beuno: commit count shows activity
[06:11] <lifeless> beuno: its not showing what they probably think it is
[06:11] <beuno> thumper, not as well
[06:12] <beuno> again, this is personal opinion, versus people who actually use it
[06:12] <lifeless> beuno: I feel like you want to keep something substandard because its graphical
[06:12] <lifeless> beuno: we should probably gather some real data on this. After all, so far we've only got the complaints - there is measurement error possibility there
[06:12] <thumper> beuno: lets work to fix it then... but right now, and for the next few days at least, I'll be gone on edge
[06:12] <beuno> lifeless, if we remove all substandard things in launchpad, we'll remain with a very think software
[06:13] <lifeless> beuno: but it would be beautiful
[06:13] <beuno> thumper, fix what Paul broke?
[06:13] <thumper> beuno: there are more issues with it though, rendering being a big one for lifeless and poolie
[06:13] <thumper> beuno: there are many bugs for the sparklines
[06:14] <thumper> beuno: perhaps we should look to address them when we bring them back
[06:14] <thumper> beuno: but right now, they don't look good
[06:14] <beuno> right *now* they don't. They where good enough a week ago
[06:14] <thumper> no
[06:14] <thumper> they weren't
[06:14] <thumper> there are a lot of bugs with them
[06:14] <thumper> I don't think you've been looking at them
[06:15] <thumper> there are issues with the sparklines on production
[06:15] <lifeless> beuno: they have *never* been good for me.
[06:15] <beuno> I have. They where wonky on the person page (they shouldn't of showed up)
[06:15] <lifeless> beuno: I'm not being difficult.
[06:15] <beuno> lifeless, I know. They have been great for other people.
[06:16] <beuno> anyway, I've said what I think. It your app, so it's all I can do.
[06:18] <lifeless> I think the problem with both our arguments is !citation
[06:18] <lifeless> I'd like to see sparklines that look good and expose useful information
[06:19] <beuno> I can dig up IRC conversations and blog posts where people mention them as what they use to measure activity
[06:19] <beuno> but it feels like a waste of time
[06:19] <beuno> meh
[06:20] <lifeless> I don't want you to waste your time
[06:20] <lifeless> and its thumpers call about this
[06:20] <beuno> yeah, I'm really absolutely off to bed now  :)
[06:20] <beuno> night guys
[06:21] <lifeless> sleep well
[06:23] <thumper> I like the idea of sparklines
[06:23] <thumper> I think they could be really good
[06:24] <thumper> lets make them better
[06:25] <lifeless> yes
[06:25] <lifeless> I would in fact like them on every row, once fixed
[06:26] <lifeless> but unlike data in (say) stocks, our branches are tightly coupled
[06:26] <lifeless> so we need to consider that
[06:28] <thumper> right
[06:28] <thumper> bug 408207
[06:28] <mup> Bug #408207: Branch sparklines are disabled <ui> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/408207>
[06:28] <thumper> I've targetted 3.0 to fix this
[06:45] <stub> What does 'max commits' on the sparklines actually mean?
[06:46] <stub> I just opened https://bugs.edge.launchpad.net/launchpad-code/+bug/408211 for giggles - the colour choices violate our UI standards.
[06:46] <mup> Bug #408211: sparklines using error red and link blue when it shouldn't <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/408211>
[06:49] <thumper> stub: bug 390645
[06:49] <mup> Bug #390645: Sparkline text doesn't make sense <confusing-ui> <Launchpad Bazaar Integration:Triaged by thumper> <https://launchpad.net/bugs/390645>
[06:50] <thumper> mwhudson: there isn't any point landing the fix now as it won't get in before the edge rollout anyway
[06:50] <thumper> mwhudson: I'll check the windmill with rockstar tomorrow
[06:50] <mwhudson> k
[06:55] <mwhudson> thumper: finally reviewed your branch
[06:55] <thumper> mwhudson: thanks very much
[07:04] <mwhudson> thumper: https://code.edge.launchpad.net/~mwhudson/launchpad-cscvs/merge-creates-file-bug-120977-attempt-2/+merge/9573
[07:04] <mwhudson> lifeless: you might like to look at that too ^^
[07:04] <lifeless> mwhudson: remind mem tomorrow
[07:04] <mwhudson> fair enough
[07:17]  * mwhudson is no longer here
[07:20] <thumper> mwhudson: replied, and I'm EOD now
[07:25] <noodles775> Morning
[07:48] <jtv> hi noodles775
[07:48] <noodles775> Hiya jtv :)
[09:18] <jtv> mthaddon, are you here?
[09:21] <stub> Killing translationstobranch(30855), 2009-08-03 03:30:08.209901+00:00, 2009-08-03 03:30:08.304575+00:00
[09:21] <stub> jtv: Doing something in a long transaction? or perhaps a hang.
[09:22] <jtv> stub: have you done that before?  I noticed the export for ddtp-ubuntu got interrupted a few days ago.
[09:22] <jtv> It's just a very large export job.
[09:22] <stub> Killing translationstobranch(21076), 2009-08-02 03:30:09.157374+00:00, 2009-08-02 03:30:09.289792+00:00
[09:23] <stub> Killing translationstobranch(11525), 2009-08-01 03:30:10.466531+00:00, 2009-08-01 03:30:10.590209+00:00
[09:24] <stub> Is there any reason to do that inside the transaction?
[09:24] <jtv> Yes, that matches.  The ddtp-ubuntu exports are taking too long & getting killed off.
[09:25] <jtv> We should be able to break it down into smaller transactions.  That'd benefit exports in general.
[09:26] <stub> Yup. Autocommit mode could be best if you don't need the transactional integrity.
[09:27] <stub> If you do need transactional integrity, it might need refactoring to dump information into a temporary table in one transaction and then export from the holding area in autocommit mode.
[09:27] <mrevell> Howdy Launchpadders
[09:27] <jtv> hi mrevell!
[09:28] <jtv> stub: I don't think we need it that badly.
[09:35] <jtv> mrevell: hey, the What's New list on the front page is still 2.2.6!
[09:35] <jtv> (a little Serbian bird just told me)
[09:36] <mrevell> jtv: I'm afraid I wasn't here for the release (paternity leave) so not everything happened exactly as normal. I need to see if there's a way to get an updated What's New onto production without a roll-out.
[09:36] <danilos> jtv: mrevell was on leave at the time, kfogel was supposed to update it
[09:36] <jtv> danilos: I know, but he's not here now.
[09:36] <danilos> mrevell: sure there is, it's called a cherrypick :)
[09:36] <danilos> jtv: that's even better: blame the one who's not here :)
[09:37] <jtv> danilos: it does mean I can't tab-complete the nick, so that's why I went with mrevell
[09:37] <mrevell> danilos: to be fair to kfogel, I was in a rush to get out the door to tend to my increasingly pained wife, so I may have left the "what's new" requirement out of my "oh my God, can you please do these things" email.
[09:37] <mrevell> heh
[09:38] <danilos> mrevell: you might have, but I remember reminding him about it and sending my items along with it :)
[09:38] <jtv> danilos: he did email them out.
[09:38] <mrevell> Anyway, let's not worry about what happened in the past, let's just make the future a great place to be.
[09:38] <mrevell> haha
[09:38] <mrevell> :)
[09:39] <mrevell> Right, anyway, I'll prepare a branch now and get it through testing and review.
[09:39] <danilos> mrevell: sure, so if you can get a branch ready, I am sure we can have it cherrypicked
[09:39] <mrevell> cool
[09:39] <danilos> mrevell: I'd be happy to restart my work with a review as well :)
[09:39] <mrevell> danilos: superb :) Gimme a few mins to prepare this branch.
[09:39] <danilos> mrevell: np :)
[10:25] <carlos> danilos: hey, you are alive!
[10:26] <carlos> btw, hi ;-)
[10:33] <danilos> carlos: hey hey
[10:33] <danilos> carlos: just back from my holidays :)
[10:33] <danilos> carlos: how's it going? have you tried the new Launchpad? :)
[10:33] <carlos> danilos: I supposed that :-P
[10:34] <carlos> danilos: I didn't have time yet, I only checked it out
[10:34] <danilos> carlos: heh, cool :)
[10:35] <carlos> danilos: btw, congratulations for the release ;-
[10:35] <carlos> ;-)
[10:35] <danilos> carlos: thanks, really happy about it myself :)
[11:00] <deryck> Morning, folks.
[11:01] <noodles775> Hi deryck :)
[11:02] <danilos> jtv, henninge: hey hey, I'd really like to hear your voices, it's been so long!
[11:02] <jtv> danilos: should I sing a bit?
[11:02] <danilos> jtv: I'd love that :)
[11:02] <henninge> danilos: I am sorry, I forgot my headset at home ... :(
[11:03] <jtv> So who's going to do backup vocals?
[11:03] <danilos> henninge: a shame, a shame
[11:03] <henninge> danilos: I can go and grab it if you are willing to wait 10 minutes for my voice ...
[11:04]  * henninge runs off
[11:04] <danilos> henninge: sure, sounds fine :)
[11:04] <jtv> danilos: did you _have_ to say "sounds fine"?
[11:05] <danilos> jtv: of course I did, the sound was splendid :)
[11:05]  * jtv sighs
[11:15] <henninge> danilos, jtv: ready!
[11:15] <jtv> go
[11:15] <danilos> jtv, henninge: calling
[13:06]  * henninge lunches
[13:30] <jtv> herb, hi!  I sent two requests to the LOSAs list.  Have to leave now, but the message-sharing one is the more important one.
[13:32] <jtv> herb, to reiterate: apply https://pastebin.canonical.com/20693/ on staging, then run scripts/rosetta/message-sharing-merge.py -vvv -T -p elisa
[13:32] <jtv> tia :)
[13:33] <jtv> Ah, that should be the -P option (the -T one isn't necessary here)
[13:37]  * jtv afks
[14:01] <mars> sinzui, around?
[14:01] <sinzui> I am
[14:01] <mars> hi sinzui, just wondering if my argument for saving 50% of CHR's project review time swayed you to give the experiment a shot :)
[14:03] <sinzui> I think we need to fix the test/translation/junk problem first
[14:04] <sinzui> The test and translation problems are a regression from the old design
[14:46] <kfogel> jml: mmm, I envy you the real Guinness
[14:46] <jml> kfogel, and an interesting thing came up in discussion
[14:46] <kfogel> jml: hit me :-)
[14:46] <jml> kfogel, heh heh
[14:46] <jml> kfogel, I reckon a lot of the potential Launchpad hackers out there are people who are actually more interested in Ubuntu.
[14:46] <jml> kfogel, there's an internal Canonical wiki page called UbuntuInfrastructureNeeds which has a bunch of stuff that we need to address
[14:46]  * kfogel goes to look at that page
[14:47] <jml> kfogel, we should move much of that page to the dev.lp.net wiki
[14:47] <kfogel> jml: agreed.  Since I'm working in the wiki right now, I'll do that too.
[14:48] <jml> kfogel, and I think, more generally, it'd be worth making it really obvious for people to answer the question "how can I help Ubuntu by patching Launchpad?"
[14:49] <kfogel> jml: I'm torn on that one.  On the one hand, Ubuntu devs are big Launchpad users.  On the other hand, by making Launchpad (including Launchpad development) more attractive to non-Ubuntu-specific upstreams, we can get them using Launchpad more... which would be good for Ubuntu in the long run of course.  So I'm not sure how Ubuntu-pandery to be.
[14:49] <jml> kfogel, fair enough.
[14:50] <kfogel> jml: the answer might be to talk about Launchpad in Ubuntu forums, not in Launchpad forums.
[14:50] <jml> kfogel, perhaps.
[14:50] <jml> kfogel, I'm going to mull over this one, I think.
[14:51] <kfogel> jml: me too.  Some of the answers may become obvious as I'm editing the wiki today.
[14:51] <jml> kfogel, cool :)
[15:02] <mars> gary_poster, btw, do you have any ideas for stub's suggestion of forking buildout for python2.6?
[15:02] <mars> does buildout let you keep a light-weight configuration fork like that?
[15:03] <stub> I was just thinking of a seperate branch with automatic merges like devel -> db-devel
[15:03] <stub> Although I guess running 'make check PYTHON=python2.5' might work just as well
[15:03] <gary_poster> mars, I'm afraid I didn't see that.  Looking.  In any case, the typical approach for that sort of thing is to have a separate .cfg file that extends the normal one (or some other similar variant).  You can specify the cfg to use with the -c option to bin/buildout
[15:04] <mars> gary_poster, lp-dev, maxb's "Launchpad on Python2.5" thread
[15:04] <gary_poster> Yeah I see it
[15:05] <mars> you know
[15:05] <gary_poster> mars, not sure if that's what he meant.  If we have a separate branch then the branch can just modify buildout.cfg as appropriate
[15:05] <mars> it would be nice to have a clear, visual buildbot display from running the suite on 2.6
[15:05] <mars> so we could start running it right now, see the errors
[15:05] <mars> and anyone can start fixing them
[15:05] <mars> *without* running the entire suite
[15:06] <gary_poster> That's a good idea.  I think I'd be more keen on that once I have the zope buildout branch done.
[15:06] <mars> ok
[15:06] <jml> hello :)
[15:06] <mars> hi jml
[15:06] <jml> I'm getting james_w set up with a Launchpad development environment...
[15:07] <jml> and he's getting errors to do with the storm egg
[15:07] <mars> stub or gary_poster, ^ ?
[15:07] <gary_poster> jml, what sort of errors? :-)
[15:07] <stub> Refresh download-cache
[15:08] <stub> (and make sure the power cord is plugged in)
[15:08] <gary_poster> lol
[15:08] <jml> stub, 'bzr up download-cache' is up to date
[15:08]  * jml gets a stack trace
[15:09] <james_w> http://pastebin.ubuntu.com/246303/
[15:10] <jml> Tree is up to date at revision 57.
[15:11] <james_w> # ls /tmp/buildd/launchpad/devel/eggs/storm-0.14trunk_321-py2.4-linux-i686.egg/storm/ | grep cext
[15:11] <james_w> cextensions.c
[15:11] <james_w> cextensions.py
[15:11] <james_w> cextensions.pyc
[15:11] <stub> Any build errors though?
[15:11] <stub> The storm egg is broken, so what happened.
[15:12] <gary_poster> right
[15:13] <stub> storm update happened last commit actually (move from custom branch to trunk), so if this is a genuine problem revert r9024. I have to head off in a few mins though.
[15:13] <stub> make clean; make build
[15:13] <gary_poster> james_w: if you have lost build errors in your terminal, you can remove /tmp/buildd/launchpad/devel/eggs/storm-0.14trunk_321-py2.4-linux-i686.egg and rerun make (or simply run bin/buildout) to try to get the error
[15:13] <stub> Or maybe make clean; rm -rf eggs/*; make build
[15:13] <JamalFanaian> hi, what is the proper way to run the python unit tests? i was trying bin/test using the --test parameter, which runs but results in 0 tests executed
[15:14] <noodles775> JamalFanaian: what's the exact command that you're running? (I generally use -vvt, but not sure why you're getting 0 tests?)
[15:14] <jml> ok.
[15:14] <JamalFanaian> noodles775: bin/test --test=test_person.py
[15:15] <jml> so that seems to have addressed the problem
[15:15] <gary_poster> huh
[15:15] <jml> it seems a bit suboptimal that 'make clean' doesn't actually clean the build
[15:15] <gary_poster> well, good, and, huh??
[15:15] <bigjools> JamalFanaian: use -t test_person
[15:15] <stub> 'bin/test test_person' is what you want.
[15:15] <JamalFanaian> bigjools: stub ok thx :)
[15:15] <jml> gary_poster, yeah, that's where I am :)
[15:16] <stub> --test is a regexp that doesn't match the filename you are specifying
[15:16] <JamalFanaian> stub: oh ok
[15:16] <stub> Because the filename is not what is being matched - the module and testname is
[15:16] <noodles775> JamalFanaian: so for unittests, just leave of the .py ... yes, as bigjools said
[15:16] <JamalFanaian> makes sense, it's running now :)
[15:16] <JamalFanaian> noodles775: yeah it's working now, thank you :)
[15:17] <gary_poster> jml: make clean does clean the build.  it doesn't delete all the eggs, which are shared resources.  I suppose we could have a make clean_eggs but I'm not even in favor of that, because it would affect other branches (at least in the current set up, which has speed advantages)
[15:18] <mars> jml, noted, we need 'make distclean'.  'make clean' already does some stuff to clean up the app server state, but not the initial artifacts
[15:18] <gary_poster> jml: your launchpad build was fine.  an egg was broken.  That's "not supposed to happen" in such a way that rebuilding the egg makes everything happy
[15:19] <jml> gary_poster, I see.
[15:19] <stub> gary_poster: Should buildout trash the egg it just tried to create if the creation fails?
[15:19] <jml> I wonder how 'make clean' interacts with sourcecode/
[15:19] <gary_poster> stub: yeah, that seems like it would be good behavior
[15:20] <jml> answer: it cleans it up incorrectly by accident
[15:21] <gary_poster> jml: good question.  so...not quite sure what the answer means to the buildout story (given the "incorrectly by accident" part)
[15:21] <jml> gary_poster, well, it's hard to determine intent
[15:22] <gary_poster> gotcha :-)
[15:22] <jml> it uses find to recursively delete things that are likely to be build artifacts
[15:23] <gary_poster> jml: huh.  ...I wonder if it therefore would be the cause of this symptom, if it walks into eggs...
[15:23] <jml> I only ever really use 'make clean' when I'm suspecting an error in the build process and want to try again...
[15:23] <jml> gary_poster, that's probably it, actually.
[15:23]  * jml experiments
[15:24]  * gary_poster thinks he's used make clean plenty since buildout-ification and not had a problem like this to his knowledge...
[15:25] <jml> oh, btw, I'm making a branch that removes the 'apidoc' dependency from 'make build'
[15:25] <jml> ahh, got it.
[15:26] <jml> james_w has download-cache in the devel directory
[15:26] <jml> not as a symlink
[15:26] <jml> so find is recursing down into it, whereas it doesn't recurse into symlinks
[15:26] <gary_poster> jml: (apidoc dependency) oh, I thought we needed that for lazr.restful-based tests.  Are you sure that's not the case?
[15:27] <jml> (so my earlier statement about it cleaning up sourcecode was untrue)
[15:27] <gary_poster> jml: "download-cache" just has .tgzs, but I suspect your analysis is true for "eggs" as well, which would in fact cause this symptom
[15:27] <gary_poster> jml: ah ok
[15:27] <jml> gary_poster, right, I meant to say eggs.
[15:27] <gary_poster> cool
[15:27] <jml> gary_poster, so this would explain why we have never seen it.
[15:28] <gary_poster> right exactly.  ...I suppose we could try to make the ``make clean`` target avoid "eggs"?
[15:28] <gary_poster> for this kind of situation:
[15:28] <jml> either that or get it to delete them :)
[15:28] <jml> but it should be one or the other.
[15:28] <gary_poster> sorry, s/:/./
[15:30] <gary_poster> jml: yeah.  ok, unless you want to argue for the deleting the eggs, I'll add a bug for making "make clean" not remove .sos and so on from eggs
[15:30] <jml> gary_poster, +1
[15:30] <gary_poster> coool
[15:30] <jml> so, on the apidocs
[15:31] <jml> there are two things. the first is that we should make the actual step more resilient to failure
[15:31] <jml> the second is that if it's not actually needed to run launchpad locally, then it shouldn't be in 'make build'
[15:31] <rockstar> jml, why in the world are you awake?
[15:33] <jml> rockstar, because it's 3:33pm where I am.
[15:34] <rockstar> jml, I do not think you are where I think you are.
[15:35] <jml> rockstar, I'm in Dublin
[15:35] <rockstar> jml, ah, okay then.
[15:36] <gary_poster> jml: make the actual step more resilient to failure, sure, makes sense.
[15:36] <kfogel> Hey folks, new page: https://dev.launchpad.net/Help .  I'll post/write about these new pages later, as I'm revamping a bunch of stuff, but thought you'd want to know about that one early.
[15:37] <gary_poster> jml: not needed to run launchpad locally: if you are right (don't know) and there's a target that the losas use for building that is not make build (don't know) then makes sense
[15:37] <jml> gary_poster, do you know if it's needed to run launchpad on production?
[15:38] <gary_poster> jml: flacoste would know if it is necessary for development, and leonardr might know.  Have you already determined this?  If not, we should consult leonardr; if he is not sure, I suspect we should consult with flacoste when he is available later this week.  (I do believe this is necessary for launchpad on production, at least because we link to it from the wiki)
[15:39] <jml> gary_poster, I haven't already determined it, but I figure that if I just do some experiments & grepping, I can find out enough.
[15:40] <leonardr> jml, gary_poster: it's necessary for development in the sense that there's a test that verifies its existence
[15:40] <leonardr> which i think is why we put it in make build
[15:40] <jml> leonardr, hi, long time no see :)
[15:40] <leonardr> hi
[15:40] <jml> leonardr, but why is the test there?
[15:40] <leonardr> to make sure that the generation code works?
[15:40] <jml> leonardr, why can't the test run the generation code itself?
[15:41] <gary_poster> jml, can we just address the first problem then (make it more resilient to failure)?  Not clear on what the problems are there
[15:41] <jml> gary_poster, yes. that's easy enough.
[15:41] <jml> the problem is that the way the make step works, if it fails, there's an empty file at $API_INDEX
[15:42] <gary_poster> ah yes
[15:42] <jml> so the next time you run 'make build', you get a horrid syntax error
[15:42]  * gary_poster looks mildly guilty
[15:42] <leonardr> jml: well, right now it's a simple pagetest. changing it to run the generation code would mean making it more like a doctest
[15:42] <leonardr> there's no reason why we couldn't do it
[15:42] <mrevell> kfogel: Help page looks good to me
[15:42] <jml> leonardr, ok. I think I'd like to do it then.
[15:42] <gary_poster> jml, leonardr, but I'm not sure what the win is, since we do need it for production, unless there is a different make target that the losas use
[15:42] <kfogel> mrevell: do you know how to color text (not in a table) in moin?
[15:43] <kfogel> mrevell: without installing the separate Color() macro, that is :-).
[15:43] <jml> gary_poster, the win is shaving 20 seconds off every make build run.
[15:44] <mrevell> kfogel: the only way, of which I know, without the macro is using tables
[15:44] <gary_poster> jml: does it still run after an initial build?  I thought I had fixed that.
[15:44] <kfogel> mrevell: ah, okay.  thanks
[15:44] <gary_poster> jml (shaving 20 seconds off every new branch's make build run is nothing to sneeze at; I'm clarifying for my own interests, I suppose)
[15:44] <jml> gary_poster, no, it doesn't, I think.
[15:44] <gary_poster> ok, good, at least.
[15:45]  * jml verifies experimentally
[15:45] <gary_poster> leonardr, jml, am I right that shaving 20 seconds at build time means we regain 20 seconds within test time, given the current proposed change?
[15:46] <leonardr> gary_poster: yeah
[15:46] <gary_poster> mm.
[15:47] <jml> gary_poster, just in time :)
[15:47] <gary_poster> and jml, I apologize for repeating, but do you know if losas have a different build target?
[15:47] <herb> gary_poster: what are you trying to figure out?
[15:47] <jml> gary_poster, no, we don't. I'd definitely want to confirm that before landing the change
[15:48] <jml> herb, I'd like to know which make targets are run as part of the deployment process
[15:48] <herb> jml: confirming. one moment.
[15:49] <jml> herb, thanks.
[15:50] <gary_poster> jml: again feeling mildly guilty, this time for putting brakes on your efforts.  I raised my concerns; now will get out of your way. :-)
[15:50] <jml> gary_poster, no worries at all :)
[15:50] <herb> jml: so, we're kinda all over the place on this.
[15:50] <gary_poster> :-)
[15:50] <herb> jml: at the very minimum we run make build
[15:50] <jml> gary_poster, friendly concern is always appreciated :)
[15:51] <kfogel> mrevell: https://dev.launchpad.net/Running (just created, review welcome)
[15:51] <herb> jml: actually
[15:51] <gary_poster> heh, cool
[15:51] <kfogel> mrevell: I also modified the top-level Getting page to refer out to Running and Help now.
[15:51] <herb> jml: let me approach it this way
[15:52] <herb> jml: in one way or another we use the following targets in production: build, static, start, initscript-start, stop, shutdown
[15:52] <jml> herb, and that list is complete?
[15:53] <mrevell> kfogel: makes sense
[15:53] <mrevell> kfogel: will look at running
[15:53] <herb> jml: don't hold me to that.
[15:53] <beuno_> mars, intellectronica, rockstar, noodles775, AJAX in 10?
[15:53] <jml> herb, fair enough :)
[15:53] <rockstar> beuno, yessir.
[15:53] <noodles775> beuno: yup.
[15:53] <herb> jml: I would say that covers 99.9% of the cases.
[15:53] <jml> herb, certainly, knowing what the public interface of our Makefile is helps a lot :)
[15:53] <herb> jml: but I didn't go out and check every server.
[15:53] <jml> herb, np. thanks for checking :)
[15:54] <herb> jml: welcome
[15:54] <intellectronica> beuno: yes
[15:54] <kfogel> mrevell: is there a single, canonical page for Karmic anywhere?  I see www.ubuntu.com/testing/karmic/alpha2 and .../alpha3, and various other pages, but I don't see a single "this is what Karmic is" page
[15:55] <mars> beuno, yep
[15:55] <mrevell> kfogel: https://wiki.ubuntu.com/KarmicKoala ?
[15:55] <kfogel> mrevell: perfect, thank you
[16:02] <AdamDH> Hey, I did a bzr co lp:launchpad but I cannot see the Soyuz source or Codehosting source code? Any ideas where this is?
[16:02] <noodles775> AdamDH: ./lib/lp/soyuz ?
[16:03] <jml> ./lib/lp/codehosting
[16:03] <intellectronica> beuno: are you leading?
[16:03] <beuno> intellectronica, I am. trying to hang up another call
[16:03] <mrevell> kfogel: I'll PM you some comments.
[16:04] <intellectronica> beuno: just offer whoever is on the line to listen to some really great, relaxing music for a bit ;)
[16:04] <beuno> heh
[16:04] <kfogel> mrevell, jml: a thought -- I'm editing https://dev.launchpad.net/PatchSubmission right now, and it says for pre-implementation discussion, contact the on-call help person in #launchpad.  That doesn't seem quite right; better to just come into #launchpad-dev and talk to someone here, no?
[16:05] <mrevell> kfogel: That certainly seems to make better sense to me. I think we're providing pretty good coverage in here.
[16:05] <intellectronica> kfogel: nor neither. the best thing to do is to come to #launchpad-reviews and talk to the ocr
[16:05] <jml> kfogel, agreed.
[16:05] <kfogel> intellectronica, jml: even better, thank you
[16:06] <kfogel> mrevell: ^^ intellectronica and jml told us where to go, sha-ZZAM
[16:06] <mrevell> aha
[16:06] <mrevell> :)
[16:06] <AdamDH> noodles775: thanks did not see it in there
[16:08] <maxb> PatchSubmission could also use some clarification about what to do for small obvious fixes - e.g. a three line fix for buildmailman.py - you can't have a pre-imp discussion when you don't know the change you'll be making until you've researched a bug
[16:09] <mars> beuno, still around?
[16:09] <beuno> mars, almost dialing in, sorry
[16:10] <beuno> dialing
[16:22] <allenap> BjornT: stub has commented on bug 253242 that he's planning on pruning bugnotification soon. wgrant pointed out to him in the bug referenced that perhaps we (bugs) want to use that data first. Do you have an idea what the value of this data is? Should we ask him for a dump or an archived copy before it's gone for good?
[16:22] <mup> Bug #253242: Fill in the gaps in the activity log using data from bug notifications <bughistory> <feature> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/253242>
[16:23] <mars> Guest36657, AJAX call?
[16:30] <mars> EdwinGrubbs, joining the call?
[16:31] <BjornT> allenap: yeah, dumping the data would be a good idea.
[16:31] <allenap> BjornT: Okay.
[16:31] <allenap> BjornT: I'll comment on the bug.
[16:31] <BjornT> thanks
[16:36] <mars> beuno, intellectronica, ah!  Forgot to settle next steps for the UI/QA experiment
[16:37] <mars> we really should close that out formally
[16:37] <mars> is was successful, right? :)
[16:38] <intellectronica> mars: it will be especially interesting in light of our qa team changing. it might mean the qa people can be even more on hand
[16:38] <intellectronica> mars: yes, from my experience i can say it was successful
[16:39] <mars> intellectronica, would you mind writing a mail to the list saying "It works!  Here's how we did it!"
[16:39] <mars> ?
[16:39] <mars> It would lend closure
[16:40] <EdwinGrubbs> mars: I'll call in now. I thought I had already missed the meeting entirely.
[16:40] <mars> and let us start talking about the next steps
[16:40] <intellectronica> mars: sure, i can do that
[16:40] <mars> EdwinGrubbs, nm, we wrapped it up at 11:35
[16:41] <intellectronica> mars: b.t.w one thing we still haven't figured out is how to track the results. we currently use the team's test plan, but we find it very inconvenient
[16:43] <mars> intellectronica, you should include that problem at the end of the experiment summary.  It might start some discussion.
[16:43] <mars> "It works!", "Here's what we did", "Here's what didn't work so well"
[16:43] <mars> :)
[16:52] <kfogel> I want to do a search for all open-and-unstarted bugs that affect Launchpad that have the 'trivial' tag.  But Launchpad isn't just one component; it's many components.  How to do this search?
[16:52] <kfogel> I tried https://bugs.edge.launchpad.net/launchpad/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.omit_dupes.used=&field.omit_dupes=on&field.h
[16:52] <kfogel> as_patch.used=&field.has_cve.used=&field.tag=trivial&field.tags_combinator=ANY&search=Search
[16:52] <kfogel> but that brought zero results.
[16:54] <kfogel> jml: ^^, and note if I do the same without the 'trivial' tag, I get 58 results.
[16:55] <jml> launchpad-project
[16:55] <jml> kfogel, launchpad-project is the conglomeration of all launchpad components.
[16:55] <jml> (sorry)
[16:56] <kfogel> jml: thanks
[16:56] <kfogel> jml: how did we make that magic happen?  Is it one of those special encapsulating projects ("project groups") that some admin has to create/
[16:56] <kfogel> ?
[16:58] <jml> kfogel, yes, that.
[16:59] <kfogel> jml: thanks
[17:08] <kfogel> mrevell: please see front page and critique away
[17:08]  * mrevell looks
[17:10] <mrevell> kfogel: Looks good! Is the line "This wiki is new and we're still moving information to it from other places:" misplaced?
[17:10] <beuno> mrevell, I promise to reply to your email today
[17:10] <mrevell> beuno: thanks man :)
[17:10] <kfogel> mrevell: oh wow, forgot about that line
[17:11] <kfogel> mrevell: killing it now
[17:11] <beuno> mrevell, don't thank me until I follow through  ;)
[17:11] <kfogel> mrevell: since it will always be true, there is no need to say it
[17:12] <mrevell> kfogel: joey was keen to see a section where we link to an overview page for each team. I've actually got that as a bug assigned to me. I guess we should leave it to each TL as to what they want on their team overview page.
[17:12] <kfogel> mrevell: that's the part right under the top table now
[17:12] <kfogel> mrevell: I was just noticing how some of the pages need to be filled in.
[17:13] <mrevell> kfogel: Is it, though? I mean, we don't have a Blueprint team and that's listed there. I suppose the question is: is it worth distinguishing, on the front page, between "parts" of Launchpad the software and the make-up of the Canonical development team?
[17:14] <kfogel> mrevell: IMHO we should concentrate on parts of Launchpad -- that's how it looks to the community.  Our internal division into teams, while not completely irrelevant to the dev community, is much less important than the architecture of Launchpad itself (particularly since in practice, people from one team often help out with bugs in some other area).
[17:17] <mrevell> kfogel: Perhaps could you take a look at the description of bug 391666 ?
[17:17] <mup> Bug #391666: Please list Launchpad Teams on dev.lp.net's front page <cleanup> <launchpad-team> <trivial> <Launchpad Documentation:Triaged by matthew.revell> <https://launchpad.net/bugs/391666>
[17:18] <kfogel> mrevell: looking
[17:19] <jtv> herb: hi!  Can I just badger you some more?
[17:20] <herb> jtv: sure.
[17:20] <kfogel> mrevell: commented there
[17:21] <mrevell> kfogel: Perhaps a CanonicalTeams page. Let me try something.
[17:21] <kfogel> jml: do you have any idea what that project group is called "launchpad-project" instead of "launchpad"?  The latter would be more natural.
[17:21] <kfogel> mrevell: should this be a high priority, anyway?  It doesn't seem that important to me, compared with the other things we need in the dev wiki.
[17:22] <jml> kfogel, historical reasons, I think. ISTR mpt doing a lot of thinking about this a while back
[17:22] <kfogel> If it's fast to do -- i.e., a simple page with links to the https://launchpad.net/~TEAM pages -- then sure.
[17:22] <kfogel> jml: *nod*
[17:22] <kfogel> jml: uh, I'll add that to my stack of questions to ask on list
[17:22]  * kfogel notices the bottom of the stack starting to spontaneously combust from the pressure
[17:24] <jtv> herb: did you get my requests for script runs on staging?
[17:25] <herb> jtv: yes. saw the emails to losas@. haven't had a chance to jump on the requests yet. will soon.
[17:26] <jtv> herb: great, thanks.  It's late night here... could you email me with the output?  A bit impersonal, but...
[17:26] <herb> jtv: will do
[17:27]  * jtv ไว่s herb
[17:27] <kfogel> beuno: https://bugs.edge.launchpad.net/launchpad/+bug/408470
[17:27] <mup> Bug #408470: "offer to mentor this work" line repeated on mentoring page <Launchpad itself:New> <https://launchpad.net/bugs/408470>
[17:27]  * beuno looks
[17:31] <mpt> kfogel, jml: In the past projects used to be called "products", and project groups were called "projects". (They still have the old names in the database schema.)
[17:31] <jtv> herb: if what I just wrote doesn't make sense to you, it's because I mis-spelled it.  I meant ไหว้, not ไว่
[17:31] <mpt> kfogel, I think kiko gave launchpad-project its ID.
[17:31] <kfogel> beuno: do you see it too?
[17:32] <mpt> kfogel, I would much prefer that bug tagging was improved enough that we didn't need separate Launchpad projects at all.
[17:32] <kfogel> mpt: well, before I go too far down this road, here's what I tried to do: I was searching for a bug (or maybe reporting one and in the dup-search stage?) and I put "launchpad-project" as the group, and that turned out to be invalid.  :-(
[17:32] <kfogel> mpt: ah, we were typing at the same time.  Yes, that's exactly the problem.
[17:32] <beuno> kfogel, yes
[17:32] <mpt> yes, you can't report a bug on a project group
[17:32] <mpt> though you can search for them
[17:32] <kfogel> beuno: I'll bet you can fix that in thirty seconds, man :-).
[17:33] <kfogel> (beuno: whereas it would take me all of two minutes!)
[17:33] <mpt> If you click "Report a bug" on bugs.launchpad.net/launchpad-project the first thing you'll be asked is to choose which project
[17:33] <kfogel> mpt: :-(
[17:33] <beuno> kfogel, yes, I agree that sinzui can fix it in 15 seconds
[17:33] <kfogel> mpt: so in one context, we should type "launchpad-project", and in another we should type "launchpad", even though they're semantically basically the same thing.
[17:33] <kfogel> beuno: niiiiiice
[17:34] <kfogel> mpt: "they" being the two contexts, I mean
[17:34]  * sinzui reads scrollback
[17:34] <kfogel> sinzui: bug #408470
[17:34] <mup> Bug #408470: "offer to mentor this work" line repeated on mentoring page <Launchpad itself:New> <https://launchpad.net/bugs/408470>
[17:34] <mpt> kfogel, yes, it's all a workaround for Launchpad having poor categorization of bug reports in large projects
[17:34] <kfogel> mpt: I see and am not shocked.
[17:39] <sinzui> beuno: this is one of this issues I reported in my email several weeks ago. The form (view) and the template are both setting headings. This will be fixed the bug team need to fix this since 2008-03-05
[17:39] <beuno> kfogel, there you go
[17:40] <beuno> under 15 seconds
[17:40] <sinzui> beuno: kfogel: The bug's team will have a change to fix this when they update the template to main_only
[17:40] <kfogel> sinzui: was there already a bug on this?
[17:41] <sinzui> kfogel: search /malone
[17:42] <sinzui> kfogel: I only understand the problem, I just uses blame to see when the error was introduces
[17:44] <kfogel> sinzui: bug #317589
[17:44] <mup> Bug #317589: "Offer to mentor this work" heading is repeated <trivial> <ui> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/317589>
[17:44] <kfogel> sinzui: and I failed to find it because of precisely the problem mpt and I were just discussing :-).
[17:46] <sinzui> kfogel: when I search for a bug that I do not know the domain, I search launchpad-project which is the project group for everything we can change: https://bugs.edge.launchpad.net/launchpad-project?field.searchtext=mentoring+heading&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%
[17:51] <jml> I can't submit via ec2test :(
[17:52] <sinzui> kfogel: beuno-lunch: mpt: matsubara-lunch: Do we want to ask an admin to: 1) rename launchpad => launchpad-old. 2) rename launchpad-project => launchpad 3) add the launchpad-project alias to launchpad. QA will then triage all bugs that belong to the project.
[17:52] <jml> socket.gaierror: (-2, 'Name or service not known') during delete_previous_key_pair
[17:55] <jml> http://paste.ubuntu.com/246454/
[17:55] <jml> gary_poster, is there anything I can do to work around this, or at least get more info?
[17:56] <matsubara> sinzui, why do you want to do that?
[17:56] <mpt> sinzui, I'm not sure that would solve kfogel's problem. Depends on whether he searched first, or relied on the dup-finder.
[17:56] <mpt> Anyway, it wouldn't solve the problem for people who *do* rely on the dup-finder.
[17:57] <sinzui> matsubara: I think kfogel would have not files a duplicate bug if he could have found the original bug. launchpad only exists to triage bugs, so users probably never find the bug they want investigate unless they know how launchpad is structured
[17:58]  * sinzui is really upset the the 'd' key keeps moving on his keyboard
[17:59] <gary_poster> jml: never seen this before.  I assume you agree that it looks vaguely like a network connection to AWS is broken or flaky somewhere along the line.  I would just need to dig into boto myself.
[17:59] <matsubara> sinzui, I think we need to fix bug 174443 instead of doing the rename
[17:59] <mup> Bug #174443:  	Better duplicate searching in Launchpad's own projects <dupefinder> <feature> <Launchpad Answers:Triaged> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/174443>
[17:59] <jml> gary_poster, james_w just diagnosed it for me
[17:59] <gary_poster> jml: and digging into boto would probably just verify that the broken socket is to AWS.  I'd hopefully see precisely what the address was, but not sure where I'd go from there
[18:00] <jml> gary_poster, my hardy chroot has a dodgy resolv.conf.
[18:00] <gary_poster> jml: ah, ok.  cool
[18:00] <jml> (and the socket module raises shitty errors, making it harder to diagnose.)
[18:00] <jml> gary_poster, thanks.
[18:00] <gary_poster> np
[18:00] <gary_poster> agree on socket module errors :-/
[18:00] <sinzui> matsubara: but the duplicate work in this case. kfogel did not know that launchapd is NOT a PROJECT.
[18:00] <jml> it's a general Python problem, saying the error but not providing enough data about the objects involved
[18:01] <sinzui> We suck for creating a project that we would NEVER approve if it was made by someone else.
[18:01] <gary_poster> agree
[18:04] <rockstar> beuno-lunch, can I have you take a look at: https://code.edge.launchpad.net/~rockstar/launchpad/codereview-js/+merge/9587
[18:05] <sinzui> I am so very tempted to spend my weekends to put wiki markup in in blueprints so that I never have to use moin again.
[18:10] <kfogel> sinzui: I if one could a) file a bug against 'launchpad' even when it's a project group, and b) have 'launchpad' work in the dup finder when filing, then your plan would be good.  The fact that the dup finder does not search the same domains as search is very problematic.
[18:11] <sinzui> kfogel: as the link I pasted showed, in your case it did work You did not know that 'launchpad' is QA's bug holding project. The real project is named launchpad-project
[18:12] <kfogel> sinzui: I'm on a call, back in a sec (had trouble understanding what you're telling me, but unable to formulate the right question right now)
[18:14] <beuno-lunch> rockstar, yes, right after lunch, I'll take that on
[18:14] <beuno-lunch> I think today is UI review day, I have like 6 of them in queue
[18:15] <mrevell> see you tomorrow guys.
[18:33] <gary_poster> BjornT: ping.  I have someone who is getting timeouts when trying to use https://bugs.edge.launchpad.net/bugs/+filebug (specifically, after pressing Continue).  I tried it, and while it didn't give me a timeout error, it was pretty slow if you just type in "Testing" in the Summary, and press Continue without filling anything else out.  Is this a known bug I can report?
[18:34] <gary_poster> BjornT: On the same page, when I try to use the Package chooser and search for "bug" then I get "Loading results failed".
[18:35] <JamalFanaian> i'm trying to create a unittest but i'm having issues.. i have created a person object using the LaunchpadObjectFactory makePerson method, but I can't figure out a decent way to create karma records for that person using the factory.. would someone be willing to help me a bit with that?
[18:39] <ia> hello. since LP has been "open sourced", should 3rd party users/developers count on packaging debs of LP (by Canonical Launchpad Engineering team, i guess) in the near future?
[18:40] <jml> ia, no. :)
[18:40] <elmo> (I like the "scare" quotes, btw)
[18:40] <jml> ia, we're all busy making Launchpad better.
[18:42] <BjornT> gary_poster: we already have a bug for it. the search for duplicates sometimes times out, and it's not easy to fix.
[18:42] <gary_poster> BjornT: ok thank you
[18:43] <gary_poster> BjornT: do you happen to know anything about the ubuntu-bug command line application?  I have someone on IRC who wants to report a bug about it, but neither he nor I can find it in Launchpad.
[18:44] <gary_poster> leonardr: ^^
[18:45] <elmo> gary_poster: https://launchpad.net/ubuntu/+source/apport
[18:45] <gary_poster> elmo: thank you!
[18:47] <rockstar> sinzui, hi
[18:47] <sinzui> hello
[18:47] <rockstar> sinzui, do you think I could have a pre-imp call with you re: javascript error handling and 3.0?
[18:48] <sinzui> sure. I know nothing about either of these issues, but I have opinions if you are willing to listen to me
[18:48] <rockstar> sinzui, well, you know most about 3.0, and mars and I have already had a few discussions about this.
[18:50] <mars> rockstar, sinzui has been doing web work for over a decade, so I trust his opinions :)
[18:50] <sinzui> rockstar: That is a common misunderstanding. I am trying to make the pictures that beuno shows me to work in the code. I do not know what any page should look like. I personally want to know what can go in the side portlets and what they look like
[18:51] <sinzui> rockstar: I am ready for a call when ever you are ready
[18:53] <rockstar> sinzui, what is your skype id?
[18:54] <sinzui> rockstar: curtis.hovey
[18:56] <salgado> kfogel, I think https://answers.edge.launchpad.net/launchpad/+faq/195 needs to be updated. ;)
[18:58] <kfogel> salgado: done; thanks
[18:59] <gary_poster> deryck: you are on the bugs team, right? :-)  A user put some primate information (his email signature) in a bug comment.  Is the only way to change this to go to a losa, or is there some other approach?
[18:59] <gary_poster> lol, s/primate/private/
[18:59] <gary_poster> <ooka ooka>
[19:00] <deryck> heh
[19:00] <deryck> monkeys in the system, no!
[19:00] <gary_poster> :-)
[19:01] <deryck> gary_poster, yeah, if it's in the comment, there's no way that I know of except to edit the comment or have a LOSA hide the comment.
[19:01] <deryck> gary_poster, anyone with admin privileged on lp can hide the comment because that is exposed in the API now.
[19:01] <deryck> gary_poster, can hide it with a script, rather.
[19:02] <gary_poster> deryck: so the only way out is database skuduggery?  oh, ok.  I'll ask the user if that's what they want then.  thank you!
[19:02] <mars> or curl, perhaps? :)
[19:02] <deryck> gary_poster, yeah, two options -- db work or run a script to hide the comment.
[19:03] <gary_poster> deryck: ok cool thanks.
[19:04] <sinzui> "There are monkeys in the palace" was a call sign at Time Life when someone misconfigured products in the database.
[19:04] <deryck> heh
[19:04] <gary_poster> :-)
[19:05] <deryck> gary_poster, I wonder if that isn't an exercise in futility ultimately, though -- Google cache or any other web archive may have picked up the person's data and make cleaning LP pointless, no?
[19:06] <gary_poster> deryck: perhaps so, but using that as a customer service reason for not doing anything strikes me as unfriendly at best, don't you think?
[19:07] <deryck> gary_poster, oh, yeah, I'm not against helping. :)  I think the user should be warned, though, that this data has been compromised and not believe that simply hiding the comment fixes the potential problem.
[19:07] <gary_poster> deryck: cool, agree
[19:08] <deryck> gary_poster, cool :)
[19:10]  * rockstar goes to lunch
[19:11] <mars> sinzui, btw, something I thought might enjoy reading, when you have a moment: http://www.inc.com/magazine/20090701/joel-spolsky-the-day-my-industry-died.html
[19:13] <sinzui> mars: you fiend! How can I ignore this article now that you have shown it to me? The new project layout cannot be finished until my reading is complete.
[19:13] <mars> well, it's a short read...
[19:14]  * beuno stabs mars 
[19:14] <beuno> don't distract sinzui!
[19:14] <mars> ow!
[19:15] <beuno> :)
[19:15] <sinzui> beuno: <as I look up from the article> is there are final picture of what side portlets should look like? Should we be showing the translation's involvement link if the project does not use translations.
[19:16] <mars> lol
[19:16] <beuno> sinzui, we should not
[19:16] <sinzui> good, I already coded it that way
[19:17] <beuno> sinzui, if only you weren't already married...
[19:17] <sinzui> my wife is very jealous woman.
[19:18] <beuno> can't have everything in life I guess...
[19:19] <sinzui> beuno: I have two answers sections to complete then I can take some screen shots. I am also struggling with the YUI first class. it is does not behave well when it is used around a portlet that the template call.
[19:20]  * sinzui is looking for a recipie to make the template and th portlet simple
[19:21] <beuno> sinzui, can you cheat using firebug to send me the screenshots?
[19:21] <beuno> I'm currently reviewing rockstar's branch
[19:21] <beuno> but I won't leave my desk today until I've done all UI reviews on my plate
[19:26] <sinzui> beuno: the first class must be on the portlet div, which means all templates that use it must always use it as first (left) portlet. The solution is to only use yui layout classes in the template that makes the page.
[19:26]  * sinzui play with this a bit more before declaring defeat
[19:40] <sinzui> beuno: we use the term "mugshot" for user images. Should we use that term instead of "branding" in links to update the small, medium, and large images?
[19:41] <beuno> sinzui, I don't think that's a very well understood term
[19:41] <beuno> "update pictures"?
[19:42] <sinzui> okay. I agree that mugshot is not clear. (nor was hackergotchi)
[19:43] <sinzui> beuno: I propose that I update the form to state where we will use the images.
[19:43] <beuno> sinzui, I saw, and it's a fantastic idea
[19:46] <sinzui> beuno: Is this the "Get involved" presentation you expect to see?
[19:46] <sinzui> https://devpad.canonical.com/~curtis/LP_projectdetail.png
[19:47] <beuno> sinzui, yes. The icons weren't a great idea
[19:48] <sinzui> thanks
[19:54] <BjornT> beuno: what is the "bug root page"? (talking about pages to be redesigned for 3.0)
[19:56] <JamalFanaian> salgado: hey, do you have another min? i'm terribly sorry that i've been such a pester today.. just trying to get my head around the way factories work :\
[19:57] <salgado> JamalFanaian, sure, what's up?
[19:57] <beuno> BjornT, bugs.lp.net/project
[19:57] <beuno> BjornT, I had no idea how to refer to it  :)
[19:57] <JamalFanaian> salgado: well i'm trying to figure out how to create a karmacache record using the factory.. i've got a unittest that is able to create a person object and set up the PersonView
[19:58] <JamalFanaian> I tried defining a makeKarmaCache method in the factory that just creates a KarmaCache object that I can then pull up when person.getProjectsAndCategoriesContributedTo() gets called
[19:58] <JamalFanaian> but I can't actually get the KarmaCache record to be created correctly..
[19:58] <JamalFanaian> i'm guessing i'm just doing it wrong, so i just wanted to see if you could give me a few pointers of where to look
[19:59] <BjornT> beuno: ok, i suspected it was that one :)
[19:59] <salgado> JamalFanaian, sure, do you get any errors when creating the KarmaCache record?  Can I have a look at the diff?
[20:00] <JamalFanaian> salgado: let me create a diff, but i get an error when i try to call transaction.commit() after creating the karmacache record, not sure if i need to commit or not
[20:02] <salgado> JamalFanaian, can you paste the error too?
[20:02] <JamalFanaian> salgado: sure thing
[20:03] <JamalFanaian> http://pastebin.com/f3627c1e6 -- this is my changes.. i created a simplified sql query to test if the data was even in there..
[20:04] <JamalFanaian> salgado: here is the test execution with errors http://pastebin.com/f1f8fbe6
[20:04] <JamalFanaian> salgado: woops ignore that last link ;0
[20:04] <JamalFanaian> ;)*
[20:06] <JamalFanaian> salgado: http://pastebin.com/f31c00a8 this would be the correct one
[20:08] <salgado> JamalFanaian, that's because the db user used on the web app (the same one that's used for tests) is not allowed to insert rows on the KarmaCache table
[20:09] <salgado> that's becasue that table is maintained by a script, so only that script's DB user can insert on that table
[20:09] <JamalFanaian> salgado: ah, ok i understand..
[20:10] <JamalFanaian> salgado: so is my option to try to get that insert query to run as the cron DB user? or am i taking a completely wrong approach at this?
[20:12] <salgado> JamalFanaian, I think it's OK to change the new factory method to do the insert as a dbuser that can write to that table
[20:13] <salgado> that dbuser would be config.karmacacheupdater.dbuser
[20:13] <salgado> but I'll have to look up how to get the existing connection to use that user
[20:14] <JamalFanaian> salgado: that's beyond my comprehension of the system so far lol
[20:17] <salgado> JamalFanaian, I don't think we have good infrastructure for switching the db user in factory methods, so I suggest you do the following
[20:17] <salgado> 1. move your new factory method as a helper method of your test class
[20:18] <salgado> 2. there you can use LaunchpadZopelessLayer.switchDbUser(dbuser) before creating the KarmaCache entries, and change it back afterwards
[20:19] <JamalFanaian> salgado: let me try that then, thank you so much for your time and assistance
[20:19] <salgado> 3. email launchpad-dev@lists.launchpad.net asking if there's any way to turn that test helper into a factory method
[20:20] <salgado> JamalFanaian, don't forget the 3rd step, that's the most important one. ;)
[20:23] <JamalFanaian> salgado: I won't :).. Should I do that after I commit the branch so I can show them? Or just post the diff in the email
[20:27] <salgado> JamalFanaian, just the diff is fine